书籍笔记 《从paxox到zk分布式一致性原理与实践》
分布式事务 事务的参与者,支持事务的服务器,资源服务器以及事务管理器位于分布式系统的不同节点之上（涉及对多个数据源或业务系统的操作）
目录
分布式事务 - CAP定理
分布式事务 - BASE理论
一致性协议 - 2PC(二阶段提交协议)
一致性协议 - 3PC(三阶段提交协议)
一致性协议 - Paxos
CAP定理
1 定理 一个分布式系统不可能同时满足一致性（Consistency）,可用性（Availability）和分区容错性（Partition tolerrance）这三个基本需求,最多只能满足其中两项
2 介绍
2.1 一致性 数据在多个副本之间是否能够保持一致的特性
2.2 可用性 系统提供的服务必须一致处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果
2.3 分区容错性 分布式系统在遇到任何网络分区故障的时候,仍然需要能够保持对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障
3 应用
3.1 放弃P 将所有的数据都放在一个分布式节点上,至少不会碰到由于网络分区带来的负面影响 （注意,那样就不是分布式系统了,分区容错性是分布式系统一个最基本的需求）
3.2 放弃A 一旦系统遇到网络分区或其它故障时,那么受到影响的服务需要等待一定的时间,因此等待期间系统无法对外提供正常的服务
3.3 放弃C 放弃数据的强一致性,而保留数据的最终一致性（时间窗口,具体多久能够达到数据一致性取决于系统的设计,主要包括数据副本在不同节点之间的复制时间长短）
4 注意
在不放弃P的时候,为什么一致性和可用性不能共存,主要是分布式环境,数据副本同步涉及到网络,而网络是不可靠的
BASE理论
1 理论 Basicall Available(基本可用) Soft state (软状态) Eventually consistent(最终一致性)
2 介绍
2.1 基本可用 分布式系统在出现不可预知故障的时候,允许损失部分可用性
2.1.1 响应时间上的损失 故障情况下,响应时间较正常情况稍长
2.1.2 功能上的损失 特殊情况下,部分功能不可用
2.2 弱状态 允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响到系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
一致性协议
每一个机器节点虽然都能够明确地知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取到其它分布式节点的操作结果.因此,当一个事务需要跨越多个分布式节点时,为了保持事务处理的ACID特性,就需要引入一个"协调者"组件来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点则称为"参与者"
协调者 负责调度参与者的行为,并最终决定这些参与者是否要把事务真正的提交
2PC(二阶段提交协议)
1 协议说明（强一致性算法）
1.1 阶段一 提交事务请求 （投票节点,各参与者投票表明是否要继续执行接下去的事务提交操作）
1.1.1 事务询问 协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应
1.1.2 执行事务 各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中
1.1.3 各参与者向协调者反馈事务询问的响应 如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行,如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行
1.2 阶段二 执行事务提交
1.2.1 执行事务提交 假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务提交
1.2.1.1 发送提交请求 协调者向所有参与者节点发出Commit请求
1.2.1.2 事务提交 参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在这个事务执行期间占用的事务资源
1.2.1.3 反馈事务提交结果 参与者在完成事务提交后,向协调者发送Ack消息
1.2.1.4 完成事务 协调者接收到所有参与者反馈的Ack消息后,完成事务
1.2.2 中断事务 假如任何一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事务
1.2.2.1 发送回滚请求 协调者向所有参与者节点发出rollback请求
1.2.2.2 事务回滚 参与者接收到Rollback请求后,会利用其在阶段一种记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源
1.2.2.3 反馈事务回滚结果 参与者在完成事务回滚之后,向协调者发送Ack消息
1.2.2.4 中断 协调者接收到所有参与者反馈的Ack消息后,完成事务中断
2 优缺点
2.1 优点 原理简单,实现方便
2.2 缺点 同步阻塞,单点问题,脑裂,太过保守
2.2.1 同步阻塞 在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,各个参与者在等待其他参与者响应的过程中,将无法进行其他任何操作
2.2.2 数据不一致 阶段二过程中,当协调者向所有的参与者发送Commit请求之后,发生了局部网络异常或者是协调在尚未发送完Commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了Commit请求。于是,这部分收到了Commit请求的参与者就会进行事务的提交,而其他没有收到Commit请求的参与者则无法进行事务提交,于是整个分布式系统便出现了数据不一致现象
2.2.3 单点问题 协调者出问题,那么整个二阶段提交流程将无法运转,如果在阶段二出现问题,那么其他参与者将会一直处于锁定事务资源的状态中,而无法继续完成事务操作
2.2.4 太过保守 如果在协调者指示参与者进行事务提交询问的过程中,参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话,这是协调者只能依靠其自身的超时机制来判断是否需要中断事务 （二阶段提交协议没有涉及较为完善的容错机制,任意一个节点的失败都会导致整个事务的失败）
3PC(三阶段提交协议)
1 协议说明（主要针对2PC 执行阶段进行改进）
1.1 CanCommit（是否能提交）
1.1.1 事务询问 协调者向所有的参与者发送一个包含事务内容的canCommit请求,询问是否可以执行事务提交操作,并开始等待各参与者的响应
1.1.2 各参与者向协调者反馈事务询问的响应 （参与者反馈 Yes or No）
1.2 PreCommit(准备提交)
1.2.1 执行事务预提交 所有参与者都是Yes反馈,则执行此步
1.2.1.1 发送预提交请求 协调者向所有参与者节点发出preCommit的请求,并进入Prepared阶段
1.2.1.2 事务预提交 参与者接收到preCommit,会执行事务操作,并将Undo和Redo信息记录到事务日志中
1.2.1.3 各参与者向协调者反馈事务执行的响应 如果参与者成功执行了事务操作,那么就会反馈给协调者Act响应,同时等待最终的指令：提交或终止
1.2.2 中断事务 有参与者返回No反馈,则执行此步
1.2.2.1 发送中断请求 协调者向所有参与者节点发出abort请求
1.2.2.2 中断事务 无论是收到来自协调者的abort请求,或者是在等待协调者请求过程中出现超时,参与者都会中断事务
1.3 doCommit （提交）
1.3.1 执行提交
1.3.1.1 发送提交请求 假设协调者处于正常工作状态,并且它接收到了来自所有参与者的Ack响应,那么它将从"预提交"状态转换成"已提交"状态,并向所有的参与者发送doCommit请求
1.3.1.2 事务提交 参与者接收到doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源
1.3.1.3 反馈事务提交结果 参与者在完成事务提交之后,向协调者发送Ack消息
1.3.1.4 完成事务 协调者接收到所有参与者反馈的Ack消息后,完成事务
1.3.2 中断事务
1.3.2.1 发送中断提交 协调者向所有的参与者节点发送abort请求
1.3.2.2 事务回滚 参与者接收到abort请求后,会利用其在阶段二记录的Undo信息来执行事务回滚操作,并在完成回滚之后是否在整个事务执行期间占用的资源
1.3.2.3 反馈事务回滚结果 参与者在完成事务回滚之后,向协调者发送Ack消息
1.3.2.4 中断事务 协调者接收到所有参与者反馈的Ack消息,中断事务
2 阶段三可能出现故障 （无论出现哪种情况,最终都会导致参与者无法及时接收到来自协调者的domCommit或是abort请求,针对这样的异常情况,参与者都会在等待超时之后,继续进行事务提交）
2.1 协调者出现问题
2.2 协调者和参与者之间的网络出现故障
3 优缺点
3.1 优点 降低了参与者的阻塞范围,并且能够在出现单点故障后继续达成一致
3.2 缺点 参与者接收到preCommit消息后,如果网络出现分区,此时协调者所在的节点和参与者无法进行正常的网络通信,在这种情况下,该参与者依然会进行事务的提交,这必然出现数据的不一致性