- 1.性能问题从流程上看，在执行过程中节点都处于阻塞状态 。各个操作数据库的节点都占用数据库资源，只有当所有节点准备完毕后，事务协调者才会通知进行全局commit/rollback，参与者进行本地事务commit/rollback之后才会释放资源，对性能影响较大
- 2.单点故障问题事务协调者是整个分布式事务的核心，一旦事务协调者出现故障，会导致参与者收不到commit/rollback的通知，从而导致参与者节点一直处于事务无法完成的中间状态
- 3.数据不一致在第二阶段的时候，如果发生局部网络问题，一部分事务参与者收不到commit/rollback消息，就会导致节点间数据不一致
- 4.太多保守必须 收到所有参与的正反馈才提交事务如果有任意一个事务参与者的响应没有收到，则整个事务失败回滚
基于2pc出现的一些问题，3pc进行了改进，也就是三阶段提交，将2pc的第二个阶段进行了一分为二，形成了CanCommit（提交询问）、Precommit（预提交）、doCommit阶段(最终提交)三个阶段；其实3pc和2pc的不同点在于3pc增加了超时机制 。
文章插图
- 阶段1:CanCommit(提交询问)协调者向所有参与者发送一个请求，询问是否可以执行事务提交操作，然后开始等待所有响应者的响应正常情况下，所有参与者会反馈yes，然后进入预备状态，否则反馈No
- 2.各参与者向协调者反馈事务询问的响应
- 1.事务询问
- 阶段2:PreCommit(预提交)
- 情况1:执行事务预提交(即所有参与者都响应yes)
- 1.发起预提交请求协调者向所有参与者发出preCommit请求，并进入准备阶段
- 2.事务预提交参与者接收到preCommit请求后，执行事务操作，然后将undo和redo信息记录到事务日志中
- 3.各参与者向协调者反馈事务执行的响应
- 情况2:中断事务(任何一个参与者反馈no或者超时就会中断事务)
- 1.发送中断请求
- 2.中断事务
- 阶段3:doCommit(最终提交)
- 情况1:执行提交
- 1.发送提交请求
- 2.事务提交
- 3.反馈事务提交结果
- 4.完成事务
- 情况2:中断事务
- 1.发送中断请求
- 2.事务回滚
- 3.反馈事务回滚结果
- 4.中断事务
- 3pc特点
- 1.降低了参与者阻塞范围,增加了超时自动处理的机制
- 2.能够在出现单点故障后继续保持一致
- 3.网络分区会出现不一致的问题即参与者接收到了preCommit消息后，出现了网络分区，即协调者和参与者无法进行正常通信，这个时候该参与者依然会进行事务的提交，就会出现数据不一致的情况
Paxos算法要解决的问题就是如何保证数据一致性，这是一种基于消息传递且具有高度容错特的一致性算法
首先要引入拜占庭问题
拜占庭问题：即不同军队的将军之间必须制定一个统一的行动计划，但是在地理上都是分隔开来的，只能依靠通讯员进行通信，但是通讯员可能会存在叛徒，对消息进行篡改，从而欺骗将军 。
这种消息篡改的情况在同一个局域网内几乎不会出现，或者简单通过校验算法进行避免 。但是在实际工程实践中，可以假设不存在拜占庭问题，基于这种假设如何保证一致性呢？这个时候又引入Paxos的故事
古希腊有一个Paxos小岛，岛上采用会议的形式来通过法令，议会上的议员通过信使来传递消息，注意信使和议员都是兼职的，有可能随时会离开议会，而且信使有可能会重复传递消息，也有可能一去不返 。那么在这种情况下议会协议也要保证法令能够正确选举出来，而且不会产生冲突 。
根据这个故事也就衍生出了Paxos算法，该算法有3个角色：
1.Proposer（提议者，用来发起提案的，相当于zk中的leader角色）
2.Acceptor(接受者，可以接受或拒绝提案，相当于zk中的follower角色)
3.Learner(学习者，学习被选定的提案，相当于zk中的observer角色)
注意这里讲解的是Basic Paxos，基于Baisc Paxos演化出了Multi Paxos,这里不做过多讲解，有兴趣的同学可自行查阅
推荐阅读
- 五分钟9步搞定nginx正向代理配置
- 分布式数据之缓存技术，今天就一起来揭开其神秘面纱
- 电脑蓝黑屏只会重启？3种方法教你轻松搞定，不花一分钱
- 据说让你抓狂的Nginx性能调优，我却这么轻松就搞定了
- MySQL还能实现分布式锁？
- 十分钟超有效瘦身瑜伽怎么做
- 「分布式计算」什么是严格一致性和最终一致性？
- 烂大街的Nginx+Redis分布式锁+MQ+MDB架构设计
- 「分布式架构」“一切都是分布式”说最终一致性
- 图解Raft：应该是最容易理解的分布式一致性算法
