CN115271736A - 验证事务一致性的方法、装置、设备、存储介质及产品 - Google Patents

Abstract

本申请实施例提供了一种验证事务一致性的方法、装置、电子设备、计算机可读存储介质及计算机程序产品，涉及分布式交易系统领域。该方法包括：在目标链路系统基于交易请求执行预设数量的交易任务时，向目标链路系统注入延迟故障事件，继而，通过预设的业务指标采集伴随延迟故障事件执行交易任务的数据，最后，根据采集到的数据确定交易任务的事务一致性结果。本申请实施例所提供的方案为在该终综合平台的指定平台(如，混沌工程平台)中先确定目标链路系统的关键节点，并向该关键节点注入延迟故障事件，即可模拟出系统之间的交易延迟场景，并在该场景下进行交易任务的事务一致性的验证操作。

Description

验证事务一致性的方法、装置、设备、存储介质及产品

技术领域

本申请涉及分布式交易系统的技术领域，具体而言，本申请涉及一种验证事务一致性的方法、装置、电子设备、计算机可读存储介质及计算机程序产品。

背景技术

事务一致性，表示一个或多个事务执行后，原来一致性的数据和数据库仍然是一致的。

目前，一般通过模拟系统之间的交易延迟场景来测试交易的事务一致性是否收到影响，该模拟过程中包括在系统之间设置转发器。例如，若模拟系统X和系统Y之间的交易场景延迟，需要在二者之间设置系统Z作为转发器，由系统X向系统Z发送交易报文，再由系统Z做出延迟处理后，向系统Y转发该交易报文，以营造一种交易延迟场景。然后根据系统X和系统Y的交易结果，来判断该笔交易的事务一致性是否收到影响。

然而，在系统之间设置转发器并通过转发器实现交易延迟场景，涉及到系统代码的更改和转发器的配置，该过程涉及繁琐的流程。除此之外，还需要了解系统的整体布局。设置转发器来模拟交易延迟场景的方案，显然需要多专业配合，较为费时费力。

发明内容

本申请实施例旨在提供一种验证事务一致性的方法，以及基于该验证事务一致性的方法的装置和电子设备。为了实现上述目的，本申请实施例提供的技术方案如下。

一方面，本申请实施例提供了一种验证事务一致性的方法，应用于综合平台，该方法包括：

在目标链路系统基于交易请求执行预设数量的交易任务时，向所述目标链路系统的目标注入节点注入预设的延迟故障事件；根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据；根据采集到的数据确定交易任务的事务一致性结果。

在一种可能的实现方式中，目标链路系统包括依照交易任务的处理顺序连接的多个节点，在目标链路系统接收交易请求之前，该方法包括：

与每个节点建立连接；其中，每个节点中配置有探针，探针用于执行延迟故障事件对应的延迟操作。

在另一种可能的实现方式中，向目标链路系统的目标注入节点注入预设的延迟故障事件，包括：

根据预设的配置信息从多个节点中确定目标注入节点，以及为目标注入节点配置的延迟故障事件；向目标注入节点的探针发送配置的延迟故障事件对应的请求。

在又一种可能的实现方式中，根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据，包括：

在伴随延迟故障事件的交易任务的执行过程中，针对每个节点至少采集以下业务指标对应的数据：为该节点分配的事务量、该节点已处理的事务量、处理事务之后的结果、响应时间，该处理事务之后的结果包括输出交易任务的交易结果。

在又一种可能的实现方式中，根据采集到的数据确定交易任务的事务一致性结果，包括针对每项交易任务执行以下操作：

从多个节点中确定出交易结果为非空的目标输出节点；

若每个目标输出节点输出的交易结果为交易成功，确定该项交易任务的事务一致性结果为未受到影响；若所有目标输出节点输出的交易结果中包括至少一个交易失败，确定该项交易任务的事务一致性结果为受到影响。

在又一种可能的实现方式中，该方法还包括：

在预设的多个时刻，分别统计所述预设数量的交易任务中事务一致性结果为未受到影响的交易任务的总数；根据所述总数确定相应时刻的目标链路系统的运行状态是否受到影响。

在又一种可能的实现方式中，根据所述总数确定相应时刻的目标链路系统的运行状态是否受到影响，包括针对所述多个时刻中每一时刻相应的总数执行以下操作：

若该总数与预设数量的比值不小于预设阈值，确定在该时刻目标链路系统的运行状态未受到延迟故障事件的影响；若该总数与所述预设数量的比值小于预设阈值，确定在该时刻所述目标链路系统的运行状态受到所述延迟故障事件的影响。

在又一种可能的实现方式中，配置的延迟故障事件包括以下至少一项：

端口级延迟事件、URL延迟事件、与交易类型相关的延迟事件、与请求方节点相关的延迟事件、总量百分比延迟事件和与设定次数相关的延迟事件。

另一方面，本申请实施例还提供了一种验证事务一致性的综合平台，该综合平台包括混沌工程平台、监控平台和测试平台，并分别与目标链路系统相连接；其中，

测试平台，用于向目标链路系统发送预设数量的交易请求，以触发目标链路系统执行预设数量的交易任务；混沌工程平台，用于向目标链路系统的目标注入节点注入预设的延迟故障事件；监控平台，用于根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据；监控平台，还用于根据采集到的数据确定执行交易任务的事务一致性结果。

又一方面，本申请实施例还提供了一种验证事务一致性的装置，该装置包括：

注入模块，用于在目标链路系统基于交易请求执行预设数量的交易任务时，向目标链路系统的目标注入节点注入预设的延迟故障事件；采集模块，用于根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据；确定模块，用于根据采集到的数据确定交易任务的事务一致性结果。

再一方面，本申请实施例还提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，处理器执行计算机程序以实现本申请实施例所示的一种验证事务一致性的方法的步骤。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本申请实施例所示的一种验证事务一致性的方法的步骤。

本申请实施例还还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现本申请实施例所示的一种验证事务一致性的方法的步骤。

本申请实施例提供的技术方案带来的有益效果是：

本申请实施例提供了一种验证事务一致性的方法，应用于综合平台；本申请实施例提供的方法在进行事务一致性的验证过程中，设置综合平台来执行注入操作和监视操作，避免在关键链路系统(如，目标链路系统)的关键节点(如，目标注入节点)之间设置转发器，并调整关键节点的代码以实现相应的配置，同时避免为了解目标链路系统的上/下游节点的具体情况而浪费时间。也即，整个验证过程，只需要在该终综合平台的指定平台(如，混沌工程平台)中先确定目标链路系统的关键节点，并向该关键节点注入延迟故障事件，即可模拟出系统之间的交易延迟场景，并在该场景下进行交易任务的事务一致性的验证操作。

另外，在验证了交易任务的事务一致性结果基础上，可以进一步地基于交易任务的事务一致性结果来验证目标链路系统的运行状态是否也受到了影响。如，通过交易成功率来判别目标链路系统的运行状态是否受到影响。而由于目标链路系统的冲正机制的原因，可以设置在多个时刻分别验证目标链路系统的运行状态，如因处于交易延迟场景，该运行状态为故障状态，则说明目标链路系统的性能不够优异。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的一种验证事务一致性的综合平台的系统架构示意图；

图2为本申请实施例提供的一种验证事务一致性的方法的流程示意图；

图3为本申请实施例提供的一种验证事务一致性的装置的结构示意图；

图4为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

本申请实施例提供了一种验证事务一致性的综合平台10，该综合平台10可以为大型计算机设备，例如服务器；其中，综合平台10包括测试平台110、混沌工程平台120和监控平台130；其中，每个平台分别与目标链路系统20相连接。其中，该综合平台10的架构可以参考图1所示的结构示意图。

测试平台110，用于向目标链路系统20发送预设数量的交易请求，以触发目标链路系统20执行预设数量的交易任务。

混沌工程平台120，用于向目标链路系统20的目标注入节点注入预设的延迟故障事件。

监控平台130，用于根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据。

监控平台130，还用于根据采集到的数据确定交易任务的事务一致性结果。

可选地，目标链路系统20为由用户确定的链路系统。例如，在银行交易体系中存在核心应用系统，该核心应用系统中往往承载着绝大多数用户/资金的交易往来，所以该类核心应用系统的性能至关重要。因此，可以将该核心应用系统确定为目标链路系统。

可选地，上述测试平台110、混沌工程平台120、监控平台130均可以实现为应用程序；该应用程序可以是独立的应用程序，也可以为其它应用程序中的插件或小程序，综合平台上配置了上述应用程序后，可以通过该应用程序针对目标链路系统20进行事务一致性的验证。

在一个示例中，测试平台110可以为LoadRunner和JMeter和APTS。LoadRunner，是一种预测系统行为和性能的负载测试工具；该工具通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。Apache JMeter是Apache组织基于Java开发的压力测试工具，用于对软件做压力测试，可用于测试静态和动态资源，如静态文件、Java小服务程序、CGI脚本、Java对象、数据库和FTP服务器等等；另外，JMeter可对服务器和网络等模拟巨大的负载，在不同压力类别下测试它们的强度，并分析整体性能。应当指出，任一用于对目标链路系统20模拟巨大交易请求的测试工具都可以作为本申请实施例的测试平台110，如APTS。

混沌工程，一种提高技术架构弹性能力的复杂技术手段，通过对分布式系统进行有目的的破坏，找出分布式系统可能存在的弱点，从而验证在真实复杂的环境下，分布式系统或者人员应对各种突发问题的能力是否符合预期，以期提升分布式系统的免疫能力。现有技术中，将具备混沌工程能力的平台称作混沌工程平台。

在一个示例中，混沌工程平台120可以是ChaosBlade(混沌实验注入工具)。ChaosBlade具有较强的场景可扩展性，可便于用户根据需求扩展更多的实验场景。目前，ChaosBlade可提供的实验场景包括：

1、基础资源：例如CPU、内存、网络、磁盘、进程等实验场景。

2、Java应用：例如数据库、缓存、消息、微服务等，还可以指定任务类方法注入各种复杂的实验场景。

3、C++应用：例如指定任意方法或者代码注入延迟、变量和返回值篡改等实验场景。

4、Docker容器：例如杀容器，杀容器内CPU、内存、网络、磁盘、进程等实验场景。

以上各类实验场景都可以理解为由具体的故障事件所触发的实验场景，该故障事件来源于Chaosblade。在本申请实施例中，目标链路系统20承载着大量的交易任务，该交易任务涉及目标链路系统20的多个节点。针对于该交易任务而言，若出现延迟故障事件，则会导致交易任务中某个请求/回应延迟发出或者延迟送达，进而导致关键的事务未及时得到处理，从而导致交易任务的事务的一致性受到影响。因此，可以通过ChaosBlade向目标链路系统20注入延迟故障事件，来测试目标链路系统20是否能够抵御延迟故障事件的影响，并稳健运行。

可选地，该监控平台130可以设置各类监控指标，以获取在向目标链路系统20注入延迟故障事件时，获取目标链路系统20的各个节点的事务处理详情，以便分析每项交易任务的事务一致性。

在一个示例中，该监控平台可以为Prometheus和Grafana。其中，Prometheus是一套开源的系统监控报警系统，支持数据的分区采样和联邦部署，以及大规模集群监控；Grafana是一个开源的度量分析与可视化套件，具备各种显示功能(如，显示报表、图表)，大多使用在时序数据的监控方面。两者可以结合使用，来作为监控平台130。

基于上述综合平台10，本申请实施例还提供了一种验证事务一致性的方法，如图2所示。其中，该方法应用于上述综合平台10，包括步骤S210～S220。

S210，在目标链路系统基于交易请求执行预设数量的交易任务时，向目标链路系统的目标注入节点注入预设的延迟故障事件。

可选地，该验证方法还包括验证准备阶段。在验证准备阶段包括接收用户输入的选择指令，从多个链路系统中筛选出目标链路系统。

具体地，由测试工具向目标链路系统发送预设数量的交易请求，每个交易请求对应发起一项交易任务。其中，该交易请求为模拟目标链路系统在生产环境下接收到的交易请求，该交易任务为模拟目标链路系统在生产环境下执行的交易任务。

示例性地，该交易任务可以为转账交易任务、支付交易任务、还款交易任务等。

S220，根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据。

其中，伴随延迟故障事件的影响，目标链路系统所受到的影响具体表现在每个交易任务的执行过程中。因此，在根据预设的业务指标采集与每项交易任务相关的数据时，可以根据该数据具体分析每项交易任务受到的影响，从而分析目标链路所受到的影响。其中，针对每项交易任务受到的影响包括该交易任务的事务一致性是否受到影响。

S230，根据采集到的数据确定交易任务的事务一致性结果。

具体而言，目标链路系统包括依照交易任务的处理顺序连接的多个节点。在目标链路系统在接收交易请求之前，还包括与目标链路系统的每个节点建立连接。其中，该连接可以为有线连接，也可以为无线连接。

可选地，节点可以配置有探针。节点中的探针用于接收延迟故障事件，并根据延迟故障事件执行对应的延迟操作。探针的设置方式可以参考现有技术。

可选地，节点可以为服务器。

本申请实施例提供了一种验证事务一致性的方法，应用于综合平台；本申请实施例提供的方法在进行事务一致性的验证过程中，设置综合平台来执行注入操作和监视操作，避免在关键链路系统(如，目标链路系统)的关键节点(如，目标注入节点)之间设置转发器，并调整关键节点的代码以实现相应的配置，同时避免为了解目标链路系统的上/下游节点的具体情况而浪费时间。也即，整个验证过程，只需要在该终综合平台的指定平台(如，混沌工程平台)中先确定目标链路系统的关键节点，并向该关键节点注入延迟故障事件，即可模拟出系统之间的交易延迟场景，并在该场景下进行交易任务的事务一致性的验证操作。

另外，在验证了交易任务的事务一致性结果基础上，可以进一步地基于交易任务的事务一致性结果来验证目标链路系统的运行状态是否也受到了影响。如，通过交易成功率来判别目标链路系统的运行状态是否受到影响。而由于目标链路系统的冲正机制的原因，可以设置在多个时刻分别验证目标链路系统的运行状态，如因处于交易延迟场景，该运行状态为故障状态，则说明目标链路系统的性能不够优异。

目标链路系统由多个节点组成，如何才能高效地注入延迟故障事件，以达到比较好的模拟效果，也是急需解决的技术问题。

针对该问题，本申请实施例还提供了一种可能的实现方式，向目标链路系统的目标注入节点注入预设的延迟故障事件，具体可以包括步骤Sa1～Sa2：

Sa1，根据预设的配置信息从多个节点中确定目标注入节点，以及为目标注入节点配置的延迟故障事件。

可选地，在验证准备阶段，还包括针对目标链路系统进行的配置操作。该配置操作可以包括从目标链路系统的多个节点中筛选出关键节点，并将该关键节点作为目标注入节点。该关键节点可以为处理交易任务的关键事务的节点，例如，输出交易结果的节点；也可以为用户指定的任一节点。

Sa2，向目标注入节点的探针发送配置的延迟故障事件对应的请求。

其中，目标注入节点的探针在获取到延迟故障事件之后，根据该延迟故障事件执行延迟处理。例如，若该延迟故障事件为URL延时事件，探针需处理基于HTTP协议实现的交易接口，若该交易接口发送请求信息，延迟5s发送该请求信息；若该交易接口为回应信息，延迟3s发送回应信息。

通过注入不同类型的延迟故障事件，可以实现对应的延时场景，每种延时场景对目标链路系统的压力是不同的。在确定为目标注入节点配置的延迟故障事件之后，根据配置的延迟故障事件生成对应的请求，并发送至目标注入节点。

可选地，延迟故障事件包括但不限于以下至少一项：

端口级延迟事件。具体地，针对基于TCP协议实现的交易接口，混沌工程平台可以针对指定的TCP端口实现网络延时场景。该场景用于模拟通过TCP协议实现的交易接口处理交易任务的具体事务时，处理时间被延长的情况。例如，该交易接口为目标链路系统中目标注入节点中的交易接口。

URL延迟事件。具体地，针对基于HTTP协议实现的交易接口，混沌工程平台可以针对HTTP协议中的网址URL实现HTTP延时的场景。该场景用于模拟通过HTTP接口处理交易任务的具体事务时，处理时间被延长的情况。

与交易类型相关的延迟事件。具体地，针对运行在JAVA Servlet容器的交易接口，混沌工程平台可以对交易任务的具体内容中的关键字实现JVM延时的场景。该场景用于模拟由JAVA程序处理交易任务的具体事务时，处理时间被延长的情况。

与请求方节点相关的延迟事件。具体地，针对运行在JAVA Servlet容器的交易接口，在交易报文规范中有请求方身份标识的接口，混沌工程平台可以对特定的请求方节点实现JVM延时的场景。该场景用于模拟指定交易任务的来源系统时，由JAVA程序处理交易任务的具体事务时，处理时间被延长的情况。

总量百分比延迟交易事件。具体地，针对基于TCP协议实现的交易接口，混沌平台可以针对指定的TCP端口，实现一部分交易网络延时场景，延时场景的总数据量根据用户输入的百分比计算。该场景用于模拟通过TCP接口处理交易任务的具体事务时，若部分请求受到网络不畅的影响，处理时间被延长的情况。

可定制次数的延迟事件。具体地，针对运行在JAVA Servlet容器的交易接口，混沌工程平台可以对交易任务的具体内容中的关键字，设置延迟交易的模拟次数N。该场景用于模拟N次JAVA程序处理交易任务的具体事务时，处理时间被延长的情况。

需要说明的是，本申请实施例还可以根据需求创建其他的延迟故障事件，为描述简便，在此不再赘述。

在目标链路系统伴随着延迟故障事件的影响下，如何通过采集数据并准确地分析每个交易任务所受到影响是很关键的。因此，本申请实施例还提供了以下可能的实现方式。

在一个可选实施例中，根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据，包括：

在伴随延迟故障事件的交易任务的执行过程中，针对每个节点至少采集以下业务指标对应的数据：为该节点分配的事务量、该节点已处理的事务量、处理事务之后的结果、响应时间；

可选地，处理事务之后的结果包括处理交易任务的具体事务时的交易结果。具体地，该交易结果包括交易成功和交易失败。

可选地，在验证准备阶段，还包括接收输入的选择指令，选择业务指标，以便于在目标链路系统被注入延迟故障事件之后采集何种数据。

可选地，该业务指标可以包括每个节点的TPS(Transaction Per Second，每秒事务处理量)、QPS(QueryPerSecond，每秒查询数量)、响应时间(从请求节点发起请求开始，到请求节点接收到响应节点反馈的回应消息结束，该过程所耗费的时间，该时间完整记录了节点处理请求的时间；其中，任一请求对应一项需要处理的事务)、交易成功率(成功的交易任务占总交易任务的比重)。

具体地，在设置交易成功率该项指标时，综合平台具体可以采集每项交易的交易过程信息，该交易过程信息包括输出的交易结果的信息。根据该交易结果的信息，可以确定交易任务关联的每个交易结果。

需要说明的是，针对目标链路系统所确定的业务指标还可以为其他指标，本申请对此并不进行限制。

在一个可选实施例中，根据采集到的数据确定交易任务的事务一致性结果，包括针对每项交易任务执行以下操作：

从多个节点中确定出交易结果为非空的目标输出节点；

若每个目标输出节点输出的交易结果为交易成功，确定该项交易任务的事务一致性结果为未受到影响；若所有目标输出节点输出的交易结果中包括至少一个交易失败，确定该项交易任务的事务一致性结果为受到影响。

其中，可将交易任务的事务一致性未受到影响的状态理解为交易任务的结果为成功；可将交易任务的事务一致性受到影响的状态理解为交易任务的结果为失败。

可选地，根据预设的业务指标采集到数据之后，针对每项交易任务，筛选与该交易任务相关联的数据。其中，相关联的数据包括处理交易任务的所有节点的信息，以及每个节点对所分配的事务的处理过程信息。通过每个节点的处理过程信息，可以了解节点是否在处理某项事务之后，得到交易结果。其中，部分节点的交易结果不为空。

可选地，根据每个节点相应的处理过程信息，筛选出交易结果为非空的目标输出节点。

可选地，统计所有的目标输出节点的交易结果。若确定每个交易结果为交易成功，确定该项交易任务的事务一致性未受到影响。若确定所有的交易结果中包括至少一个交易失败，则确定该项交易的事务一致性受到影响。

在一个具体的场景示例中，目标链路系统包括子系统A(每个子系统对应一个节点)、子系统B、子系统C和子系统D，该目标链路系统执行一项转账交易任务。在采集目标链路系统执行转账交易任务结束之后，筛选出子系统A和子系统B为目标输出节点。其中，子系统A为用户1(发起转账的用户)对应的节点，子系统B为用户2(接收转账的用户)对应的节点。其中，若子系统A的交易结果为交易成功，子系统B的交易结果为交易失败，则该转账交易任务的事务一致性结果为受到影响；若子系统A和子系统B的交易结果为交易成功，则该转账交易任务的事务一致性结果为未受到影响。

验证每项交易任务的事务一致性是否受到影响，实际上是在间接地验证目标链路系统在受到延迟故障事件的影响下，是否还能正常运转。

在一个可选实施例中，得到预设数量的交易任务的处理过程信息之后，还包括步骤Sb1～Sb2。

Sb1，在预设的多个时刻，分别统计所述预设数量的交易任务中事务一致性结果为未受到影响的交易任务的总数；

Sb2，根据所述总数确定相应时刻的目标链路系统的运行状态是否受到影响。具体地，若该总数与所述预设数量的比值不小于预设阈值，确定在该时刻所述目标链路系统的运行状态未受到所述延迟故障事件的影响；若该总数与所述预设数量的比值小于预设阈值，确定在该时刻所述目标链路系统的运行状态受到所述延迟故障事件的影响。

其中，该总数与预设数量的比值实质为交易成功率。可选地，该预设阈值可以为100％，也可以为预设的经验值。

可选地，在预设的时间段内，通过统一的间隔时间来选取多个时刻，如：以1s为间隔时间，在5s内选取5个时刻来统计总数。或者，从注入延迟事件的开始，每单位时间结束，就统计总数，如：从注入延迟事件开始，以1s为单位时间，选取多个时刻。或者在预设的时间段内，随机选取多个时刻，统计总数。

在一个可选实施例中，该方法还可以包括：通过可视化方式展示数据。

可选地，该展示的数据可以为S220中采集到的数据。

现有的链路系统在处理交易任务时，若遇到失败的情形，还会进行冲正处理，而冲正处理就是目标链路系统应对各种延时场景的关键手段。

一方面，目标链路系统作为一个分布式系统，涉及多个节点以及复杂的业务逻辑，因此，造成交易任务的事务一致性受到影响的原因相对复杂；而分布式系统每增加一个节点，相当于进一步加深复杂度。另一方面，为了保护交易任务的事务一致性不被影响，目标链路系统的设计者从结果出发，在验证交易任务的事务一致性受到影响之后，通过冲正机制再次处理交易任务，以达到保护交易任务的事务一致性不被影响。

为了能够理解目标链路系统如何应对延迟故障事件，本申请实施例还基于上述场景示例添加新的示例来进行说明。伴随着延迟故障事件的注入，交易任务可能延迟后成功，可以延迟后失败，而目标链路系统会给予相应的处理，以保护交易任务延迟后依然能够成功。

本示例中，以子系统A在处理事务之后得到交易成功的结果，然后向子系统B发送交易请求，以促使子系统B也能够得到交易成功的过程为例。

第一步、子系统A向子系统B发送交易请求，子系统A在超时时间内未收到子系统B反馈的响应消息，子系统A对子系统B交易结果未知。子系统B实际已成功处理事务并得到交易成功的结果，或者实际处理事务失败并得到交易失败的结果。

在子系统A对于子系统B的交易结果处于未知的状态下，可采取第二步。

第二步、子系统A向子系统B发起的交易请求超时后，子系统A继续向子系统B发起冲正交易请求。冲正交易请求超时，导致子系统A对子系统B的交易结果未知。子系统B实际已成功冲正成功并得到交易成功的结果，或者实际冲正失败并得到交易失败的结果。

在子系统A对于子系统B的交易结果处于未知的状态下，可采取第三步或者第四步去应对。

第三步、子系统A向子系统B发起冲正交易。子系统B冲正交易失败。子系统A后续向子系统B发起冲正到N次都失败。在子系统A第N+1次冲正交互时，子系统B冲正成功并得到交易成功的结果。

第四步、子系统A向子系统B发起冲正交易。子系统B冲正失败，子系统A后续向子系统B发起冲正到N次都失败。N次为子系统A自动冲正次数的最大值。对应交易转为手动冲正状态。其中，手动冲正状态是相对于子系统A自动冲正而言，比较依赖人工操作。

另外，延迟故障事件可能影响交易请求迟迟不达，导致冲正交易请求可能早于交易请求先到达子系统B。

具体地，子系统A向子系统B发送交易，子系统A在超时时间内未收到子系统B响应，交易结果未知。子系统B实际还未收到A的请求。后续子系统A发送冲正请求到子系统B，子系统B收到冲正请求并处理完成后，子系统A的交易请求到达子系统B。

基于冲正机制的存在，在多个时刻对交易任务的事务一致性的检查结果可能存在区别，如在包括第一时刻在内的多个时刻检测到交易任务的事务一致性受到影响，而在第二时刻检测到交易任务的事务一致性未受到影响。

基于冲正机制的存在，在较长一段时间内的多个时刻对交易任务的事务一致性的检查结果为未受到影响，还可以再次向目标链路系统发送交易请求，并再次注入其他类型的延迟故障事件或者延迟故障事件的组合，以测试目标链路系统是否会受到延迟故障事件的影响。

本申请实施例还提供了一种验证事务一致性的装置，如图3所示，该装置30以包括：注入模块310、采集模块320以及确定模块330，其中，

注入模块310，用于在目标链路系统基于交易请求执行预设数量的交易任务时，向目标链路系统的目标注入节点注入预设的延迟故障事件。

采集模块320，用于根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据。

确定模块330，用于根据采集到的数据确定交易任务的事务一致性结果。

在一种可能的实现方式中，目标链路系统包括依照交易任务的处理顺序连接的多个节点，在目标链路系统接收交易请求之前，注入模块310还用于：

与每个节点建立连接；其中，每个节点中配置有探针，探针用于执行延迟故障事件对应的延迟操作。

在一种可能的实现方式中，注入模块310在向目标链路系统的目标注入节点注入预设的延迟故障事件中，具体用于：

根据预设的配置信息从多个节点中确定目标注入节点，以及为目标注入节点配置的延迟故障事件；向目标注入节点的探针发送配置的延迟故障事件对应的请求。

其中，配置的延迟故障事件包括以下至少一项：

端口级延时事件、URL延时事件、根据交易类型延迟、根据请求方节点延迟事件、总量百分比延迟交易事件和可定制次数的延迟事件。

在一种可能的实现方式中，采集模块320在根据预设的业务指标采集伴随延迟故障事件时执行交易任务的数据中，具体用于：

在伴随延迟故障事件的交易任务的执行过程中，针对每个节点至少采集以下业务指标对应的数据：为该节点分配的事务量、该节点已处理的事务量、处理事务之后的结果、响应时间，处理事务之后的结果包括输出交易任务的交易结果。

在一种可能的实现方式中，确定模块330在根据采集到的数据确定交易任务的事务一致性结果中，具体用于针对每项交易任务执行以下操作：

从多个节点中确定出交易结果为非空的目标输出节点；若每个目标输出节点输出的交易结果为交易成功，确定该项交易任务的事务一致性结果为未受到影响；若所有目标输出节点输出的交易结果中包括至少一个交易失败，确定该项交易任务的事务一致性结果为受到影响。

在一种可能的实现方式中，确定模块330还可以用于：

在预设的多个时刻，分别统计所述预设数量的交易任务中事务一致性结果为未受到影响的交易任务的总数；

根据总数确定相应时刻的目标链路系统的运行状态是否受到影响。具体地，若该总数与所述预设数量的比值不小于预设阈值，确定在该时刻所述目标链路系统的运行状态未受到所述延迟故障事件的影响；若该总数与所述预设数量的比值小于预设阈值，确定在该时刻所述目标链路系统的运行状态受到所述延迟故障事件的影响。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现一种验证事务一致性的方法的步骤，与相关技术相比可实现：通过综合平台向目标链路系统的目标注入节点注入预设的延迟故障事件，以及采集目标链路系统的运行数据，从而实现对交易任务的事务一致性的验证。

在一个可选实施例中提供了一种电子设备，如图4所示，图4所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

其中，电子设备包括但不限于：计算机终端。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (10)

1.一种验证事务一致性的方法，其特征在于，所述方法包括：

在目标链路系统基于交易请求执行预设数量的交易任务时，向所述目标链路系统的目标注入节点注入预设的延迟故障事件；

根据预设的业务指标采集伴随所述延迟故障事件时执行所述交易任务的数据；

根据采集到的数据确定所述交易任务的事务一致性结果。

2.根据权利要求1所述的方法，其特征在于，所述目标链路系统包括依照所述交易任务的处理顺序连接的多个节点，在目标链路系统接收所述交易请求之前，所述方法包括：

与每个所述节点建立连接；其中，每个节点中配置有探针，所述探针用于执行所述延迟故障事件对应的延迟操作。

3.根据权利要求2所述的方法，其特征在于，所述向所述目标链路系统的目标注入节点注入预设的延迟故障事件，包括：

根据预设的配置信息从所述多个节点中确定目标注入节点，以及为所述目标注入节点配置的延迟故障事件；

向所述目标注入节点的探针发送所述配置的延迟故障事件对应的请求。

4.根据权利要求2或者3所述的方法，其特征在于，所述根据预设的业务指标采集伴随所述延迟故障事件时执行所述交易任务的数据，包括：

在伴随所述延迟故障事件的所述交易任务的执行过程中，针对每个节点至少采集以下业务指标对应的数据：

为该节点分配的事务量、该节点已处理的事务量、处理事务之后的结果、响应时间，所述处理事务之后的结果包括输出交易任务的交易结果。

5.根据权利要求4所述的方法，其特征在于，所述根据采集到的数据确定所述交易任务的事务一致性结果，包括针对每项交易任务执行以下操作：

从所述多个节点中确定出交易结果为非空的目标输出节点；

若每个目标输出节点输出的交易结果为交易成功，确定该项交易任务的事务一致性结果为未受到影响；

若所有目标输出节点输出的交易结果中包括至少一个交易失败，确定该项交易任务的事务一致性结果为受到影响。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在预设的多个时刻，分别统计所述预设数量的交易任务中事务一致性结果为未受到影响的交易任务的总数；

根据所述总数确定相应时刻的目标链路系统的运行状态是否受到影响。

7.根据权利要求6所述的方法，其特征在于，所述根据所述总数确定相应时刻的目标链路系统的运行状态是否受到影响，包括针对所述多个时刻中每一时刻相应的总数执行以下操作：

若该总数与所述预设数量的比值不小于预设阈值，确定在该时刻所述目标链路系统的运行状态未受到所述延迟故障事件的影响；

若该总数与所述预设数量的比值小于预设阈值，确定在该时刻所述目标链路系统的运行状态受到所述延迟故障事件的影响。

8.根据权利要求3所述的方法，其特征在于，所述配置的延迟故障事件包括以下至少一项：

端口级延迟事件、URL延迟事件、与交易类型相关的延迟事件、与请求方节点相关的延迟事件、总量百分比延迟事件和与设定次数相关的延迟事件。

9.一种验证事务一致性的综合平台，其特征在于，所述综合平台包括混沌工程平台、监控平台和测试平台，并分别与目标链路系统相连接；其中，

所述测试平台，用于向所述目标链路系统发送预设数量的交易请求，以触发所述目标链路系统执行预设数量的交易任务；

所述混沌工程平台，用于向所述目标链路系统的目标注入节点注入预设的延迟故障事件；

所述监控平台，用于根据预设的业务指标采集伴随所述延迟故障事件时执行所述交易任务的数据；以及根据采集到的数据确定执行所述交易任务的事务一致性结果。

10.一种验证事务一致性的装置，其特征在于，应用于权利要求8所示的综合平台，所述装置包括：

注入模块，用于在目标链路系统基于交易请求执行预设数量的交易任务时，向所述目标链路系统的目标注入节点注入预设的延迟故障事件；

采集模块，用于根据预设的业务指标采集伴随所述延迟故障事件时执行所述交易任务的数据；

确定模块，用于根据采集到的数据确定所述交易任务的事务一致性结果。

Images