分布式事务模型详解与一致性算法拓展：从CAP到Raft的深度解析-CSDN博客

一、分布式基础理论

1.1 CAP理论

CAP理论指出，分布式系统最多只能同时满足以下三项中的两项：

一致性（Consistency）：所有节点同时看到相同的数据。
可用性（Availability）：任何时候读写都能成功。
分区容错性（Partition Tolerance）：系统在部分节点或网络分区故障时仍能继续运行。

实际系统设计常在保证P和A的前提下，舍弃强一致性，采用最终一致性。

1.2 BASE理论

BASE是对CAP中AP架构的延伸，包括：

基本可用（Basically Available）：系统在故障时仍能提供基本服务。
软状态（Soft State）：允许数据存在中间状态。
最终一致性（Eventually Consistent）：系统在一定时间后达到数据一致。

BASE适用于大多数互联网高并发场景，如电商秒杀、限流排队等。

二、分布式事务模型

2.1 强一致性模型

适用于对一致性要求极高的场景，如跨行转账。

DTP模型（X/Open标准）

包含三个核心组件：

AP（应用程序）：定义事务边界。
RM（资源管理器）：如数据库，提供资源接口。
TM（事务管理器）：协调分布式事务，管理2PC协议。

DTP中的分布式事务（即全局事务）的执行流程如下：

（1）首先，在系统中的所有RM通过XA规范提供的API向TM注册，即RM涉及的分支事务处理将纳入
到TM统一管理；
（2）然后，AP开启全局事务，AP通过TX规范提供的API向TM申请全局事务的开启，此时，全局事务
正式开启。TM会返回其为本次全局事务分配的全局事务ID，即XID，给提出全局事务的AP；
（3）接着，AP根据获取到的XID开始其操作序列，具体的操作就是向不同的RM发送SQL操作请求；
（4）然后，RM根据接受的来自AP的SQL操作请求进行本地数据库操作（即执行本地事务）。RM在
执行本地事务时会通过TM提供的XA规范API提交分支事务请求（请求中携带XID）。TM在接收到RM
的分支事务请求后，分配分支事务ID并将其反馈给相应的RM；
（5）TM与RM进行基于2PC协议的事务预提交，及进行Prepare操作；
（6）当TM根据RM Prepare操作的执行情况决策出现有分支事务已经全部完成Prepare操作，如果
是，那么TM向AP发送Commit决策结果；否则，那么TM向AP发送Rollback决策结果。当进行2PC协议
时，如果RM出现故障，TM负责协调故障处理，保证其决策可进行；
（7）当AP接收到TM的决策时，如果后续还有分支事务需要执行，那么AP继续步骤③；否则，AP决
策分布式事务的结果是Commit还是Rollback。
（8）如果AP决定Commit/Rollback分布式事务，那么它将通过TX规范API通知TM，最终的执行决定由
TM通过2PC协议通知RM完成；
（9）最后，RM向TM提出注销申请，TM注销已注册的RM；AP向TM提交分布式事务结束请求，TM结
束分布式事务。

XA规范与2PC/3PC

2PC（两阶段提交）：
- 阶段一：Prepare，各RM准备提交。
- 阶段二：Commit/Rollback，TM根据Prepare结果决策。
- 问题：同步阻塞、单点故障、数据不一致。
3PC（三阶段提交）：
- 引入CanCommit、PreCommit、DoCommit三阶段。
- 增加超时机制，减少阻塞，但仍存在数据不一致风险。

2.2 最终一致性模型

TCC（Try-Confirm-Cancel）

Try：预留资源。
Confirm：确认提交。
Cancel：取消释放。
需保证Confirm/Cancel幂等，支持重试与日志恢复。

TCC VS XA

XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。
1) 在阶段1：
在XA中，各个RM准备提交各自的事务分支，事实上就是准备提交资源的更新操作(insert、delete、update等)；而在TCC中，是主业务活动请求(try)各个从业务服务预留资源。
2) 在阶段2：
XA根据第一阶段每个RM是否都prepare成功，判断是要提交还是回滚。如果都prepare成功，那么就commit每个事务分支，反之则rollback每个事务分支。
TCC中，如果在第一阶段所有业务资源都预留成功，那么confirm各个从业务服务，否则取消
(cancel)所有从业务服务的资源预留请求。

TCC VS DTP

TCC模型中的主业务服务相当于 DTP模型中的AP，TCC模型中的从业务服务相当于 DTP模型中的RM
TCC模型中，从业务服务提供的try、confirm、cancel接口，相当于 DTP模型中RM提供prepare、commit、rollback接口
DTP模型和TCC模型中都有一个事务管理器。不同的是：

在DTP模型中，阶段1的(prepare)和阶段2的(commit、rollback)，都是由TM进行调用的。

在TCC模型中，阶段1的try接口是主业务服务调用(绿色箭头)，阶段2的(confirm、cancel接口)是事务管理器TM调用(红色箭头)。

可靠消息最终一致性

本地消息表：业务耦合，通过消息日志异步保证一致。
RocketMQ事务消息：支持Prepare、Commit、Rollback三阶段，确保消息事务一致。
最大努力通知：适用于一致性要求不高的场景，如通知类业务。

本地消息表

本地消息表的方案最初是由 ebay 的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理，通过消息日志的方式来异步执行。
本地消息表是一种业务耦合的设计，消息生产方需要额外建一个事务消息表，并记录消息发送状态，消息消费方需要处理这个消息，并完成自己的业务逻辑，另外会有一个异步机制来定期扫描未完成的消息，确保最终一致性。
下面我们用下单减库存业务来简单模拟本地消息表的实现过程：
（1）系统收到下单请求，将订单业务数据存入到订单库中，并且同时存储该订单对应的消息数据，比如购买商品的 ID 和数量，消息数据与订单库为同一库，更新订单和存储消息为一个本地事务，要么都成功，要么都失败。
（2）库存服务通过消息中间件收到库存更新消息，调用库存服务进行业务操作，同时返回业务处理结果。
（3）消息生产方，也就是订单服务收到处理结果后，将本地消息表的数据删除或者设置为已完成。
（4）设置异步任务，定时去扫描本地消息表，发现有未完成的任务则重试，保证最终一致性。

RocketMQ 事务消息

RocketMQ 事务消息是一种支持分布式事务的消息。它通过引入 prepare、commit 和 rollback 三个阶段，来确保事务消息的一致性。

prepare 阶段：消息发送方发送半消息，此时消息的状态为“待提交”。
commit 阶段：消息发送方向 RocketMQ 发送 commit 消息请求，RocketMQ 判断此时半消息是否被确认，如果半消息已被确认，则将消息标记为“可消费”并提交事务。如果半消息未被确认，则将消息标记为“不可消费”并终止事务。
rollback 阶段：消息发送方向 RocketMQ 发送 rollback 消息请求，RocketMQ 将半消息标记为“不可消费”并回滚事务。

最大努力通知

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。最大努力通知型的实现方案，一般符合以下特点：

不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。
定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。

三、数据一致性算法

3.1 Paxos算法

Paxos是分布式共识的基础算法，包含：

Proposer：提出提案。
Acceptor：接受或拒绝提案。
Learner：学习已接受的提案。

流程分为准备阶段与选举阶段，通过多数派原则达成一致。

Paxos选举过程：

选举过程可以分为两个部分，准备阶段和选举阶段，可以查看下面的时序图：

Phase 1 准备阶段

Proposer 生成全局唯一且递增的 ProposalID，向 Paxos 集群的所有机器发送 Prepare 请求，这里不携带 value，只携带 N 即 ProposalID。
Acceptor 收到 Prepare 请求后，判断收到的 ProposalID 是否比之前已响应的所有提案的 N 大，如果是，则：

在本地持久化 N，可记为 Max_N；
回复请求，并带上已经 Accept 的提案中 N 最大的 value，如果此时还没有已经 Accept 的提案，则返回 value 为空；
做出承诺，不会 Accept 任何小于 Max_N 的提案。

如果否，则不回复或者回复 Error。

Phase 2 选举阶段

为了方便描述，我们把 Phase 2 选举阶段继续拆分为 P2a、P2b 和 P2c。
P2a：Proposer 发送 Accept
经过一段时间后，Proposer 收集到一些 Prepare 回复，有下列几种情况：

若回复数量 > 一半的 Acceptor 数量，且所有回复的 value 都为空时，则 Porposer 发出 accept 请求，并带上自己指定的 value。
若回复数量 > 一半的 Acceptor 数量，且有的回复 value 不为空时，则 Porposer 发出 accept 请求，并带上回复中 ProposalID 最大的 value，作为自己的提案内容。
若回复数量 <= 一半的 Acceptor 数量时，则尝试更新生成更大的 ProposalID，再转到准备阶段执行。

P2b：Acceptor 应答 Accept

Accpetor 收到 Accpet 请求后，判断：

若收到的 N >= Max_N（一般情况下是等于），则回复提交成功，并持久化 N 和 value；
若收到的 N < Max_N，则不回复或者回复提交失败。

P2c: Proposer 统计投票

经过一段时间后，Proposer 会收集到一些 Accept 回复提交成功的情况，比如：

当回复数量 > 一半的 Acceptor 数量时，则表示提交 value 成功，此时可以发一个广播给所有的 Proposer、Learner，通知它们已 commit 的 value；
当回复数量 <= 一半的 Acceptor 数量时，则尝试更新生成更大的 ProposalID，转到准备阶段执行。

当收到一条提交失败的回复时，则尝试更新生成更大的 ProposalID，也会转到准备阶段执行。

3.2 Zab协议（ZooKeeper）

Zab用于ZooKeeper集群的一致性保证，支持：

消息广播：Leader广播Proposal，过半Follower确认后Commit。
崩溃恢复：Leader失效时重新选举，同步数据。
Zxid机制：64位事务ID，保证顺序与一致性。

3.3 Raft算法

Raft是Multi-Paxos的简化实现，角色包括：

Leader：处理所有请求，同步日志。
Follower：响应Leader。
Candidate：参与选举。

流程包括Leader选举、日志复制、安全性保证，易于理解与实现。

3.4 Gossip协议

一种去中心化的最终一致性协议，适用于大规模P2P网络。

反熵传播：节点定期随机同步数据，可靠但流量大。
谣言传播：节点传播“谣言”，达到一定比例后停止，效率高。
应用于Cassandra、Redis Cluster、Consul等系统。

四、总结

模型/算法	一致性级别	适用场景
2PC/3PC	强一致性	金融、转账
TCC	最终一致性	订单、库存
Paxos/Raft	强一致性	配置中心、分布式锁
Gossip	最终一致性	数据库复制、集群状态同步