我正在参加「掘金·启航计划」

简介

重试任务在分布式系统中也是经常使用到的一种策略，它的主要作用是在分布式事务执行过程中，出现一些不可避免的异常时，为了确保整个流程的完整性，主动发起重试任务，对为完成的事务进行补偿处理，保证了分布式事务的最终一致性。

架构设计

• 重试参数说明

• 重试任务触发机制
  
  上图简单描述了重试任务触发逻辑，支持http请求发送、MQ消息发送的两种方式，紧接着重试任务集群收到消息后就将消息进行存储。看到这里相信很多人不理解为什么要发送消息吧，这个就可以简单的理解为common-retry-task作为一个公共服务，就是要先接收到消息，才知道下一步要做什么事情，别着急我们继续进一步分析。

• 消息处理机制
  
  如图无论是通过http发送或者MQ拉取的重试消息，都需要先经过基础的参数校验，然后将要重试的消息进行入库。

消息入库后我们有两种方案对需要重试的任务消息进行消费处理：

异步发送MQ消息，确认好需要重试的时间点发送延迟消息，等到达指定时间点由内部消费者进行消费。
采用定时任务分批次刷库，每次从库里读取一批最近时间需要重试的消息，根据需要发送的时间做延时处理，以确保时间点的准确性。(例：每隔5秒刷一次库，把5秒内需要执行的任务捞取出来，放入线程池执行)

• 执行重试策略

由以上两种方案，最终都是要进入执行重试策略，在这一步骤里要做的主要就是触发业务端进行重试，这里也需要根据所配置的“消息重试渠道”进行渠道选择。

案例分析

互联网时代相信大家都用过网上购物吧，类似于在网上购物的过程中，我们收到商品之后，首先要验证商品有没有质量问题，没问题的话我们就要进行订单签收或者等待系统自动签收，订单签收后平台的资金就会自动打款到商户。在我们程序设计过程这一个订单签收的业务就可以设计为最终一致的，具体流程如下图：

根据以上流程图我们可以看出订单签收后，平台给商户打款是一个异步的动作，实际业务流程中我们更应该注重主流程的状态，也就是确保客户签收流程无误，后面的平台打款给商户这个动作对用户来说是无感知的，即使打款流程出错了用户也无需关心（平台资金不足、商户信息异常、网络波动等原因），所以这里就可以配置成重试任务，在任务执行失败时自动进行重试，可以最大程度确保任务执行成功。

总结

任务重试机制其目的就是确保事务的最终一致性，一般同步流程都是强一致的，所以任务重试主要适用于异步流程。针对异步任务且时效性要求严谨的，可以针对重试时效进行合理的配置，以及做好监控配置，在重试失败的时候能够触发告警通知相关人员进行问题排查。简而言之没有一个架构是万能的，适合自己的业务场景那就是最合适的。