认识达内从这里开始

事务一致性问题是大多数程序员在开发软件的时候都需要重点关注的一个编程问题，而本文我们就通过案例分析来简单了解一下，分布式事务一致性解决方法分享。

1、TCC模式

二阶段提交协议和三阶段提交协议很好的解决了分布式事务的问题，但是在极端情况下仍然存在数据的不一致性，此外它对系统的开销会比较大，引入事务管理者(协调者)后，比较容易出现单点瓶颈，以及在业务规模不断变大的情况下，系统可伸缩性也会存在问题。注意的是，它是同步操作，因此引入事务后，直到全局事务结束才能释放资源，性能可能是一个很大的问题。因此，在高并发场景下很少使用。因此，需要另外一种解决方案：TCC模式。注意的是，很多读者把二阶段提交等同于二阶段提交协议，这个是一个误区，事实上，TCC模式也是一种二阶段提交。

TCC模式将一个任务拆分三个操作：Try、Confirm、Cancel。假如，我们有一个func()方法，那么在TCC模式中，它就变成了tryFunc()、confirmFunc()、cancelFunc()三个方法。

在TCC模式中，主业务服务负责发起流程，而从业务服务提供TCC模式的Try、Confirm、Cancel三个操作。其中，还有一个事务管理器的角色负责控制事务的一致性。例如，我们现在有三个业务服务：交易服务，库存服务，支付服务。用户选商品，下订单，紧接着选择支付方式进行付款，然后这笔请求，交易服务会先调用库存服务扣库存，然后交易服务再调用支付服务进行相关的支付操作，然后支付服务会请求三方支付平台创建交易并扣款，这里，交易服务就是主业务服务，而库存服务和支付服务是从业务服务。

我们再来梳理下，TCC模式的流程。一阶段主业务服务调用全部的从业务服务的Try操作，并且事务管理器记录操作日志。二阶段，当全部从业务服务都成功时，再执行Confirm操作，否则会执行Cancel逆操作进行回滚。

我们要特别注意操作的幂等性。幂等机制的核心是保证资源性，例如重复提交或服务端的多次重试只会产生一份结果。支付场景、退款场景，涉及金钱的交易不能出现多次扣款等问题。事实上，查询接口用于获取资源，因为它只是查询数据而不会影响到资源的变化，因此不管调用多少次接口，资源都不会改变，所以是它是幂等的。而新增接口是非幂等的，因为调用接口多次，它都将会产生资源的变化。因此，我们需要在出现重复提交时进行幂等处理。

那么，如何保证幂等机制呢?事实上，我们有很多实现方案。其中，一种方案就是常见的创建索引。在数据库中针对我们需要约束的资源字段创建索引，可以防止插入重复的数据。但是，遇到分库分表的情况是，索引也就不那么好使了，此时，我们可以先查询一次数据库，然后判断是否约束的资源字段存在重复，没有的重复时再进行插入操作。注意的是，为了避免并发场景，我们可以通过锁机制，例如悲观锁与乐观锁保证数据的性。这里，分布式锁是一种经常使用的方案，它通常情况下是一种悲观锁的实现。但是，很多人经常把悲观锁、乐观锁、分布式锁当作幂等机制的解决方案，这个是不正确的。除此之外，我们还可以引入状态机，通过状态机进行状态的约束以及状态跳转，确保同一个业务的流程化执行，从而实现数据幂等。

2、补偿模式

我们提到了重试机制。事实上，它也是一种终一致性的解决方案：我们需要通过大努力不断重试，保证数据库的操作终一定可以保证数据一致性，如果终多次重试失败可以根据相关日志并主动通知开发人员进行手工介入。注意的是，被调用方需要保证其幂等性。重试机制可以是同步机制，例如主业务服务调用超时或者非异常的调用失败需要及时重新发起业务调用。重试机制可以大致分为固定次数的重试策略与固定时间的重试策略。除此之外，我们还可以借助消息队列和定时任务机制。消息队列的重试机制，即消息消费失败则进行重新投递，这样就可以避免消息没有被消费而被丢弃，例如JMQ可以默认允许每条消息多重试多少次，每次重试的间隔时间可以进行设置。定时任务的重试机制，我们可以创建一张任务执行表，并增加一个“重试次数”字段。这种设计方案中，我们可以在定时调用时，获取这个任务是否是执行失败的状态并且没有超过重试次数，如果是则进行失败重试。但是，当出现执行失败的状态并且超过重试次数时，就说明这个任务永久失败了，需要开发人员进行手工介入与排查问题。

除了重试机制之外，也可以在每次更新的时候进行修复。例如，对于社交互动的点赞数、收藏数、评论数等计数场景，也许因为网络抖动或者相关服务不可用，导致某段时间内的数据不一致，我们就可以在每次更新的时候进行修复，保证系统经过一段较短的时间的自我恢复和修正，数据终达到一致。需要注意的是，使用这种解决方案的情况下，如果某条数据出现不一致性，但是又没有再次更新修复，那么其永远都会是异常数据。

定时校对也是一种非常重要的解决手段，它采取周期性的进行校验操作来保证。关于定时校对可以分为两种场景，一种是未完成的定时重试，例如我们利用定时任务扫描还未完成的调用任务，并通过补偿机制来修复，实现数据终达到一致。另一种是定时核对，它需要主业务服务提供相关查询接口给从业务服务核对查询，用于恢复丢失的业务数据。现在，我们来试想一下电商场景的退款业务。在这个退款业务中会存在一个退款基础服务和自动化退款服务。此时，自动化退款服务在退款基础服务的基础上实现退款能力的增强，实现基于多规则的自动化退款，并且通过消息队列接收到退款基础服务推送的退款快照信息。但是，由于退款基础服务发送消息丢失或者消息队列在多次失败重试后的主动丢弃，都很有可能造成数据的不一致性。因此，我们通过定时从退款基础服务查询核对，恢复丢失的业务数据就显得特别重要了。

3、可靠事件模式

在分布式系统中，消息队列在服务端的架构中的地位非常重要，主要解决异步处理、系统解耦、流量削峰等问题。多个系统之间如果使用同步通信，则很容易造成阻塞，同时会将这些系统耦合在一起，因此，引入消息队列后，一方面解决了同步通信机制造成的阻塞，另一方面通过消息队列实现了业务解耦。

可靠事件模式，通过引入可靠的消息队列，只要保证当前的可靠事件投递并且消息队列确保事件传递至少一次，那么订阅这个事件的消费者保证事件能够在自己的业务内被消费即可。这里是否只要引入了消息队列就可以解决问题了呢?事实上，只是引入消息队列并不能保证其终的一致性，因为分布式部署环境下都是基于网络进行通信，而网络通信过程中，上下游可能因为各种原因而导致消息丢失。

其一，主业务服务发送消息时可能因为消息队列无法使用而发生失败。对于这种情况，我们可以让主业务服务(生产者)发送消息，再进行业务调用来确保。一般的做法是，主业务服务将要发送的消息持久化到本地数据库，设置标志状态为“待发送”状态，然后把消息发送给消息队列，消息队列先向主业务服务(生产者)返回消息队列的响应结果，然后主业务服务判断响应结果执行之后的业务处理。如果响应失败，则放弃之后的业务处理，设置本地的持久化消息标志状态为“失败”状态。否则，执行后续的业务处理，设置本地的持久化消息标志状态为“已发送”状态。

此外，消息队列接收消息后，也可能从业务服务(消费者)宕机而无法消费。JMQ有ACK机制，如果消费失败，会重试，如果成功，会从消息队列中删除此条消息。那么，消息队列如果一直重试失败而无法投递，会在一定次数之后主动丢弃，当然我们也可以设置为一直重试，这种方式不推荐。我们需要如何解决呢?我们在上个步骤中，主业务服务已经将要发送的消息持久化到本地数据库。因此，从业务服务消费成功后，它也会向消息队列发送一个通知消息，此时它是一个消息的生产者。主业务服务(消费者)接收到消息后，终把本地的持久化消息标志状态为“完成”状态。这就是使用“正反向消息机制”确保了消息队列可靠事件投递。当然，补偿机制也是必不可少的。定时任务会从数据库扫描在一定时间内未完成的消息并重新投递。大家也可能会说，消费成功之后可以用RPC调用主业务服务，先这样主业务服务要额外提供一个RPC的接口;另外也会对从业务服务造成业务的复杂度和耗时影响。这里要注意从业务服务要保证幂等性。

了解了“可靠事件模式”的方法论后，现在我们来看一个真实的案例来加深理解。先，当用户发起退款后，自动化退款服务会收到一个退款的事件消息，此时，如果这笔退款符合自动化退款策略的话，自动化退款服务会先写入本地数据库持久化这笔退款快照，紧接着，发送一条执行退款的消息投递到给消息队列，消息队列接受到消息后返回响应成功结果，那么自动化退款服务就可以执行后续的业务逻辑。与此同时，消息队列异步地把消息投递给退款基础服务，然后退款基础服务执行自己业务相关的逻辑，执行失败与否由退款基础服务自我保证，如果执行成功则发送一条执行退款成功消息投递到给消息队列。后，定时任务会从数据库扫描在一定时间内未完成的消息并重新投递。这里，需要注意的是，自动化退款服务持久化的退款快照可以理解为需要确保投递成功的消息，由“正反向消息机制”和“定时任务”确保其成功投递。此外，真正的退款出账逻辑在退款基础服务来保证，因此它要保证幂等性。当出现执行失败的状态并且超过重试次数时，就说明这个任务永久失败了，需要开发人员进行手工介入与排查问题。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。