面试准备：分布式事务协议汇总

Refer：

• BASE介绍、CAP介绍
• 2PC介绍、3PC介绍、 TCC介绍
• Saga模式介绍、AT模式介绍
• ZAB介绍、 PAXOS介绍、Raft共识算法
• BlockChain学习——奖励机制与共识机制
• MQ 生产端可靠性投递和消费端幂等性保障方案、Mysql Binlog不止是主从同步

基本概念

ACID

• 原子性(Atomic)：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样
• 一致性(Consistency)：在事务开始之前和事务结束以后， 数据库的完整性没有被破坏
• 隔离性(Isolation)：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）
• 持久性(Durability)：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

BASE

BASE：Basically Available(基本可用)，Soft state（软状态）, Eventually consistent（最终一致性）。

Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

Refer：BASE介绍

CAP

CAP理论是说对于分布式数据存储，最多只能同时满足 一致性（C，Consistency）、可用性（A， Availability）、分区容忍性（P，Partition Tolerance） 中的两者。

Refer：CAP介绍

强一致性协议

2PC

Two-Phase Commit ，两阶段提交协议。

1. 请求阶段（commit-request phase，或称表决阶段，voting phase）
   在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。
   在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
2. 提交阶段（commit phase）
   在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。
   当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。
   参与者在接收到协调者发来的消息后将执行响应的操作。

两阶段提交的缺点

• 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。
  当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
• 单点故障。由于协调者的重要性，一旦协调者发生故障。
  参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
• .数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。
  而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

两阶段提交无法解决的问题

当协调者出错，同时参与者也出错时，两阶段无法保证事务执行的完整性。
考虑协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。
那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

Refer：2PC介绍

3PC

3PC，全称 “three phase commit”，是 2PC 的改进版，其将 2PC 的 “提交事务请求” 过程一分为二，总共形成了 3 个部分：

1. CanCommit：协调者向所有参与者发送CanCommit命令，询问是否可以执行事务提交操作。如果全部响应YES则进入下一个阶段。
2. PreCommit：协调者向所有参与者发送PreCommit命令，询问是否可以进行事务的预提交操作，参与者接收到PreCommit请求后，如参与者成功的执行了事务操作，则返回Yes响应，进入最终commit阶段。一旦参与者中有向协调者发送了No响应，或因网络造成超时，协调者没有接到参与者的响应，协调者向所有参与者发送abort请求，参与者接受abort命令执行事务的中断。
3. DoCommit： 在前两个阶段中所有参与者的响应反馈均是YES后，协调者向参与者发送DoCommit命令正式提交事务，如协调者没有接收到参与者发送的ACK响应，会向所有参与者发送abort请求命令，执行事务的中断。

• 3PC介绍

TCC

Try-Confirm-Cancel

TCC（Try-Confirm-Cancel）又被称补偿事务，TCC与2PC的思想很相似，事务处理流程也很相似，但2PC 是应用于在DB层面，TCC则可以理解为在应用层面的2PC

1. Try阶段：
   下单时通过Try操作去扣除库存预留资源。
2. Confirm阶段：
   确认执行业务操作，在只预留的资源基础上，发起购买请求。
3. Cancel阶段：
   只要涉及到的相关业务中，有一个业务方预留资源未成功，则取消所有业务资源的预留请求。
   

TCC的缺点：

• 应用侵入性强：TCC由于基于在业务层面，至使每个操作都需要有 try、confirm、cancel三个接口。
• 开发难度大：代码开发量很大，要保证数据一致性 confirm 和 cancel 接口还必须实现幂等性。

Saga

Refer: Saga模式介绍

AT

Refer: AT模式介绍

ZAB

Refer: ZAB介绍

PAXOS

Refer：PAXOS

Raft

Refer: Raft共识算法

PoW

Refer: BlockChain学习——奖励机制与共识机制

最终一致性协议

基于MQ

Refer: MQ 生产端可靠性投递和消费端幂等性保障方案

基于Binlog

Refer: Mysql Binlog不止是主从同步