分布式事务解决方案

分布式一致性的级别

• 强一致性：系统写入了什么，读出来的就是什么。
• 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
• 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

CAP

• 一致性（Consistency） : 所有节点访问同一份最新的数据副本
• 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

BASE 理论

• 基本可用（Basically Available）：基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是这不等价于系统不可用。

• 软状态（Soft-state）：软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

• 最终一致性（Eventually Consistent）：

  最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

如何实现最终一致性呢？可以通过下面的方式：

• 读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
• 写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。
• 异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。

两阶段提交 2PC

• Prepare 阶段：协调者向所有参与者发送 Prepare 命令。如果参与者准备好了，那么就向协调者发送 Prepared，否则发送 No。如果发送的是 No，那么事务要进行回滚。
• Confirm 阶段：当协调者发现所有参与者都发送了 Prepared，那么协调者向所有参与者发送 Commit 消息，否则向所有的参与者发送 Abort 消息。
• 缺点
  • 严重依赖协调者，存在单点故障的风险。
  • 当某一个参与节点超时，其它所有节点都会阻塞。
  • 可能由于网络抖动导致部分参与者未收到 Commit 消息，导致数据不一致。

三阶段提交 3PC

3PC 的三个阶段分别是 CanCommit、PreCommit、DoCommit。

• CanCommit 阶段：协调者向所有参与者发送 CanCommit 命令，询问是否可以执行事务提交操作，如果全部响应 YES 则进入下一个阶段。
• PreCommit 阶段： 协调者向所有参与者发送 PreCommit 命令，询问是否可以进行事务的预提交操作。在接收到协调者的 PreCommit 后，参与者如果成功预执行事务操作，则返回 Yes 响应，进入最终的提交阶段；若有任一参与者返回 No，或因网络超时协调者未收到响应，则协调者将向所有参与者发送 Abort ，所有参与者收到后中断事务。
• DoCommit：在前两个阶段中，当所有参与者的响应均是 YES 时，协调者向参与者发送DoCommit 命令正式提交事务，如协调者没有接收到参与者发送的 ACK 响应，协调者会向所有参与者发送 Abort ，中断事务。

补偿型事务 TCC

TCC（Try-Confirm-Cancel） 的原理是在业务操作前将资源进行预留（Try），待所有参与方预处理成功后再统一确认执行（Confirm）；若任一参与方失败或中断，则统一执行回滚操作（Cancel）。TCC 通过开发者在应用层手动实现三段逻辑，使得各个服务具备独立的预处理、确认与补偿能力，从而保障全局事务的一致性与可靠性。

以“下单扣库存”场景为例，TCC 模式的三个阶段如下：

• Try 阶段：下单操作首先进入预处理阶段，此时库存服务会进行库存预留，即冻结相应数量的库存资源，但尚未真正扣减。
• Confirm 阶段：当所有业务方的 Try 操作均成功后，系统会发起确认操作，此时库存服务正式扣减库存，并完成下单业务流程。
• Cancel 阶段：如果任意业务方的 Try 操作失败，或整个流程中断，则会触发回滚操作，库存服务将释放已冻结的库存，取消资源预留，保证数据一致性。