分布式微服务架构下的事务一致性解决方案

CAP 原则

CAP 原则是 Consistency (一致性)、Availability (可用性) 和 Partition-tolerance (分区容错性) 的缩写，它是分布式系统中的平衡理论。

一致性要求所有节点每次读操作都能保证获取最新数据。

可用性要求，系统提供的服务必须处于可用状态，对于用户的请求能够在有限的时间内返回结果。

分区容错性要求被分区的节点在遇到网络分区故障时候，仍然需要正常对外提供服务。

事实上，任何系统只可同时满足其中两个，无法三者兼顾，即所有分布式系统只能满足 CP 或者 AP

Base 理论

BASE 是 Basically Available (基本可用)、Soft-state (软状态)和 Eventually Consistent (最终一致性) 的缩写，是对 CAP 原则的一致性和可用性进行权衡之后得到的结果。

其核心思想是即使系统无法做到强一致性，但应用可以采用适当的方式使系统达到最终一致性。

Basically Available (基本可用) 即表示系统在出现故障时候，还能够提供部分服务。

Soft-state (软状态) 与硬状态相反，表示系统不同节点之间的数据存在中间状态，可能存在一定的延时，但不影响系统的整体可用性。

Eventually Consistent (最终一致性) 描述系统之间的数据副本，经过一段时间的同步之后，最终达到一个一致的状态。

一致性解决方案

分布式事务一致性解决方案分为两种类型：

• 强一致性

即事务的操作是同步进行，包括：两阶段提交协议、三阶段提交协议。

• 最终一致性

包括 TCC 模式、补偿模式、可靠事件模式

两阶段提交协议

当一个事务跨越多个节点时，需要引入一个协调者去控制每个节点的操作结果。即事务管理者（协调者）负责控制所有资源管理者（参与者）准备流程和提交流程。

第一阶段：协调者向参与者发起准备命令，询问参与者是否预提交成功（执行操作，但不提交）。

第二阶段：协调者根据参与者的响应结果，发起提交命令或者回滚命令（有参与者没有准备好或者执行失败）。

缺点：

同步阻塞：参与者需要听从协调者的调度，在此期间处于阻塞状态；

单点故障：协调者若发生故障，参与者将一直等待；

数据不一致：协调者向参与者发送 commit 请求时发生故障，导致一部分参与者执行了 commit 请求。

三阶段提交协议

在两阶段提交基础上，引入超时机制解决同步阻塞问题

并加入预备阶段，尽早发现有问题的参与者，只有预备节点完成，才会执行后续的准备和提交阶段。

缺点：

数据不一致：参与者无法及时收到协调者请求时，会默认 commit。

TCC 模式

将任务拆分为三个操作：Try、Confirm、Cancel

具体流程：第一阶段主业务调用全部从业务服务的 Try 操作，并且记录操作日志。第二阶段，当从业务服务全部成功，再执行 Confirm 操作，否则执行 Cancel 逆操作。

补偿模式

通过定时任务、重试机制实现数据的最终一致性

可靠事件模式

借助消息队列，保证消息投递的有效性，实现数据最终一致性。

正反消息机制：

1. 主业务向从服务发起业务调用，先记录 待发送 状态至数据库中，并向消息队列投递消息；
2. 主业务根据消息队列的响应结果成功与否进行判断，响应成功将消息改为 已发送 状态，否则改为 结束 状态
3. 消息队列向从服务发送消息，根据从服务 ACK 结果进行判断；ACK 响应成功进行下一步，ACK 响应失败或者超时，消息队列或者定时任务将待发送的记录进行重发。
4. 从业务消费成功，向主服务发送已完成消息，主业务将记录改为 已完成 状态。

参考

《高可用可伸缩微服务架构：基于Dubbo、Spring Cloud和ServiceMesh》