分布式事务一致性算法概述

CAP理论

• C一致性：数据在分布式下的多个副本之间数据保持一致性
• A可用性：分布式系统一直处于可用状态
• P分区容错性：分布式系统在任何网络或者单点故障时，仍能对外提供满足一致性和可用性的服务

一个分布式系统，不可能同时满足这三个要求，最多只能满足其中两项，一般就是在A、C之间寻找平衡。

 

base理论/柔性事务

base理论就是不做强一致性，只保持最终的一致性。

它在事务开始前数据是一致的，数据进行中是非一致的，事务进行后是一致的

 

XA规范下的2pc（强一致性算法）

优点

• 原理简单、实现方便

缺点

• 同步阻塞。他每次prepare或者commit都会等待ok的返回
• 单点故障。
• 数据有可能不一致。如果提交的时候，当有一个资源挂掉的时候，那么两个资源就会出现数据不一致的问题。

示例

1. 引入jar

• 配置xadatasource,下面这一段是关键，具体实现方法可以百度，百度上有很多，这里只说明方式

• 这样就可以实现分布式事务

这种方式的分布式事务缺点

• 必须要使用支持XA协议的datasource数据源
• 因为要同时锁定两个数据库的数据，事务锁定时间大大延长 ------ 现实中数据库性能欠佳
• 跨业务系统的情况下无法实现

 

XA规范下的3pc

• 第一阶段：CanCommit阶段。这个阶段类似于2PC中的第二个阶段中的Ready阶段，是一种事务询问操作，事务的协调者向所有参与者询问“你们是否可以完成本次事务？”，如果参与者节点认为自身可以完成事务就返回“YES”

• 第二阶段：PreCommit阶段。如果第一阶段所有参与者都返回yes，那么进入第二阶段。此时分布式事务协调者会向所有的参与者节点发送PreCommit请求，参与者收到后开始执行事务操作，并将Undo和Redo信息记录到事务日志中。参与者执行完事务操作后（此时属于未提交事务的状态），会返回yes.

• 第三阶段：DoCommit阶段。第二阶段如果都返回成功，那么就会进入第三阶段，向所有参与者发送docommit命令，参与者开始真正的提交事务，并且返回yes。如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

与2PC的区别

• 3PC对于协调者（Coordinator）和参与者（Partcipant）都设置了超时时间。当协调者宕机的时候，参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而2pc只有协调者拥有超时时间

优点

• 优化了同步阻塞问题
• 改善了单点故障

缺点

同2pc，他虽然改善了，但是并没有完全解决

 

TCC两阶段、补偿式事务

    它在try的时候，数据库数据就已经正式生效，在confrim阶段是去确认数据是否真正生效，如果没有生效那么会在cancel阶段抵消数据。当try失败，抛出异常的时候，也执行cancel阶段。

 

ZAB协议

ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性；

ZAB协议两种模式：消息广播和崩溃恢复

消息广播

• Leader 接收到消息请求后，将消息赋予一个全局唯一的 64 位自增 id，叫做：zxid，通过 zxid 的大小比较即可实现因果有序这一特性。
• Leader 通过先进先出队列(通过 TCP 协议来实现，以此实现了全局有序这一特性)将带有 zxid 的消息作为一个提案(proposal)分发给所有 follower。
• 当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
• 当 leader 接收到合法数量的 ACKs 后，leader 就向所有 follower 发送 COMMIT 命令，会在本地执行该消息。
• 当 follower 收到消息的 COMMIT 命令时，就会执行该消息

崩溃恢复

• 当领导崩溃之后，每个Server会发出一个投票,第一次都是投自己。投票信息：（myid，ZXID）
• 收集来自各个服务器的投票
• 处理投票并重新投票，处理逻辑：优先比较ZXID,然后比较myid
• 统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader
• 改变服务器状态