随着业务的发展，为了提高系统的可用性，可维护性等，单一系统逐渐分解为业务功能独立的多个微服务组成的分布式系统集群，事务处理能力也被拆解到各个微服务中。这个时候一笔交易会涉及到交易，支付，券，账户等多个微服务系统的交互，多个微服务之间的交互如何保证上下游系统的数据一致性，就成了在日常研发过程中比较头疼的事情。

当遇到数据一致性问题时，首先需要做到的就是可监控和可恢复。

• 可监控：一般来说由整个业务的发起方对业务处理进度进行监控，监控所有未达到系统终态的记录，或者通过数据仓库对上下游系统各自记录进行数据核对。只有通过监控及时的发现数据不一致情况，才能发现问题并针对的进行相应处理措施。

• 可恢复：在发现上下游系统数据不一致时，需要有能力对业务进行补偿重试操作或者回滚操作，直到上下游相关系统状态达到合理的一致状态。下面列举了一些日常工作中处理数据一致性问题的几种常见解决方案。

日常工作中处理数据一致性问题的几种常见解决方案：

1. 定时任务补偿

   通过定时任务不断轮询扫描业务中间状态的记录，然后针对当前处理进度做相应的补偿逻辑，比如重试，或者回滚。一般常用两类定时任务，crontab或者分布式定时任务组件。

   • crontab定时任务

     • 优点：

       1. 灵活，简单，快速。

       2. 无额外接入成本，一台linux服务器就能跑。

     • 缺点：

       1. 单点。

       2. 性能差。

       3. 监控困难。

       4. 运维困难，尤其是往往脚本部署无规范。

       5. 不易维护，脚本独立于项目之外，修改、测试、回归代码困难，且容易遗漏。

   • 分布式定时任务

     • 优点：

       1. 通用性好，适用于各种场景。

     • 缺点：

       1. 接入成本高，需要额外接入一些市面上成熟的分布式任务组件或者自己造轮子，增加了中间件的运维和研发成本。

       2. 业务逻辑研发成本高，需要针对各个场景额外开发并维护一份定时任务补偿逻辑，增加了业务的运维和研发成本。

2. 可靠事务消息

   业务事务提交时发送可靠事务消息，保证了消息必达，下游根据消息做相应处理，直至处理完成。

   • 优点：

     1. 解耦，适用于对下游处理结果非强依赖的业务。例如：交易后记录风控信息。

     2. 提高核心链路吞吐量，增强整体服务的可用性。

   • 缺点：

     1. 接入成本高，市面上成熟的MQ中间件支持事务特性的少，要么系统额外接入一套支持事务的MQ比如RocketMQ，要么需要自己造轮子，增加了中间件的运维和研发成本。

     2. 额外的业务研发成本，例如：RocketMQ的事务消息需要额外实现事务回查接口。

3. 分布式事务

   分布式事务保证了上下游所有操作在同一个事务中，保证了数据的最终一致性。

   • 优点：

     1. 开发、维护成本低。系统逻辑清晰，适用于对下游处理结果强依赖的业务。例如：转账业务。

   • 缺点：

     1. 接入成本高，市面上没有成熟的分布式事务解决方案，需要自己造轮子。

     2. 场景限制，往往用在时间可控的内部业务中，一旦涉及外部第三方系统交互或者一些时间不可控的业务，则不适用。

上面列举了一些日常开发时常见的数据一致性解决方案，开发时一般可以根据上述各种方法的优缺点、适用场景，结合业务特点和团队实际情况，选择合适的方式进行处理，特殊场景下也可以依据自身业务系统特点做针对性的解决方案。