自己公司的产品，基于TencentOS tiny物联网操作系统；感谢TencentOS 官方公众号转发助力；以下为正文： 近年来，公共交通、快递运输、大型会议场馆会务等复合型服务业随着国民经济的快速发展，需求暴增，同时也暴露出来许多问题。如快递沦为一些不法分子犯罪的新渠道，快递网络正成为管制刀具、枪支弹药、易燃易爆品、危险化学品的运输流通渠道。公共交通和公共场所安检排查工作日益复杂，缺乏高效的违禁炸药、毒品等物质的检测手段，导致安检效率偏低。 随着反恐形势的不断升温，依靠科技手段提升安检排爆能力成为世界各国共同面对的重要课题。从技术原理上，安检排爆技术大致可以分为体检测和痕迹检测两种技术路径。体检测方法主要依靠如X射线，太赫兹，毫米波等技术通过成像等手段对人，物，车辆等进行安全检查；痕迹检测则是通过对待测目标挥发出的微痕量残留炸药等违禁品进行检测的技术。两类技术通常配合使用，以实现多个维度精准锁定违禁品。 基于这些背景，TencentOS Tiny 助力合作伙伴砺剑防卫打造了一套便携式的智能化高速安检设备。该设备融合了高速荧光检测技术、云端智能判图等多种融合违禁品检测技术。设备如下图： 危险物品的荧光传感薄膜探测原理 荧光淬灭痕迹炸药探测技术是痕迹检测领域的热点技术。相较于传统的IMS（离子迁移谱）技术，荧光淬灭拥有诸多优良性能。首先，荧光淬灭技术无需电离过程，所以操作便捷，体积小、重量轻、开机快、响应快、清洗快；其次，基于前端聚合物优良的“分子导线”效应，荧光淬灭传感器通常拥有更高的探测灵敏度；再者，相对于IMS模板库匹配的检测原理，荧光淬灭技术对混合炸药，土制炸药检测性能优良，实战性更强。基于这些优势，荧光痕量炸药探测器已经广泛运用在警卫安保，轨道交通，大型活动等重要安检排爆工作中。 手持式智能安检探测仪软硬件方案 手持式智能安检探测仪的应用 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

来源：https://segmentfault.com/a/1190000038292644 前言 我们经常会讨论这样的问题：什么时候数据存储在堆栈 (Stack) 中，什么时候数据存储在堆 (Heap) 中。我们知道，局部变量是存储在堆栈中的；debug 时，查看堆栈可以知道函数的调用顺序；函数调用时传递参数，事实上是把参数压入堆栈，听起来，堆栈象一个大杂烩。那么，堆栈 (Stack) 到底是如何工作的呢？本文将详解 C/C++ 堆栈的工作机制。阅读时请注意以下几点： 1）本文讨论的编译环境是 Visual C/C++，由于高级语言的堆栈工作机制大致相同，因此对其他编译环境或高级语言如 C# 也有意义。 2）本文讨论的堆栈，是指程序为每个线程分配的默认堆栈，用以支持程序的运行，而不是指程序员为了实现算法而自己定义的堆栈。 3)  本文讨论的平台为 intel x86。 4）本文的主要部分将尽量避免涉及到汇编的知识，在本文最后可选章节，给出前面章节的反编译代码和注释。 5）结构化异常处理也是通过堆栈来实现的(当你使用 try…catch 语句时，使用的就是  c++ 对 windows 结构化异常处理的扩展)，但是关于结构化异常处理的主题太复杂了，本文将不会涉及到。 从一些基本的知识和概念开始 1) 程序的堆栈是由处理器直接支持的。在 intel x86 的系统中，堆栈在内存中是从高地址向低地址扩展（这和自定义的堆栈从低地址向高地址扩展不同），如下图所示：  因此，栈顶地址是不断减小的，越后入栈的数据，所处的地址也就越低。 2) 在 32 位系统中，堆栈每个数据单元的大小为 4 字节。小于等于 4 字节的数据，比如字节、字、双字和布尔型，在堆栈中都是占 4 个字节的；大于 4 字节的数据在堆栈中占4字节整数倍的空间。 3) 和堆栈的操作相关的两个寄存器是 EBP 寄存器和 ESP 寄存器的，本文中，你只需要把 EBP 和 ESP 理解成 2 个指针就可以了。ESP 寄存器总是指向堆栈的栈顶，执行 PUSH 命令向堆栈压入数据时，ESP减4，然后把数据拷贝到ESP指向的地址；执行POP 命令时，首先把 ESP 指向的数据拷贝到内存地址/寄存器中，然后 ESP 加 4。EBP 寄存器是用于访问堆栈中的数据的，它指向堆栈中间的某个位置（具体位置后文会具体讲解），函数的参数地址比 EBP 的值高，而函数的局部变量地址比 EBP 的值低，因此参数或局部变量总是通过 EBP 加减一定的偏移地址来访问的，比如，要访问函数的第一个参数为 EBP+8。 4) 堆栈中到底存储了什么数据？包括了：函数的参数，函数的局部变量，寄存器的值（用以恢复寄存器），函数的返回地址以及用于结构化异常处理的数据（当函数中有 try…catch 语句时才有，本文不讨论）。这些数据是按照一定的顺序组织在一起的， 我们称之为一个堆栈帧（Stack Frame）。一个堆栈帧对应一次函数的调用。在函数开始时，对应的堆栈帧已经完整地建立了（所有的局部变量在函数帧建立时就已经分配好空间了，而不是随着函数的执行而不断创建和销毁的）；在函数退出时，整个函数帧将被销毁。 5) 在文中，我们把函数的调用者称为 caller（调用者），被调用的函数称为callee（被调用者）。之所以引入这个概念，是因为一个函数帧的建立和清理，有些工作是由 Caller 完成的，有些则是由 Callee 完成的。 开始讨论堆栈是如何工作的 我们来讨论堆栈的工作机制。堆栈是用来支持函数的调用和执行的，因此，我们下面将通过一组函数调用的例子来讲解，看下面的代码： int foo1(int m, int n){ int p=m*n;    return p;}int foo(int a, int b){    int c=a+1;        int d=b+1;        int e=foo1(c,d);        return e;}int main(){    int result=foo(3,4);    return 0;} 这段代码本身并没有实际的意义，我们只是用它来跟踪堆栈。下面的章节我们来跟踪堆栈的建立，堆栈的使用和堆栈的销毁。 堆栈的建立 我们从main函数执行的第一行代码，即 int result=foo(3,4); 开始跟踪。这时 main 以及之前的函数对应的堆栈帧已经存在在堆栈中了，如下图所示： 图1 参数入栈  当 foo 函数被调用，首先，caller（此时caller为main函数）把 foo 函数的两个参数：a=3,b=4 压入堆栈。参数入栈的顺序是由函数的调用约定 (Calling Convention) 决定的，我们将在后面一个专门的章节来讲解调用约定。一般来说，参数都是从右往左入栈的，因此，b=4 先压入堆栈，a=3…

本文介绍了如何解决STM32芯片Flash写保护导致无法下载程序，无法在线调试的问题；如果您遇到相同的问题，希望本文可以带来一些帮助； 1 FLASH的写保护 如果对Flash设置了写保护，那就无法对Flash进行编程和擦除。 在开发STM32的时候，如果出现这种情况，通常仿真器都支持对Flash进行解锁，像jlink，stlink等仿真器都支持这个功能。 2 错误提示 在使用MDK进行调试的时候，出现报错 ==Flash Timeout.Reset Target and try it again==，具体如下图所示； 折腾了一番之后，并没有解决问题，因为使用的仿真器是stlink，因此下载了stlink utility尝试解决问题； 3 stlink utility 3.1 基本功能 stlink utility是ST官方提供的免费软件，支持STM32 ST-LINK的程序包括带有命令行界面（CLI）的图形用户界面（GUI）。该工具还提供了较多的其他功能，具体如下； 可以对STM32 内部存储器 （Flash，RAM，OTP和其他存储器）， 外部存储器进行编程； 验证程序内容（校验和，在编程期间和之后进行校验，与文件进行比较等） 还能实现 STM32编程自动化； 另外还提供其他的功能； 3.2 解锁Flash 在stlink连接目标板的情况下，打开stlink utility，在菜单栏的Target下选择connect，因为这时候Flash已经被锁住了，所以同样地也看到相应的错误提示 Can not read memory Disable Read Out Protection and retry，具体如下图所示； OK，下面只需要接触写保护就行了，所以在菜单栏target里打开Option Bytes…选项，或者直接通过快捷键ctrl+B打开，请确保当前已经正确连接了stlink和目标板，否则会出现报错； 正确连接的情况下，打开Option Bytes…，发现在这里Read Out Protection选项是enable，这个表示无法通过swd读取STM32内部Flash的程序。 关键点：将Read Out Protection选项设置为disable，点击Apply，这时候Flash已经成功解锁了。但是同时发现，内部Flash已经被擦除了； 这可能STM32的保护机制有关，防止程序被拷机，然后进行反编译破解，这样也可以提高破解的门槛。具体显示如下图所示； 完成以上步骤之后，在菜单栏Target下选择Disconnect，或者通过快捷键ctrl+D断开和目标板的连接；重新进入MDK，就能正常对目标板进行调试，仿真，以及程序的烧写。 3.3 写保护 在菜单栏target里打开Option Bytes…选项，我们还看到下面有Flash sector protection选项；选择Select all之后，发现所有Page都已经写保护了，只要选择apply选项就可以对Flash进行写保护；具体如下所示； 4 总结 对于Flash写保护的问题可以结合STM32参考手册进行相应的学习，其内部Flash提供相应的保护机制，本文只是结合ST官方工具stlink utility解决一下常见的这个简单的问题。 笔者能力和水平有限，文中难免有错误和纰漏之处，请大佬们不吝赐教； – END – 推荐好文   点击蓝色字体即可跳转  全网最通俗易懂SPWM入门教程，快来白嫖  天哪！原来PWM这么简单  PID微分器与滤波器的爱恨情仇  简易PID算法的快速扫盲 增量式PID到底是什么？ 三面大疆惨败，因为不懂PID的积分抗饱和 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

1.说说Spring 里用到了哪些设计模式? 单例模式：Spring 中的 Bean 默认情况下都是单例的。无需多说。 工厂模式：工厂模式主要是通过 BeanFactory 和 ApplicationContext 来生产 Bean 对象。 代理模式：最常见的 AOP 的实现方式就是通过代理来实现，Spring主要是使用 JDK 动态代理和 CGLIB 代理。 模板方法模式：主要是一些对数据库操作的类用到，比如 JdbcTemplate、JpaTemplate，因为查询数据库的建立连接、执行查询、关闭连接几个过程，非常适用于模板方法。 2.谈谈你对IOC 和 AOP 的理解？他们的实现原理是什么？ IOC 叫做控制反转，指的是通过Spring来管理对象的创建、配置和生命周期，这样相当于把控制权交给了Spring，不需要人工来管理对象之间复杂的依赖关系，这样做的好处就是解耦。在Spring里面，主要提供了 BeanFactory 和 ApplicationContext 两种 IOC 容器，通过他们来实现对 Bean 的管理。 AOP 叫做面向切面编程，他是一个编程范式，目的就是提高代码的模块性。Srping AOP 基于动态代理的方式实现，如果是实现了接口的话就会使用 JDK 动态代理，反之则使用 CGLIB 代理，Spring中 AOP 的应用主要体现在 事务、日志、异常处理等方面，通过在代码的前后做一些增强处理，可以实现对业务逻辑的隔离，提高代码的模块化能力，同时也是解耦。Spring主要提供了 Aspect 切面、JoinPoint 连接点、PointCut 切入点、Advice 增强等实现方式。 3. JDK 动态代理和 CGLIB 代理有什么区别？ JDK 动态代理主要是针对类实现了某个接口，AOP 则会使用 JDK 动态代理。他基于反射的机制实现，生成一个实现同样接口的一个代理类，然后通过重写方法的方式，实现对代码的增强。 而如果某个类没有实现接口，AOP 则会使用 CGLIB 代理。他的底层原理是基于 asm 第三方框架，通过修改字节码生成成成一个子类，然后重写父类的方法，实现对代码的增强。 4. Spring AOP 和 AspectJ AOP 有什么区别？ Spring AOP 基于动态代理实现，属于运行时增强。 AspectJ 则属于编译时增强，主要有3种方式： 编译时织入：指的是增强的代码和源代码我们都有，直接使用 AspectJ 编译器编译就行了，编译之后生成一个新的类，他也会作为一个正常的 Java 类装载到JVM。 编译后织入：指的是代码已经被编译成 class 文件或者已经打成 jar 包，这时候要增强的话，就是编译后织入，比如你依赖了第三方的类库，又想对他增强的话，就可以通过这种方式。 加载时织入：指的是在 JVM 加载类的时候进行织入。 总结下来的话，就是 Spring AOP 只能在运行时织入，不需要单独编译，性能相比 AspectJ 编译织入的方式慢，而 AspectJ 只支持编译前后和类加载时织入，性能更好，功能更加强大。 5. FactoryBean 和 BeanFactory有什么区别？ BeanFactory 是 Bean 的工厂， ApplicationContext 的父类，IOC 容器的核心，负责生产和管理 Bean 对象。 FactoryBean 是 Bean，可以通过实现 FactoryBean 接口定制实例化 Bean…

点击蓝字进入亚德诺半导体，然后右上角“设为星标”吧~ 在当今的许多细分市场，交错式模数转换器(ADC)在许多应用中都具有多项优势。在通信基础设施中，存在着一种推动因素，使ADC的采样速率不断提高，以便支持多频段、多载波无线电，除此之外满足DPD（数字预失真）等线性化技术中更宽的带宽要求。在军事和航空航天领域，采样速率更高的ADC可让多功能系统用于通信、电子监控和雷达等多种应用中——此处仅举数例。工业仪器仪表应用中始终需要采样速率更高的ADC，以便充分精确地测量速度更高的信号。 首先，一定要准确地了解交织型ADC是什么。要了解交错，最好了解一下实际发生的情况以及它是如何实现的。有了基本的了解后，再讨论交错的好处。当然，我们都知道，天下没有免费的午餐，因此需要充分评估和验证交织采样相关的技术难点。 关于交错 若ADC为交错式，则两个或两个以上具有固定时钟相位差关系的ADC用来同步采样输入信号，并产生组合输出信号，使得采样带宽为单个ADC带宽的数倍。利用m个ADC可让有效采样速率增加m倍。为简便起见并易于理解，我们重点考察两个ADC的情况。这种情况下，如果两个ADC的每一个采样速率均为fS, 且呈交错式，则最终采样速率为2× fS。这两个ADC必须具有确定的时钟相位差关系，才能正确交错。时钟相位关系由等式1给出，其中：n是某个特定的ADC，m是ADC总数。 举例而言，两个ADC采样速率均为100 MSPS且呈交错式，因此采样速率为200 MSPS。此时，等式1可用来推导出两个ADC的时钟相位关系，如等式2和等式3。 注意，如果已知时钟相位关系，便可确定不同量化值的组合输出。图1以图形说明时钟相位关系，以及两个100 MSPS交织型ADC的样本结构。注意180°时钟相位关系，以及样本是如何交 错的。输入波形也可由两个ADC进行采样。在这种情况下，采用经过2分频的200 MHz时钟输入，并所需的时钟相位发送至每个ADC，便可实现交错。 图1. 两个交错式100 MSPS ADC—基本原理图。 此概念还可以另一种方式表达，如图2所示。通过将这两个100MSPS ADC以交错方式组合，采样速率便能增加至200 MSPS。这样每个奈奎斯特区可以从50 MHz扩展到100 MHz，使工作时的可 用带宽翻倍。增加的工作带宽可为多个市场领域的应用带来诸多优势。无线电系统可以增加其支持的频段数；雷达系统可以增加空间分辨率；而测量设备可以实现更高的模拟输入带宽。 图2. 两个交错式100 MSPS ADC—时钟和样本。 交错的优势 交错结构的优势可惠及多个细分市场。交织型ADC最大好处是增加了带宽，因为ADC的奈奎斯特带宽更宽了。同样，我们举两个100 MSPS ADC交错以实现200 MSPS采样速率的例子。图3显示通过交错两个ADC，可以大幅增加带宽。这为多种应用场景产生了诸多收益。就像蜂窝标准增加了通道带宽和工作频段数一样，对ADC可用带宽的要求也越来越高。此外，在军事应用中，需要更好的空间识别能力以及增加后端通信的通道带宽，这些都要求ADC提供更高的带宽。由于这些领域对带宽的要求越来越高，因此需要准确地测量这些信号。因此，为了正确地获取和测量这些高带宽信号，测量设备也需要更高的带宽。很多设计中的系统要求其实领先于商用ADC技术。交错结构可以弥补这一技术差距。 图3. 两个交织型ADC——奈奎斯特区。 增加采样速率能够为这些应用提供更多的带宽，而且频率规划更轻松，还能降低通常在ADC输入端使用抗混叠滤波器时带来的复杂性和成本。面对这些优势，大家一定想知道需要为此付 出什么代价。就像大多数事情一样，天下没有免费的午餐。交织型ADC具有更高的带宽和其他有用的优势，但在处理交织型ADC时也会带来一些挑战。 交错挑战 在交错组合ADC时存在一些挑战，还有一些注意事项。由于与交错ADC相关的缺陷，输出频谱中会出现杂散。这些缺陷基本上是两个正在交错的ADC之间不匹配。输出频谱中的杂散导致的基本不匹配有四种。包括失调不匹配、增益不匹配、时序不匹配和带宽不匹配。 其中最容易理解的可能是两个ADC之间的失调不匹配。每个ADC都会有一个相关的直流失调值。当两个ADC交错并在两个ADC之间来回交替采样时，每个连续采样的直流失调会发生变化。图4 举例说明了每个ADC如何具有自己的直流失调，以及交错输出如何有效地在这两个直流失调值之间来回切换。输出以fS/2的速率在这些失调值之间切换，将导致位于fS/2的输出频谱中产生杂散。由于不匹配本身没有频率分量，并且仅为直流，因此出现在输出频谱中的杂散频率仅取决于采样频率，并将始终出现fS/2在2频率下。杂散的幅度取决于ADC之间失调不匹配的幅度。不匹配值越大，杂散值就越大。为了尽可能减少失调不匹配导致的杂散，不需要完全消除每个ADC中的直流失调。这样做会滤除信号中的所有直流成分，不适合使用零中频(ZIF)架构的系统，该架构信号成分复杂，DC量实际是有用信号。相反，更合适的技术是让其中一个ADC的失调与另一个ADC匹配。选择一个ADC的失调作为基准，另一个ADC的失调设置为尽可能接近的值。失调值的匹配度越高，在fS/2产生的杂散就越低。 图4. 失调不匹配。 交错时要注意的第二个不匹配是ADC之间的增益不匹配。图5显示了两个交错式转换器之间的增益不匹配。在这种情况下，有一个不匹配频率分量。为了观察这种不匹配，必须向ADC施加 信号。对于失调不匹配，无需信号即可查看两个ADC的固有直流失调。对于增益不匹配，如果不存在信号，就无法测量增益不匹配，因而无法了解增益不匹配。增益不匹配将会产生与输入频率和采样速率相关的输出频谱杂散，出现在fS/2 ± fIN处。为了最大程度地降低增益不匹配引起的杂散，采用了与失调不匹配类似的策略。选择其中一个ADC的增益作为基准，另一个ADC的增益设置为尽可能接近的值。每个ADC增益值的匹配度越高，输出频谱中产生的杂散就越小。 图5. 增益不匹配。 接下来，我们必须探讨两个ADC之间的时序不匹配。时序不匹配有两个分量：ADC模拟部分的群延迟和时钟相位偏差。ADC中的模拟电路具有相关的群延迟，两个ADC的群延迟值可能不同。此外还有时钟偏斜，它也包括两个分量：各ADC的孔径不确定性和一个与输入各转换器的时钟相位精度相关的分量。图6以图形说明ADC时序不匹配的机制和影响。与增益不匹配杂散相似，时序不匹配杂散也与输入频率和采样速率呈函数关系，出现在fS/2 ± fIN处。 图6. 时序不匹配 为了尽可能降低时序不匹配引起的杂散，需要利用合适的电路设计技术使各转换器模拟部分的群延迟恰当匹配。此外，时钟路径设计必须尽量一致以使孔径不确定性差异最小。最后，必须精确控制时钟相位关系，使得两个输入时钟尽可能相差180°。与其他不匹配一样，目标是尽量消除引起时序不匹配的机制。 最后一个不匹配可能最难理解和处理：带宽不匹配。如图7所示，带宽不匹配具有增益和相位/频率分量。这使得解决带宽不匹配问题变得更为困难，因为它含有另外两个不匹配参数的分量。然而，在带宽不匹配中，我们可在不同的频率下看到不同增益值。此外，带宽具有时序分量，使不同频率下的信号通过每个转换器时具有不同的延迟。出色的电路设计和布局布线实践是减少ADC间带宽失配的最好方法。ADC之间的匹配越好，则产生的杂散就越少。正如增益和时序不匹配会导致在输出频谱的fS/2 ± fIN处产生杂散一样，带宽不匹配也会在相同频率处产生杂散。 图7. 带宽不匹配。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

本篇思维导图 工程实践中，标准化的可靠性设计与分析工作，包括确定产品的可靠性要求、可靠性建模、可靠性预计、特性分析和设计评审等15个工作项目。电子产品可靠性设计工作基本流程如图1所示，涉及的可靠性设计关键技术主要包括：可靠性建模技术、可靠性预计技术、可靠性分配技术、薄弱环节分析技术、特性分析与适应性设计技术、耐久性分析技术。 图1 电子产品可靠性设计工作基本流程 1 可靠性建模技术 可靠性建模技术，即建立系统产品可靠性框图及相应的可靠性数学模型（可靠性概率表达式），它是产品可靠性预计技术、可靠性分配技术的重要基础。其中，编制可靠性框图，需要深入了解产品工作过程及任务完成中的要求，通过框图直观地展示工作过程中产品所有单元之间可靠性的相互依赖关系，每个方框所代表的单元（分系统或设备、板级组件、零部件、元器件）失效概率是相互独立的；建立可靠性数学模型，需要根据可靠性框图及其定义，用普通概率法、布尔真值表法等方法拟定每个框图的可靠性数学模型。 目前，可靠性建模技术发展了适用于单功能和多功能系统的串联系统模型、并联系统模型、冗余（贮备）系统模型、表决系统模型及其组合结构的复杂网络系统模型。几种典型的可靠性框图如图2-6所示，其中，可靠度数学模型中Ri（t）表示第i个单元的可靠度、ti表示第i个单元的工作寿命。 （1）串联系统模型：由n个单元组成的串联系统，任意单元发生故障均会导致整个系统发生故障。串联系统的可靠性框图如图2所示。 图2 串联系统的可靠性框图 对于给定的工作时间t，串联系统工作寿命的可靠度数学模型： （2）并联系统模型：由n个单元组成的并联系统，所有单元都发生故障才会导致整个系统发生故障。并联系统的可靠性框图如图3所示。 图2 并联系统的可靠性框图 对于给定的工作时间t，并联系统工作寿命的可靠度数学模型： （3）冗余（贮备）系统模型：由n个单元组成的冗余（贮备）系统，其中，一个单元工作，n-1个单元贮备，当工作单元发生故障时系统能自动转向贮备单元继续工作。贮备单元失效率和工作单元失效率相等时的热贮备系统可靠性数学模型与上述并联系统模型相同。冷贮备系统可靠性框图如图4所示。 图4 冷贮备系统可靠性框图 对于给定的工作时间t，冷贮备系统工作寿命（tS=t1+t2+…+tn＞t）的可靠度数学模型（所有单元寿命均服从指数分布时）： （4）表决系统模型：由n个单元组成的表决系统，当有任意k个单元正常工作时系统就能正常工作，称为n中取k表决系统（k/n（G））。k/n（G）表决系统的可靠性框图如图5所示。 对于给定的工作时间t，k/n（G）表决系统工作寿命tS={t1，t2，…，tn}中至少有k个大于t的可靠度RS（t）数学模型（一般情况下系统由相同的单元组成，各单元可靠度相等，均为Ri（t），假设表决器完全可靠）： 2 可靠性预计技术 可靠性预计，即对设计或生产的电子设备的基本可靠性和任务可靠性进行预测，它是产品可靠性分配、可靠性设计方案评价和产品维修方案制订的重要依据。预计时，根据可靠性框图的基本可靠性模型或任务可靠性模型，导入可靠性基础数据或经验数据进行计算预计。其中，基本可靠性预计采用串联模型，预计参数是平均失效间隔时间（MTBF）或失效率（λ）；任务可靠性预计采用并联或表决系统等模型，将任务完成概率（MCSP）的预计作为预计参数，评估产品执行任务过程中完成规定功能的能力。 电子产品的创新和应用，推动了可靠性预计技术的发展。20世纪90年代，建立了基于数理统计分析及四个层面数据源的电子设备可靠性预计方法：相似设备法，用于系统层面早期设计方案的权衡；相似复杂性法和功能预计法，用于分系统设备方案优选；元器件计数法，用于设备元器件品种和数量基本确定的初步设计分析；元器件应力法，用于设备元器件详细清单和元器件所承受应力已确定的研制阶段分析。到21世纪初，电子产品在航天、航空领域广泛应用，为提高可靠性预计的合理性和准确性，发展了基于失效物理的可靠性预计方法，以解决布线特征尺寸小于130nm的大规模半导体集成电路耗损失效和SMT互连焊点疲劳失效等模式对失效率贡献凸显的问题，以及电子产品在多变环境条件下传统预计手册无法预计其可靠性的问题。 电子元器件可靠性预计是电子设备可靠性预计的核心基础。经过多年的研究发展，电子元器件可靠性预计方法已经形成两大类预计手册。 一类称为基于数理统计的失效率预计手册，其中，以GJB 299C、MIL-HDBK-217F标准为代表。手册中各类元器件失效率预计模型，是基于数理统计结果建立的经验模型，它通过大量收集整理各类元器件的现场和试验的随机失效数据，把失效时间视为随机变量，以概率论为基础建立了经验式的元器件工作失效率预计模型，其中基本失效率模型仅考虑了温度、电应力引起的失效率贡献（集成电路增加机械应力引起的失效率贡献），根据预计模型对元器件在不同温度应力水平和降额条件下的工作失效率进行统计推断和预测。 另一类称为基于失效物理的失效率预计手册[96,100]，以ANSI/VITA51.2预计手册、FIDES guide指南为代表。它通过收集整理各类元器件对其失效率贡献较大的主要应力和失效机理，利用失效机理退化模型，分别获取元器件在温度、温循、湿度、机械等相关应力条件下的典型基本失效率数据，并结合元器件在电子设备中的实际工作时间权重和各类应力加速系数，建立元器件的工作失效率预计模型，实现更切合实际的元器件失效率预测，作为传统基于数理统计的失效率预计方法的补充。 两类预计手册都建立了各类电子元器件工作失效率预计模型，积累了大量的元器件基本失效数据，在进行电子设备失效率预计时，无论哪种预计方法，都将元器件失效率或失效机理失效率简化为指数分布，视其在电子设备随机失效阶段对总体失效率的贡献为恒定失效率，这与电子设备失效率最终统计结果的浴盆曲线基本相符，这种简化处理为电子设备的可靠性预计带来了极大的便利。 （1）基于数理统计的失效率预计模型。例如：GJB 299C预计手册中的电子元器件工作失效率预计模型如下： 式中，λP是元器件工作失效率； λb是仅考虑温度和电应力的元器件基本失效率； πi是各种影响元器件工作失效率的修正因子。 如，普通晶体管及二极管的基本失效率λb模型： 普通晶体管及二极管的工作失效率λP模型： λP=λbπEπQπAπSDπrπC 模型中基本失效率λb仅考虑元器件在电应力和温度应力作用下的失效率，工作失效率λP通过环境系数πE、质量系数πQ、应用系数πA、电压应力系数πSD、额定功率或额定电流系数πr、结构系数πC的修正，调整这些影响因素对晶体管及二极管失效率带来的影响。 （2）基于失效物理的失效率预计模型。例如：FIDES guide预计手册指南的电子元器件工作失效率预计模型如下： λ=λPhysical·∏PM·∏Process 式中，λ是某类元器件的工作失效率； λPhysical是该类元器件物理因素失效率，是由于各类物理因素引起的失效率； ∏PM是零部件制造质量和技术因素的失效率修正因子； ∏Process是整机产品研发、制造和使用中的质量及技术因素的失效率修正因子。 是该类元器件的时间权重，寿命剖面第i阶段时间在一年中的比例； λphase-i是该类元器件在寿命剖面第i阶段的物理因素失效率； λ0·∏acceleration是该类元器件在寿命剖面第i阶段的物理因素总体基本失效率。 式中，∏induced是该类元器件在寿命剖面第i阶段的过应力影响调整系数； ∏Thermal是该类元器件在寿命剖面第i阶段芯片的温度加速调整系数。 上述两类预计模型均可用于电子设备的可靠性预计，区别在于元器件基本失效率的预计。前者仅考虑温度应力和电应力对基本失效率的贡献，这对传统元器件产品完全适用；后者全面考虑了芯片温度、外壳温循、引脚焊点温循、潮湿、机械等应力下的一系列失效机理的基本失效率之和，这对特征尺寸小于130nm的亚微米级、超深亚微米级半导体集成电路和高密度集成组件SMT焊点而言是必须的。 3 可靠性分配技术 可靠性分配就是把系统产品可靠性总体要求转换为产品每个单元的可靠性要求的过程。可靠性分配参数可以是：可靠度（R（t））、平均失效间隔时间（MTBF）、故障率（λ）等，分配后的参数作为产品各单元的可靠性设计指标。产品可靠性分配的基本原则是保证依据分配指标设计出来的产品满足规定的可靠性总体要求，因此产品可靠性分配包括求解下面的不等式： 式中，Ri^是分配给第i个单元的可靠性要求参数（i=1，2，3，…，n）； R*是产品可靠性总体要求参数； f是产品各单元与产品间的可靠性函数关系。 系统产品可靠性分配方法，包括：不考虑各单元重要性串联系统的等分配法，考虑产品复杂程度、技术成熟度、工作时间、环境条件等因素分值的评分分配法（目标可达性分配法），适用于与老系统相似的新设计系统产品的比例组合分配法，考虑产品各单元重要度和复杂度的分配法（AGREE分配法），针对产品较低可靠度单元提升的最少工作量分配法（可靠度再分配法）等。 实际应用中，不论采用哪种可靠性分配方法，为减少分配的重复次数和避免附加设计的反复分配，需要在规定的可靠性指标的基础上，对各单元的可靠性分配留有一定的裕量。 4 薄弱环节分析技术 薄弱环节分析技术，包括：失效模式与影响分析（FMEA）、故障树分析（FTA）、潜在电路分析（SCA）、电路容差分析（CTA）等技术。多年的研究总结和凝练，形成了标准化的FMEA、FTA、SCA、CTA方法和技术，目的是通过对电子设备产品自上而下或自下而上的全面分析，发现元器件、零部件、设备在设计和制造过程中可能存在的故障模式，以及每一种故障模式的产生原因及影响，找出潜在的薄弱环节，并提出改进措施。 5 特性分析与适应性设计技术 特性分析与适应性设计技术，包括：降额设计、冗余设计、热设计、机械强度分析、环境防护设计、有限元分析等技术。其中，降额设计使元器件使用中承受的应力低于其额定值，以达到延缓其参数退化，提高使用可靠性的目的；冗余设计是指重复配置系统中的一些部件，当系统出现故障时，让冗余的部件及时承担故障部件的工作；热设计是通过采用适当的散热方式，控制产品内部所有电子元器件的工作温度，使其在所处的工作环境条件下不超过规定的最高温度上限；机械强度分析是通过分析产品结构的机械特性，确定包装、储存、装卸、运输、维修等对产品可靠性的影响；环境防护设计是指针对影响产品可靠性的环境因素，采取必要的设计防护，减少或消除有害的环境影响，设计防护包括：温度保护、冲击和振动隔离、潮湿保护、沙尘保护、防爆、电磁兼容设计等；有限元分析是指通过采用有限元分析技术，在设计过程中对产品的机械强度、热特性、电磁场、潮气扩散等进行分析和评价，尽早发现产品承载设计结构和材料的薄弱环节及产品的过热部分。 6 耐久性分析技术 耐久性分析技术，包括：机械零部件的机械疲劳损伤、电子元器件的电耗损和热机械耗损退化等分析技术。通过对产品薄弱环节的耐久性分析，评价机械零部件的耐久性或机械疲劳寿命，评价电子元器件的耗损机理退化寿命。可通过评价产品寿命周期的载荷与应力、产品结构、材料特性和失效机理等进行耐久性分析，发现过早发生耗损故障的机械零部件、电子元器件，确定故障的根本原因和可能采取的纠正措施。   免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

1、SQL语句执行流程 MySQL大体上可分为Server层和存储引擎层两部分。 Server层： 连接器：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。 查询缓存：查询后的结果存储位置，MySQL8.0版本以后已经取消，因为查询缓存失效太频繁，得不偿失。 分析器：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。 优化器：多种执行策略可实现目标，系统自动选择最优进行执行。 执行器：判断是否有权限，将最终任务提交到存储引擎。 存储引擎层 负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎(经常用的也是这个)。 SQL执行顺序 2、BinLog、RedoLog、UndoLog BinLog BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。 STATEMENT 模式 内容：binlog 只会记录可能引起数据变更的 sql 语句 优势：该模式下，因为没有记录实际的数据，所以日志量和 IO 都消耗很低，性能是最优的 劣势：但有些操作并不是确定的，比如 uuid() 函数会随机产生唯一标识，当依赖 binlog 回放时，该操作生成的数据与原数据必然是不同的，此时可能造成无法预料的后果。 ROW 模式 内容：在该模式下，binlog 会记录每次操作的源数据与修改后的目标数据，StreamSets就要求该模式。 优势：可以绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的 劣势：缺点在于 binlog 体积会非常大，同时，对于修改记录多、字段长度大的操作来说，记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。 MIXED 模式 内容：是对上述STATEMENT 跟 ROW  两种模式的混合使用。 细节：对于绝大部分操作，都使用 STATEMENT 来进行 binlog 的记录，只有以下操作使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不确定函数，使用了 insert delay 语句，使用了临时表 主从同步流程： 1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。 2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 。 3、主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。 4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个）。 5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。 mysql默认的复制方式是异步的，并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。 全同步复制 主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。 半同步复制 半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。 还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则还是可用性优先原则？如何判断主库Crash了？互为主备情况下如何避免主备循环复制？被删库跑路了如何正确恢复？(⊙o⊙)… 感觉越来越扯到DBA的活儿上去了。 RedoLog 可以先通过下面demo理解： 饭点记账可以把账单写在账本上也可以写在粉板上。有人赊账或者还账的话，一般有两种做法： 1、直接把账本翻出来，把这次赊的账加上去或者扣除掉。 2、先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。 生意忙时选后者，因为前者太麻烦了。得在密密麻麻的记录中找到这个人的赊账总额信息，找到之后再拿出算盘计算，最后再将结果写回到账本上。 同样在MySQL中如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时账本 = BinLog，粉板 = RedoLog。 1、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个操作记录更新到磁盘里面。 2、 如果更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，然后擦除RedoLog部分数据。RedoLog类似转盘。 RedoLog有write pos 跟checkpoint write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。 check point：是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。 write pos和check point之间的是粉板上还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。 有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下： 1 prepare阶段 –>  2 写binlog  –> 3…

分 享嘉宾： 付海涛 京 东 高级技术专家 编辑整理：赵明明 出品平台：DataFunTalk 导读：Flink是目前流式处理领域的热门引擎，具备高吞吐、低延迟的特点，在实时数仓、实时风控、实时推荐等多个场景有着广泛的应用。京东于2018年开始基于Flink+K8s深入打造高性能、稳定、可靠、易用的实时计算平台，支撑了京东内部多条业务线平稳度过618、双11多次大促。本次讲演将分享京东Flink计算平台在容器化实践过程中遇到的问题和方案，在性能、稳定性、易用性等方面对社区版Flink所做的深入的定制和优化，以及未来的展望和规划。主要内容包括： 实时计算演进 Flink容器化实践 Flink优化改进 未来规划 01 实时计算引进 1.发展历程 最初大数据的模式基本都是T+1，但是随着业务发展，对数据实时性的要求越来越高，比如对于一个数据，希望能够在分钟级甚至秒级得到计算结果。京东是在2014年开始基于Storm打造第一代流式计算平台，并在Storm的基础上，做了很多优化改进，比如基于cgroup实现对worker使用资源的隔离、网络传输压缩优化、引入任务粒度toplogy master分担zk压力等。到2016年，Storm已经成为京东内部流式处理的最主要的计算引擎，服务于各个业务线，可以达到比较高的实时性。 随着业务规模的不断扩大，Storm也暴露出许多问题，特别是对于吞吐量巨大、但是对于延迟不是那么敏感的业务场景显得力不从心。于是，京东在2017年引入了Spark Streaming流式计算引擎，用于满足此类场景业务需要。 随着业务的发展，不光是对于数据的延迟有很高要求，同时对于数据的吞吐处理能力也有很高的要求，所以迫切需要一个兼具低延迟和高吞吐能力的计算框架，于是在2018年我们引入了Flink。在Flink社区版的基础上，我们从性能、稳定性、易用性还有功能等方面，都做了一些深入的定制和优化。同时我们基于k8s实现了实时计算全面的容器化，因为容器化有很多的优点，它可以做到很好的资源隔离，同时它有一个很强的自愈能力，另外它很容易实现资源的弹性调度。同时我们基于Flink打造了全新的SQL平台，降低用户开发实时计算应用的门槛。 到2020年，基于Flink和k8s实时计算平台已经做的比较完善了。过去流式处理是我们关注的重点，今年我们也开始逐渐的支持批处理，朝着批流一体的方向演进。另外AI是目前比较火的一个方向，对于AI来说，它的实时化也是一个重要的研究方向。所以我们的实时计算平台将会朝着批流一体和AI的方向进行发展。 2.平台架构 上面是京东实时计算平台JRC的整体架构，整个架构以定制化改造后的Flink为核心，Flink运行在K8S上，状态存储在HDFS集群上，通过Zookeeper保证集群的高可用。支持流式源JDQ（京东基于Kafka深入定制实现的实时数据总线）和Hive，数据主要写入JimDB（京东内存数据库）、ES、Hbase和京东OLAP。计算平台支持SQL和普通JAR包两种方式的作业，具有配置、部署、调试、监控、和日志处理等功能。 3. 业务场景 京东Flink服务于京东内部非常多的业务线，有70多个一级部门在使用，主要应用场景包括实时数仓，实时大屏，实时推荐，实时报表，实时风控和实时监控，当然还有其他一些应用场景。对数据计算实时性有一定要求的场景，一般都会使用Flink进行开发。 4. 业务规模 京东Flink集群目前由5000多台物理机组成，它服务了京东内部70多个一级业务部门，目前线上的流计算任务大概有3000多个，数据的处理能力可以达到每分钟数十亿甚至更高。 02 Flink容器化实践 1.容器化历程 京东从2018年开始进行计算引擎的容器化改造，2019年初已经实现计算单元全部容器化，2020年进行了容器化方案升级，使用native k8s实现计算资源的弹性扩容。容器化改造的好处是提升了资源使用率，提高了研发效率，增强了业务稳定性，减少了运维部署成本。 2.容器化方案 旧的容器化方案是基于k8s Deployment部署的Standalone Session集群，它需要事先预估出集群所需资源，比如需要的JobManager和TaskManager的资源规格和个数。然后JRC平台通过K8S客户端向K8S Master提出请求，创建JobManager的Deployment和TaskManager的Deployment。其中使用ZK保证高可用，使用Hdfs实现状态存储，使用Prometheus实现监控指标的上传，结合Grafana实现指标的直观展示。集群使用ES存储日志，方便日志的查询。 3.容器化遇到的问题&对策 容器化过程中可能遇到很多问题： ① JM/TM故障自动恢复 应用部署在容器中，当应用出现异常时，如何发现应用或者异常的情况呢？比如可以使用存活探针，编写检测脚本定期读取应用的心跳信息。当检测到Pod处于不健康状态时，可以采用k8s的重启机制来重启不健康的容器。 ② 减少Pod异常对业务影响 在k8s中由于硬件异常、资源过载、Pod不健康等问题会导致Pod被驱逐或自动重启，Pod重启时势必会影响到该Pod上分布计算任务的正常运行。这个时候可以考虑采用适当的重启策略、改造内核等方案来减少对任务影响。比如京东实现了JM Failover优化，当Pod异常引起JM Failover时采用的是任务不恢复、重建任务状态恢复的方式，可以一定程度上减少Pod重启对业务带来的影响。 ③ 性能问题 在容器环境下，JVM对cpu和内存的感知会有一定的问题，在Java8版本中，一些参数就要进行显式的设置。对于机器性能差异或热点等问题导致部分Pod计算慢的问题，可以考虑进行针对性优化（比如实现基于负载的数据分发）或处理（比如检测到计算慢的Pod将其驱逐到负载较低的机器）。此外，对于使用容器网络的情况下，可能会带来一定的网络性能损耗，此时可以根据情况选择使用主机网络避免网络虚拟化带来的开销，或者选择更高性能的网络插件。 ④ 重要业务稳定性 如何保证业务的稳定性是一个需要重点考虑的问题。除了保证系统各个环节的高可用外，还可以根据业务情况考虑使用其它合理的方案，例如业务分级管理，独立资源池，多机房互备等。 4.容器化方案升级（Native k8s） 原有容器化方案存在一定的问题： 资源需要提前分配 无法实现资源弹性伸缩 极端场景下Pod不能正常拉起，影响任务恢复 重要业务稳定性 容器化升级的解决方案是采用Native K8s的方式。由JRC平台先向K8S Master发出请求，创建JobManager的Deployment；然后在用户通过Rest服务提交任务后，由JobMaster通过JDResourceManager 向JRC平台发出请求，然后JRC平台向 K8s Master 动态申请资源去创建运行TaskManager 的Pod。 此处，通过引入JRC平台与K8s交互，屏蔽了不同容器平台的差异，解耦了镜像与平台集群配置&逻辑变化。另外，为了兼容原有Slot分配策略，在提交任务时会预估出任务所需资源并一次性申请，之后采用等待一定时间后进行slot分配的方式达到兼容目的。 03 Flink优化改进 主要做了以下四个方面的优化： 性能 稳定性 易用性 功能扩展 下边分几个重要的点进行讲解： 1.预览拓扑 预览拓扑主要是为了解决业务的一些痛点：比如任务调优繁琐、SQL任务无法指定并行度、任务需要的额Slot数不清楚、并行度调整后网络buffer不足等。在Flink任务调试阶段，对任务并行度、Slot分组、Chaining策略的调整是个反复的过程，如果把参数写到命令行就太繁琐了。而基于预览拓扑就可以很方便地对这些参数进行配置。 预览拓扑基本的实现方案如上图：用户提交JAR包后可根据JAR包生成对应的拓扑图，之后用户根据拓扑图可以进行在线调整，最后自动将修改后的配置和原来的JAR包一起进行任务提交。 预览拓扑机制使得不修改程序多次提交任务调优成为可能，但是如何保证前后两次提交生成算子稳定的对应关系呢？解决方案的关键是保证算子有稳定的唯一身份标识，具体算法是：如果算子指定了uidHash就用uidHash，如果算子指定了uid就使用uid，否则就从source开始广度优先遍历，利用算子在graph中的位置生成一个稳定hash值。 2.背压量化 第二个重要的优化是背压量化。 在Flink开发的时候，主要有两种方式： ①通过Flink UI背压面板观察是否背压。使用这种方式在某些场景比较方便，但是它存在几个问题： 在有些场景下采集不到背压 对于历史背压情况无法跟踪 背压影响不直观 大并行度时背压采集压力 ②通过任务背压相关指标进行观察和分析，通过将指标定期采集并存储起来，可以进行实时或历史的背压分析。但是它也有一些不足的地方： 不同Flink版本中指标含义有一定差异 分析背压有一定门槛，需要对于指标含义有深入理解，联合进行分析 背压未量化，对业务影响程度不够直观 京东的解决方案是采集背压发生的位置、时间和次数指标，并对这些指标进行上报存储。同时对量化的背压指标结合运行时拓扑，可以精确反映发生背压现场的情况。 3.HDFS优化 随着业务数量的增多，HDFS集群的压力就会变得很大。这会直接导致RPC响应时间变慢，造成请求堆积，同时大量小文件也会对NN内存造成很大压力。对此京东尝试的解决方案有4方面：限制checkpoint最小间隔，时间最小设置在1min左右可以满足大部分业务需求；进行小文件合并；降低cp创建和删除时的hdfs rpc请求；HDFS集群多ns分散均衡压力。 4.网络分发优化 在实践过程中我们发现，即使业务使用了rebalance并且对任务进行了打散分布，但是由于机器处理能力和负载的差异，会导致任务各个并行度不同程序的背压表现，严重影响了任务的性能。为此，我们开发了基于负载的动态rebalance，在数据进行分发时优先选择下游负载最小的channel进行分发。 经测试，在特定场景下性能能够提升近一倍。 5.ZK防抖 目前一般都是使用ZK集群实现Flink集群的高可用，但是当网络抖动、机器繁忙、ZK集群暂时无响应或运维机器的时候，都可能会导致任务重启。 任务重启的原因是由于在这些场景发生时，Curator会将状态设置为suspended，并且Curator认为suspended为Error状态，从而会释放leader，Flink发现notleader后会revokeLeadership，从而造成任务重启。 一个可行的解决办法是升级Curator的版本，同时将connectionStateErrorPolicy设置为SessionConnetionStateErrorPolicy。 6.日志分离 目前我们一个集群是支持跑多个任务的，这时日志会出现的问题是：任务的日志和集群Framework日志混在一起，同时集群的多个任务日志也是混在一起的，不太方便用户查看日志，快速定位问题。 为了解决这个问题，首先要弄清楚目前Flink加载日志框架的基本机制：为了避免跟业务Job中可能包含的日志框架的依赖、配置文件产生冲突，Flink日志相关类的加载都代理给TaskManager框架的类加载器，也就是Parent Classloader，而框架加载的这些类都是从Flink安装包的lib目录下加载的。对于日志配置文件，Flink通过 JVM 启动参数来指定配置日志配置文件路径。 日志分离的解决方案是：将日志相关jar包加入到各个task自己classloader（user classloader）的类路径中；同时确保使用user classloader加载日志类和加载自己的日志配置； 另外对于使用了Flink框架的类（比如PrintSinkFunction），日志不能做到很好的分离，可以考虑使用logback MDC机制。 04 未来规划…

你好，我是 yes。 面向对象编程想必大家都耳熟能详，但是写了这么多代码你对面向对象有清晰的认识吗？ 来看看这几个问题： 到底什么是面向对象编程？ 和面向过程编程有什么区别？ 什么又称为面向对象语言、面向过程语言？ 用面向对象语言写的代码就面向对象了？ 面向对象编程真的就这么好吗？ 复杂的业务用面向对象编程就合适了吗？ 我还真没具体地定义过到底什么是面向对象编程。 所以假设有人问到底什么是面向对象编程？有什么好处？ 一时还真不知道怎么说，或者说成体系的解释。 这篇文章我就谈谈我的理解，也试着看能不能说清啥叫面向对象编程。 正文 从二进制命令到汇编语言。 从汇编语言到面向过程语言再到面向对象语言。 计算机语言的发展是为了便于人类的使用，使其更符合人类的思考方式。 计算机的思路就是取指执行，一条直道走到底，它可不会管你什么抽象，不管什么业务建模，通通得给它变成一条条指令，排好顺序让它执行。 而我们人类不一样，我们的思维在简单场景来看是一条道，但在复杂场景就需要做各种分类，才能理清楚关系，处理好事务。 就像法庭，分为法官、书记员、法警、原告、被告、证人等角色。 这么多人分好类，按照法庭审理各司其职，一个案子才能高效、顺利得审判。 再回到计算机语言来，汇编我就不说了，面向过程其实就是一条道的思路，因为起初就是按计算机的思路来编写程序。 我就拿用咖啡机煮咖啡为例，按照面向过程的流程是： 执行加咖啡豆方法 执行加水方法 执行煮咖啡方法 执行喝咖啡方法 很简单直观的操作，你可能没什么感觉，我再按面向对象思想来分析下这个流程。 在执行煮咖啡操作前要抽象出：人和咖啡机（分类），然后开始执行： 人.加咖啡豆 人.加水 咖啡机.煮 人.喝咖啡 是不是有点感觉了？ 面向过程，从名字可以得知重点是过程，而面向对象的重点是对象。 从这个例子可以看出两者的不同：面向过程是很直接的思维，一步步的执行，一条道走到底。 而面向对象是先抽象，把事物分类得到不同的类，划分每个类的职责，暴露出每个类所能执行的动作，然后按逻辑执行时调用每个类的方法即可，不关心内部的逻辑。 从例子可以看出面向对象编程执行的步骤没有变少，整体执行流程还是一样的，都是先加咖啡豆、加水、煮咖啡、喝，这个逻辑没有变。 无非就是划分了类，把每一步骤具体的实现封装了起来，散布在不同的类中。 对我们程序员来说是最最直接的感受：变的其实就是代码的分布，煮咖啡的代码实现被封装在咖啡机内部，喝咖啡的代码实现被封装在人内部，而不是在一个方法中写出来。 代码的分布确实是最直观的，但是变得不仅只是分布，而是思想上的变化。 就是上面提到的计算机思维到人类思维的变化。 我认为这个变化是因为软件的发展，业务越来越复杂。 人们用面向过程语言编写复杂的软件时，需要按照不同的功能把一些数据和函数放到不同的文件中，渐渐地人们就发现这不就是先分类吗？ 并且好像业务分析下来都能和现实世界的东西对应上？ 于是人们慢慢地总结、提炼就演变成了面向对象，再根据面向对象的特性提炼出关键点：封装、继承和多态。 而这个面向对象思想就类似我们人类面对复杂场景时候的分析思维：归类、汇总。 所以面向对象编程就成为了现在主流的编程风格，因为符合人类的思考方式。 面向过程编程和面向对象编程从思想上的变化是：从计算机思维转变成了人类的思维来编写编码。 所以我们知道面向对象编程其实是一种进步，一种更贴近人类思考方式的编码风格，是源于人们用面向过程编程时的经验总结。 至此我们知道了面向对象编程的来源，相信知晓了来源能更好的理解面向对象。 那到底什么是面向对象编程？ 面向对象编程(Object Oriented Programming，OOP)是一种编程范式或者说编程风格。 学术一点讲就是把类或对象作为基本单元来组织代码，并且运用提炼出的：封装、继承和多态来作为代码设计指导。 这其实就是面向对象编程。 其实从上面煮咖啡的流程应该能 get 到这个含义了。 OOP 说白了就是拿到需求开始分析，进行抽象建立业务模型，每个模型建立对应的类。 思考业务的交互，根据交互定义好接口并做好接口的控制访问，将于此类相关的数据和动作都封装起来。 抽象出父类，子类继承父类来进行代码的复用和扩展。 执行功能时用父类来调用，在实际代码运行过程会进行动态绑定，调用子类的实现达到多态的特性。 多态，学术点讲就是：运行时用相同的代码根据不同类型的实例呈现出不同行为的现象。 如果有新功能要实现，只需要创建一个新子类，以前的执行逻辑不需要发生变化，这就是「开闭原则」，对修改关闭，对扩展开放”。 来简单的看个代码可能会有更直观的感受，没记错的话大学时也是拿动物举例。 狗是动物、鸭子是动物，所以有个 Animal 类。 然后能发声，所以有 voice 方法。     public class Animal {      public void voice(){          System.out.println("动物的叫声");      }    } 然后搞个 Dog、Duck 继承 Animal 实现各自的 voice。     public class Dog extends Animal {      public void voice(){         System.out.println("汪汪汪~");      }    }   public  class Duck extends Animal {      public void voice(){         System.out.println("gagaga~");      }    } 然后到时候就可以实例化不同的对象来达到多态的效果。     public class Test{      private Animal animal;      public void setAnimal(Animal animal) {        this.animal = animal;      }      public void voice(){          animal.voice();      }    } 多态带来的好处，无非就是 Test 里面代码不用动，你想要狗叫你就 new Dog 然后 set 进去，如果要鸭子就  new Duck 然后 set 进去。 如果加入了新动物那就建一个新动物类 set 进去就行，符合开闭原则。 和面向过程编程有什么区别？ 其实从上面煮咖啡和动物的这两个例子应该能感受出来区别。 最重要的是思想上的区别，上面也已经提到了。 还有一点就是数据和动作。 面向过程编程这种编程风格是以过程作为基本单元来组织代码的，过程其实就是动作，对应到代码中来就是函数，面向过程中函数和数据是分离的，数据其实就是成员变量。 而面向对象编程的类中数据和动作是在一起的，这也是两者的一个显著的区别。 什么又称为面向对象语言、面向过程语言 面向对象语言其实就是有现成的语法机制来支持类、对象的语言，比如 Java。 当然还要有支持继承、多态的语法机制。 面向过程语言就反着理解，没有现成的语法机制来支持类、对象等基本单元来组织代码。 当然不是你用了面向对象语言写出来的代码就面向对象了。 你要通篇就一个 class，一堆杂乱无章都往里面塞，不归类、没有封装的意识，一条直到，这可不叫面向对象编程。 当然也不是用面向过程语言就写不出面向对象的代码，只是由于语法层面的不支持，写起来没那么方便，需要用一些手段，具体就不展开了。 所以语言只是为了更好的支持编程范式，重要的还是思想上的转变。 面向对象编程真的就这么好吗？ 结论先上：软件设计没有银弹，没有最好的，只有合适的。 前面也提到了面向对象更符合人类的思考方式，这其实就是优势，能…

宜普电源转换公司(EPC)宣布推出EPC9151，这是一款300 W、双向、超小尺寸的1/16砖型DC/DC降压转换器模块，其尺寸仅为33 mm x 22.9 mm (1.3”x 0.9”)。EPC9151采用Microchip公司的数字信号控制器(dsPIC33CK)和EPC公司的 ePower™ 功率级集成电路(EPC2152)，于300 W、48 V/12 V的转换器中，可以实现95%以上的效率，而且可以在这个可扩展的两相设计中增加相数，使得功率可以更高。 砖型DC/DC转换器广泛用于数据中心、电信和车载应用，可将标称48 V总线转换为标称12 V配电总线(或从标称12 V总线转换)。氮化镓集成电路技术的迅猛发展推动了半桥器件和栅极驱动器的集成，EPC9151模块就是采用了单芯片解决方案(EPC2152)，从而针对各种目标应用，简化布局、减小面积并降低成本。 EPC首席执行官Alex Lidow表示：“ 氮化镓场效应晶体管(eGaN FET)和集成电路具备快速开关、小尺寸和低成本等优势，以满足前沿计算应用对功率密度的严格要求。EPC9151是很好的范例，它展示如何利用集成功率级EPC2152，满足计算应用中48 V转换所要求的提高功率密度并降低系统成本。”