https://blog.csdn.net/qq_38526635/article/details/81632971   转载对象存储概述 什么是对象存储（OSD）？存储局域网（SAN）和网络附加存储（NAS）是目前两种主流网络存储架构，而对象存储（Object-based Storage)是一种新的网络存储架构，基于对象存储技术的设备就是对象存储设备（Object-based Storage Device）简称OSD。1999年成立的全球网络存储工业协会（SNIA）的对象存储设备工作组发布了ANSI的X3T10标准。总体上来讲，对象存储综合了NAS和SAN的优点，同时具有SAN的高速直接访问和NAS的分布式数据共享等优势，提供了具有高性能、高可靠性、跨平台以及安全的数据共享的存储体系结构。SAN存储架构采用SCSI快I/O命令集，通过磁盘或FC（iber Channel）级的数据访问提供高性能的随机I/O个数据吞吐率，它具有高宽带、低时延的优势，在高性能计算中占有一席之地，如SGI的CXFS文件系统就是基于SAN实现高性能文件存储的，但是由于SAN系统的价格较高，且扩展性较差，已不能满足成千上万个CPU规模的系统。NAS存储架构它采用NFS或CIFS命令集访问数据，以文件为传输协议，通过TCP/IP实现网络化存储，可扩展行好、价格便宜、用户易管理，如目前在集群计算中应用较多的NFS文件系统，但由于NAS的西医开销高、带宽低、延迟大，不利于在高性能集群中使用。对象存储架构核心是将数据通路（数据读或写）和控制通路（元数据）分离，并且基于对象存储设备构建存储系统，每个对象存储设备具有一定的只能，能够自动管理其上的数据分布。对象存储结构由对象、对象存储设备、元数据服务器、对象存储系统的客户端四部分组成。1. 对象对象 是系统中数据存储的基本单位，每个Obeject是数据和数据属性集的综合体，数据属性可以根据应用的需求进行设置，包括数据分布、服务质量等。在传统的存储系统中用文件或块作为基本的存储单位，块设备要记录每个存储数据块在设备上的位置。Object维护自己的属性，从而简化了存储系统的管理任务，增加了灵活性。Object的大小可以不同，可以包含整个数据结构，如文件、数据表项等。在存储设备中，所有对象都有一个对象标识，通过对象标识OSD命令访问对象。通常由多种类型的对象，存储设备上的根对象标识存储设备和该设备的各种属性，组队象是存储设上共享资源管理策略的对象集合等。                                                  传统的访问层次和虚拟数据访问模型2. 对象存储设备每个OSD都是一个智能设备，具有自己的存储介质、处理器、内存以及网络系统等，负责管理本地的Object，是对象存储系统的核心。OSD同块设备的不同不在于存储介质，而在于两者提供的访问接口。OSD的主要功能包括数据存储和安全访问、目前国际上通常采用刀片式结构实现对象存储设备。OSD提供三个主要功能：（1）数据存储。OSD管理对象数据，并将它们放置在标准的磁盘系统上，OSD不提供接口访问方式，Client请求数据时用对象ID、偏移进行数据读写。（2）智能分布。OSD用其自身的CPU和内存优化数据分布，并支持数据的预取。由于OSD可以智能地支持对象的预取，从而可以优化磁盘的性能。（3）每个对象数据的管理。OSD管理存储在其它对象上的元数据，该元数据与传统的inode元数据相似，通常包括对象的数据块和对象的长度。而在传统的NAS系统中，这些元数据是由文件服务器提供的，对象存储架构将系统中主要的元数据管理工作由OSD来完成，降低了Client的开销。3. 元数据服务器（Metadata Server，MDS）MDS控制Client与OSD对象的交互，为客户端提供元数据，主要是文件的逻辑视图，包括文件与目录的组织关系、每个文件所对应的OSD等。主要提供以下几个功能：（1)对象存储访问。MDS构造、管理描述每个文件分布的视图，允许Client直接访问对象。MDS为Client提供访问该文件所含对象的能力，OSD在接收到每个请求时先验证该能力，然后才可以访问。（2）文件和目录访问管理。MDS在存储系统上构建一个文件结构，包括限额控制、目录和文件的创建和删除、访问控制等。（3）Client Cache一致性。为了提高Client性能，在对象存储系统设计时通常支持Client的Cache。由于引入Client方的Cache，带来了Cache一致性的问提，MDS支持基于Client的文件Cache，当Cache的文件发生改变时，将通知Client刷新Cvashe，从而防止Cache不一致引发的问提。4. 对象存储系统的客户端Client为了有效支持Client支持访问OSD上的对象，需要在计算节点实现对象存储系统的Client。现有的应用对数据的访问大部分都是通过POSIX文件方式进行的，同时为了提高性能，也具有对数据的Cache功能和文件的条带功能。同时，文件系统必须维护不同客户端上Cache的一致性，保证文件系统的数据一致。文件系统访问流程：1）客户端应用发出读请求；2）文件系统向元数据服务器发送请求，获取要读取的数据所在的OSD；3）然后直接向每个OSD发送数据读取请求；4）OSD得到请求后，判断要读取的Object，并根据此Object的认证方式，对客户端进行认证，如果客户端得到收授权，则将Object的数据返回给客户端；5）文件系统收到OSD返回的数据以后，读操作完成。对象存储文件系统的关键技术1、分布元数据 传统的存储结构元数据服务器通常提供两个主要功能。（1）为计算结点提供一个存储数据的逻辑视图（Virtual File System，VFS层），文件名列表及目录结构。（2）组织物理存储介质的数据分布（inode层）。对象存储结构将存储数据的逻辑视图与物理视图分开，并将负载分布，避免元数据服务器引起的瓶颈（如NAS系统）。元数据的VFS部分通常是元数据服务器的10％的负载，剩下的90％工作（inode部分）是在存储介质块的数据物理分布上完成的。在对象存储结构，inode工作分布到每个智能化的OSD，每个OSD负责管理数据分布和检索，这样90%的元数据管理工作分布到智能的存储设备，从而提高了系统元数据管理的性能。另外，分布的元数据管理，在增加更多的OSD到系统中时，可以同时增加元数据的性能和系统存储容量。2、并发数据访问 对象存储体系结构定义了一个新的、更加智能化的磁盘接口OSD。OSD是与网络连接的设备，它自身包含存储介质，如磁盘或磁带，并具有足够的智能可以管理本地存储的数据。计算结点直接与OSD通信，访问它存储的数据，由于OSD具有智能，因此不需要文件服务器的介入。如果将文件系统的数据分布在多个OSD上，则聚合I/O速率和数据吞吐率将线性增长，对绝大多数Linux集群应用来说，持续的I/O聚合带宽和吞吐率对较多数目的计算结点是非常重要的。对象存储结构提供的性能是目前其它存储结构难以达到的，如ActiveScale对象存储文件系统的带宽可以达到10GB/s。

IT这种大规模分布式网络软件设计和实践，与当下流行的IT的Cloud Native的设计理念高度吻合：无状态：业务处理（应用）和存储（后台数据库）分离，将业务状态和会话数据从业务处理单元中分离出来，并存储在独立的数据库中，实现业务处理单元的无状态设计，使得业务处理单元可以任意弹性伸缩，从而可以应对突发的大流量。同时如果处理逻辑单元故障，则可以通过数据服务快速获取会话的数据/状态，包括正在进行的会话，从而不影响应用对外提供服务，保证业务的连续性。分布式存储: 简单来说，就是通过内部协议约定，将要求保存的文件同时写入到多台机器中，这样文件也有了多个备份，再也不怕一台机器出故障，数据就丢失的情况。通过分布式存储，利用多台存储服务器分担存储负荷，不但提高了系统的可靠性、可用性和存取效率，还易于扩展。（微）服务解耦：例如业务a将会员、商品、交易、个性化服务等进行功能解耦拆分，拆分之后的每个系统可以单独部署，业务简单，方便扩容，同时通过模块灵活组合来完成新业务快速上线。轻量虚拟化（容器）：在上述关键技术特征下，原有的单体应用被解构成多个小型的服务化模块，在虚拟化环境下，这些模块的资源载体相应地需要更轻量化，才能在大流量时进行快速部署，快速扩容。相对于传统的虚拟技术，容器技术不需要进行硬件虚拟以及运行完整操作系统等额外开销，所以容器对系统资源的利用率更高，并且启动速度更快。传统的虚拟机技术启动应用服务往往需要数分钟，而容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

历史在分析趋势之前，我们先看一下分布式调度系统的历史。早期分布式调度系统以批处理系统为主，例如九几年的LSF/SGE/PBS等，这些批处理系统大规划的使用在HPC领域，而且对作业级的调度进行大量的研究工作；后续由批处理系统延伸出多集群、多组织资源共享的需求，便成了网络计算。网络计算与云计算最大的不同是：网络计算强调多组织的资源共享，而云计算强调云厂商的集中式支持；这也是云计算成为主流的主要原因：多组织之间共享需要完备的协议和足够的安全支持，而云服务仅需要对用户提供相应服务和安全，并不需要在多个云厂商之间进行共享；随着开源社区的发展，再将应用接口逐步统一，e.g. Kubernetes。Hadoop出现后，不仅推动了分布式调度系统中对数据的处理，同时也推动了开源软件的生态。2012和2014是两个重要的节点，Hadoop将资源管理层与领域框架层分开，随后的领域框架也有机会构建自己的生态，e.g. Spark；同时，将资源管理层与领域框架分开也被广泛认可。在容器及Kuberentes流行后，凭借其高资源利用率与隔离，环境标准化等优势，越来越多的人希望将这些批量计算应用统一到 Kubernetes 平台上。未来的趋势多种应用统一调度随着各行各业的发展，涌现出越来越多的领域框架来支持业务的发展；这些框架都在相应的业务领域有着不可替代的作用，e.g. Spark, Tensorflow, Flink等。在业务复杂性能不断增加的情况下，单一的领域框架很难应对现在复杂的业务场景；因此现在普遍使用多种框架达成业务目标，如下图所示。但随着各个领域框架集群的不断扩大，以及单个业务的波动性，各个子集群的资源浪费比较严重；因此越来越多的用户希望通过统一调度系统来解决资源共享的问题。在技术选型上，Kubernetes凭借其优秀的扩展性获得大部分用户青睐。异构硬件在批量计算任务向云原生环境迁移的过程中，对云原生环境的算力提出了新的要求；各个厂商为了应对这些新的需求，为各个场景提供了不同架构的硬件，例如 鲲鹏，昇腾，X86，GPU等。当多种应用运行在统一平台上时，需要云原生调度系统能够对异构硬件资源进行统一的管理与调度，使用各种应用达到最优的资源配比。目前，硬件的信息通过kubernetes的 device plugin 机制提供，但Kubernetes的 device plugin 仍有一些不足，例如 无法很好的支持硬件拓扑。在调度方面 Volcano 已经支持主流的调度策略，并在最新的1.0版本中支持了 GPU 共享，大大增加了GPU的利用率，有效降低了GPU的使用成本。跨集群/跨云跨集群一直是分布调度系统解决大规模、灾备等问题的主要解决方案；同时，为了降低厂商绑定的风险，并最大限度兼顾不同云厂商的优势，多云环境下的负载高效分发逐渐成为趋势。在多云的环境中，面向数据位置的优化，作业执行时间预估等问题都是需要调度系统解决的问题；在 Volcano 中，将通过多个项目实现跨集群、跨云的作业调度，例如 JobForward (#880)。智能化调度算法在分布调度系统中有大量的研究，从早期的批处理系统到近期的Borg，Volcano等；早期的批处理系统以特定场景的算法优化为主，对于复杂的场景需要大量的计算，虽然有大量针对HPC和网络的调度优化，但常用和落地的算法比较少。随着人工智能的发展，越来越多的调度系统将会使用AI相应的能力对算法进行优化；在 Volcano 中，将通过AI的能力驱动 Volcano 中各个调度算法进行优化，并通过AI的能力提供新的调度算法。总结分布式调度系统是一个复杂的系统，需要多个组件共协作以提高整体的效率，例如 应用管理，调度，异构硬件管理，存储等，仅靠调度器无法完成这些工作。Volcano 作为CNCF首个面向批量计算的分布式调度系统，包含了应用管理，作业调度，异构硬件等多个组件和功能；其调度器兼容kubernetes调度策略，同时支持在线、离线两种作业类型；控制器提供了统一的作业管理，支持多种作业的接入，包括 MPI, Tensorflow, MidSpore, Spark 等；设备插件提供了对异构硬件的支持，例如 1.0 版中支持了 GPU 共享。因此，Volcano面向分布式调度系统的趋势提供了完整的方案，可以在多种场景下提高作业性能，资源使用率等。Volcano特训营：六节课学懂容器批量计算由Volcnao项目发起者马达主讲的直播课程正在进行中，课程共有6期，从技术原理到实战演练，涵盖Volcano全景。锁定后续课程信息，获取往期回放与讲师PPT，请假助手微信（k8s2222）并备注“Volcano”。

Zookeeper是一个开源的分布式协调器，是一个典型的分布式数据一致性解决方案，其设计目的是将复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的系统。提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

第一章Wings企业级单元测试自动编码引擎诞生的背景 （附Wings讲解视频和白皮书pdf下载）随着科技的飞速发展，软件系统越来越复杂，在系统测试阶段不断遇到的瓶颈，迫使行业逐步追根溯源到了单元测试阶段。软件缺陷发现得越晚，其处理费用就越呈几何激增，因此测试左移概念已经成为趋势。单元测试面临的最大问题是单元测试用例编写工作量巨大，极端情况下与开发工作量比达到1：1，甚至更高，这使大部分开发团队要么主动忽视单元测试，要么象征性的走个流程。如果可以让计算机先对被测试程序进行全局分析和深度理解，再由计算机进行全自动的完成单元测试编码，同时还能确保自动编写的代码无语法、语义错误的直接运行起来，这种用计算机智能算法全自动产生的测试编码去验证开发人员编写的源代码逻辑输入输出对错的高端测试模式，无疑是未来软件测试领域最为璀璨的“明珠”技术。国外软件诸如c++ test完成了这个领域的初步技术探索，星云测试研发的Wings（目前商用产品支持c/c++程序）产品，则大踏步完成了整体技术跨越和多方商用落地验证。Wings可以对程序参数进行深度解析，比如c++类、模板类、数组、结构体、指针、链表以及任意复杂结构的层级嵌套，同时对于面向对象的程序特性以及常用的容器库，能够完美识别和支持。对于一些void*、函数指针、模板类等无法直接静态分析进行类型确定的特殊情况，均有基于人工智能的程序分析辅助进行类型确定。Wings在基于深度参数解析的基础上，对于全局范围的程序进行理解分析后，第一步 按照内置规则，自动化构建被测程序的输入用例代码；第二步 构建测试代码用于调用被测程序的源代码；第三步 构建被测程序输出断言，完成调用被测试程序单元的全部环境准备。这个构建速度非常快，可以达到每分钟100万行左右的生成速度，编写的代码比程序开发人员手工编写的规范度高出一截，并确保100% 的语法语义正确，免去大量的调试时间。在驱动数据上，Wings实现了驱动代码和数据的分离。Wings基于深度参数解析基础上，可以根据参数的结构自动生成层级嵌套的测试数据结构，用图形界面可视化的展示给用户。用户只需要根据Wings提供的界面向导对测试数据进行填充即可，驱动程序会自动识别并读取这些数据，完成对被测试程序的调用。Wings还可以全自动生成参数捕获程序，并自动插装在被测试程序中。当被测试程序运行后，可以通过专用软件捕获程序中每个函数模块运行的具体参数值。Wings的测试代码驱动自动生成和参数捕获，相当于完成了一种全智能的闭环测试验证体系。Wings使测试数据不需要人工准备，只需要在前序轮次中通过参数捕获自动存储。若前序测试用例运行正常，那么这些数据都可以作为后续测试输入和进行校验的基础数据。第二章 单元测试自动生成技术2.1 测试左移后单元测试面临的问题测试左移后，传统的单元测试一般面临很多问题，主要如下：(1) 传统程序级测试用例的编写会耗费开发人员大量的工时，比如TDD测试驱动开发里面的单元测试无法有效实施，导致所有测试几乎全部依赖于系统级黑盒测试。程序级测试用例的开发成本是功能实现代码本身时间至少为1：1，绝大部分企业选择放弃开发程序级测试，而采用系统级测试方法。(2)     需求发生变化导致程序实现发生变化后，程序集用例也需要发生变化，和自动化面临的问题一样，单元测试本身的可维护性问题导致投入是持续的而不是一次性的，会打消其企业应用的热情。(3)     很多单元在未组装成系统的时候切入，如果需要进行测试需要进行大量的mock操作或者桩模拟，这个过程会造成单元测试的不精确性。(4)     程序集测试数据量很大，全部需要用户来进行准备无法全自动从前序系统测试过程中获取。      针对以上问题，很多业内人士提出了很多办法，例如自动生成测试用例、自动构建测试驱动、模糊测试方法等诸多方式，但是实际开发中程序输入参数十分复杂，简单的输入已经不能满足，如何能够构建复杂的参数输入，是要解决的重要问题。因此，星云测试研发了Wings产品--单元级的自动编码引擎，它不仅能够自动构建测试驱动，还能处理十分复杂的大型程序参数，帮助企业能够更好的进行单元测试。2.2 完成单元测试要素构成单元测试的要素如下：a.        测试数据b.        测试驱动代码例如针对以下程序，需要准备的测试输入以及测试代码①　全局变量：c②　参数：a、b③　预期输出：320 30 int c = 100; int sum(int a, int b) {      return a + b + c; } int driver_sum() {      int a = 100, b = 20;      c = 200;      return sum(a, b); }                                                                                TEST(test, driver_sum) {      EXPECT_EQ(320, driver_sum);      EXPECT_EQ(30, driver_sum); }2.3构建测试数据和测试代码遇到的技术瓶颈编写测试代码比较繁琐开发编写驱动不难，但是浪费大量的时间，并且没有创造性。编写代码是否有良好的代码规范单元测试也需要一些规范支持，例如代码规范，注释规范等，有了这些规范能够为测试人员提供很好的功能测试用例设计的逻辑思考，也为其他开发熟悉代码提供极大的便利。数据类型比较复杂通常情况下，输入参数比较复杂，嵌套层析结构比较深入，例如类包含其他类等。能否支持多组测试数据一般代码中每个循环、分支判断以及输入输出都有可能产生缺陷。因此单元测试需要很多用例，满足不同的条件分支，达到满足覆盖率。第三章 Wings的基本架构介绍3.1 Wings测试用例驱动自动生成技术的特性l  Wings是智能的全自动测试用例驱动构建系统，能够在很短时间内完成对大型复杂程序的自动解析、构建。每分钟达到100万行代码的生成速率。l  可以将任意复杂类型逐步分解为基本数据类型，例如结构体嵌套，复杂类对象，c++标准容器，自定义模板类等。l  支持多层次的可视化的数据表格来对变量类型进行赋值，无需关注驱动程序本身。数据表格可以表达任意深度和多层次的数据关系，用户只需要关注表格数据，完成对输入数据的校对。l  能够区分系统数据类型和用户自定义类型，对于复杂的约定俗成系统类型可由用户自定义扁平式赋值模板，例如std::vector类型等，内部集成常用系统类型的模板。3.2 Wings的技术架构介绍Wings的技术架构：首先Wings利用代码静态分析技术，提取被测程序的主干信息并保存到Program Structure Description（PSD）结构中，PSD结构中主要存储函数的参数、全局变量以及返回值的信息，类的成员变量，成员函数，以及访问权限等信息。利用存储的信息，依据一定的编写规则，自动构建测试驱动、googletest 期望断言、测试输入、参数捕获等代码和值。                                             图 3.2 Wings总体架构图上述Wings的总体架构图，说明了Wings构建代码与测试输入的具体过程，整个核心技术是通过编译底层技术获取程序的信息，然后按照一定的规则构建需要的数据。第四章 程序结构信息描述程序结构信息（Program Structure Description）是指对源程序进行提取后的描述信息，主要包括类名、命名空间、类的成员变量信息、类的函数信息，以及各种类型信息等（程序结构信息，下文简称“PSD”）。描述信息的保存C语言是以一个文件为单元存储，C++提取所有的类信息存储在一个文件中。Wings的主要特性是能够对复杂的类型（结构体、类、模板类等）进行逐层展开分解到最基本数据类型（char、int、string等）。PSD结构存储在XML文件中，不同的XML文件存储不同的描述信息。Wings提取的程序结果都存储在Wingsprojects文件下的funxml与globalxml文件夹中，其中funxml文件中主要存储的文件以及作用如下：RecordDecl.xml: 结构体，联合体与类描述信息。ClassTemplateDecl.xml:模板类描述信息EnumDecl.xml:枚举描述信息funcPoint.txt： 存储函数参数为函数指针的分析结果。funcCount.txt: 存储分析到的全部函数，参数个数，参数类型信息。void.txt: 存储函数参数为void*的分析结果。filename.xml：存储c语言文件的信息。注：具体文件的描述信息，参看附录A。针对复杂类型，例如结构体类型location_s，成员变量中除了基本数据类型之外，还存在包含结构体类型的情况，如下所示的代码中，location_s中包含coordinate_s结构体，以及FILE等类型的信息，针对不同的类型进行标记区分。 源代码如下：typedef struct coordinate_s{     void(*setx)(double, int);     int mInt;     char *mPoi;     int mArr[2][3];     void *vo; } coordinate;   typedef struct location_s {     int **mPoi;     coordinate *coor;     FILE *pf;     struct location_s *next; }location;   coordinate *coordinate_create(void); int coordinate_destroy(location *loc,size_t length,char *ch); void func_point(double param1, int param2); 生成对应的PSD结构信息如下图4：图4：PSD描述信息C++的主要表示类型是类，因此测试是C++以一个类为单元做测试，类主要包括类的成员变量名以及类型信息，成员变量的访问权限信息。类的成员函数分为构造函数、内联函数、虚函数等，成员函数的参数信息以及类型信息等。具体描述信息可以登陆www.codeWings.net下载Wings试用版本进行学习。第五章 Wings构建程序描述Wings通过获取到的存储信息，依据一定的编码规则，构建不同的代码程序，如驱动程序、期望断言程序、参数捕获程序等。5.1 驱动程序构建驱动程序指单元测试代码，Wings针对函数参数的类型，自动完成单元测试代码的编写。为了更详细的说明驱动程序，以一个C++类作为具体的例子说明。 类的声明如下：class BlockBuilder { public:     explicit BlockBuilder(const Options* options);     BlockBuilder(const BlockBuilder&) = delete;     BlockBuilder& operator=(const BlockBuilder&) = delete;     void Reset();     void Add(const Slice& key, std::string & value);     Slice Finish();     size_t CurrentSizeEstimate() const; private:     const Options* options_;     std::string buffer_;     int counter_;     bool finished_; };针对如上BlockBuilder 类，构建一个对应的驱动类DriverBlockBuilder，驱动类中主要包含构造函数、析构函数、每个成员函数的驱动函数以及返回值函数。为了避免类中重名函数，对写入PSD需要对应生成驱动的函数进行顺序编号。驱动类声明：class DriverBlockBuilder { public:     DriverBlockBuilder(Json::Value Root, int times);     ~DriverBlockBuilder();     int DriverBlockBuilderReset1(int times);     int Reset1Times;     int DriverBlockBuilderAdd2(int times);     int Add2Times;     int DriverBlockBuilderFinish3(int times);     void ReturnDriver_Finish3(class Wings::Slice returnType);     int Finish3Times;     int DriverBlockBuilderCurrentSizeEstimate4(int times);     void ReturnDriver_CurrentSizeEstimate4(size_t returnType);     int CurrentSizeEstimate4Times; private:     Wings::BlockBuilder* _BlockBuilder; };在上述驱动类中，构造函数的作用是构造BlockBuilder的对象，用构造的对象，调用测试BlockBuilder中的成员函数。析构函数的作用是释放构建的对象。 构造函数与析构函数：DriverBlockBuilder::DriverBlockBuilder(Json::Value Root, int times){   Json::Value _BlockBuilder_Root = Root["BlockBuilder" + std::to_string(times)];   /* options_ */   Json::Value _options__Root = _BlockBuilder_Root["options_"];   int _options__len = _options__Root.size();   Wings::Options* _options_ = DriverstructOptionsPoint(_options__Root, _options__len);   /* buffer_ */   std::string _buffer_= _BlockBuilder_Root["buffer_"].asString();   /* counter_ */   int _counter_ = _BlockBuilder_Root["counter_"].asInt();   /* finished_ */   bool _finished_;   int _finished__value_ = _BlockBuilder_Root["finished_"].asInt();   if (_finished__value_ == 0) {     _finished_ = true;    }   else {     _finished_ = false;   }   _BlockBuilder = new Wings::BlockBuilder(_options_, _buffer_, _counter_, _finished_, false); } DriverBlockBuilder::~DriverBlockBuilder() {     if (_BlockBuilder != nullptr) {         delete _BlockBuilder; } }每个成员函数对应生成自己的驱动函数。类中的Add函数对应的驱动函数如下。Add驱动函数：int DriverBlockBuilder::DriverBlockBuilderAdd2(int times) {     Add2Times = times;     const char* jsonFilePath = "drivervalue/BlockBuilder/Add2.json";     Json::Value Root;     Json::Reader _reader;     std::ifstream _ifs(jsonFilePath);     _reader.parse(_ifs, Root);     Json::Value _Add2_Root = Root["Add2" + std::to_string(times)];     /*It is the 1 global variable: count    Add */     int _count = _Add2_Root["count"].asInt();     count = _count;     /*It is the 1 parameter: key Add2      * Parameters of the prototype:const Wings::Slice &key */     Json::Value _keykey_Root = _Add2_Root["key"];     /* data_ */     char* _keydata_;     {         std::string _keydata__str = _keykey_Root["data_"].asString();         _keydata_ = new char[_keydata__str.size()];         memcpy(_keydata_, _keydata__str.c_str(), _keydata__str.size());     }     /* size_ */     unsigned int _keysize_ = _keykey_Root["size_"].asUInt();     Wings::Slice _key(_keydata_, _keysize_, false);     /*It is the 2 parameter: value    Add2      * Parameters of the prototype:const std::string &value  */     string _value = _Add2_Root["value"].asString();       //The Function of Class    Call     _BlockBuilder->Add(_key, _value);     return 0; }构成以上驱动函数的主要包括全局变量、参数、调用被测函数的构建。以上是针对BlockBuilder类的驱动类的主要信息，而构建的程序遵守google的编码规范。一些命名规则如下：Wings生成的驱动代码，存储在drivercode文件夹中。（1）driver.cc与driver.h，针对程序中使用到的一些公共函数以及头文件。（2）同一个结构体或者联合体，可能会作为多个函数的参数使用，为了避免代码的重复，Wings针对所有的结构体和联合体的不同类型，封装成不同的驱动函数或者参数捕获函数。driver_structorunion.cc 存储结构体驱动函数的代driver_structorunion.h 对应的头文件。结构体实现函数的命名规则为：DriverStruct+结构体名字+类型，其中Point代表一级指针或者一维数组，PointPoint代表二级指针或者二维数组使用。源文件的命名规则为：driver_+源文件名/类名+.cc例如：driver_nginx.cc 或 driverBlockBuilder.cc驱动函数的命名规则：Driver_+函数名+（编号）例如：Driver_ngx_show_version_info(void);DriverBlockBuilderAdd2(int times)    （3）返回值的打印输出返回值的打印输出函数命名规则：Driver+Return+Print_+函数名。例如：DriverReturnPrint_ngx_show_version_info();（4）用户源代码中的main函数自动进行注释，重新生成一个main函数文件，来进行测试。Wings会生成驱动main的主函数文件为:gtest_auto_main.ccWings主要针对参数进行逐层展开，解析到最底层为基本类型进行处理。驱动的赋值部分，主要就是针对基本类型进行处理。（注：特殊类型，比如FILE等，后面会详细讲解如何赋值）以int类型举例，一般程序构成int的主要组成大概包括以下情况：int p; int *p; int **p; int ***p;int p[1]; int p[2][3]; int p[1][2][3];int(*p)[]; int(*p)[][3]; int *(*p)[]; int (**p)[];int *a[]; int **a[]; int *a[][3]; int (*a[])[];Wings会针对基本类型的以上15种类型，进行不同的赋值。构建完驱动程序之后，要对驱动程序进行运行，Wings构建googletest的框架，来进行测试。下面我们将针对期望断言的googletest程序进行构建。5.2 googletest程序的构建在构建完单元测试驱动程序之后，Wings将调用googletest的框架，完成对返回值的期望值验证代码，并且输出测试结果。Wings运行单元测试过程中，会构建返回值的保存代码，将程序的返回值结果进行存储，然后读取用户输入的预期值，进行结果对比，判断是否通过。针对具体的类，对应生成gtest类，每个gtest类中对每个函数构建期望代码。例如针对BlockBuilder类，生成的gtest类为 GtestBlockBuilder。GtestBlockBuilder类的声明：class GtestBlockBuilder : public testing::Test { protected:     virtual void SetUp()     {         const char* jsonFilePath = "../drivervalue/RecordDecl.json";         Json::Value Root;         Json::Reader _reader;         std::ifstream _ifs(jsonFilePath);         _reader.parse(_ifs, Root);         driverBlockBuilder = new DriverBlockBuilder(Root, 0);     }     virtual void TearDown()     {         delete driverBlockBuilder;     }       DriverBlockBuilder* driverBlockBuilder; }; BlockBuilder类中的每个函数对应一个gtest函数，每个函数负责调用DriverBlockBuilder编写的驱动函数，对于包含返回值信息的函数，则对应生成具体的期望值对比。 期望对比函数CurrentSizeEstimate：TEST_F(GtestBlockBuilder, DriverBlockBuilderCurrentSizeEstimate4) {     const char* jsonFilePath = "drivervalue/BlockBuilder/CurrentSizeEstimate4.json";     Json::Value Root;     Json::Reader _reader;     std::ifstream _ifs(jsonFilePath);     _reader.parse(_ifs, Root);     for (int i = 0; i < BLOCKBUILDER_CURRENTSIZEESTIMATE4_TIMES; i++) {         driverBlockBuilder->DriverBlockBuilderCurrentSizeEstimate4(i);         Json::Value _CurrentSizeEstimate4_Root = Root["CurrentSizeEstimate4" + std::to_string(i)];         /* return */         unsigned int _return_actual = _CurrentSizeEstimate4_Root["return"].asUInt();         /* return */         unsigned int _return_expected = _CurrentSizeEstimate4_Root["return"].asUInt();         /* return_expected */         EXPECT_EQ(_return_expected, _return_actual);     } }最后调用自动构建的main函数运行整个单元测试过程。5.3 参数捕获程序构建参数捕获是指在程序运行过程中获取程序的变量信息，主要包括函数的参数、全局变量、返回值等。Wings自动构建获取参数的程序，利用插装技术，将构建的捕获函数插入源代码中对应的位置，将获取的具体信息，写入值文件，可以将获取的数据作为单元测试的输入，在代码发生变更后，利用相同的输入判断是否得到相同的输出，进行回归测试。Wings的参数捕获代码存储在paramcaputrecode文件夹中。其中命名规则同驱动格式一样，将所有的driver替换为param即可。Wings针对每个类生成一个对应的参数捕获类，而参数捕获类中针对每个函数生成对应的捕获参数、全局变量以及返回值的函数。c++ 中类的成员变量是私有，无法从外部获取，Wings利用插桩技术，对每个类插入一个捕获函数，来获取类的私有成员变量。参数捕获类ParamCaptureBlockBuilder：class ParamCaptureBlockBuilder { public:   ParamCaptureBlockBuilder();   ~ParamCaptureBlockBuilder();   void ParamCapture_Reset1();   void GlobalCapture_Reset1();   void ReturnCapture_Reset1();   void ParamCapture_Add2(const Wings::Slice &key, const std::string &value);   void GlobalCapture_Add2();   void ReturnCapture_Add2();   void ParamCapture_Finish3();   void GlobalCapture_Finish3();   void ReturnCapture_Finish3(class Wings::Slice returnType);   void ParamCapture_CurrentSizeEstimate4();   void GlobalCapture_CurrentSizeEstimate4();   void ReturnCapture_CurrentSizeEstimate4(size_t returnType); };具体的捕获函数不再详细说明，具体信息可以在Wings官网下载试用版本查看。第六章 Wings类型以及面向对象语法特性的支持Wings能够支持任意的类型以及面向对象的语法特性。类型支持：l  基本类型，int、double、float、std::string等l  任意复杂的结构类型，结构体、联合体、枚举、链表、多级指针、数组、树、图等l  任意复杂的类对象，标准库容器、自定义模板类特殊模板：n  区分用户自定义的类型与系统变量类型（标准库头文件中包含的类型）n  类的运算符重载函数n  void *与函数指针n  识别类中包含delete与default关键字的函数进行特殊处理语法支持：u  处理static函数、保护和私有函数u  类中定义私有结构体u  类中包含delete与default关键字的函数进行特殊处理u  多态与复杂的类继承6.1链表针对链表类型，采用比较灵活的赋值方式，考虑到实际应用中的一些因素，针对链表类型，默认赋值两层结构，在实际测试过程中，用户可依据需要自动添加节点。6.2 标准库容器Wings能够支持c++的标准库容器，能够对容器进行逐层展开，利用不同容器的标准赋值函数进行赋值以取值。其他类似的容器例如QT中的容器以及boost库中的相关容器，我们在继续支持。6.3 自定义模板类一些用户自定义的模板类类型，Wings能够识别是用户自定义的模板类，Wings依据实际程序中的赋值类型，进行处理。6.4  void*与函数指针Void*与函数指针在实际程序中可以作为函数参数或者结构体与类的成员变量，针对不确定的赋值类型，Wings提供了具体的解决办法：①　利用编译底层技术，对源程序静态分析，获取真实类型，对真实类型进行赋值②　由用户在数据表格界面配置实际类型6.5 特殊模板在实际的代码程序中，会存在一些类型无法使用通用的模式全部展开,如一些系统变量（FILE、iostream）、第三方库以及一些用户需要特殊赋值。Wings是如何针对以上特殊类型进行赋值，举例如下：struct sockaddr_in {         short   sin_family;         u_short sin_port;         struct  in_addr sin_addr;         char    sin_zero[8]; };步骤如下：a.        识别sockaddr_in为系统变量类型，特殊标记b.        检测程序中的所有系统变量类型，显示在模板界面c.         用户配置特殊变量，如sin_familyd.        构建sockaddr_in对象e.        调用模板，生成驱动模板配置如下：图：6.5模板配置  第七章 数据表格Wings目前测试用例数据采用随机生成的方式，支持int、char、double、float、bool、char*类型。数据表格可以任意编辑以上类型的数值。(1)Wings数据表格将会针对参数进行展开，假如参数类型为结构类型，数据表格将分层展开结构的类型，到基本类型。(2) 针对基本类型的指针类型，例如int *p;Wings处理为不定长度的一维数组类型，int **p;处理为不定长度的二维数组类型，默认长度为3，数据表格界面可以点击进行添加和删除数据。(3) 针对不定长度的数组作为函数参数，例如int p[];Wings默认长度为1，用户依据需求，在数据表格界面进行任意添加和修改即可。图 7-1数据表格展示 附录A表一：type属性ZOA_CHAR_S/ZOA_UCHAR/ZOA_INT/ZOA_UINT/ZOA_LONG/ZOA_ULONG/ZOA_FLOAT/ZOA_UFLOAT/ZOA_SHOTR/ZOA_USHORT/ZOA_DOUBLE/ZOA_UDOUBLE基本类型StructureOrClassType结构体类型ZOA_FUNC函数指针类型ZOA_UNION联合体类型ZOA_ENUM枚举类型ClassType类类型  表二：basetype属性BuiltinType基本类型ArrayType数组类型PointerType指针类型StructureOrClassType结构体类型UnionType联合体类型EnumType枚举类型FunctionPointType函数指针类型 表三：其他属性Name代表结构体、类、联合体名字NodeType代表链表类型parmType代表函数参数类型parNum代表函数参数个数SystemVar代表此类型为系统头文件类型value代表枚举类型的值bitfield代表位域类型所占字节returnType代表返回值类型Field类成员变量Method类构造函数paramName类构造函数参数名paramType类构造函数参数类型TemplateArgumentTypeSTL结构参数类型WingsTemplateArgumentSTL结构嵌套参数名字TemplateArgumentValueSTL结构中参数为具体值FunctionModifiers函数访问权限FunctionAttribute函数是extern或者static函数FuncClassName函数所属类OperatorFundecl重载运算符函数Operator重载运算符类型

第一章 精准测试诞生的背景（附完整版精准测试讲解视频和白皮书pdf下载）20年前（2000年），上网是一件很酷的事，叫做“网上冲浪”，主要是几个门户网站占据绝大多数注意力；20年后（2020年），我们已经全方位“浸泡”在软件的海洋里，很多大型软件系统已经超过亿行，架构模型越来越复杂。未来的20年（2020-2040年），随着各种智能应用的层出不穷，软件系统内部逻辑会不可逆转的越来越复杂，而外部操作会越来越“傻瓜”。用户一个眼神或者一动脑，就能够切换出不同的功能需求。同时中国的软件产品化进程，近些年来正在蓬勃的进行，大量的公司开始研发自己的产品。伴随着关键核心软件的国产替代，使得原本应用级难度的开发正在向高复杂度和高质量的产品型研发转型。这个转型的过程，注定将产生对于高端测试工具的巨大需求。软件缺陷发现得越晚，其处理费用即呈几何性激增，而不是线性增长。如何从庞大复杂的系统中迅速及时地找到故障所在，一直是行业的一大难点。无法对大型软件进行有效的质量把控，就无法真正构建与维护大型软件。目前国内软件测试基本处于两种状态：一是绝大多数企业采用功能（黑盒）测试，二是小部分对软件产品有高可靠性要求的软件，企业会使用代码级的白盒测试工具。但这两种传统测试办法在目前的软件日趋智能化复杂化下，弊端越来越明显。功能（黑盒）测试技术**，使墨菲定律在所难免。**由于无法获知程序内部逻辑结构，这种测试办法对软件可靠性要求不高的应用来讲问题不是很大，但是对于大型金融机构、智能工业、航天军工等关键系统，就意味着时刻携带隐形的巨大风险。为此，功能测试后期需要极高的人力投入才能完成复杂逻辑的用例分析和设计。然而对于黑盒测试来说，程序越大，杀虫剂效应越明显。而行业内当作银弹的自动化测试，当自动化程序本身规模扩大以后，它的维护本身就存在了很严重的问题。低效的黑盒测试状态，最终将影响和制约未来整体软件发展。代码级（白盒）测试工具一般重点应用在研发阶段的单元测试上，满足了客户的部分高可靠性需求，但由于其价格高昂、技术老化，仅适合于小规模迭代瀑布式开发的软件，无法完成复杂的系统级别的测试以及分布式基于云的测试，更不适应敏捷迭代的开发模式。另外白盒测试工具基本都是国外产品，通常这些产品无法完成深度的定制化功能实现以及快速的用户响应，代码安全更是一个较大的问题。所有先进的科技都是具备前瞻性眼光的。随着国内军民各项大型核心软件系统的上马，研发一种面向高复杂度大型软件、自主可控的高性能智能精准测试平台的必要性，逐渐凸显。在这个时代背景下，2012年初，星云测试团队开始了筚路蓝缕、心无旁骛的研发征程。精准测试是个交叉学科，里面涉及到编译器、测试分析、图形技术、高性能通信与存储，软件的研发等多项底层技术。经历无数个不眠之夜对技术难点突破的煎熬与最佳解决方案的反复推敲，星云精准测试产品在诸多方面率先实现了重大技术创新，成功突破了白盒测试使用难度大、价格高昂的桎梏，有效消弭了国外高端测试产品垄断的壁垒。星云精准测试产品更偏向于软件测试业界的“灰盒测试”，即用简单的黑盒操作办法，可以同时得到单元级和系统级的精准测试数据。“星云精准测试”不负众望，在众多性能上大幅超越国外进口高端白盒测试工具产品，并在数据追溯、覆盖率可视化、智能回归、智能缺陷定位、分布式数据穿透与追踪等特性上有突出贡献。星云精准测试，既继承了传统功能测试前期的高效率运行区间，又能在后期通过系统的数据，让开发、测试充分协同，完成全程高效的测试与数据分析。（1）将测试团队的价值放大，能够将开发与测试更加紧密的连接起来，互为支撑。（2）采用精准、可信的测试技术，测试管理的难度大幅度降低。（3）降低企业对人员的过度依赖，通过系统适应人员的变更。（4）为企业实现测试数据资产的有效积累和分析，打下坚实基础。“星云精准测试VIP大企业离线版云平台”在整体测试试功能上的优异特性，成功获得了一批重要大型企业的高度认可及产品采购。星云测试的首发版本为：穿线测试 ThreadingTest，2014年6月6日上线，侧重于系统级白盒测试技术，测试用例和代码逻辑的双向追溯技术，测试示波器技术，覆盖率可视化技术。2015年8月6日，“穿线测试”正式更名为“星云测试”。在继承穿线测试整体技术上，星云精准测试增强了回归测试用例的自动选取技术，缺陷最后执行时序分析、智能缺陷定位、敏捷环境下多版本白盒测试数据的聚合、聚类分析、结合代码结构与动态数据的测试漏洞检出、代码安全特性，全面的测试管理特性等几十种优秀功能。目前有“星云精准测试VIP大企业离线版云平台”、“星云精准测试PASS在线云平台www.teststars.cc”、“全自动测试用例驱动生成系统Wings”等多种工具产品。星云精准测试旗下产品平台有Horn、Paw、Shell、Wings等系列产品。适用语言和平台暂为：为响应广大用户的需求，目前正在进一步扩展适应的语言和平台覆盖面。图1-1 精准测试在大型系统的效率运行分析星云精准测试，既保证了传统功能测试前期的高效率运行区间，又能在后期通过系统的数据，让开发、测试充分协同，完成全程高效的自动化精准测试。第一章 精准测试技术体系对软件测试技术的升级解析精准测试技术体系经过近6年的商业项目实践日臻成熟，大量商业应用案例的正面积极反馈，表明它已经成为新的软件测试技术方向体系。星云精准测试灵巧详细的功能设计和高度可靠的产品内核得到了市场的广泛认可，对于国际上原有的白盒测试工具来讲，是一种质的飞跃。2012年，精准测试的商用工具正式进入设计和研发阶段。与引进国外技术不一样，精准测试的核心技术体系是星云测试团队在国内的原创设计和研发。产品经过3年的悉心研发、反复内测、不断优化后，2014年精准测试在CSTQB会议上，发布了第一个商用版本ThreadingTest，引起了很大反响。6年前，行业上还全面沉浸在黑盒测试的大氛围中，从未见过精准测试的超前的运行方法和提供的强大智能的功能，由于理念与设计过于超前，早期有一些业内质疑的声音。但由于产品独到的优秀特点和巨大的潜在价值，诸多伯乐开始试用，给了产品在实际场景中不断优化、强化的宝贵机会。经过不同领域、不同客户的各种高复杂度大型系统的百般锤炼、验证后，自2016年开始，精准测试开始赢得全行业的重视和响应。优秀的商用落地性是精准测试技术流行的一个重要因素。由于精准测试把准了黑盒测试无法解决的难题和固有瓶颈，踏准了测试技术发展大的进程，并从设计一开始就特意注重了商业场景下使用要求复杂性，因此它从诞生之日起就不仅仅是一套理论，而是有着非常强的实用性基因和可扩展架构，多场景应用成果卓然。精准测试最底层的核心技术：“一种基于用例与源码双向追溯的测试装置及方法”，类似在重建量子纠缠的场景和数据。它成功的将功能用例和对应的代码二者之间的追溯路线，实现了精准无误的可视化。这彻底解决了在黑盒的状态下，软件工程师们无法获知程序内部运行轨迹的难题。自此开始，计算机处理海量测试数据的强大分析能力开始展现。我们知道，所有的黑盒测试都是人工进行的，它依赖的是人的算力，而软件正确性验证的工作量，主要是组合路径膨胀的问题，人的算力是远远跟不上的。那么精准测试如何从测试的角度对业务进行深度的测试辅助分析呢？我们用量子纠缠的形象类比来说明这个问题。量子纠缠理论我们可以简单理解为两个处在纠缠态的粒子一旦分开，不论分开多远，如果对其中一个粒子作用，另一个粒子会立即发生变化，且是瞬时变化。“一个粒子”会与“另一个粒子”产生相互作用，两个表面互相不关联的粒子，互相作用互相影响，他们对外是一个整体，无法单独描述“单个粒子”的性质，只能描述这“两个粒子”的整体性质，这就叫做“量子纠缠”。类比到软件测试上，我们的被测试软件中常见的软件界面和功能输入输出以及渲染它的复杂代码，他们之间就和两个纠缠在一起的粒子一样，具备强关联性。一个发生了变化，另一个必定发生变化。精准测试的另一核心功能是：“回归测试用例的自动选取”，就是基于用例和代码的追溯（量子纠缠）关系在进行运算之后全自动得出的。用例和代码精准的追溯机制，使数据开始可以实施大量的智能测试算法。在软件测试理论界，大量论文算法的基础都是默认建立在用例和代码的关系上进行分析的，但因其追溯机制工业实现难度极大，所以一直停留在学术理论阶段。星云测试引领的精准测试方法体系，落地在精确便捷的商用产品和大型解决方案中，让大量先进的测试分析方法和理论，得以实实在在的验证。精准测试首次明确的提出了：如何采集和应用双向追溯数据，进行测试辅助分析系统的构建。不管是纯软件系统还是运行在设备中的软件系统，用例与代码精准的数据可追溯性，都是基础性的强需求。比如金融转账业务、用手机拍照、机器人控制器的动作控制指令等，每个操作都有与之对应的代码。星云精准测试产品的强大之处在于：所有的分析算法不需要和被测系统的业务功能做特定的适配，因此可以应用于任意软件系统的测试辅助分析。而传统的白盒在产品实现上以采集和分析总体覆盖率为主，没有能力将覆盖细化到用例层级，因此传统的白盒测试囿于覆盖率的概念中，无法实现更高层次的测试辅助分析需求。星云测试产品的技术优越性及应用的易用性，使它成为新一代软件测试技术流的中坚力量。星云精准测试在企业应用场景中，为了方便客户还设计了完全静默的“傻瓜”运行模式，客户基本无需增加额外的学习成本。比如测试工程师打开测试用例的excel表格，当他准备执行某个用例的时候，只需点击这一项测试用例。随后通过VBA技术，直接调用星云精准测试的后台接口，再附加一整套深入应用后台执行线程的用户标签技术，就可以将用例和代码关联和分离出来（这里说的分离是指类似于J2EE服务端后台应用）。在对外提供多用户并发访问的情况下，可分离出每个用户执行的用例所对应的相应代码。前面我们提到功能和代码这两个量子数据的重建，以前主要出现在研发/开发人员相对比较零散的执行单步调试功能的时候（即单元测试），无法存储。国外白盒工具因其设计基因的限制，无法支撑超大型、高复杂度的系统级测试需求。在星云精准测试体系中，只要测试工程师执行测试用例，几乎不需要额外付出，在建立测试用例与数据的对应关系的同时，瞬间即可将海量数据实时采集并存储起来，用于后续测试大数据的分析和运算上。它的内核设计，使之可以轻松应用在数亿行的超大型应用上，实时采集、存储测试数据，而对原有系统的响应性能不产生干扰。星云精准测试对软件测试体系是重大的技术革新，它从以下几个层面改变并提升了测试：对软件测试的深度进行了大幅度的拓宽，让计算机有能力直接对测试用例进行辅助分析，给出更深入的测试决策分析依据。传统测试主要通过人工业务测试发现缺陷，定位缺陷必须由开发人员进行，二者信息没有精确的数据交互。精准测试主要基于测试人员标识的用例状态，以及自动记录的用例对应的代码路径进行频谱分析。它可以自动计算缺陷产生的代码位置，在发现缺陷的同时，同步产生缺陷定位的结果数据。精准测试提供的测试用例的聚类分析，是基于测试用例的路径空间距离进行聚类，聚类的结果可以直接对用例执行正确性进行审核，对用例进行等价类划分、分析缺陷密集区以及对用例执行分布进行评估等。精准测试提供的回归用例选取结果，经由海量的计算精准推荐而来，总体算法思路与人工分析的思路是类似的，采用人工智能算法模式把大量的计算完全交由计算机去总结分析，精准、稳定、可靠、高速。这个功能相当于解放了测试和开发团队大量的人力资源，彻底解决因团队成员变更而引入的未知风险。精准测试开辟的测试方法新体系，支撑了黑盒测试快速提升测试效能比的刚需。精准测试对于企业来讲，相对于比需要人工编写、维护庞大自动化脚本的自动化测试，工作量是低很多的。精准测试和自动化测试是并行的技术方向，企业应用可以根据各自团队的特点来选择，并没有绝对的应用时序依赖关系。自动化测试近些年的应用遇到一个广泛的批评就是：让测试团队疲于应付用例的编写而不是测试用例设计等测试核心技术。精准测试属于测试分析系统，着眼点和立意相对较高，在测试理论、方法和商业应用落地验证与成果上，形成较好的整体闭环。它把测试需要关注的核心，引领到一个正确方向上来。精准测试在技术特性上解决了测试结果可信性的问题。在精准测试之前，我们所见到的所有测试数据都是易伪造、易篡改的。例如我们通常使用的测试管理系统，一个用例是否被有效执行，绝大部分是在测试管理系统中被人工录入的。精准测试是在用例动态执行过程中，由计算机内部算法真实记录对应的程序运行逻辑，然后形成后面对测试数据进行精确分析的数据源基础。所以其底层程序运行的数据是没有办法也绝对不允许进行伪造和篡改的。精准测试果断去除了阻碍测试行业发展的重要障碍，让测试的结果精准化、可量化、可衡量化、可信化。此举，将大幅减低测试行业本身的管理成本，有效推动测试行业的快速、健康发展。精准测试大幅提升了开发和测试部门的协作效能。前面提到全景调试器，测试工程师执行完用例，即时产生代码层级的全景调试数据；测试完成后一旦用例存在缺陷，那么基于这个全景调试图以及高度可视化的数据路径追溯，开发人员可以直接对缺陷进行定位，不需要在开发环境下重现缺陷，再单步调试以解决问题。实施精准测试之前，开发人员苦于很难有效参与对测试用例进行审核；实施精准测试后，用例的执行结果都映射到了代码层，开发人员通过代码的覆盖视图很容易就可以协助测试人员补充和确认用例，开发和测试的协作变得非常简单和直接有效。      不可否认，在精准测试之前，开发和测试存在沟通不畅的问题。通过精准测试在项目中的有效实施我们会发现，精准测试可以帮助开发提供非常有价值的数据： 例如代码和用例的反向追溯可以帮助开发人员修改代码做参考，精准测试自动计算回归范围减轻了开发人员必须协助测试进行分析的工作量，因此，精准测试对开发和测试来讲，是一举两得、相得益彰的。星云精准测试发明了多个全新的、适应敏捷迭代开发模型下的覆盖率计算方法。覆盖率是白盒测试最基本的技术，但是随着敏捷迭代的开发模式，即使最高端的白盒测试工具已经几乎没有用武之地，原因就在于由于迭代很快，在某个版本上通常只能采集少量的覆盖率后新版本就发布了。本应在一个版本上分析的覆盖数据，分布到了数个代码结构不一样的程序版本上，因此原有的统计方法和参考意义基本上都失效了。精准测试提供了累计覆盖率，能够将多个版本的覆盖率以最新版本的代码结构进行投影，在控制流上进行累加。这样测试团队无需关注每个版本的覆盖情况，即可关注一个完整测试周期内所有版本的累积覆盖率。另外，考虑到敏捷迭代每个版本的测试需求，即：针对特定模块和功能范围进行测试（并不是全量测试），精准测试提供了相关覆盖率的计算方法。它可以自动圈定某个用例和用例集有关的代码范围（这些也是基于用例和代码的关系分析基础上动态计算的），在运行少量用例或者某个功能模块的情况下，它可以自动确定相关代码，把不相关的代码从覆盖率的分母中过滤掉。这样相关覆盖率在仅仅运行部分少量用例的情况下，依然具有很强的统计和参照意义。第三章 精准测试的定义精准测试定义：由中国团队发起并原创完成测试理念设计和商用产品研发的全新测试技术。旨在测试用例执行过程中，全自动建立任意运行模式的软件系统的功能点与源代码之间高度的可视化追溯机制，获取功能点相关的代码覆盖率并进行精准回归等测试用例深度辅助分析算法的应用。精准测试是测试理论界首次同时使用测试用例及其相关代码两个关键因子，进行质量综合考量和分析的创新测试方法体系。3.1 基本定义星云精准测试在测试用例执行过程中，可以同步全自动建立任意运行模式的软件系统功能点与源代码之间的高度可视化追溯机制，即通过内部算法能够将缺陷对应的代码出错位置直接定位出来；能够获取功能点相关的代码覆盖率并进行精准回归等，使测试用例深度辅助分析算法得以强化应用。这是软件测试首次同时使用测试用例及其相关代码两个关键因子，进行质量综合考量和分析的创新测试理论方法体系。这种有效的数据追溯与“量子联动”的突破性技术特性，大大增强了测试的深度与广度，打破了测试部门的成长天花板，为测试过程本身的价值挖掘和测试数据资产的增值，提供了必要而充分的条件。3.2 关键技术精准测试体系贯穿整个软件测试生命周期。精准测试主要侧重于系统级测试，在单元测试、集成测试、系统测试、验收测试、回归测试中，均能赋予测试数据强大的追溯能力。关键核心技术有：测试用例和代码逻辑的双向追溯，测试示波器、覆盖率可视化、回归测试用例的自动选取、缺陷最后执行时序分析、智能缺陷定位、敏捷环境下多版本白盒测试数据的聚合、聚类分析、结合代码结构与动态数据的测试漏洞检出等。精准测试在测试用例执行过程中，为用户从底层自动建立任意运行模式的软件系统功能点与源代码之间的可视化追溯机制，使用户获取用例级的代码覆盖率等多种高级测试数据。这一突破性的创新智能算法，有力的打破了软件开发、测试、维护及管理人员等之间的数据孤岛状态，实现了软件测试过程和结果的高度精准可视化，在软件高可靠性和高可信度方面，提供了全面而有力的数据支撑。精准测试运行模式是灰盒模式，即：可以在黑盒功能测试的时候，同步完成数据采集和分析计算，让“点测”团队也可轻易切入到精准测试模式，无需改变现有测试形式与流程，不增加额外的技术学习与转换成本。3.3 应用范围精准测试适用于任何形态的软件系统。星云精准测试可应用于各种软件包括嵌入式系统、分布式系统、web应用系统、单机软件系统等各类软件的测试，并且完全不受限于被测试软件本身的业务需求。3.4 用户收益实现从发现缺陷到预防缺陷的转型。减少因为缺陷而对整个研发运维流程造成的返工成本。使发现缺陷前移，减少因项目后期的严重缺陷而导致产品交付延期、成本增高，影响交付质量。建立跨需求、开发、测试等部门的测试协同平台。实现业务数据可追溯化和路径可视化。优化技术与业务方案。根据不同的质量要求，优先级顺序、技术实现手段等，实现智能灵活的技术方案推荐、交付和应变机制。减少无数据支撑造成的内耗。企业“精准众测”平台，支撑千人团队同时在线。测试数据可以根据管理需要做分析，为企业内的成本管控提供选型参考。实现跨地区，跨部门的业务人员，开发人员和测试人员的测试协同，即使不在同一办公地点的人员，也可针对测试需求，测试任务，测试用例和测试缺陷等方面进行远程沟通和实时协同作用，最终完成整个测试过程的实施。支持敏捷开发与测试模式。关注新功能的增量测试，支持自动化回归测试，实现高效的IT交付。第四章 精准测试的基础架构介绍4.1 精准测试的技术架构精准测试从某些层面来讲，赋予了测试用例真正的生命力。测试用例是测试数据的一种，当测试数据实现路线可追溯可视化的时候，一些高级算法的强大能力就可以显示出来。我们从精准测试的整体架构图中可以做一具体分析。图4.1-1 精准测试的总体架构图第一层：利用先进的前置编译器，为客户做源码静态结构分析（在客户的实际环境中，根据客户的需求进行相关的技术配合）；第二层：将处理好的系统程序放入测试环境运行，测试工程师通过人工或程序自动化的形式，开始执行用例（人工执行用例可以和测试管理平台或者Excel表格方式进行对接)，精准测试的 “软件示波器”采集运行数据并进行高速智能运算，获取精确的测试数据；第三层：根据采集的代码与对应的测试用例，在星云精准测试平台中实现用例与源码的互相追溯；第四层：通过精准测试的分析平台，可以对测试数据进行缺陷定位、用例聚类分析、回归测试用例和最小测试用例集等功能的计算，用户还可以根据需求，批量生成相应的测试报告，或进行测试数据高级分析。图4.1-2 精准测试的用例魔方在总体业务架构图的左上角区域，我们可以看到“用例魔方”几个字。大家可能会比较好奇“用例魔方”的涵义，它是精准测试中非常核心的高级回归功能之一。所谓“魔”是精准测试核心算法所赋予的超能力，所谓“方”实际上是代表测试用例的集合，每个测试用例用一个小方块标识，所有测试用例的集合用一个大方块。当我们把精准测试的和用例分析相关的功能画成架构图形表示的时候，它自然而然地看起来就像魔方。精准测试体系中，测试用例对应的代码逻辑精确而完整的实现了全自动化的追溯和存储，因此赋予了测试用例深入分析的基础能力。在精准测试的用例魔方中，目前存在三个面（随着后续功能的增加，将增加分析的面）：即回归测试用例选取、测试用例聚类分析、测试用例最小化，同时辅之以智能缺陷定位技术。当测试用例与代码的追溯关系建立的时候，测试魔方的核心功能区即同步构建出来。为数据的多角度分析，提供了丰富的资源素材库。4.2 软件示波器软件示波器是星云精准测试独有的功能，它如同软件的质量运行情况“追溯穿行器”一样，在测试工程师按下启动键的同时，即时开始建立用例与代码的自动关联。示波器把采集到的测试数据通过可视化的窗口界面进行实时展示，内容涵盖采集到的块、条件和函数信息。蓝色波形代表写入的数值，黄色波形表示读取的数值，用户可以清晰的看到被测系统的数据变化。它如同心跳监控仪一样，如果被测试程序发生了崩溃，软件示波器就像人的心脏停止跳动一样，一根横线拉直向用户报警。如果正常采集到数据，会有持续的波形展示出来，高效而精准地监控程序细微的运行状况。示波器精密捕获每个软件单元任何微小的运行波动和行为改变，支持多次运行数据的比对。它可以根据需要记录崩溃前的至少50个块，使“崩溃重现”变得轻松简单。软件示波器中的测试用例可以从现有的测试管理系统导入进来，先选中用例点击开始，驱动被测试系统运行后，软件示波器就会采集到程序内部运行逻辑对应的波形信息。用例执行结束后，点击停止。这个用例运行阶段的数据，通过开始和结束的点击，边界就记录下来了。图4.2-1 软件示波器面板的正下方可以展示函数的各种调用信息。包括类、函数，参数类型等。清晰的列示出参数列表、类运行情况、内存检测数据、数据库拦截等多角度的数据分析追溯情况信息。示波器观测的维度较多，用例与代码的追溯是精准测试的基础功能，后面的高级算法都在这个基础上展开。用例和代码的追溯就像一个全景的调试器，只要功能由测试人员运行，所有的内部代码执行逻辑瞬间就可以展示出来。通过测试数据的反向追溯分析，开发人员可进行一致性修改，避免修改引入新的缺陷，通过正向追溯结果，开发可对用例的执行进行全面掌握，可用于快速修复缺陷和详细实现确认。同时软件示波器也提供一个辅助的等价类划分的功能，它将一个用例从开始到结束所执行的路径信息终值，完整记录下来。如果两个用例终值不一样，就可以确定为不是等价类。对于很多从功能表面很难界定是否等价类的测试用例，软件示波器可以给出精确结果。因此软件示波器的价值与意义在于：（1）只要测试开始执行，即可以透明方式高速采集功能运行过程中对应程序的运行逻辑。（2）在系统高速运转下采集，可保证对原有应用无干扰，超过1500w/s的采集速率。（3）可采集程序的条件，执行路径，执行参数，内存使用等动态运行数据。为了方便客户在运行项目测试时，一边对被测系统做实时数据监测，一边同步观察到示波器里面数据写入和读取的波形，星云做出了实时数据监测的悬浮窗缩略图，减少了切换带来的工作量。它不影响原有被测系统的界面，以半透明悬浮的方式展示在被测试应用界面的前面。图4.2-2 软件示波器悬浮窗4.3精准测试的双向追溯精准测试的测试用例和代码的双向追溯功能，是精准测试核心技术之一。如同前文的“量子纠缠”，即运行测试用例的同时，精准测试可以通过程序自动的记录并追溯到这个测试用例相应执行的代码。如果测试人员关注某一些代码行，它可以追溯出哪些测试用例在运行过程中运行过这段代码。通过这个技术特性，测试工程师的每个测试用例都可以进行量化分析和统计，提供了开发人员和测试人员之间精准的数字化交流依据， 增加测试和开发的交流效率。双向追溯技术记录了每个测试用例对应的程序内部的执行细节，细致到每个条件、分支、语句块的执行情况。开发人员亦可通过双向追溯的结果去理解程序逻辑，进行软件维护以及进行可一致性的修改。4.3.1 双向追溯技术正向追溯将测试用例和代码执行信息自动关联，可追溯到函数级别及代码块级别；通过正向追溯可直接把BUG定位到故障和缺陷逻辑相应的代码，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。图4.3.1-1 双向追溯(正向)-测试用例追溯到代码图4.3.1-2 双向追溯(正向)-测试用例追溯到代码4.3.2 双向追溯技术反向追溯将代码执行、函数、代码块级别和测试用例执行信息自动关联；通过反向追溯可直接观察代码变动所影响的测试范围；协助开发，进行代码修改后影响功能的范围评估；协助测试人员对代码修改部分所影响的测试用例进行评估。图4.3.2-1 双向追溯(反向)-代码追溯到测试用例图4.3.2-2 双向追溯(反向)-代码追溯到测试用例4.3.3 数据追溯技术-追溯测试用例的全景调用精准测试通过正向追溯把测试用例运行的代码执行进行了全景绘制，在全景图中，测试人员可以有效的观察到函数之间的整体的调用与走向，观察出被测模块与上层之间的调用关系。图4.3.3 测试用例运行的代码整体调用第五章 精准测试的核心组件与功能精准测试的核心组件与功能：软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统等，完整的构成了精准测试技术体系。精准测试系统本质是一套强大的计算机开发与测试系统，实现了数据的可视化联动，以及开发辅助分析。它的关键技术赋予了测试用例和代码强大的相互追溯能力，随后衍生实现了很多高级测试功能与算法。精准测试系统将用例深入到代码层分析后，可以大幅改进人工测试所产生的各种问题。接下来将从风险控制、工作协同、敏捷迭代方面详细解析精准测试的核心功能和实际收益。5.1 风险控制5.1.1 七种测试覆盖率星云精准测试提供7种测试覆盖率：分别为：SC0语句块覆盖率、True覆盖率、Both覆盖率、CDC覆盖率、Branch覆盖率、MC/DC覆盖率。用户首先选择分析覆盖率的维度，例如选择了“SCO语句块”维度，那么系统就会将被测试程序的所有语句块结构展示出来，并且用颜色表达覆盖情况，绿色代表覆盖，深蓝色代表未覆盖。同时告知覆盖率的分子和分母都是哪些，非常清晰的展示覆盖率可视化结果。精准测试在前期已经对程序的静态结构进行了深度的分析，因此用户在覆盖率可视化界面，根据选择的维度在代码层面上把需要展示的结构单元都结构化的展示出来。例如图5.1.1-1 七种测试覆盖率中的第二张图 图5.1.1-1 七种测试覆盖率MC/DC覆盖率可视化MC/DC覆盖率，即修正判定条件覆盖，该覆盖率数据 MC/DC是DO-178B/C Level A认证标准中规定的、欧美民用航空器强制要求遵守的覆盖率标准。MC/DC覆盖率可以基本保证被测试软件无缺陷，对于大型系统的可靠性要求很高的一些关键模块，建议采用这个覆盖率标准。MC/DC覆盖简单来说，就是追踪复合条件中每个子条件的真假翻转，在其子条件不变前提下，是否都独立的影响了整个条件的真假值。星云精准测试系统会自动的把各种组合都列好，通过颜色表达哪些子条件已经满足，以及对应满足情况时其他独立子条件的组织情况。图5.1.1-2 MC/DC覆盖率可视化条件组合可视化展示精准测试对于多条件组合的代码，采用了最新研发的条件组合可视化视图进行展示。视图中，用户可以观察到每个条件的真假运行情况，以及条件与条件的组合运行情况。对于测试人员来说，当全部条件组合之间的T与F都完全满足时，即可实现代码全路径覆盖。图5.1.1-3条件组合可视化展示5.1.2 新增代码覆盖率敏捷模式下，因迭代频繁其存量的代码量很大，通常更关注增量覆盖度量。精准测试可以在程序新版本发布后，自动计算新增（变更）代码的范围，给出新增代码的覆盖率。覆盖率的分母中的函数都是变更和新增的函数。与此同时，基于反向追溯的功能，我们还可以给出新增代码对应的测试用例名称。当某个新增函数没有达到很高覆盖率的时候，我们通过反向追溯的用例，可以判定因为哪些功能范围的用例设计不充分，导致了新增代码覆盖率不高。图5.1.2 新增代码覆盖率5.1.3 测试覆盖率范围筛选与再统计在做精准测试或统计覆盖率时，往往测试管理者、开发人员、测试人员为了保证测试覆盖率的正确性，会对某个方法、类进行查看或在统计中把代码中一些废弃的函数、某些特殊情况下无法测试到的代码进行移除（至少是做相应备注），从而让测试代码覆盖统计率达到更加准确。星云精准测试在设计中，通过多种搜索、方法、类、模块过滤等功能，把需要统计的范围进行缩小、不需要统计的去除。根据用户的选择，进行覆盖率再统计展示。图5.1.3 测试覆盖率范围筛选与再统计5.2 工作协同5.2.1 打通开发与测试的隔阂精准测试打通开发与测试的协同工作通道，使得开发与测试能够更好的沟通，提高工作效率。传统模式下，开发人员关注的是代码，测试人员关注的是业务角度的测试用例，彼此的直接关联相对较弱。开发和测试的沟通，基本就是采用自然语言、Excel表格、内部系统等，存在交流信息不够严谨的问题。例如测试工程师发现一个缺陷，提交到缺陷系统，开发需要花费大量时间再行理解、准备数据、复现、调试，直到最后的修正。因为业务上的功能执行和代码并没有明确的关系，通常测试工程师执行完功能测试用例后，让开发人员帮助评审也非常困难。若测试工程师提供的测试结果都是比较模糊的功能逻辑描述，重现缺陷需要花费大量的时间。开发人员修改代码后，对于变更描述，以及变更引起的关联问题描述通常也都很模糊，导致测试又出现新问题。企业采用精准测试技术后，通过执行用例可以直接追溯到对应执行的程序代码块，这样的数据化沟通，将使开发人员和测试人员之间的协同工作效率大大提高。图5.2.1  协同模式5.2.2 源码动静态数据的统一星云精准测试通过插装得到的项目静态结构信息，结合测试后采集到的测试数据，能够精准记录测试的过程，通过这些静态数据和动态数据视图，便于开发人员基于图形化结果进行快速分析。对于不懂开发的测试工程师，通过程序控制流程图的图形以及通过颜色表示的覆盖信息，可以直接看到程序内部漏测的逻辑是什么，也可以通过这些结果直接与开发沟通，进行辅助用例和逻辑的补充。因为内部逻辑的强追溯性并且能够图形化的打开，可以有力保证黑盒测试后期开发快速理解并解决瓶颈问题，保持全程测试的高效执行。图5.2.2-1 源码静态结构与动态测试数据统一图（函数调用图）图5.2.2-2 源码静态结构与动态测试数据统一图（控制流程图）精准测试在程序静态分析的基础上，可以对程序绘制可视化的图形，同时将动态执行的覆盖信息染色到这些视图上。对于不懂开发的测试人员也可以很清晰的看到程序的哪些结构节点没有被覆盖到。例如图形中蓝色的节点是未覆盖的节点，绿色的是覆盖的，因为控制流程图本身有分支，嵌套等各种关系，测试工程师可以很容易判断出覆盖的范围大致是哪些。而如果有开发人员介入，可以更清晰地分析测试工程师执行的用例所遗漏的程序逻辑。图 5.2.2-3源码静态结构与动态测试数据统一视图5.2.3 缺陷最后执行时序分析星云测试可自动捕获缺陷或崩溃发生时，程序最后执行的详细路径信息。缺陷发生后，开发人员能够直接看到缺陷出现时，代码执行的时序和路径信息，直接定位缺陷并排查问题，节省大量的沟通、复现和调试的时间成本。当功能执行发现缺陷后，在软件示波器上可以立即按下“停止”键，那么最后执行的代码序列就可以被抓取到，开发人员可快速定位缺陷最后执行的50个代码块、条件、判断的各种执行信息。在下面视图中，我们可以根据标号（从1到50），看到代码最后的运行时序，在图形里面的每一个绿色小方块为一个代码语句块或者一个条件、判定，在一个大方框下的绿色方块代表一个函数内部的代码块。经过布局算法后产生下述图形。图5.2.3 缺陷最后执行时序分析5.2.4 智能缺陷定位通常测试工程师只是负责发现缺陷，缺陷的具体定位只能交由开发人员来执行。精准测试打破了测试部门的天花板，即通过内部算法能够将缺陷对应的代码出错位置直接定位出来。这相当于增加了测试深度，同时体现了测试数据和测试过程本身的价值。对于测试工程师来说，只要发现用例相似而程序在输出上有对错区分，就可以使用精准测试的智能缺陷定位功能。精准测试平台通过测试人员在功能测试阶段标记的用例执行状态，以及软件示波器自动记录的程序运行频谱，自动分析缺陷的出现的代码块。因精准测试平台可以获取每个用例执行时详细的路径追溯信息，测试工程师只要告知系统用例的状态，例如是否通过是否正确，那么精准测试内部算法就会去根据正确和失败的路径差异进行计算，给出缺陷出现具体位置的可疑度排名。这个功能可以大大增强测试在整个开发流程的参与度和测试数据价值，也让开发人员减少了自己去模拟场景的时间，快速提高开发和测试的协同和配合的效率。对于同类测试用例，经过多组测试可给出非常有效的结果。列出的可疑代码，可直接通过测试过程给出，提升测试的价值及产出。图5.2.4-1 通过功能测试频谱法分析进行智能缺陷定位选择可疑度算法、得到可疑度高的代码块，关联源码后，可根据代码可视化查看具体位置。可疑度计算有一个公式，并不复杂，通常每个代码块有2个变量，四种状态值。分别是：是否执行、是否通过，这样每代码块都有一个可疑度值。星云精准测试提供3种常用计算公式，供大家参考。aep表示通过且覆盖到该块的测试用例的个数、anp表示通过且未覆盖到该块的测试用例的个数、aef表示未通过且覆盖到该块的测试用例的个数、anf表示未通过且覆盖到该块的测试用例的个数。结果表示该块的可疑度。图5.2.4-2 智能缺陷定位展示5.3 精准测试对敏捷迭代的支持5.3.1 敏捷迭代下多版本白盒测试数据的聚合在敏捷环境下由于版本迭代速度很快，每个不用的代码版本上通常只能采集到少量的覆盖率。一旦发布新版本，就意味着代码发生了变化，覆盖率数据就需要重新采集，但是每个版本采集的少量覆盖率，从分析层面上并没有多大的意义。针对以上问题，精准测试给出了“**累计覆盖率”**的计算方法。它将一系列迭代版本的覆盖率，在最新的程序版本上进行投影累加。用户可将一个阶段各个版本的覆盖率累加起来进行分析。算法的思路是以最新版本代码为基础，以某个函数为单位，一直往前累加。直到这个函数在之前的某个版本代码发生了变化，就停止累加。例如下图函数A的4个版本的覆盖都可以累加，是因为这个函数在4个版本中都没有发生变化。而红色的函数B只累加了3个版本，是因为从版本v2.0-2后这个函数发生了代码变更。之前的代码覆盖就不能累加了。星云精准测试-敏捷环境下多版本白盒测试数据的聚合如图所示。图5.3.1-1敏捷环境下多版本白盒测试数据的聚合这种累加是在确保函数代码没有发生变化的情况下，在控制流上对相应节点的覆盖率进行累加。例如下图中3个版本，覆盖率不同的分支和控制流，数据累加后可以看到所有分支都覆盖到了。图5.3.1-2敏捷环境下多版本白盒测试数据的合并分析5.3.2 聚类分析星云精准测试提供的聚类分析功能，根据测试用例的函数执行剖面的向量化信息，对测试用例进行精确的空间距离计算后执行聚类分析。聚类结果可以分析被错误执行的用例，例如不相关的功能点聚类到一起，则说明其测试执行可能存在错误。精准测试提供的聚类分析功能，也可以辅助找到缺陷分布的密集区域。大部分情况下，缺陷分布会呈现2/8的聚集特性。在时间紧张的情况下，我们可以通过聚类结果，每个类选取中心点以及周边几个用例。如果没有问题，就可以去测试其他聚类，如果发现一个类缺陷概率高，那么这个类就需要进行重点测试。通过聚类结果可以分析测试用例的分布密度等信息，辅助进行测试决策。图5.3.2-1 测试密度下图中测试用例分类都有一个名字，这个名字是聚类结果中每个类中心点的测试用例名字，它基本标定了这个类的功能点范围。聚类的大小代表了某个功能范围测试是否足够充分。例如一些应该重点测试的功能，聚类结果中的用例数应该很多；一些小众的功能，聚类中用例数应该比较少。一个类中用例数越多，这个类圆圈比例越大，反之则越小。在聚类的基础上，我们也可以对一个类中的等价类用例进行分析。是等价类的用例，会分成一组专门展示。 图5.3.2-2 聚类分析5.3.3 覆盖率漏洞检出在敏捷迭代过程中，通常没有充分的时间将所有函数的覆盖率都达到一个很高的层级（Level）。精准测试结合代码结构和动态数据综合分析，通过计算直接筛选出潜在的高危测试漏洞，可以在短期内确定高危漏测模块并针对性的解决，帮助用户快速找到严重缺陷。当测试时间不充分的时候，执行完黑盒测试以后，先看测试漏洞列表，里面显示了通过静态信息和动态信息计算，得到的最高风险的漏测点模块。我们可以通过复杂度进行计算，因为复杂度高的模块一般来讲，它是相对重要的模块并且逻辑复杂，如果动态覆盖比较低，我们会优先筛选出来进行排序。处于调用和被调用中间的模块，因为属于中间关键模块，我们也会计算它的扇入扇出，和动态覆盖率信息。如果它的比率很高，将被认为是高风险模块，被筛选出来进行排序。回归时，应优先测试风险指数高的高危模块，补充他们的覆盖率。图5.3.3漏洞检测列表5.3.4 最小测试用例集精准测试也可以对用例集进行优化。比如用户有大量用例的情况下，尤其是自动化用例集含有长期维护的冗余用例。精准测试平台可以对很多重复用例的逻辑进行筛选和过滤，优化出满足当前总体覆盖的最小用例集。图5.3.4星云测试最小测试用例集第六章 精准测试支持不同剖面的分析报告在时间有限，经费有限，资源有限的情况下，我们既要考虑测试是否充分，也要顾及时间、人员、设备配置等限制条件。精准测试可以支持企业不同剖面的软件质量分析需求。6.1 详细的测试总结报告内容测试资源分析：多少人，多长时间、整体测试有效率及执行率测试结果分析：描述需求的测试结果，系统实现了哪些功能点，哪些还没有实现缺陷情况分析：缺陷复现、缺陷处理、缺陷数量、属性、状态分布，缺陷预防、缺陷收敛度度量指标分析：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率效率指标分析：进度偏离度、缺陷发现率、用例执行效率和质量等高风险识别与排序：注明当前项目中面临的最严重、最优先的问题整体评估：哪些功能已经实现，哪些功能还未实现，还遗留哪些问题，遗留缺陷分析优化建议：测试过程优化，从测试组的角度为测试工作提出建议图6.1 星云测试的差异报告分析6.2 高级回归测试报告对前期测试执行阶段发现的问题、缺陷集中的功能，业务比较重要且使用频繁的功能进行再次测试，确保系统上线后，已被修复的问题不会重新出现，重要的、高优先级的业务不会发生错误。图6.2智能回归测试用例选取6.3 测试用例库评估报告软件测试的主要工作，是把软件需求映射为软件测试。测试用例是软件测试全过程的核心，也是测试执行环节的基本依据。精准测试充分满足软件测试执行过程中的各种指标：测试用例执行进度测试用例通过率测试用例颗粒度分析识别无用的测试用例识别冗余的测试用例从侧面提供增添新测试用例的依据从侧面提供调整测试用例库结构的依据图6.3 测试用例最小集6.4 精准测试的VIP企业内网私有云可信化报表星云精准测试提供多个剖面的高可靠性测试质量进度追踪报表。当客户端录入测试用例并采集数据后，用户内网web端将产生实时、详实的测试数据分析报表。该报表与普通的测试管理系统不同：普通的测试管理系统人为录入数据的情况比较多，使得数据状态的真实性没办法确切保证。精准测试提供的报表，底层数据来自于执行测试用例时候代码数据的采集，通过专用底层接口上传，完全无法进行数据调整或者篡改和伪造。通过浏览器登录测试系统，选择需要跟踪的项目，就可以实时对整个测试的质量、进度、人员进行精准的分析和管理。企业内网云端管理系统展示的数据基于精准测试数据的分析，所有数据原生精确，支持移动测试+本地测试。测试团队、开发团队、甲方负责人等多种角色都可以登录系统，从各个层面对测试、软件质量进行分析。图6.4项目汇总展示6.4.1 精准测试的VIP企业内网私有云-测试效率的直观展示精准测试报告可直观分析每天的测试效率，通过代码模块和复杂度关系图，看到函数群落测试情况分布及趋势，可直观精准识别系统测试所处阶段。每日增长覆盖率报表：管理者可以清晰的看到整个团队的效率趋势变化，比如刚开始测试的时候覆盖率增长快，到了黑盒测试瓶颈点上升就很慢了。这时候精准测试技术就开始发力，可以清晰地看到它在弥补效率损失方面的优势。覆盖率和复杂度报表：可以很直观地看到测试的质量深度，例如在测试不充分的时候，复杂度高的模块通常覆盖率都比较低，统计点分布自一个左上角的区域（表示高复杂度+低覆盖率），而当测试深入进行，这些点就会向右侧移动。管理者可以非常直观的看到系统测试的充分程度和上线的质量把握。图6.4.1-1 覆盖率每日增长趋势图与黑盒测试瓶颈图6.4.1-2 测试效率换档点与测试深度趋势观察表6.4.2 精准测试的VIP企业内网私有云-测试用例排行图测试用例排行分析报表：可直观展示参与测试工程师所执行的用例数、通过率和缺陷率，真实记录并分析每个测试用例的实效性。星云精准测试-测试工程师实效精准分析系统，将参与的测试工程师所执行的用例从逻辑覆盖映射到代码覆盖，真实记录并分析每个测试参与者的工作实效。以逻辑覆盖为基准的而不是用例数量为考核标准。图6.4.2 测试用例排行图6.4.3 精准测试的VIP企业私有云-测试用例双向追溯与覆盖率可视化通过用户的内网精准测试web报表，可以追踪每个测试用例执行的覆盖率和执行的函数路径信息，那些没有真正执行的用例，将无法伪造其对应的覆盖率信息。图6.4.3-1测试用例双向追溯追踪每个用例执行的函数信息以及具体的代码覆盖信息，在web端展示代码覆盖率视图，更具体的分析用例的执行情况。图6.4.3-1覆盖率可视化6.5 精准测试在数字化转型中的作用 完成数字化转型。提高软件交付质效、实现快速迭代持续交付，有效呈现测试价值。培养业务和测试的“两栖专家”。从不同角度提供有价值的数据依据，使测试团队既能熟悉业务知识、业务场景，又具备较强的业务分析评估和整合创新的能力。数据化交付。实现企业内部云平台建设、明确各工程活动环节的交付物和交付标准，并将质量验证标准、验证手段和监控工具嵌入流水线，保证各环节的有效性，对质量趋势进行提示和预警，及早发现缺陷，实现质量可视、过程可追溯、可审计。建立测试数据资源池，整合测试资产。利用大数据、人工智能等技术建立质量智能分析模型等，为“产品质量智能分析平台”提供有效数据。减少因人员变动而产生的成本影响。一般外包人员的流失率普遍为20-40%左右，重新招聘和培养，将对项目进度及成本进度，造成很大影响。因篇幅限制，完整版可查看 星云测试官网（www.teststars.cc）

1

前言数据存储倾斜（即图中1-4被占用存储资源不均衡）是Shared nothing分布式架构下的重要难题，它破坏了MPP架构中各个节点对等的要求，导致倾斜节点所需存储及计算资源都远大于其他节点，进而导致性能下降（木桶效应）、full disk或oom等严重问题。技术背景目前各类分布式数据库厂商都有提供存储倾斜的检测工具，常用方法主要有计算表的COUNT,计算表的SIZE和通过统计信息计算这三种，下面以在GaussDB(DWS)分布式数据库产品为例，分别介绍这三种方式的优劣： 方法一：通过表的COUNT计算倾斜方案：例如使用table_skewness函数，其内部通过统计表在各节点的COUNT数实现postgres=# select dnname,num from table_skewness('mytable') order by dnname;    dnname    | num --------------+------  datanode1  | 4800  datanode2  | 5216  datanode3  | 5792  datanode4  | 5568  datanode5  | 5152  datanode6  | 5472 (6 rows)优点：简单粗暴，适用表数据量小且UPDATE/DELETE操作少的表；缺点：数据量大的场景计算表的COUNT比较耗时；脏数据占存储和SCAN消耗但不会统计； 方法二：通过表的SIZE计算倾斜（推荐）方案：例如使用table_distribution函数，其内部通过统计表在各节点的SIZE大小实现postgres=# select nodename,dnsize from table_distribution('public','mytable') order by nodename;  nodename  | dnsize -------------+--------  datanode1 | 221184  datanode2 | 229376  datanode3 | 253952  datanode4 | 253952  datanode5 | 229376  datanode6 | 253952 (6rows)优点：实时性好；准确度高；相比计算COUNT速度快；缺点：表对应数据文件多的场景性能会受影响，当前实测100+节点场景影响在可接受范围方法三：通过统计信息计算倾斜方案：使用pg_class中reltuples/relpages以及统计信息来计算倾斜CREATE OR REPLACE FUNCTION PUBLIC.pgxc_analyzed_tuples (     OUT schemaname text,     OUT tablename text,     OUT dn_name text,     OUT tuples real ) RETURNS SETOF record AS $$ DECLARE     datanode_rd     record;     fetch_tuples    record;     fetch_dn        text;     fetch_tuple_str text; BEGIN     fetch_dn := 'SELECT node_name FROM pg_catalog.pgxc_node WHERE node_type=''D'' order by node_name';     FOR datanode_rd IN EXECUTE(fetch_dn) LOOP         dn_name         :=  datanode_rd.node_name;         fetch_tuple_str := 'EXECUTE DIRECT ON (' || dn_name || ') ''SELECT n.nspname, c.relname, c.reltuples                    FROM pg_catalog.pg_class c                    INNER JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace                    where c.oid >16384 AND c.relkind = ''''r''''                     and n.nspname <> ''''cstore'''' and n.nspname <> ''''pmk''''                     and n.nspname <> ''''pg_catalog''''''';         FOR fetch_tuples IN EXECUTE(fetch_tuple_str) LOOP             tuples    := fetch_tuples.reltuples;             schemaname := fetch_tuples.nspname;             tablename  := fetch_tuples.relname;             return next;         END LOOP;     RAISE INFO 'Finished fetching stats info from DataNode % at %',dn_name, clock_timestamp();     END LOOP;     return; END; $$ LANGUAGE 'plpgsql' ROWS 1000000; postgres=# select dn_name,tuples from public.pgxc_analyzed_tuples() where tablename='mytable';   dn_name | tuples -------------+--------  datanode1 | 4800  datanode2 | 5216  datanode3 | 5792  datanode4 | 5568  datanode5 | 5152  datanode6 | 5472 (6 rows)优点：计算过程不需要实时SCAN，只需要通过已有统计信息来计算，速度最快。缺点：强依赖实时ANALYZE统计信息来保证实时性；不包含实际占用存储空间和SCAN 消耗的脏数据统计，准确度不如方法二。 小结以上三种方法主要针对单个表的倾斜查询，各有优劣，这里比较推荐准确度最高速度居中的方法二，并基于此方法实现了系统视图PGXC_GET_TABLE_SKEWNESS用于查询库内所有表的存储分布情况，例：postgres=# select * from PGXC_GET_TABLE_SKEWNESS; schemaname | tablename | totalsize | avgsize  | maxratio | minratio | skewsize | skewratio | skewstddev ------------+------------+-------------+------------+------------+------------+-----------+-----------+------------  public  | orders  | 705413120 | 117568853 |  .167  |  .166  | 278528  |  0.000 |  95628  public  | mytable  | 1441792  | 240299  |  .176  |  .153  | 32768  |  .023  |  15253  public  | customer | 131579904 | 21929984 |  .167  |  .166  | 131072  |  .001  |  46050  public  | part   | 101646336 | 16941056 |  .167  |  .166  | 114688  |  .001  |  38772  public  | supplier | 8552448  | 1425408  |  .168  |  .166  | 16384  |  .002  |  8974  public  | lineitem | 3351937024 | 558656171 |  .167  |  .166  | 1302528 |  0.000 |  516984  public  | partsupp | 461922304 | 76987051 |  .167  |  .166  | 401408  |  .001  |  148130 (7 rows)后面将语句基于table_distribution函数及PGXC_GET_TABLE_SKEWNESS视图，介绍如何在真实业务场景中及早、快速定位到存储倾斜的表。 实际操作场景从早发现、快定位、勤检查三个角度，介绍如何在实际业务场景中最大程度避免数据存储倾斜带来的影响。早发现：数据导入场景即时检测当前我们支持在数据导入过程对DN导入行数进行统计，导入完成后计算倾斜率，超过一定阈值时，立即进行告警。倾斜率通过（ DN导入行数最大值-DN导入行数最小值） /导入总行数计算，方法如下：1、开启即时检测的参数table_skewness_warning_rows：表倾斜告警最小行数，取值范围0～ INT_MAX，默认值100000，表示当导入总行数超过该值与导入DN数之积时，才可能触发告警，避免小数据量导入的场景进行无意义的告警。table_skewness_warning_threshold：表倾斜告警阈值，取值范围0~1.0，默认值为0，表示当DN返回行数的最小值和最大值的比例小于指定的倾斜告警阈值时，进行告警。2、执行导入（INSERT或COPY）当导入数据出现倾斜，执行SQL和日志中会发出告警，告警信息包括表名、最小行数、最大行数、总行数、平均行数、倾斜率，以及提示信息（检查数据分布或者修改参数）。WARNING: Skewness occurs, table name: xxx, min value: xxx, max value: xxx, sum value: xxx, avg value: xxx, skew ratio: xxx HINT: Please check data distribution or modify warning threshold 快定位：磁盘满场景快速定位倾斜表出现磁盘满场景，在表数量非常多的情况下，全量排查哪些表倾斜非常耗时，我们支持使用如下方式快速定位倾斜表：1、查询近期发生过数据变更的表通过pg_stat_get_last_data_changed_time(oid)函数查询出近期发生过数据变更的表，基于表的最后修改时间只在进行IUD操作的CN记录，要查询库内1天(间隔可在函数中调整)内被修改的所有表，可以使用如下封装函数：CREATE OR REPLACE FUNCTION get_last_changed_table(OUT schemaname text, OUT relname text) RETURNS setof record AS $$ DECLARE     row_data record;     row_name record;     query_str text;     query_str_nodes text; BEGIN     query_str_nodes := 'SELECT node_name FROM pgxc_node where node_type = ''C''';     FOR row_name IN EXECUTE(query_str_nodes) LOOP        query_str := 'EXECUTE DIRECT ON (' || row_name.node_name || ') ''SELECT b.nspname,a.relname                FROM pg_class a INNER JOIN pg_namespace b on a.relnamespace = b.oid where                pg_stat_get_last_data_changed_time(a.oid)                 BETWEEN current_timestamp - 1 AND current_timestamp;''';       FOR row_data IN EXECUTE(query_str) LOOP         schemaname = row_data.nspname;         relname = row_data.relname;         return next;       END LOOP;     END LOOP;     return; END; $$ LANGUAGE plpgsql;2、查看近期数据变更的表的分布情况postgres=# SELECT table_distribution(schemaname,relname) FROM get_last_changed_table() limit 6;         table_distribution -----------------------------------  (public,mytable,datanode1,221184)  (public,mytable,datanode2,229376)  (public,mytable,datanode3,253952)  (public,mytable,datanode4,253952)  (public,mytable,datanode5,229376)  (public,mytable,datanode6,253952) (6 rows) 勤检查：常规数据倾斜巡检1、在库中表个数比较少（<1W）场景直接使用PGXC_GET_TABLE_SKEWNESS视图来查询当前库内所有表的数据倾斜情况。2、在库中表个数非常多（>1W）场景PGXC_GET_TABLE_SKEWNESS涉及全库查并计算非常全面的倾斜字段，所以可能会花费比较长的时间（小时级），建议参考PGXC_GET_TABLE_SKEWNESS视图定义，直接使用table_distribution()函数自定义输出，减少输出列进行计算优化，例如：postgres=# SELECT schemaname,tablename,max(dnsize) AS maxsize, min(dnsize) AS minsize postgres-# FROM pg_catalog.pg_class c postgres-# INNER JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace postgres-# INNER JOIN pg_catalog.table_distribution() s ON s.schemaname = n.nspname AND s.tablename =c.relname postgres-# INNER JOIN pg_catalog.pgxc_class x ON c.oid = x.pcrelid AND x.pclocatortype = 'H' postgres-# GROUP BY schemaname,tablename; schemaname | tablename | maxsize | minsize ------------+-------------+-----------+-----------  public  | orders   | 117686272| 117407744  public  | mytable   | 253952  | 221184  public  | customer  | 21979136 | 21848064  public  | part    | 16982016 | 16867328  public  | supplier  | 1433600 | 1417216  public  | lineitem  | 559284224| 557981696  public  | partsupp  | 77094912 | 76693504 (7 rows)总结分布式框架下的倾斜是个大课题，本文主要针对存储倾斜（不包含计算倾斜）重点分享我们在业务中如何尽快发现倾斜、定位倾斜，希望能给大家提供一些思路和帮助。

5.WiredTiger对GSI的实现上文中我们介绍了GSI的基本概念，WiredTiger在不使用timestampAPI时，实现了CSI。它的冲突检测算法如下：Transaction's localViewTransaction -> {    // Global monotonicly increasing id, allocated when transaction starts.    txnId: int    // The local view of the global transaction list.    snapshots: []int}Global Transaction ListGTL -> {    // used for allocating one txn's txnId txnIdAllocator: atomic<int> // uncommitted transactions activeTxns: List<Transaction*> // protect GTL from concurrent visit rwlock: RwLock}Transaction's mvcc prodecure Begin -> {     With(GTL.rwlock.wlock()) {         txn = Transaction {             txnId: GTL.txnIdAllocator++              snapshots: GTL.activeTxns.copy()         }         GTL.activeTxns.add(txn)     }     // txns are naturalled sorted in this way. } Update(key, value)-> { // get the updatelist of a key from the btree // pick its header    upd = GetUpdateList(key).header    if (upd.txnId > self.snapshots.back()) {        throw Conflict    }    if (txn.snapshots.find(upd.txnId) {        throw Conflict    }    GetUpdateList(key).insertAtFront({self.txnId, value}) } Commit -> {     With(GTL.rwlock.wlock()) {        GTL.activeTxns.remove(self)     } }在事务开始时，对将全局未提交的事务id copy 到事务的localView中的snapshots链表中。采用firstUpdateWin的冲突检测策略，在更新记录时如果违背SI，当且仅当：如果key的mvcc链头的txnId 大于localView的snapshots中的最大值，如果key的mvcc链头的txnId在本事务的localView的snapshots上述规则是经典的CSI的实现，在PG中也是类似的做法，正确性证明请见这篇文章WiredTiger timestamp 与 GSIWiredTiger中引入readTimestamp和commitTimestamp，readTimestamp即GSI中的snapshotTimestamp。Transaction -> {    // Global monotonicly increasing id, allocated when transaction starts.    txnId: int    // The local view of the global transaction list.    snapshots: []int    read_timestamp: int    commit_timestamp: int}相应的冲突检测判断部分，也引入了GSI的规则即本事务的read_timestamp 小于已提交key的commit_timestamp 即认为违背GSI这里默认本事务的commit_timestamp 一定大于key的mvcc链中的最大的commit_timestamp，即对于某个特定的key，该key的commit_timestamp的顺序一定要和物理提交顺序一致，这是由application-level（mongoServer层）保证的，那么Mongo层是如何保证这一点的呢，请继续往下看。 Update(key, value)-> { // get the updatelist of a key from the btree // pick its header    upd = GetUpdateList(key).header    if (upd.txnId > self.snapshots.back()) {        throw Conflict    }    if (txn.snapshots.find(upd.txnId) {        throw Conflict    }    if (txn.read_timestamp < upd.commit_timetamp) {        throw Conflict    }    GetUpdateList(key).insertAtFront({self.txnId, value}) }前缀一致的复制（PrefixConsistent Replication）MongoDB从节点拉取主节点的Oplog来实现复制，主节点上的Oplog是并行提交的，因此在Oplog的末尾存在(时间上的)乱序。如果不屏蔽乱序的话，从节点读到的Oplog就会产生空洞。举个例子：T0: txn1.start(); txn1.setCommitTimestamp(1)T1: txn2.start(); txn2.setCommitTimestamp(2)T2: txn3.start(); txn3.setCommitTimestamp(3)T3: txn3.commit()  // local.oplog.rs: [3]T4: txn1.commit()  // local.oplog.rs: [1,3]T5: txn2.commit()  // local.oplog.rs: [1,2,3]从空间上来讲，oplog的顺序就是事务的commitTimestamp顺序，即[1,2,3]的顺序。但是从时间上来讲，物理提交顺序不可控，尽管三条oplog最终会生成，但是不同时间点看到的oplog，是有空洞的。比如T4时刻的oplog是[1,3]，如果从节点此刻去遍历Oplog，就会丢失commitTimetamp=2的记录。CommitQueue 与 AllCommitTimestamp的计算从本质上讲，所谓前缀一致的复制，指的是，如果我读到了某条commitTimestamp = X的数据，就不允许在我读这条数据后，对数据库做出commitTimestamp < X的更改。因此，不难想到我们可以维护一个最大的没有空洞的commitTimestamp，叫做AllCommitTimestamp, 形式化的定义如下， 也就是GSI读规则的第4点，描述了不会出现空洞：上面我们分析过，事务有commitTimestamp属性。在wiredTiger中，事务被按照commitTimestamp排序，即TAILQ_HEAD(__wt_txn_cts_qh, __wt_txn) commit_timestamph;我们知道，事务开始和设置commitTimestamp不在一个临界区中，因此事务的txnId的顺序和事务的commitTimestamp顺序并不完全一样，这也是为什么wiredTiger除了维护全局的active_transaction_list这个活跃事务链之外，还维护了一个commit_timestamph的队列。active_transaction_list可以看作按照txnId有序的队列，commit_timestamph可以看作按照commitTimestamp有序的队列。commit_timestamph 队列可以用来辅助AllCommitTimestamp的计算。相关伪代码如下：for (auto v : commit_timestamph) {  if (v.committed || v.rollbacked) {    continue;  }  return v.commit_timestamp - 1;}根据上述伪代码，wiredTiger中，从左往右遍历commit_timestamph队列，找到第一个没有提交的事务T，allCommitTimestamp = T.commitTimestamp - 1; 这也很容易理解，T为commitTimestamp最小的未提交事务，那么比它更小的commitTimestamp所属的事务必然都已经提交了。这里有个假设，对commit_timestamph的插入操作必然都是插入到末尾，换句话说，commitTimestamp的分配必然是递增的，这一点是由application-level(mongodb-server层)保证的，那么Mongo层是如何保证这一点的呢，请继续往下看。MongoDB用来做复制的，读oplog的读事务，它的readTimestamp由AllCommitTimestamp得到，因此能够做到前缀一致的复制。遗留问题的解决上面我们留了两个遗留问题Mongo如何做到对于某个特定的key，该key的commit_timestamp的顺序和物理提交顺序一致Mongo如何做到对commit_timestamph的插入操作必然都是插入到末尾，换句话说，commitTimestamp的分配必然是递增的这两个问题，是wiredTiger不做任何保证的，如果违背了，数据就错乱了。MongoDB的同一段代码保证了上述两点，或者说，上述问题其实是一个问题。就是所谓的PBMA策略 1. // the global timestamp allocator 2. GTA -> { 3.     lock     Lock 4.     globalTs int 5. }   6. // the timestamp allocation prodecure 7. Transaction txn 8. txn.Begin() 9. with(GTA.lock) {10.      txn.setCommitTimestamp(globalTs++)11. }12. ......13. txn.Commit()PBMA策略的关键要素是事务先开始，再分配提交时间戳分配提交时间戳要保证全局递增（加锁）PBMA为何能一箭双雕的保证上面两个遗留问题呢，正确性的证明在这里简单的说，对于某个特定的key，如果有两个事务都在修改， 那么根据事务冲突的规则可知， 这两个事务，一定是一个提交后，一个才开始的，满足 commit(Ti) < snapshot(Tj)的关系，对于本事务，也满足 snapshot(Tj) < commit(Tj) 的关系， 那么可知， commit(Ti) 是小于 commit(Tj)的， 即commit 顺序跟物理顺序相一致。上面介绍了MongoDB副本集系统跟4.0的时间戳的一些实现， 底下我们需要了解一下在MongoDB 4.2 的分布式事务又是如何使用时间戳来实现的。6.分布式系统的时钟分布式系统，各个节点时钟的是不一致：1，分布式各节点，时钟不一致，会导致分布式事务，无法定序。2，对于分布式系统，一般都有时钟同步服务来保证各个节点的时间一致性。3，但是即使存在时钟同步服务，任一时间点的绝对一致是很难达到的。这对于分布式系统来说，是不可依赖的。4，分布式事务处理，如果不想为节点时间差专门去做逻辑处理，则需要基于一个稳定一致的时钟系统。— 即：逻辑时钟。7.MongoDB sharding与时间戳的关系HLC与ChangeStream从3.6之后，MongoDB就引入了HLC的概念，在实现上的体现是，Mongos/Mongod的每次操作都会带ClusterTime，ClusterTime也作为Mongos和Client交互传递的Token。HLC在MongoDB中的体现在以下几点：ClusterTime在Client/Mongos/Mongod的所有操作(读/写/命令)之间传递，每个进程收到更大的ClusterTime后就更新本地的ClusterTime。Mongod侧，Oplog的分配与物理时间的递增会作为ClusterTime推进的驱动力。Mongos/Mongod侧，物理时间的偏斜会作为ClusterTime推进的驱动力。ClusterTime传递给Client时是被签名的，以防止被篡改使得Server端的ClusterTime无限制变大。Client本身只传递不推进ClusterTime。相关代码在 logical_clock.h::advanceClusterTime，mongos和mongod在rpc的处理函数处均有调用。void processCommandMetadata {    return logicalClock->advanceClusterTime(signedTime.getTime());}通过上述HLC的机制，mongos/mongod各个进程之间的物理时钟不需要协调，集群的ClusterTime会随着mongos/mongod/configsvr的每次交互相互接近。如果没有HLC机制，各个shard之间的写操作的OplogTime相互独立，各个shard上的oplogTime没有totalOrder，全局的ChangeStream就无法实现。CLOCK-SI与MongoDB 的2PC分布式事务MongoDB的2PC和CLOCK-SI paper中的算法非常接近（由于官方并未明确说明，因此并不可以说，MongoDB的2PC是对CLOCK-SI paper的实现）。MongoDB的分布式事务流程介绍可以参考这篇文章CLOCK-SI分布式系统中，考虑到多事务并发，对每个单个事务的开始时间是严格要求的，只有在不同节点上的单个事务都在同一个时间戳开始执行，那么多个事务在每个节点上的顺序才是一致的。考虑到分布式系统会有 clock skew (时钟偏斜) 的场景， 我们就需要在其他节点等待时间流逝到这个时间，才可以开始执行， 如下图所示:上图中事务 T1，因为在P1节点是在 t时刻开始的， 所以在事务在 P2节点运行时，也需要等到t时刻才能运行， 如上图所示 P2 节点时间早于P1节点， 那么事务在P2节点，就需要等这个延迟时间。这样会造成事务执行过程中的延迟的增大。CLOCK-SI就是为了提出了一个方法，用来解决上面事务执行过程中的延迟问题的,读规则如下CLOCK-SI 的读规则提供了一个多分区情况下的一致的snapshot， 主要有两点1> 如何设置事务T的SnapshotTime2> 如何延迟读操作知道每个节点都有一个一致的snapshot第2行，表示我们可以将snapshotTime适当的向前调整，这样，可以减少这个事务在远端节点的等待时间， 远端节点等待操作，见 第 21 和 22 行。第7-9行， 如果查看的oid，发现是事务T’修改的，且T’事务正在提交，并且T’事务的提交时间小于事务T(对事物T可见的话)， 那么应该等到T’提交成功后，再读取。因为 commiting 也可能会提交失败， 所以事务T不能直接读取；因为 已经判断了，T’ 对事务T可见，所以事务T不能忽略。综上所述，事务T的读操作只能等待。第 11- 15行， 与上面类似，如果 T’ 已经 prepared，且 T’ 对事务T可见，那么 读操作需要等待到T’成功提交后，再读取。原因与上面描述类似21-22 行， 规定了读请求在每个节点上，都需要等到远端物理时钟到了后，才可执行。写规则如下写规则针对事务是单点的，还是跨节点的，又分为 local commit, 和 distributed commit采取两阶段的提交方式先发送 prepare T 请求到所有事务参与节点等待所有事务参与节点返回 T 事务已经被 prepared的结果设置T 状态为 commiting状态选取最大的 prepare timestamps 作为 commit timestamp, 并分配给事务T记录事务T的提交时间和提交决策设置事务T为commited状态将 commit T 发送给所有事务参与节点事务参与节点，一旦收到 prepare T的请求，检查 事务 T 在本节点是否可以被修改记录事务的写操作结果和协调者的id将事务T状态设置为 prepared设置T.prepared 时间为本地时间发送 T 事务已经prepared成功的信息给事务T的协调者事务参与节点, 收到 commit T的消息后记录事务T 的commitTime将事务T 设置为 commited 状态MongoDB如何处理读操作读取了处于prepare状态的值可以看出，CLOCK-SI中明确定义了， 当分布式事务处于Prepare 状态时， 如果其他读事务可以看见这个 Prepare， 那么需要等到分布式事务状态变为提交后，才可以继续执行。这对应到 mongodb 4.2 代码中，在wt的 当读事务 碰到了 正在 Prepare的事务，会返回一个 WT_PREPARE_CONFLICT 来表示当前并不是一个合适时机， 我们需要等到这个写事务完成。而上层的MongoDB如果碰到 WT_PREPARE_CONFLICT， 则会等待事务提交后，继续尝试读取，int ret = wiredTigerPrepareConflictRetry(opCtx, [&] { return c->search(c); });所有对底层 cursor的遍历和查询操作，都会被封装到 wiredTigerPrepareConflictRetry 函数中， wiredTigerPrepareConflictRetry 会根据传入的函数对象的执行结果进行retry，如果返回结果不是 WT_PREPARE_CONFLICT， 那么 wiredTigerPrepareConflictRetry 直接返回，如果返回对象是 wiredTigerPrepareConflictRetry， 那么会下一次有事务提交或者abort时，再次调用函数对象检查一次。更多关于 WT 层修改，参考这篇文章为什么 commitTs=max{prepareTs}首先我们需要明确的是，分布式事务哪怕在多个节点运行，最终的 commit timestamp 只能有一个。因为 commit timestamp 必须大于 prepare timestamp， 所以 commitTs=max{prepareTs} 是一个合理的规定。如果不认同上面规则， 认为 commit timestamp 可以小于某个节点的 prepare timestamp， 那会违反事务的原子性要求的，举例如下:prepareTs(P1, T1) = commitTs(T1) < snapshotTs(T2) < prepareTs(P2, T1)那么T2事务在节点1，可以看见T1的修改，但是在节点2， 是看不到 T1修改的， 这就违背了 事务的原子性的要求。

5.WiredTiger对GSI的实现上文中我们介绍了GSI的基本概念，WiredTiger在不使用timestampAPI时，实现了CSI。它的冲突检测算法如下：Transaction's localViewTransaction -> {    // Global monotonicly increasing id, allocated when transaction starts.    txnId: int    // The local view of the global transaction list.    snapshots: []int}Global Transaction ListGTL -> {    // used for allocating one txn's txnId txnIdAllocator: atomic<int> // uncommitted transactions activeTxns: List<Transaction*> // protect GTL from concurrent visit rwlock: RwLock}Transaction's mvcc prodecure Begin -> {     With(GTL.rwlock.wlock()) {         txn = Transaction {             txnId: GTL.txnIdAllocator++              snapshots: GTL.activeTxns.copy()         }         GTL.activeTxns.add(txn)     }     // txns are naturalled sorted in this way. } Update(key, value)-> {  // get the updatelist of a key from the btree  // pick its header    upd = GetUpdateList(key).header    if (upd.txnId > self.snapshots.back()) {        throw Conflict    }    if (txn.snapshots.find(upd.txnId) {        throw Conflict    }    GetUpdateList(key).insertAtFront({self.txnId, value}) } Commit -> {     With(GTL.rwlock.wlock()) {        GTL.activeTxns.remove(self)     } }在事务开始时，对将全局未提交的事务id copy 到事务的localView中的snapshots链表中。采用firstUpdateWin的冲突检测策略，在更新记录时如果违背SI，当且仅当：如果key的mvcc链头的txnId 大于localView的snapshots中的最大值，如果key的mvcc链头的txnId在本事务的localView的snapshots上述规则是经典的CSI的实现，在PG中也是类似的做法，正确性证明请见这篇文章WiredTiger timestamp 与 GSIWiredTiger中引入readTimestamp和commitTimestamp，readTimestamp即GSI中的snapshotTimestamp。Transaction -> {    // Global monotonicly increasing id, allocated when transaction starts.    txnId: int    // The local view of the global transaction list.    snapshots: []int    read_timestamp: int    commit_timestamp: int}相应的冲突检测判断部分，也引入了GSI的规则即本事务的read_timestamp 小于已提交key的commit_timestamp 即认为违背GSI这里默认本事务的commit_timestamp 一定大于key的mvcc链中的最大的commit_timestamp，即对于某个特定的key，该key的commit_timestamp的顺序一定要和物理提交顺序一致，这是由application-level（mongoServer层）保证的，那么Mongo层是如何保证这一点的呢，请继续往下看。 Update(key, value)-> {  // get the updatelist of a key from the btree  // pick its header    upd = GetUpdateList(key).header    if (upd.txnId > self.snapshots.back()) {        throw Conflict    }    if (txn.snapshots.find(upd.txnId) {        throw Conflict    }    if (txn.read_timestamp < upd.commit_timetamp) {        throw Conflict    }    GetUpdateList(key).insertAtFront({self.txnId, value}) }前缀一致的复制（PrefixConsistent Replication）MongoDB从节点拉取主节点的Oplog来实现复制，主节点上的Oplog是并行提交的，因此在Oplog的末尾存在(时间上的)乱序。如果不屏蔽乱序的话，从节点读到的Oplog就会产生空洞。举个例子：T0: txn1.start(); txn1.setCommitTimestamp(1)T1: txn2.start(); txn2.setCommitTimestamp(2)T2: txn3.start(); txn3.setCommitTimestamp(3)T3: txn3.commit()  // local.oplog.rs: [3]T4: txn1.commit()  // local.oplog.rs: [1,3]T5: txn2.commit()  // local.oplog.rs: [1,2,3]从空间上来讲，oplog的顺序就是事务的commitTimestamp顺序，即[1,2,3]的顺序。但是从时间上来讲，物理提交顺序不可控，尽管三条oplog最终会生成，但是不同时间点看到的oplog，是有空洞的。比如T4时刻的oplog是[1,3]，如果从节点此刻去遍历Oplog，就会丢失commitTimetamp=2的记录。CommitQueue 与 AllCommitTimestamp的计算从本质上讲，所谓前缀一致的复制，指的是，如果我读到了某条commitTimestamp = X的数据，就不允许在我读这条数据后，对数据库做出commitTimestamp < X的更改。因此，不难想到我们可以维护一个最大的没有空洞的commitTimestamp，叫做AllCommitTimestamp, 形式化的定义如下， 也就是GSI读规则的第4点，描述了不会出现空洞：上面我们分析过，事务有commitTimestamp属性。在wiredTiger中，事务被按照commitTimestamp排序，即TAILQ_HEAD(__wt_txn_cts_qh, __wt_txn) commit_timestamph;我们知道，事务开始和设置commitTimestamp不在一个临界区中，因此事务的txnId的顺序和事务的commitTimestamp顺序并不完全一样，这也是为什么wiredTiger除了维护全局的active_transaction_list这个活跃事务链之外，还维护了一个commit_timestamph的队列。active_transaction_list可以看作按照txnId有序的队列，commit_timestamph可以看作按照commitTimestamp有序的队列。commit_timestamph 队列可以用来辅助AllCommitTimestamp的计算。相关伪代码如下：for (auto v : commit_timestamph) {  if (v.committed || v.rollbacked) {    continue;  }  return v.commit_timestamp - 1;}根据上述伪代码，wiredTiger中，从左往右遍历commit_timestamph队列，找到第一个没有提交的事务T，allCommitTimestamp = T.commitTimestamp - 1; 这也很容易理解，T为commitTimestamp最小的未提交事务，那么比它更小的commitTimestamp所属的事务必然都已经提交了。这里有个假设，对commit_timestamph的插入操作必然都是插入到末尾，换句话说，commitTimestamp的分配必然是递增的，这一点是由application-level(mongodb-server层)保证的，那么Mongo层是如何保证这一点的呢，请继续往下看。MongoDB用来做复制的，读oplog的读事务，它的readTimestamp由AllCommitTimestamp得到，因此能够做到前缀一致的复制。遗留问题的解决上面我们留了两个遗留问题Mongo如何做到对于某个特定的key，该key的commit_timestamp的顺序和物理提交顺序一致Mongo如何做到对commit_timestamph的插入操作必然都是插入到末尾，换句话说，commitTimestamp的分配必然是递增的这两个问题，是wiredTiger不做任何保证的，如果违背了，数据就错乱了。MongoDB的同一段代码保证了上述两点，或者说，上述问题其实是一个问题。就是所谓的PBMA策略 1. // the global timestamp allocator 2. GTA -> { 3.     lock     Lock 4.     globalTs int 5. }   6. // the timestamp allocation prodecure 7. Transaction txn 8. txn.Begin() 9. with(GTA.lock) {10.      txn.setCommitTimestamp(globalTs++)11. }12. ......13. txn.Commit()PBMA策略的关键要素是事务先开始，再分配提交时间戳分配提交时间戳要保证全局递增（加锁）PBMA为何能一箭双雕的保证上面两个遗留问题呢，正确性的证明在这里简单的说，对于某个特定的key，如果有两个事务都在修改， 那么根据事务冲突的规则可知， 这两个事务，一定是一个提交后，一个才开始的，满足 commit(Ti) < snapshot(Tj)的关系，对于本事务，也满足 snapshot(Tj) < commit(Tj) 的关系， 那么可知， commit(Ti) 是小于 commit(Tj)的， 即commit 顺序跟物理顺序相一致。上面介绍了MongoDB副本集系统跟4.0的时间戳的一些实现， 底下我们需要了解一下在MongoDB 4.2 的分布式事务又是如何使用时间戳来实现的。6.分布式系统的时钟分布式系统，各个节点时钟的是不一致：1，分布式各节点，时钟不一致，会导致分布式事务，无法定序。2，对于分布式系统，一般都有时钟同步服务来保证各个节点的时间一致性。3，但是即使存在时钟同步服务，任一时间点的绝对一致是很难达到的。这对于分布式系统来说，是不可依赖的。4，分布式事务处理，如果不想为节点时间差专门去做逻辑处理，则需要基于一个稳定一致的时钟系统。— 即：逻辑时钟。7.MongoDB sharding与时间戳的关系HLC与ChangeStream从3.6之后，MongoDB就引入了HLC的概念，在实现上的体现是，Mongos/Mongod的每次操作都会带ClusterTime，ClusterTime也作为Mongos和Client交互传递的Token。HLC在MongoDB中的体现在以下几点：ClusterTime在Client/Mongos/Mongod的所有操作(读/写/命令)之间传递，每个进程收到更大的ClusterTime后就更新本地的ClusterTime。Mongod侧，Oplog的分配与物理时间的递增会作为ClusterTime推进的驱动力。Mongos/Mongod侧，物理时间的偏斜会作为ClusterTime推进的驱动力。ClusterTime传递给Client时是被签名的，以防止被篡改使得Server端的ClusterTime无限制变大。Client本身只传递不推进ClusterTime。相关代码在 logical_clock.h::advanceClusterTime，mongos和mongod在rpc的处理函数处均有调用。void processCommandMetadata {    return logicalClock->advanceClusterTime(signedTime.getTime());}通过上述HLC的机制，mongos/mongod各个进程之间的物理时钟不需要协调，集群的ClusterTime会随着mongos/mongod/configsvr的每次交互相互接近。如果没有HLC机制，各个shard之间的写操作的OplogTime相互独立，各个shard上的oplogTime没有totalOrder，全局的ChangeStream就无法实现。CLOCK-SI与MongoDB 的2PC分布式事务MongoDB的2PC和CLOCK-SI paper中的算法非常接近（由于官方并未明确说明，因此并不可以说，MongoDB的2PC是对CLOCK-SI paper的实现）。MongoDB的分布式事务流程介绍可以参考这篇文章CLOCK-SI分布式系统中，考虑到多事务并发，对每个单个事务的开始时间是严格要求的，只有在不同节点上的单个事务都在同一个时间戳开始执行，那么多个事务在每个节点上的顺序才是一致的。考虑到分布式系统会有 clock skew (时钟偏斜) 的场景， 我们就需要在其他节点等待时间流逝到这个时间，才可以开始执行， 如下图所示:上图中事务 T1，因为在P1节点是在 t时刻开始的， 所以在事务在 P2节点运行时，也需要等到t时刻才能运行， 如上图所示 P2 节点时间早于P1节点， 那么事务在P2节点，就需要等这个延迟时间。这样会造成事务执行过程中的延迟的增大。CLOCK-SI就是为了提出了一个方法，用来解决上面事务执行过程中的延迟问题的,读规则如下CLOCK-SI 的读规则提供了一个多分区情况下的一致的snapshot， 主要有两点1> 如何设置事务T的SnapshotTime2> 如何延迟读操作知道每个节点都有一个一致的snapshot第2行，表示我们可以将snapshotTime适当的向前调整，这样，可以减少这个事务在远端节点的等待时间， 远端节点等待操作，见 第 21 和 22 行。第7-9行， 如果查看的oid，发现是事务T’修改的，且T’事务正在提交，并且T’事务的提交时间小于事务T(对事物T可见的话)， 那么应该等到T’提交成功后，再读取。因为 commiting 也可能会提交失败， 所以事务T不能直接读取；因为 已经判断了，T’ 对事务T可见，所以事务T不能忽略。综上所述，事务T的读操作只能等待。第 11- 15行， 与上面类似，如果 T’ 已经 prepared，且 T’ 对事务T可见，那么 读操作需要等待到T’成功提交后，再读取。原因与上面描述类似21-22 行， 规定了读请求在每个节点上，都需要等到远端物理时钟到了后，才可执行。写规则如下写规则针对事务是单点的，还是跨节点的，又分为 local commit, 和 distributed commit采取两阶段的提交方式先发送 prepare T 请求到所有事务参与节点等待所有事务参与节点返回 T 事务已经被 prepared的结果设置T 状态为 commiting状态选取最大的 prepare timestamps 作为 commit timestamp, 并分配给事务T记录事务T的提交时间和提交决策设置事务T为commited状态将 commit T 发送给所有事务参与节点事务参与节点，一旦收到 prepare T的请求，检查 事务 T 在本节点是否可以被修改记录事务的写操作结果和协调者的id将事务T状态设置为 prepared设置T.prepared 时间为本地时间发送 T 事务已经prepared成功的信息给事务T的协调者事务参与节点, 收到 commit T的消息后记录事务T 的commitTime将事务T 设置为 commited 状态MongoDB如何处理读操作读取了处于prepare状态的值可以看出，CLOCK-SI中明确定义了， 当分布式事务处于Prepare 状态时， 如果其他读事务可以看见这个 Prepare， 那么需要等到分布式事务状态变为提交后，才可以继续执行。这对应到 mongodb 4.2 代码中，在wt的 当读事务 碰到了 正在 Prepare的事务，会返回一个 WT_PREPARE_CONFLICT 来表示当前并不是一个合适时机， 我们需要等到这个写事务完成。而上层的MongoDB如果碰到 WT_PREPARE_CONFLICT， 则会等待事务提交后，继续尝试读取，int ret = wiredTigerPrepareConflictRetry(opCtx, [&] { return c->search(c); });所有对底层 cursor的遍历和查询操作，都会被封装到 wiredTigerPrepareConflictRetry 函数中， wiredTigerPrepareConflictRetry 会根据传入的函数对象的执行结果进行retry，如果返回结果不是 WT_PREPARE_CONFLICT， 那么 wiredTigerPrepareConflictRetry 直接返回，如果返回对象是 wiredTigerPrepareConflictRetry， 那么会下一次有事务提交或者abort时，再次调用函数对象检查一次。更多关于 WT 层修改，参考这篇文章为什么 commitTs=max{prepareTs}首先我们需要明确的是，分布式事务哪怕在多个节点运行，最终的 commit timestamp 只能有一个。因为 commit timestamp 必须大于 prepare timestamp， 所以 commitTs=max{prepareTs} 是一个合理的规定。如果不认同上面规则， 认为 commit timestamp 可以小于某个节点的 prepare timestamp， 那会违反事务的原子性要求的，举例如下:prepareTs(P1, T1) = commitTs(T1) < snapshotTs(T2) < prepareTs(P2, T1)那么T2事务在节点1，可以看见T1的修改，但是在节点2， 是看不到 T1修改的， 这就违背了 事务的原子性的要求。

1、什么是架构和架构本质在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。我们主要针对互联网服server系统（类似网站）来定义架构：架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。组件：类似应用服务，独立模块、数据库、nginx等等、连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、约束规范： 定规则做限制：例如设计原则、编码规范等等。是系统性地思考，权衡利弊之后在现有资源约束下的“最合理决策”，并由它来指导团队中的每个人思想层面上的一致。即架构=组件+交互。这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭理最后是什么样？架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。那什么样的系统要考虑做架构设计?1. 需求相对复杂.2. 非功能性需求在整个系统占据重要位置.3. 系统生命周期长,有扩展性需求.4.系统基于组件或者集成的需要.5.业务流程再造的需要. 2、架构分类架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。一、业务架构（俯视架构）：包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。看看京东业务架构（网上分享图）：二、应用架构（剖面架构，也叫逻辑架构图）：硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。类似：应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。应用架构图关键有2点：1、职责划分: 明确应用（各个逻辑模块或者子系统）边界1）逻辑分层2）子系统、模块定义。3）关键类。2、职责之间的协作：1）接口协议：应用对外输出的接口。2）协作关系：应用之间的调用关系。应用分层有两种方式：一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。三、代码架构（也叫开发架构）：子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。代码架构主要定义：一、代码单元:1、配置设计2、框架、类库。二、代码单元组织：1、编码规范，编码的惯例。2、项目模块划分3、顶层文件结构设计，比如mvc设计。4、依赖关系四、技术架构，也可以叫系统架构技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。五、部署拓扑架构图（实际物理架构图）：拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。3、应用架构架构演进路程：->初始阶段：LAMP,部署在一台服务器->应用服务器和数据服务器分离->使用缓存改善性能->使用集群改善并发->数据库地读写分离->使用反向代理和cdn加速->使用分布式文件和分布式数据库->业务拆分->分布式服务业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。企业一开始业务比较简单，比如进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查即可，单体应用可以满足要求。随着业务深入，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增加，这时需要对系统按照业务拆分，变成一个分布式系统。更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务类似，没必要重做一套，此时把内部系统的逻辑做服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。紧接着业务模式越来越复杂，订单、商品、库存、价格每块玩法都很深入，比如价格区分会员等级，访问渠道（无线还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。同时不管是企业内部用户，还是外部顾客所需要的功能，都由很多细分的应用提供支持，需要提供portal，集成相关应用，为不同用户提供统一视图，顶层变成一个AOA的架构（application orientated architecture）。4、衡量架构的合理性架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。一、稳定性。指标：1. 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。二、高效指标：1. 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。2. 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。3. 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。三、安全指标1. 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段5、常见架构误区误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？6、架构知识体系架构演进初始阶段：LAMP,部署在一台服务器应用服务器和数据服务器分离使用缓存改善性能使用集群改善并发数据库地读写分离使用反向代理和cdn加速使用分布式文件和分布式数据库业务拆分分布式服务架构模式分层：横向分层：应用层，服务层，数据层分割：纵向分割：拆分功能和服务分布式分布式应用和服务分布式静态资源分布式数据和存储分布式计算集群：提高并发和可用性缓存：优化系统性能cdn方向代理访问资源本地缓存分布式缓存异步：降低系统的耦合性提供系统的可用性加快响应速度冗余：冷备和热备，保证系统的可用性自动化：发布，测试，部署，监控，报警，失效转移，故障恢复安全：架构核心要素高性能：网站的灵魂性能测试前端优化应用优化数据库优化可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成负载均衡数据备份自动发布灰度发布监控报警伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器集群负载均衡缓存负载均衡可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖分布式消息服务化安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。xss攻击sql注入csr攻击web防火墙漏洞安全漏洞ssl7、架构书籍推荐1. 《大型网站技术架构：核心原理与案例分析》这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。2. 《亿级流量网站架构核心技术》相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。3. 《架构即未来》这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。4. 《分布式服务架构：原理、设计与实战》这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。5. 《聊聊架构》这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。6. 《软件架构师的12项修炼》大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

Apache Kafka 是一个快速、可扩展的、高吞吐的、可容错的分布式“发布-订阅”消息系统， 使用 Scala 与 Java 语言编写，能够将消息从一个端点传递到另一个端点。较之传统的消息中间件（例如 ActiveMQ、RabbitMQ），Kafka 具有高吞吐量、内置分区、支持消息副本和高容错的特性，非常适合大规模消息处理应用程序。Kafka 官网：http://kafka.apache.org/Kafka 主要设计目标如下：以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间的访问性能。高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息的传输。支持 Kafka Server 间的消息分区，及分布式消费，同时保证每个 Partition 内的消息顺序传输。同时支持离线数据处理和实时数据处理。支持在线水平扩展。Kafka 通常用于两大类应用程序：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。构建实时流应用程序，以转换或响应数据流。要了解 Kafka 如何执行这些操作，让我们从头开始深入研究 Kafka 的功能。首先几个概念：Kafka 在一个或多个可以跨越多个数据中心的服务器上作为集群运行。Kafka 集群将记录流存储在称为主题的类别中。每个记录由一个键，一个值和一个时间戳组成。Kafka 架构体系如下图：Kafka 的应用场景非常多, 下面我们就来举几个我们最常见的场景：①用户的活动跟踪：用户在网站的不同活动消息发布到不同的主题中心，然后可以对这些消息进行实时监测、实时处理。当然，也可以加载到 Hadoop 或离线处理数据仓库，对用户进行画像。像淘宝、天猫、京东这些大型电商平台，用户的所有活动都要进行追踪的。②日志收集如下图：③限流削峰如下图：④高吞吐率实现：Kafka 与其他 MQ 相比，最大的特点就是高吞吐率。为了增加存储能力，Kafka 将所有的消息都写入到了低速大容量的硬盘。按理说，这将导致性能损失，但实际上，Kafka 仍然可以保持超高的吞吐率，并且其性能并未受到影响。其主要采用如下方式实现了高吞吐率：顺序读写：Kafka 将消息写入到了分区 Partition 中，而分区中的消息又是顺序读写的。顺序读写要快于随机读写。零拷贝：生产者、消费者对于 Kafka 中的消息是采用零拷贝实现的。批量发送：Kafka 允许批量发送模式。消息压缩：Kafka 允许对消息集合进行压缩。Kafka的优点如下：①解耦：在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。②冗余（副本）：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。③扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。④灵活性&峰值处理能力：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。⑤可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。⑥顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka 保证一个 Partition 内的消息的有序性。⑦缓冲：在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行，写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。⑧异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。Kafka 于其他 MQ 对比如下：①RabbitMQ：RabbitMQ 是使用 Erlang 编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP，SMTP，STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了 Broker 构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。②Redis：Redis 是一个基于 Key-Value 对的 NoSQL 数据库，开发维护很活跃。虽然它是一个 Key-Value 数据库存储系统，但它本身支持 MQ 功能，所以完全可以当做一个轻量级的队列服务来使用。对于 RabbitMQ 和 Redis 的入队和出队操作，各执行 100 万次，每 10 万次记录一次执行时间。测试数据分为 128Bytes、512Bytes、1K 和 10K 四个不同大小的数据。实验表明：入队时，当数据比较小时 Redis 的性能要高于 RabbitMQ，而如果数据大小超过了 10K，Redis 则慢的无法忍受；出队时，无论数据大小，Redis 都表现出非常好的性能，而 RabbitMQ 的出队性能则远低于 Redis。③ZeroMQ：ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ 能够实现 RabbitMQ 不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这 MQ 能够应用成功的挑战。ZeroMQ 具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用 ZeroMQ 程序库，可以使用 NuGet 安装，然后你就可以愉快的在应用程序之间发送消息了。但是 ZeroMQ 仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter 的 Storm 0.9.0 以前的版本中默认使用 ZeroMQ 作为数据流的传输（Storm 从 0.9 版本开始同时支持 ZeroMQ 和 Netty 作为传输模块）。④ActiveMQ：ActiveMQ 是 Apache 下的一个子项目。类似于 ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于 RabbitMQ，它少量代码就可以高效地实现高级应用场景。⑤Kafka/Jafka：Kafka 是 Apache 下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而 Jafka 是在 Kafka 之上孵化而来的，即 Kafka 的一个升级版。具有以下特性：快速持久化，可以在 O(1) 的系统开销下进行消息持久化。高吞吐，在一台普通的服务器上既可以达到 10W/s 的吞吐速率。完全的分布式系统，Broker、Producer、Consumer 都原生自动支持分布式，自动实现负载均衡。支持 Hadoop 数据并行加载，对于像 Hadoop 的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka 通过 Hadoop 的并行加载机制统一了在线和离线的消息处理。Apache Kafka 相对于 ActiveMQ 是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。Kafka的几种重要角色如下：①Kafka 作为存储系统：任何允许发布与使用无关的消息发布的消息队列都有效地充当了运行中消息的存储系统。Kafka 的不同之处在于它是一个非常好的存储系统。写入 Kafka 的数据将写入磁盘并进行复制以实现容错功能。Kafka 允许生产者等待确认，以便直到完全复制并确保即使写入服务器失败的情况下写入也不会完成。Kafka 的磁盘结构可以很好地扩展使用-无论服务器上有 50KB 还是 50TB 的持久数据，Kafka 都将执行相同的操作。由于认真对待存储并允许客户端控制其读取位置，因此您可以将 Kafka 视为一种专用于高性能，低延迟提交日志存储，复制和传播的专用分布式文件系统。②Kafka 作为消息传递系统：Kafka 的流概念与传统的企业消息传递系统相比如何？传统上，消息传递具有两种模型：排队和发布订阅。在队列中，一组使用者可以从服务器中读取内容，并且每条记录都将转到其中一个。在发布-订阅记录中广播给所有消费者。这两个模型中的每一个都有优点和缺点。排队的优势在于，它允许您将数据处理划分到多个使用者实例上，从而扩展处理量。不幸的是，队列不是多用户的—一次进程读取了丢失的数据。发布-订阅允许您将数据广播到多个进程，但是由于每条消息都传递给每个订阅者，因此无法扩展处理。Kafka 的消费者群体概念概括了这两个概念。与队列一样，使用者组允许您将处理划分为一组进程（使用者组的成员）。与发布订阅一样，Kafka 允许您将消息广播到多个消费者组。Kafka 模型的优点在于，每个主题都具有这些属性-可以扩展处理范围，并且是多订阅者，无需选择其中一个。与传统的消息传递系统相比，Kafka 还具有更强的订购保证。传统队列将记录按顺序保留在服务器上，如果多个使用者从队列中消费，则服务器将按记录的存储顺序分发记录。但是，尽管服务器按顺序分发记录，但是这些记录是异步传递给使用者的，因此它们可能在不同的使用者上乱序到达。这实际上意味着在并行使用的情况下会丢失记录的顺序。消息传递系统通常通过“专有使用者”的概念来解决此问题，该概念仅允许一个进程从队列中使用，但是，这当然意味着在处理中没有并行性。Kafka 做得更好，通过在主题内具有并行性（即分区）的概念，Kafka 能够在用户进程池中提供排序保证和负载均衡。这是通过将主题中的分区分配给消费者组中的消费者来实现的，以便每个分区都由组中的一个消费者完全消费。通过这样做，我们确保使用者是该分区的唯一读取器，并按顺序使用数据。由于存在许多分区，因此仍然可以平衡许多使用者实例上的负载。但是请注意，使用者组中的使用者实例不能超过分区。③Kafka 用作流处理：仅读取，写入和存储数据流是不够的，目的是实现对流的实时处理。在 Kafka 中，流处理器是指从输入主题中获取连续数据流，对该输入进行一些处理并生成连续数据流以输出主题的任何东西。例如，零售应用程序可以接受销售和装运的输入流，并输出根据此数据计算出的重新订购和价格调整流。可以直接使用生产者和消费者 API 进行简单处理。但是，对于更复杂的转换，Kafka 提供了完全集成的 Streams API。这允许构建执行非重要处理的应用程序，这些应用程序计算流的聚合或将流连接在一起。该功能有助于解决此类应用程序所面临的难题：处理无序数据，在代码更改时重新处理输入，执行状态计算等。流 API 建立在 Kafka 提供的核心原语之上：它使用生产者和使用者 API 进行输入，使用 Kafka 进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。01Kafka 中的关键术语解释Topic：主题。在 Kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 Topic。Topic 相当于消息的分类标签，是一个逻辑概念。物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 Broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处。Partition：分区。Topic 中的消息被分割为一个或多个 Partition，其是一个物理概念，对应到系统上 就是一个或若干个目录。Partition 内部的消息是有序的，但 Partition 间的消息是无序的。Segment 段。将 Partition 进一步细分为了若干的 Segment，每个 Segment 文件的大小相等。Broker：Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 Broker。Broker 存储 Topic 的数据。如果某 Topic 有 N 个 Partition，集群有 N 个 Broker，那么每个 Broker 存储该 Topic 的一个 Partition。如果某 Topic 有 N 个 Partition，集群有（N+M）个 Broker，那么其中有 N 个 Broker 存储该 Topic 的一个 Partition，剩下的 M 个 Broker 不存储该 Topic 的 Partition 数据。如果某 Topic 有 N 个 Partition，集群中 Broker 数目少于 N 个，那么一个 Broker 存储该 Topic 的一个或多个 Partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致 Kafka 集群数据不均衡。Producer：生产者。即消息的发布者，生产者将数据发布到他们选择的主题。生产者负责选择将哪个记录分配给主题中的哪个分区。即：生产者生产的一条消息，会被写入到某一个 Partition。Consumer：消费者。可以从 Broker 中读取消息。一个消费者可以消费多个 Topic 的消息；一个消费者可以消费同一个 Topic 中的多个 Partition 中的消息；一个 Partiton 允许多个 Consumer 同时消费。Consumer Group：Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者，它们共享一个公共的 ID，即 Group ID。组内的所有消费者协调在一起来消费订阅主题 的所有分区。Kafka 保证同一个 Consumer Group 中只有一个 Consumer 会消费某条消息。实际上，Kafka 保证的是稳定状态下每一个 Consumer 实例只会消费某一个或多个特定的 Partition，而某个 Partition 的数据只会被某一个特定的 Consumer 实例所消费。下面我们用官网的一张图, 来标识 Consumer 数量和 Partition 数量的对应关系。由两台服务器组成的 Kafka 群集，其中包含四个带有两个使用者组的分区（P0-P3）。消费者组 A 有两个消费者实例，组 B 有四个。对于这个消费组, 以前一直搞不明白, 我自己的总结是：Topic 中的 Partitoin 到 Group 是发布订阅的通信方式。即一条 Topic 的 Partition 的消息会被所有的 Group 消费，属于一对多模式；Group 到 Consumer 是点对点通信方式，属于一对一模式。举个例子：不使用 Group 的话，启动 10 个 Consumer 消费一个 Topic，这 10 个 Consumer 都能得到 Topic 的所有数据，相当于这个 Topic 中的任一条消息被消费 10 次。使用 Group 的话，连接时带上 groupid，Topic 的消息会分发到 10 个 Consumer 上，每条消息只被消费 1 次。Replizcas of partition：分区副本。副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。Partition Leader：每个 Partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写 的 Partition。即所有读写操作只能发生于 Leader 分区上。Partition Follower：所有 Follower 都需要从 Leader 同步消息，Follower 与 Leader 始终保持消息同步。Leader 与 Follower 的关系是主备关系，而非主从关系。ISR：ISR，In-Sync Replicas，是指副本同步列表。ISR 列表是由 Leader 负责维护。AR，Assigned Replicas，指某个 Partition 的所有副本, 即已分配的副本列表。OSR，Outof-Sync Replicas，即非同步的副本列表。AR=ISR+OSROffset：偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 Offset，它是相当于当前分区第一条消息的偏移量。Broker Controller：Kafka集群的多个 Broker 中，有一个会被选举 Controller，负责管理整个集群中 Partition 和 Replicas 的状态。只有 Broker Controller 会向 Zookeeper 中注册 Watcher，其他 Broker 及分区无需注册。即 Zookeeper 仅需监听 Broker Controller 的状态变化即可。HW 与 LEO：HW，HighWatermark，高水位，表示 Consumer 可以消费到的最高 Partition 偏移量。HW 保证了 Kafka 集群中消息的一致性。确切地说，是保证了 Partition 的 Follower 与 Leader 间数 据的一致性。LEO，Log End Offset，日志最后消息的偏移量。消息是被写入到 Kafka 的日志文件中的， 这是当前最后一个写入的消息在 Partition 中的偏移量。对于 Leader 新写入的消息，Consumer 是不能立刻消费的。Leader 会等待该消息被所有 ISR 中的 Partition Follower 同步后才会更新 HW，此时消息才能被 Consumer 消费。我相信你看完上面的概念还是懵逼的，好吧！下面我们就用图来形象话的表示两者的关系吧：Zookeeper：Zookeeper 负责维护和协调 Broker，负责 Broker Controller 的选举。在 Kafka 0.9 之前版本，Offset 是由 ZK 负责管理的。总结：ZK 负责 Controller 的选举，Controller 负责 Leader 的选举。Coordinator：一般指的是运行在每个 Broker 上的 Group Coordinator 进程，用于管理 Consumer Group 中的各个成员，主要用于 Offset 位移管理和 Rebalance。一个 Coordinator 可以同时管理多个消费者组。Rebalance：当消费者组中的数量发生变化，或者 Topic 中的 Partition 数量发生了变化时，Partition 的所有权会在消费者间转移，即 Partition 会重新分配，这个过程称为再均衡 Rebalance。再均衡能够给消费者组及 Broker 带来高性能、高可用性和伸缩，但在再均衡期间消费者是无法读取消息的，即整个 Broker 集群有小一段时间是不可用的。因此要避免不必要的再均衡。Offset Commit：Consumer 从 Broker 中取一批消息写入 Buffer 进行消费，在规定的时间内消费完消息后，会自动将其消费消息的 Offset 提交给 Broker，以记录下哪些消息是消费过的。当然，若在时限内没有消费完毕，其是不会提交 Offset 的。转载自:CSDN云计算原文链接：https://blog.csdn.net/FL63Zv9Zou86950w/article/details/105283010

鲲鹏BoostKit分布式存储使能套件的移植、部署、调优 端到端使用流程和一站式资源获取最新动态https://www.hikunpeng.com/document/detail/zh/kunpengsdss/wtsnew/index.html特性清单https://www.hikunpeng.com/document/detail/zh/kunpengsdss/function/function.html技术白皮书https://www.hikunpeng.com/document/detail/zh/kunpengsdss/twp/kunpengsdss_19_0001.html基础加速特性数据缩减KAE zlib压缩（指向调优指南）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/dataReduc/kunpengsdss_datareduc_0001.html压缩算法 特性指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/dataReduc/kunpengsdss_datareduc_0002.html数据压紧 特性指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/dataReduc/kunpengsdss_datareduc_0003.htmlCache加速Ceph分布式存储应用IO智能预取 用户指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/cacheAccel/kunpengsdss_cacheaccel_0001.html智能写Cache 特性指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/cacheAccel/kunpengsdss_cacheaccel_0002.htmlBcache 用户指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/cacheAccel/kunpengsdss_cacheaccel_0003.htmlIO加速IO直通工具 用户指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/ioaccel/kunpengsdss_IOaccel_0001.htmlEC Turbo 特性指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/ioaccel/kunpengsdss_IOaccel_0002.html硬件加速KAE MD5摘要算法（指向调优指南）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/basicAccelFeatures/hdwoffload/kunpengsdss_offloading_0001.html应用加速特性全局缓存技术白皮书https://www.hikunpeng.com/document/detail/zh/kunpengsdss/appAccelFeatures/globalCache/kunpengsdss_globalcache_0003.html特性指南（openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/appAccelFeatures/globalCache/kunpengsdss_globalcache_0001.html调优指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/appAccelFeatures/globalCache/kunpengsdss_globalcache_0004.html验收测试指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/appAccelFeatures/globalCache/kunpengsdss_globalcache_0005.html 生态使能CephCeph 14.2.8 移植指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0001.htmlCeph-ansible 部署指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0002.htmlCeph块存储 部署指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0003.htmlCeph对象存储 部署指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0004.htmlCeph文件存储 部署指南（CentOS 7.6&openEuler 20.03）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0005.htmlCeph自动部署指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0006.html使用鲲鹏性能分析工具调优https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0007.htmlCeph块存储 调优指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0008.htmlCeph对象存储 调优指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0009.htmlCeph文件存储 调优指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0010.htmlCeph 扩容指南https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Ceph/kunpengsdss_ceph_0011.htmlBeeGFSBeeGFS 7.2 部署指南（CentOS 7.6）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/BeeGFS/kunpengsdss_beegfs_0001.htmlFastDFSFastDFS 6.06 部署指南（CentOS 7.6）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/FastDFS/kunpengsdss_fastdfs_0001.htmlMinIOMinIO 2020-12-12T08-39-07Z 部署指南（CentOS 7.6）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/MinIO/kunpengsdss_minio_0001.htmlLustreLustre 2.13.0 部署指南（CentOS 8.0）https://www.hikunpeng.com/document/detail/zh/kunpengsdss/ecosystemEnable/Lustre/kunpengsdss_lustre_0001.html 测试指导Ceph块存储 测试指导https://www.hikunpeng.com/document/detail/zh/kunpengsdss/testGuide/tg/kunpengsdss_tstg_0001.htmlCeph对象存储 测试指导https://www.hikunpeng.com/document/detail/zh/kunpengsdss/testGuide/tg/kunpengsdss_tstg_0002.htmlCeph文件存储 测试指导https://www.hikunpeng.com/document/detail/zh/kunpengsdss/testGuide/tg/kunpengsdss_tstg_0003.html故障案例分布式存储使能套件 故障案例https://www.hikunpeng.com/document/detail/zh/kunpengsdss/trouble/trouble/kunpengsdss_09_0001.html

分布式消息服务DMS和分布式消息服务Kafka是什么关系?

分布式消息服务DMS和分布式消息服务Kafka是什么关系?