CN115604164A - 一种分布式定时消息系统测试方法、装置以及设备 - Google Patents

Abstract

本说明书实施例公开了一种分布式定时消息系统测试方法、装置以及设备。方案包括：通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息，根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

Description

一种分布式定时消息系统测试方法、装置以及设备

技术领域

本说明书涉及测试技术领域，尤其涉及一种分布式定时消息系统测试方法、装置以及设备。

背景技术

在分布式定时消息系统中，有多个节点都负责定时消息的投递，它们通常按照一定的策略进行合作以提高效率，同时兼顾容灾。

由于定时消息不是立即发出的，而是经过一定的延迟时间后才会发出，因此整个系统的不确定性提高了。在延迟时间内，以及延迟时间到期后投递定时消息的过程中，系统内可能发生节点状态变迁，进而导致各种分布式不一致的风险，这些风险直观的表现包括定时消息丢失、重发、投递时间不符合预期等。

基于此，需要能够可靠低成本地测试分布式定时消息系统测试的鲁棒性的测试方案，以指导对系统的改进，降低这些风险。

发明内容

本说明书一个或多个实施例提供一种分布式定时消息系统测试方法、装置、设备以及存储介质，用以解决如下技术问题：需要能够更可靠地测试分布式定时消息系统测试的鲁棒性的测试方案，以指导对系统的改进，降低这些风险。

为解决上述技术问题，本说明书一个或多个实施例是这样实现的：

本说明书一个或多个实施例提供的一种分布式定时消息系统测试方法，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述方法包括：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

本说明书一个或多个实施例提供的一种分布式定时消息系统测试装置，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述装置包括：

消息订阅模块，通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

故障注入模块，根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

发布投递模块，通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

结果确定模块，根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

本说明书一个或多个实施例提供的一种分布式定时消息系统测试设备，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

本说明书一个或多个实施例提供的一种非易失性计算机存储介质，所述介质存储有计算机可执行指令，所述计算机可执行指令设置为：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

本说明书一个或多个实施例采用的上述至少一个技术方案能够达到以下有益效果：针对基于分布式集群的定时消息的使用，提供了消息发布客户端、消息订阅客户端和定时消息服务端三端配合的架构，由消息发布客户端向定时消息服务端发布定时消息，定时消息服务端向消息订阅客户端投递定时消息，对定时消息服务端进行主动的可选类型的故障注入，以使得定时消息的投递过程收到服务端故障的影响，进而以这种影响下消息订阅客户端对大量定时消息的接收情况(比如，完整性、实时性等)作为系统稳态评判依据，定向性和可靠性较好，能够实现日常级可持续运行异常测试和降低人工操作成本，较好地支持了分布式定时消息系统鲁棒性的测试场景。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例提供的一种分布式定时消息系统测试方法的流程示意图；

图2为本说明书一个或多个实施例提供的一种分布式定时消息系统的部分架构示意图；

图3为本说明书一个或多个实施例提供的图2中的系统中的分区接管的场景示意图；

图4为本说明书一个或多个实施例提供的图1中方法的一种具体实施方案的原理示意图；

图5为本说明书一个或多个实施例提供的一种分布式定时消息系统测试装置的结构示意图；

图6为本说明书一个或多个实施例提供的一种分布式定时消息系统测试设备的结构示意图。

具体实施方式

本说明书实施例提供一种分布式定时消息系统测试方法、装置、设备以及存储介质。

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请提出了适用性较好的分布式定时消息系统鲁棒性的测试方案，尝试在中间件定时消息产品等产品系统上测试使用。其中，定时消息指的是在指定时间戳之后才可被消费者消费的消息，用于解决一些消息生产和消费有时间窗口要求的场景，或者通过消息触发定时任务的场景，定时消息往往用于触发指定业务功能定时运行，比如，页面刷新、交易重试、支付提醒、运行风控策略、收集订单数据、上报监控数据等；鲁棒性指的是软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，仍然能够正常完成工作。

本方案在以定时消息完整性和实时性为检验标准的前提下，通过发送指令构造服务端故障注入，从而实现日常级稳定性测试集成，持续挖掘产品鲁棒性相关问题。下面基于这样的思路详细说明。

图1为本说明书一个或多个实施例提供的一种分布式定时消息系统测试方法的流程示意图。该方法可以应用于不同的业务领域中，这些业务领域比如包括：电子支付业务领域、电商业务领域、社交业务领域、游戏业务领域、公务业务领域等。该流程可以在这些领域中的分布式定时消息系统设备，和/或连接这些系统的测试设备上执行，比如，在这些设备上预先安装测试程序，通过运行测试程序，向一端或者多端发送相应的控制指令，指令接收端响应于控制指令，具体执行相应步骤。流程中的某些输入参数或者中间结果允许人工干预调节，以帮助提高准确性。

图1中的流程可以包括以下步骤：

S102：通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅。

分布式定时消息系统包括消息发布客户端、消息订阅客户端、定时消息服务端(可简称为服务端)，各端都可以有多个，预先进行了分布式的部署。

在本说明书一个或多个实施例中，该系统至少包括由多个定时消息服务端构成的分布式集群，各定时消息服务端分别为该分布式集群中的一个节点，而消息发布客户端、消息订阅客户端也可以作为该分布式集群中的节点，或者处于该分布式集群之外。通过该分布式集群为客户端提供定时消息服务。由消息订阅客户端订阅定时消息，消息发布客户端或者定时消息服务端自身对应地发布定时消息，发布的定时消息由定时消息服务端适时地投递给消息订阅客户端，在测试过程中，比如，由测试脚本来触发消息订阅客户端进行订阅，触发消息发布客户端进行发布，然后测试定时消息服务端的投递效果是否出现异常。

S104：根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障。

在本说明书一个或多个实施例中，背景技术中提到了系统内可能发生节点状态变迁进而导致风险，该风险主要体现在对定时消息服务端的投递效果的影响。为了实现日常级的故障复现和稳定测试，主动通过构造故障注入指令，向定时消息服务端注入所需的故障，如此，既便于按需随时测试，又能够及时恢复正常业务。

定时消息对应的延迟时间至少包括定时时长，比如，为某定时消息设定30秒的定时时长，则应当在预定的其实时间点之后的30秒时，发送(比如，投递、或者发布加投递等)该定时消息或者接收到该定时消息，那么，该定时消息对应的延迟时间可以相应地为30秒。另外，考虑到消息发送和接收也需要耗费少量时间(比如，毫秒级别的时长)，则也可以在定时时长基础上增补一点时延，再将整体作为定时消息对应的延迟时间。

本方案同样也可以用于在即时消息的场景下测试，但是，由于消息是即时发送的，而即刻下该场景下服务端的稳定性和可预期性相对明确，因此，测试时间窗口更窄，测试效果局限性较大，不利于完整全面地模拟和挖掘出真实情况下的各种复杂的风险发生环境。基于此，本申请的方案主要是针对定时消息的场景的，可以通过大量定时消息不同延迟时间的配合，以及多种可选类型和可选策略的服务端故障注入，更真实地构造各种复杂的测试场景，有助于在低成本下取得更高效和有效的测试效果。

在本说明书一个或多个实施例中，根据定时消息对应的延迟时间，构造对应的故障注入时间不小于该延迟时间的故障注入指令，以进行服务端故障注入，其中，故障注入时间包括注入的故障的至少部分生效持续时间。如此，有利于使得在定时消息在延迟后，进行发送或者接收等关键时间点上，服务端是处于所期望的故障状态的，由此，接收定时消息的情况所可能发生的异常，更有可能是该故障导致的，有助于明确测试过程中测试影响因素与测试结果之间的关联关系和关联程度。

在本说明书一个或多个实施例中，在测试过程中，同时有大量定时消息参与，它们的延迟时间的设定策略是多样的，比如，设置一致的延迟时间，设置阶梯化的延迟时间等，类似地，参与消息投递的服务端和消息订阅客户端也可以是大量的，由此能构造出更复杂更真实的测试环境，更准确地测试服务端的鲁棒性。

S106：通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息。

在本说明书一个或多个实施例中，一个或者多个消息订阅客户端向定时消息服务端订阅定时消息，该定时消息由消息发布客户端向服务端发布，服务端将发布的该定时消息，向订阅了该定时消息的各消息订阅客户端投递，故障的注入则可能影响服务端的投递动作，进而影响消息订阅客户端的接收情况。

在本说明书一个或多个实施例中，定时消息服务端在投递定时消息前或者投递定时消息的过程中，处于受到注入的故障影响的状态，由此，可能使得该定时消息服务端被另一个定时消息服务端接管服务，继续完成投递，接管服务的过程则会发生节点状态变迁，本方案尤其关注这种情况下的服务端鲁棒性表现。需要说明的是，该另一个定时消息服务端也可以是注入了故障的，本方案不光关注单个定时消息服务端的鲁棒性，更关注整个分布式集群的鲁棒性。

S108：根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

在本说明书一个或多个实施例中，订阅反映了对所要接收到的定时消息的预期，而由于故障的影响，导致消息订阅客户端接收定时消息的情况未必符合该预期，通过校验确定与该预期的不符程度。比如，根据订阅，对消息订阅客户端通过服务端的投递，接收到的定时消息的完整性和实时性进行校验，以确定投递受注入的指定类型的故障的影响，从而确定服务端的鲁棒性表现。除此之外，还可以校验涉及该定时消息的一个服务端本地或者多个服务端之前的交互动作和状态变迁情况，看是否符合预定的逻辑。

在本说明书一个或多个实施例中，上述的测试过程可以编排为日常级测试用例，反复执行，以获得更可靠的全局的测试结果。

通过图1的方法，针对基于分布式集群的定时消息的使用，提供了消息发布客户端、消息订阅客户端和定时消息服务端三端配合的架构，由消息发布客户端向定时消息服务端发布定时消息，定时消息服务端向消息订阅客户端投递定时消息，对定时消息服务端进行主动的可选类型的故障注入，以使得定时消息的投递过程收到服务端故障的影响，进而以这种影响下消息订阅客户端对大量定时消息的接收情况(比如，完整性、实时性等)作为系统稳态评判依据，定向性和可靠性较好，能够实现日常级可持续运行异常测试和降低人工操作成本，较好地支持了分布式定时消息系统鲁棒性的测试场景。

基于图1的方法，本说明书还提供了该方法的一些具体实施方案和扩展方案，下面继续进行说明。

更直观地，结合一种示例性的分布式定时消息系统继续说明，参见图2。图2为本说明书一个或多个实施例提供的一种分布式定时消息系统的部分架构示意图。

在图2中，生产者作为上述的消息发布客户端，消费者作为上述的消息订阅客户端，定时消息服务端有多个，分区表中示出的服务端A、服务端B和服务端C等，还有分区协调者负责协调各定时消息服务端。该系统可以以定时消息服务端作为维度，对全部消息(包括待投递的定时消息)进行逻辑上的划分，得到多个分区，分配给对应的定时消息服务端，由对应的定时消息服务端为属于该分区的消息提供投递等服务。比如，当前服务端A对应的分区为P1、P2，服务端B对应的分区为P3、P4，服务端B对应的分区为P5、P6，分区协调者则在各定时消息服务端之间进行分区配置信息同步，以及分配分区。

正常工作时，生产者生产消息，并输入对应的定时消息服务端，还可以向服务端发送定时指令，以使得消息成为定时消息，也可以发送指令取消定时。在定时消息服务端上，可以设置过滤器(有多个过滤器时可以构成过滤器链)用于对输入消息进行过滤，过滤出满足规则的消息存储路由器，该系统中示例性地利用称为时间轮的轮状数据结构存储定时消息，时间轮划分为多格，根据定时消息的定时时长确定其应当存储在哪个格中，当定时时间较长(长于时间轮的一周所代表的时长)时，需要通过轮数加格数的方式，确定定时消息应当存储在哪格中，等待在达到轮数且到达该格时再将该定时消息发出，存储区可以分为短期存储区和长期存储区，根据实际需求选择使用。定时消息服务端同时会通过时间轮触发器计时，并在定时时长到期时，触发向存储查询对应的定时消息，并通过投递路由器，将该消息作为输出消息向对应的消费者投递。

在实际应用中，当分布式集群中的定时消息服务端的数量出现变化时(比如，机器扩缩容，替换，宕机等)，为了保证新上线的服务端能拥有分区配置信息开始提供服务，或者下线的服务端的分区被其他服务端接管，会触发集群的分区重分配。参见图3，图3为本说明书一个或多个实施例提供的图2中的系统中的分区接管的场景示意图。

在图3中，初始时，分区P3由服务端A负责，服务端B作为P3的备份负责者，当服务端A由于诸如故障或者主动关闭等原因，暂时无法负责P3时，则服务端B会接管P3。服务端A通过关闭P3的计时器，以及相应地更新检测点，关闭了P3，服务端B通过建立P3的计时器，以及读取分区检测点，启动失效消息补偿任务，恢复P3，具体比如，在关闭P3前，索引到了1007的时间点，在接管时，针对P3，可以从1007开始继续获取相应时间点的消息，比如，获取了从1007到1009的时间点对应的消息，进而当前索引更新到了1010处，服务端B继续为P3服务。在这个过程中，会有分区状态变迁阶段，从而导致分布式不一致的风险。

类似地，向定时消息服务端注入指定类型的故障之后，通过注入指定类型的故障，可以在分布式集群中触发：至少一个定时消息服务端新上线负责投递定时消息的服务，或者至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务。对于整个系统而言，其响应于向服务端注入的指定类型的故障，可能进入分区状态变迁阶段，在分区状态变迁阶段，至少部分分区被重新分配或者切换容灾状态(比如，不同服务端接管服务以实现多备份容灾)。

在本说明书一个或多个实施例中，测试过程实际执行时，故障注入时间段可能相对长，而在这段时间内，较为关键的分区状态变迁阶段可能占其中一小部分，定时消息对应的延迟时间都是预先设定的，未必能够命中分区状态变迁阶段，如此，可能降低异常情况发生的概率，不利于通过测试挖掘出问题。针对这个问题，本方案采用自适应调整的延时时间，使得定时消息实质上成为自适应动态定时的定时消息，具体比如，定时消息服务端等待以及执行投递定时消息的步骤时，可以判断定时消息对应的延迟时间是否与分区状态变迁阶段相匹配，若否，则相应地调整延迟时间，以强制在分区状态变迁阶段中尝试投递定时消息，从而有助于更高概率地引发异常，提高测试收益。

根据上面的说明，本说明书一个或多个实施例还提供了图1中方法的一种具体实施方案的原理示意图，如图4所示。结合图4，对该具体实施方案进行说明，示例性的步骤包括以下：

环境搭建：在稳定测试环境搭建固定的一个或者多个定时消息发布客户端和定时消息订阅客户端，定时消息服务端启动指定的指令接收端对外暴露HTTP服务，用于接受故障注入。

数据准备：通过清理残余数据，确保各客户端无残留消息，批量发起定时消息的订阅和对应发布。比如，发起100笔30秒延迟后的定时消息订阅(量级可任意调节)，触发后检查当前这100笔订阅初始化成功，并且尚接收到所订阅的消息。

发送故障注入指令：在数据准备完成后异步发起不小于定时消息延迟时间的故障注入。所注入的故障比如包括以下至少一种类型的原子故障：宕机、CPU飙高、磁盘打满、IO异常、内存飙高、网络包延迟重复和丢失、JVM方法级异常等。与此同时，定时消息服务端根据消息发布客户端发布上来的数据异步进行定时消息的投递，消息订阅客户端收到服务端投递过来的消息后进行消费。通过这步实现构造了分布式定时消息系统在异常下处理定时消息的场景。

结果校验：在预期时间，比如30秒后校验消息订阅端收到上述100条批量定时消息，以此为依据判断定时消息的完整性与实时性未受到服务端异常的影响，可以检查定时消息是否按预期消费成功，从而验证系统的鲁棒性，本次测试完毕后可以及时清理残余数据，以便后续测试。

生成基线：将测试结果对应的测试过程和场景编排为日常测试任务，进行多次触发运行，根据一次或者多次运行的结果生成鲁棒性测试基线，若测试结果异常可以相应调整后，再生成基线。

在本说明书一个或多个实施例中，分布式集群中有多个定时消息服务端参与测试过程，因此，定时消息服务端之间有可能切换接管服务，为了在单次测试中尽可能地让异常暴露出来，采用链式的故障跟踪注入方案，让故障注入跟随服务的转移也相应地及时转移。如此，也能够避免预先大面积地给定时消息服务端注入故障而浪费资源。

具体比如，向定时消息服务端注入指定类型的故障之后，将被注入故障的该定时消息服务端作为第一服务端，确定响应于该故障，多个定时消息服务端中的第二服务端要从第一服务端接管投递定时消息的服务，通过第一服务端，向所述第二服务端注入指定类型的故障，可以在接管切换过程中顺便注入，有助于避免增加指令交互开销。

进一步地，基于这样的思路，设计了逐渐减弱的故障注入，以延长服务接管链(由依次接管服务的多个服务端构成)。沿用上例进行说明，可以使得第二服务端被注入的故障对应的服务妨害效果，低于第一服务端被注入的故障对应的服务妨害效果(比如，CPU飙高对应的服务妨害效果，通常低于宕机对应的服务妨害效果)，因为，服务妨害效果越高的故障越有可能导致服务端切换接管，从而针对同一个定时消息可能导致多次接力接管，以此类推，若第二服务端由于故障也无法投递消息，则可能由第三服务端继续接管服务，则第二服务端向第三服务端注入服务妨害效果进一步降低的故障。除了接力注入故障的方式以外，也可以由统一的一端来负责所有故障的注入，相应的精准性和灵活性可能受到影响。除了服务妨害效果逐渐降低以外，还可以使得服务接管链上各次注入的故障在类型上呈现至少部分差异化(比如，第一次注入的是宕机故障，第二次注入的是CPU飙高等)，从而提高了场景的复杂度，有助于更有效率地挖掘出系统异常。

在本说明书一个或多个实施例中，对于一些类型的故障，在实际应用中具有即时波动性，比如，CPU飙高、内存飙高，大多数时候由于服务妨害效果并非达到临界值，因此未必会引发服务端切换接管，则会在故障状态持续一段时间。在这种情况下，考虑在测试过程中不仅要模拟故障的高峰状态，同样也要模拟故障的低谷状态，因为低谷状态可能是系统保持鲁棒性的关键所在，即系统虽然在故障高峰状态可能发生异常，但其也有可能撑过高峰状态，而在低谷状态顺利完成业务。当然，在实际应用中，低谷状态可能是转瞬即逝的，本方案考虑出在测试过程中，通过插入安全时隙的方案模拟这种低谷状态，以给予同一个服务端打翻身仗的机会，而不是平稳地一直用故障持续压制它，从而能够更加客观地评估系统在实际业务剧烈波动的状态下的鲁棒性。

具体比如，在向定时消息服务端注入指定类型的故障之后，可以判断通过注入指定类型的故障，是否触发了至少一个定时消息服务端从另一个定时消息服务端接管投递定时消息的服务，若否，则在故障的注入生效时间段中插入安全时隙，在安全时隙，注入的故障不生效，安全时隙的长度小于甚至可以远小于注入生效时间段，从而有助于精准地评价系统鲁棒性的敏感和响应速度，若服务端能抓住安全时隙来顺利投递定时消息，则鲁棒性的敏感和响应速度相对高，整个系统相对更可靠。

基于同样的思路，本说明书一个或多个实施例还提供了上述方法对应的装置和设备，如图5、图6所示。

图5为本说明书一个或多个实施例提供的一种分布式定时消息系统测试装置的结构示意图，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述装置包括：

消息订阅模块502，通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

故障注入模块504，根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

发布投递模块506，通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

结果确定模块508，根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

可选地，所述故障注入模块504，根据所述定时消息对应的延迟时间，构造对应的故障注入时间不小于所述延迟时间的故障注入指令。

可选地，所述系统包括由多个所述定时消息服务端构成的分布式集群；

所述故障注入模块504，在所述向所述定时消息服务端注入指定类型的故障之后，通过所述注入指定类型的故障，在所述分布式集群中触发：至少一个定时消息服务端新上线负责投递所述定时消息的服务，或者至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务。

可选地，还包括：

分区管理模块510，以所述定时消息服务端作为维度，对待投递的全部定时消息进行逻辑上的划分，得到多个分区，分配给对应的所述定时消息服务端；

所述分区管理模块510，在所述向所述定时消息服务端注入指定类型的故障之后，响应于所述注入的指定类型的故障，进入分区状态变迁阶段；

在所述分区状态变迁阶段，至少部分所述分区被重新分配或者切换容灾状态。

可选地，所述故障注入模块504，判断所述定时消息对应的延迟时间是否与所述分区状态变迁阶段相匹配；

若否，则相应地调整所述延迟时间，以强制在所述分区状态变迁阶段中尝试投递所述定时消息。

可选地，所述故障注入模块504，在所述向所述定时消息服务端注入指定类型的故障之后，将被注入所述故障的所述定时消息服务端作为第一服务端；

确定响应于所述故障，所述多个定时消息服务端中的第二服务端要从所述第一服务端接管投递所述定时消息的服务；

通过所述第一服务端，向所述第二服务端注入指定类型的故障。

可选地，所述第二服务端被注入的故障对应的服务妨害效果，低于所述第一服务端被注入的故障对应的服务妨害效果。

可选地，所述故障注入模块504，在所述向所述定时消息服务端注入指定类型的故障之后，判断通过所述注入指定类型的故障，是否触发了至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务；

若否，则在所述故障的注入生效时间段中插入安全时隙，在所述安全时隙，所述故障不生效，所述安全时隙的长度小于所述注入生效时间段。

可选地，所述故障注入模块504，向所述定时消息服务端注入以下至少一种类型的原子故障：

宕机、CPU飙高、磁盘打满、IO异常、内存飙高、网络包延迟重复和丢失、JVM装置级异常。

可选地，所述结果确定模块508，根据所述订阅，对所述定时消息服务端通过所述投递，接收到的定时消息的完整性和实时性进行校验，以确定所述投递受所述注入的指定类型的故障的影响。

可选地，所述结果确定模块508，在所述根据校验结果确定对所述系统的测试结果之后，将所述测试结果对应的测试过程编排为日常测试任务，进行多次运行；

根据所述多次运行的结果生成测试基线。

图6为本说明书一个或多个实施例提供的一种分布式定时消息系统测试设备的结构示意图，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

处理器与存储器之间可以通过总线通信，设备还可以包括与其他设备通信的输入/输出接口。

基于同样的思路，本说明书一个或多个实施例还提供了对应于图1中方法的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (23)

1.一种分布式定时消息系统测试方法，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述方法包括：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

2.如权利要求1所述的方法，所述根据所述定时消息对应的延迟时间，构造故障注入指令，具体包括：

根据所述定时消息对应的延迟时间，构造对应的故障注入时间不小于所述延迟时间的故障注入指令。

3.如权利要求1所述的方法，所述系统包括由多个所述定时消息服务端构成的分布式集群；

所述向所述定时消息服务端注入指定类型的故障之后，所述方法还包括：

通过所述注入指定类型的故障，在所述分布式集群中触发：至少一个定时消息服务端新上线负责投递所述定时消息的服务，或者至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务。

4.如权利要求3所述的方法，还包括：

以所述定时消息服务端作为维度，对待投递的全部定时消息进行逻辑上的划分，得到多个分区，分配给对应的所述定时消息服务端；

所述向所述定时消息服务端注入指定类型的故障之后，所述方法还包括：

响应于所述注入的指定类型的故障，进入分区状态变迁阶段；

在所述分区状态变迁阶段，至少部分所述分区被重新分配或者切换容灾状态。

5.如权利要求4所述的方法，所述定时消息服务端向所述消息订阅客户端投递所述定时消息，还包括：

判断所述定时消息对应的延迟时间是否与所述分区状态变迁阶段相匹配；

若否，则相应地调整所述延迟时间，以强制在所述分区状态变迁阶段中尝试投递所述定时消息。

6.如权利要求3所述的方法，所述向所述定时消息服务端注入指定类型的故障之后，所述方法还包括：

将被注入所述故障的所述定时消息服务端作为第一服务端；

确定响应于所述故障，所述多个定时消息服务端中的第二服务端要从所述第一服务端接管投递所述定时消息的服务；

通过所述第一服务端，向所述第二服务端注入指定类型的故障。

7.如权利要求6所述的方法，所述第二服务端被注入的故障对应的服务妨害效果，低于所述第一服务端被注入的故障对应的服务妨害效果。

8.如权利要求3所述的方法，所述向所述定时消息服务端注入指定类型的故障之后，所述方法还包括：

判断通过所述注入指定类型的故障，是否触发了至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务；

若否，则在所述故障的注入生效时间段中插入安全时隙，在所述安全时隙，所述故障不生效，所述安全时隙的长度小于所述注入生效时间段。

9.如权利要求1所述的方法，所述向所述定时消息服务端注入指定类型的故障，具体包括：

向所述定时消息服务端注入以下至少一种类型的原子故障：

宕机、CPU飙高、磁盘打满、IO异常、内存飙高、网络包延迟重复和丢失、JVM方法级异常。

10.如权利要求1所述的方法，所述根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，具体包括：

根据所述订阅，对所述消息订阅客户端通过所述投递，接收到的定时消息的完整性和实时性进行校验，以确定所述投递受所述注入的指定类型的故障的影响。

11.如权利要求1所述的方法，所述根据校验结果确定对所述系统的测试结果之后，所述方法还包括：

将所述测试结果对应的测试过程编排为日常测试任务，进行多次运行；

根据所述多次运行的结果生成测试基线。

12.一种分布式定时消息系统测试装置，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述装置包括：

消息订阅模块，通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

故障注入模块，根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

发布投递模块，通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

结果确定模块，根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

13.如权利要求12所述的装置，所述故障注入模块，根据所述定时消息对应的延迟时间，构造对应的故障注入时间不小于所述延迟时间的故障注入指令。

14.如权利要求12所述的装置，所述系统包括由多个所述定时消息服务端构成的分布式集群；

所述故障注入模块，在所述向所述定时消息服务端注入指定类型的故障之后，通过所述注入指定类型的故障，在所述分布式集群中触发：至少一个定时消息服务端新上线负责投递所述定时消息的服务，或者至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务。

15.如权利要求14所述的装置，还包括：

分区管理模块，以所述定时消息服务端作为维度，对待投递的全部定时消息进行逻辑上的划分，得到多个分区，分配给对应的所述定时消息服务端；

所述分区管理模块，在所述向所述定时消息服务端注入指定类型的故障之后，响应于所述注入的指定类型的故障，进入分区状态变迁阶段；

在所述分区状态变迁阶段，至少部分所述分区被重新分配或者切换容灾状态。

16.如权利要求15所述的装置，所述故障注入模块，判断所述定时消息对应的延迟时间是否与所述分区状态变迁阶段相匹配；

若否，则相应地调整所述延迟时间，以强制在所述分区状态变迁阶段中尝试投递所述定时消息。

17.如权利要求14所述的装置，所述故障注入模块，在所述向所述定时消息服务端注入指定类型的故障之后，将被注入所述故障的所述定时消息服务端作为第一服务端；

确定响应于所述故障，所述多个定时消息服务端中的第二服务端要从所述第一服务端接管投递所述定时消息的服务；

通过所述第一服务端，向所述第二服务端注入指定类型的故障。

18.如权利要求17所述的装置，所述第二服务端被注入的故障对应的服务妨害效果，低于所述第一服务端被注入的故障对应的服务妨害效果。

19.如权利要求14所述的装置，所述故障注入模块，在所述向所述定时消息服务端注入指定类型的故障之后，判断通过所述注入指定类型的故障，是否触发了至少一个定时消息服务端从另一个定时消息服务端接管投递所述定时消息的服务；

若否，则在所述故障的注入生效时间段中插入安全时隙，在所述安全时隙，所述故障不生效，所述安全时隙的长度小于所述注入生效时间段。

20.如权利要求12所述的装置，所述故障注入模块，向所述定时消息服务端注入以下至少一种类型的原子故障：

宕机、CPU飙高、磁盘打满、IO异常、内存飙高、网络包延迟重复和丢失、JVM装置级异常。

21.如权利要求12所述的装置，所述结果确定模块，根据所述订阅，对所述定时消息服务端通过所述投递，接收到的定时消息的完整性和实时性进行校验，以确定所述投递受所述注入的指定类型的故障的影响。

22.如权利要求12所述的装置，所述结果确定模块，在所述根据校验结果确定对所述系统的测试结果之后，将所述测试结果对应的测试过程编排为日常测试任务，进行多次运行；

根据所述多次运行的结果生成测试基线。

23.一种分布式定时消息系统测试设备，所述系统包括消息发布客户端、消息订阅客户端、定时消息服务端，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述消息订阅客户端，批量发起对所述消息发布客户端可发布的定时消息的订阅；

根据所述定时消息对应的延迟时间，构造故障注入指令并发送给所述定时消息服务端，以向所述定时消息服务端注入指定类型的故障；

通过所述消息发布客户端，将所述消息订阅客户端订阅的各所述定时消息向所述定时消息服务端发布，以便所述定时消息服务端向所述消息订阅客户端投递所述定时消息；

根据所述订阅，对所述消息订阅客户端接收所述定时消息的情况进行校验，根据校验结果确定对所述系统的测试结果。

Images