框架篇：分布式一致性解决方案

发布时间：2025-11-04 00:19:08 来源：云智核 作者：系统运维

本文转载自微信公众号「潜行前行」，框架作者cscw。篇分转载本文请联系潜行前行公众号。布式

前言

上一篇架构篇：分布式理论CAP、致性BASE[1]，解决我们了解到分布式存在的框架问题以及大致的解决理论，但是篇分具体的实现协议或者方案有哪些?

1 分布式一致性

什么是分布式一致性?分布式一致性其实更多是偏向解决多个服务间的数据副本状态的一致，而不同于关系型数据库的解决一致性(数据的约束)

2 分布式共识算法

paoxs算法

Raft算法

选举阶段

一开始任何一个服务器都是Follwer，它们内置一个倒计时，当倒计时结束时变成Candidate，向其他follwers发出要求选举自己的请求

此时有三个状态

A:超过半数follwers追随，云服务器成为新的leader

B:存在竞争者,且有超过半数追随者，放弃竞选，成为其follwer

C:存在竞争者,大家半斤八两。Candidate则在下个竞选周期term再次发起竞选，此时也有内置一个倒计时，谁先倒计时结束快，谁则先成为抢占半数follwer的leader(注意：前一轮成为别人的follwer不能在竞选了)

日志复制阶段

1：Leader领导人已经选出，客户端发出增加一个日志的要求，比如日志是"hello"

2：Leader要求Followe遵从他的指令，都将这个新的日志内容追加到他们各自日志中

3：大多数follower服务器将日志写入磁盘文件后，确认追加成功，发出Commited Ok

4：在下一个心跳heartbeat中，Leader会通知所有Follwer更新commited 项目

如果在这一过程中，发生了网络分区或者网络通信故障。使得Leader不能访问大多数Follwers了，而follwers重新选举新的Leade对外提供服务。在恢复网络时，旧的leader会成为拥有多数follwer的新Leader的follwer。故障期间的commit回滚

zab算法

ZXID

协议的事务编号 Zxid 设计中， Zxid 是一个 64位的数字

其中低 32 位是一个简单的单调递增的计数器， 针对客户端每一个事务请求，计数器加 1

而高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中的最大事务 ZXID ,并从中读取 epoch 值，然后加 1 ，以此作为新的 epoch。而低 32 位计数器则从 0 开始重新计数

崩溃恢复模式(选举)

集群初始化或者Leader失去连接时，节点(任意节点)发起选主，然后集群其他节点会为发起选主的节点进行投票

节点B判断确定A可以成为Leader，那么节点B就投票给节点A，判断的依据是：election epoch(A) > election epoch (B) || zxid(A) > zxid(B) || sid(A) > sid(B)。并更新自己的投票为B投票

sid是服务ID，人为配置的

消息广播模式

一些细节

Leader在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一ID，称为事务ID(ZXID)，ZAB协议需要保证事务的顺序，因此必须将每一个事务按照ZXID进行先后排序然后处理

在Leader和Follwer之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞

zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的请求，也会转发到 Leader 服务器进行处理

3 分布式事务一致性

对于分布式一致性和分布式事务一致性。我更愿意区分开来：

A-分布式一致性是为了解决数据分布在多个服务的状态一致(多个副本保持一致)

B-分布式事务一致性，更加类似关系型数据库的一致性，是约束数据在分布式服务的关系(比如数据a在服务A的状态和数据b在服务B需要保持一个固定的映射关系)

分布式共识算法和分布式一致性的区别

共识算法就是为了解决分布式一致性的算法，但不适合解决分布式事务一致性(可以解决只是不合适)

4 分布式事务一致性的实现方案(XA模式和AT模式)

XA模式是预提交数据模式(预提交数据无法被其他事务访问)，如果发生故障，则回滚预提交的数据

AT模式的数据是确认提交的，只不过存在锁，使该数据无法被其他事务访问。如果发生故障，则使用冲正操作修复数据。相对XA模式，AT模式更适合解决分布式事务，减少阻塞等待时间

两阶段提交(强一致性)(XA模式)

二阶段提交协议(Two-phase Commit，即 2PC)是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段

处理流程

阶段 1：准备阶段

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。

各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中(但不提交事务)。

如参与者执行成功，给协调者反馈 yes，即可以提交;如执行失败，给协调者反馈 no，即不可提交

阶段 2：提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息;否则，发送提交(commit)消息。

参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源

2PC 方案缺点：

性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈

可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态

数据一致性问题：在提交阶段commit时，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，会导致了节点之间数据的不一致

三阶段提交(强一致性)(XA模式)

三阶段提交协议，是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制

处理流程

阶段 1：canCommit

协调者向参与者发送 commit 请求，参与者如果可以提交就返回 yes 响应(参与者不执行事务操作)，否则返回 no 响应：

协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复

参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no

阶段 2：preCommit

阶段 3：do Commit

优缺点

优点：在第二阶段，在等待超时后协调者或参与者会中断事务

优点：在第三阶段，避免了协调者单点问题，在协调者出现问题时，参与者会继续提交事务(同时也是个缺点)

缺点：数据不一致问题依然存在，在第三阶段，如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致

柔性事务TCC (XA模式在服务级别的实现)

Try阶段：需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户可用余额是否充足，再冻结账户的资金。Try 方法执行之后，账号余额虽然还是100，但是其中 30 元已经被冻结了，不能被其他事务使用

Confirm阶段：扣减 Try 阶段冻结的资金，Confirm 方法执行之后，账号在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元

Cancel阶段：回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号的余额回到初始状态，100 元全部可用

AT模式(阿里分布式框架seata)

一阶段：提交

二阶段提交或回滚

事件通知(事务消息)

同步通知

异步回调通知

相对同步通知，它的处理接口是异步回调的。因此可以避免超时处理，超时返回的问题

考虑到回调时接口报错则需要发起重试回调，因此需要加入重试机制

消息队列

事务状态表+消息队列方案

欢迎指正文中错误

参考文章

Reference

[1]架构篇：分布式理论CAP、BASE:

https://juejin.cn/post/6948809101392478245

[2]分布式理论之一：Paxos算法的通俗理解:

https://www.cnblogs.com/esingchan/p/3917718.html

[3]分布式事务一致性解决方案:

https://www.cnblogs.com/williamjie/p/11200885.html

[4]2PC和3PC:

https://blog.csdn.net/skyie53101517/article/details/80741868

[5]还不理解“分布式事务”?这篇给你讲清楚!:

https://www.cnblogs.com/zjfjava/p/10425335.html

[6]分布式事务——消息最终一致性方案:

https://www.jianshu.com/p/04bad986a4a2

[7]分布式事务?No, 最终一致性:

https://zhuanlan.zhihu.com/p/25933039

[8]分布式事务的4种模式:

https://zhuanlan.zhihu.com/p/141645172

[9]分布式事务 Seata(二) 理解什么是AT、TCC、Saga:

https://www.jianshu.com/p/f2caa8737b7b

相关文章