第一章 分布式架构
分布式特点
分布性 对等性 并发性 缺乏全局时钟 故障总会发生
分布式环境问题
- 通信异常
- 网络分区（可能产生“脑裂”）
- 三态（成功、失败、超时）
- 节点故障
ACID
原子性 一致性 隔离性 持久性
分布式事务
CAP
Consistency,Availability,Partition tolearnce
BASE
Basically Available, Soft state,Eventually consistent
是对CAP一致性和可用性权衡结果。
最终一致性 包含 因果一致性 读己之所写 会话一致性 单调读一致性 单调写一致性
第二章 一致性协议
2PC和3PC
协调者Coordinator 统一调度分布式节点，参与者Participant被调度。
2PC
绝大部分关系型数据库都是使用二阶段提交处理分布式事务。
阶段一 提交事务请求（投票阶段）
- 事务询问
- 执行事务
- 各参与者向协调者反馈事务询问的响应
阶段二 执行事务提交
执行事务提交(第一阶段所有参与者回馈Yes)
- 发送提交请求
- 事务提交
- 反馈事务提交结果
- 完成事务
中断事务(有一个参与者反馈No或者等待超时)
- 发送回滚请求
- 事务回滚
- 反馈回滚结果
- 中断事务
二阶段提交将一个事务分成了投票和执行的阶段。
优缺点
协调者对于参与者有timeout机制，但是参与者对协调者没有timeout机制
优点: 原理简单，实现方便
缺点: 同步阻塞 单点问题 脑裂(第二阶段依然会出现不一致问题) 保守
3PC
解决2PC的阻塞，引入了参与者超时机制和一个额外的PreCommit阶段,但还是可能造成数据不一致
** 阶段一 CanCommit**
- 事务询问
- 各参与者向协调者反馈事务询问响应
** 阶段二 PreCommit**
-
执行事务预提交(全yes)
- 发送预提交请求
- 事务预提交
- 各参与者向协调者反馈事务执行响应
-
中断事务(有一个no或者超时)
- 发送中断请求
- 中断事务
** 阶段三 doCommit**
-
执行提交
- 发送提交请求
- 事务提交
- 反馈事务提交结果
- 完成事务
-
中断事务（有no或者超时）
- 发送中断请求
- 事务回滚
- 反馈回滚结果
- 中断事务
一旦进入阶段三， 可能会有两种故障
- 协调者出问题
- 协调者和参与者网络出问题
这样参与者都在等待超时后继续事务提交,为什么选择提交事务而不是中断事务？因为此时提交事务成功的可能性非常非常大了，但仍有例外，例如： 进入PreCommit后，协调者发出的是abort请求，如果只有一个Cohort收到并进行了abort操作，而其他对于系统状态未知的Cohort会根据3PC选择继续Commit，这仍然会导致不一致，不过这个概率就显然非常小了
优缺点
优点：较2PC降低了参与者阻塞范围，单点故障后继续一直
缺点: 参与者收到preCommit后如果网络故障 参与者依然会事务提交，必然数据不一致
Paxos算法
基于消息传递且有高度容错特性的一致性算法
Proposer Acceptor Learner