有关 分布式事务 的小讨论

CAP 定理

• 一致性（Consistency） 在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新数据副本）
• 可用性（Availability） 在集群一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）
• 分区容错性（Partition Tolerance） 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区。分区容错的意思是，区间通信可能失败，需要容忍错误。

CAP原则即为 以上三要素只能同时实现两点，不能三者兼顾，对于多数大型互联网的应用场景，主机众多，部署分散，而现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.99…% 即保证AP，舍弃C永远要满足分区容错

• AP（Eureka、Nacos）
  
• CP（Zookeeper、Consul）
  

---

raft算法实现一致性

http://thesecretlivesofdata.com/raft/

• 所有节点有三种状态、跟随者、候选者、领导者
• 如果跟随者不能感知到领导者，他将变成一个候选者，然后向其他跟随者请求投票给自己
• 其他跟随者回应他们的投票
• 如果候选者获得了超过半数的选票，他将变为领导者，以上这个过程为 领导选举

---

• 系统的所有改变都需要通过领导者
• 每一个改变都被当作一个entry放入领导者节点日志，数据不会被更新，因为entry并没有被提交
• 提交entry的第一步，是领导者先把其复制给其他跟随者，然后领导者待到大多数跟随者将entry写入后更新数据
• 然后领导者通知跟随者 entry已经提交，至此，集群完成了一致性操作。以上这个过程为 日志复制

领导选举

• 有两个时限限制设置控制领导选举
• 第一个是选举时限，指的是跟随者等待变为候选者的时间，随机分布在150ms-300ms
• 在选举时限时间过去之后，一个跟随者变为候选者并开启了一个新的选举，首先他会自己投自己一票
• 然后发送投票请求给其他跟随者投票，如果其他跟随者在这次选举中还没有投过票，就把票投给他，并且重置选举时限时间
• 一旦一个候选者获得了大多数票数，他成为领导者
• 然后领导者将增量条目发送给它的跟随者，这些消息在内部发送，并且在规定的心跳时间内，跟随者会响应每条增量条目
• 跟随者每次接受心跳都会重置选举时限时间
• 在下一个跟随者停止收到领导者的心跳，成为候选者之前，该次选举结果会持续
• 如果同时有两个候选者进行选举并且获得了相同票数，则会重新开启一轮选举时限，产生新的候选者进行选举

日志复制

• 一旦新领导被选举出来，需要复制所有的改变给其他跟随者，通过心跳机制完成增量复制
• 首先客户端把改变发给领导者，领导者将改变放入日志，在下一次心跳的时候将改变发送给跟随者
• entry被提交一旦大部分跟随者确认收货，然后响应客户端

分区容错

每个分区都会产生一个领导，最后根据选举代数高的作为最新领导。如果每个分区节点数量相同，选不出领导，直接响应客户端集群当前不可用

BASE理论

• 基本可用（basically available） 是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）需要注意的是，基本可用绝不等价于系统不可用
  • 响应时间上的损失。 正常情况下，搜索引擎需要在0.5s内返回给用户相应的查询结果，但是由于故障，查询结果响应时间增加到2-3秒
  • 功能上的损失 购物网站在购物高峰时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面
• 软状态（soft state） 指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据有多个副本，允许不同副本同步的延时就是 软状态的体现。MySQL replication的异步复制也是一种体现
• 最终一致性（eventual consistency） 指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况

分布式事务解决方案

2PC模式

数据库支持的2pc【2 phase commit 二阶提交】，又叫做 XA Transaction MYSQL从5.5版本开始支持，SQL server 2005开始支持，Oracle7开始支持 XA是一个两阶段提交协议，该协议分为以下两个阶段：

• 事务协调器要求每个涉及到事务的数据库预提交（precommit）此操作，并反映是否可以提交
• 事务协调器要求每个数据库提交数据 其中如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们在此事务中的那部分信息
  
  

2PC 是一个同步阻塞协议，第一阶段协调者会等待所有参与者响应才会进行下一步操作，第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。

第二阶段协调者的没有超时机制，只能不断重试！

协调者是一个单点，存在单点故障问题

• 协调者在发送准备命令之前挂了，等于事务还没开始
• 发送准备命令之后挂了，有些参与者等于都执行了处于事务资源锁定的状态。不仅事务执行不下去，还会因为锁定了一些公共资源而阻塞系统其它操作。
• 发送回滚事务命令之前挂了，事务执行不下去，且在第一阶段那些准备成功参与者都阻塞着。
• 发送回滚事务命令之后挂了，命令发出去了，很大的概率都会回滚成功，资源都会释放。但是如果出现网络分区问题，某些参与者将因为收不到命令而阻塞着。
• 发送提交事务命令之前挂了，所有参与者都阻塞着
• 发送提交事务命令之后挂了，命令发出去了，很大概率都会提交成功，然后释放资源，但是如果出现网络分区问题某些参与者将因为收不到命令而阻塞着。

新协调者的缺陷

每个参与者自身的状态只有自己和协调者知道，所以当老协调者和某些参与者一起挂掉之后，新协调者不知道这些挂掉的参与者之前的状态，也无法继续做决定，可能会出现数据不一致的情况。

特点：

• 2PC 是一种尽量保证强一致性的分布式事务
• 同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低
• 存在单点故障问题，在极端条件下存在数据不一致的风险。
• XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低
• 性能不理想，特别是在交易下单链路，并发量通常很高，XA无法满足高并发场景
• XA目前在商业数据库支持的比较理想，在MySQL数据库中支持的不太理想，MySQL的XA实现，没有记录prepare阶段的日志，主备切换导致主库与备库数据不一致
• 许多nosql也没有支持XA，这让XA的应用场景变得十分狭隘

3PC模式

3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段：CanCommit、PreCommit 和 DoCommit。

3pc准备阶段=了解参与者运行状况，是否可以参加事务，而不会直接执行事务
3PC预提交=2PC准备阶段
3PC提交=2PC提交

引入了超时机制，参与者就不会傻等了，如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。

然而超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了。

柔性事务-TCC 事务补偿型方案

• 刚性事务：遵循ACID，强一致性
• 柔性事务：遵循BASE，最终一致性 与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致

---

TCC 是业务层面的分布式事务
TCC 指的是Try - Confirm - Cancel。

• Try 指的是预留，即资源的预留和锁定，注意是预留。
• Confirm 指的是确认操作，这一步其实就是真正的执行了。
• Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。

一阶段：prepare行为，调用自定义的prepare逻辑
二阶段：commit行为，调用自定义的commit逻辑
三阶段：rollback行为，调用自定义的rollback逻辑 TCC支持把自定义的分支事务纳入全局事务的管理中

TCC 对业务的侵入较大和业务紧耦合，撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等。

柔性事务- 最大努力通知型方案

按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时。比如：调用微信或者支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现。例如：MQ发送http请求，设置最大通知次数，达到通知次数后不再通知。 案例：银行通知、商户通知等（各大交易平台间的商户通知：多次通知、查询校对、对账文件），支付宝支付成功异步回调

柔性事务- 可靠消息+最终一致性方案（异步确保型）

业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正地发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送，只有在得到确认发送指令后，实时消息服务才会真正发送

参考

分布式事务