这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天，本文主要以概括总结，全局记录为主，而不是作为细致的知识点讲解，细节之处多有疏忽还望多多包容。
一、本堂课重点内容：
- 共识协议
- 分布式事务
二、详细知识点介绍：
二阶段提交
二阶段提交（Two-phase commit）：为了使基于分布式系统架构下的所有结点在进行事务提交时保持一致性而设计的一种演算法
三个假设：
- 引入协调者（Coordinator）和参与者（Participants），互相进行网络通信，
- 所有结点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
- 所有节点不会永久性循环，即使损坏后仍然可以恢复
可能出现的情况：
情况一）：Coordinator 不宕机，Participants 宕机，需要进行回滚操作
情况二）：Coordinator 宕机，Participants不宕机，可以起新的协调者，待查询状态后，重复二阶段提交
情况三）：Coordinator宕机，Participants也宕机，无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态
回滚：在Prepare 阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚
两阶段提交需注意的问题：
1.性能问题 两阶段提交需要多次节点间的网络通信，耗时过大，资深需要进行锁定，徒增资源等待时间。
2.协调者单点故障问题 如果事务协鸿者节点容机，需要另起新的协调者，否则参与者处于中间快态无法完成事务。
3.网络分区带来的数据不一致 一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致，
三阶段提交
三阶段提交 vs 两阶段提交
将两阶段提交中的Prepare阶段，拆成两部分： CanCommit和PreCommit机制
解决了两个问题： 1.单点故障问题 2.阻塞问题
另外引入超时机制，在等待超时之后，会继续进行事务的提交。
三阶段缓和了两阶段面临的问题，但依然没有解决： 1.性能问题 2.网络分区场景带来的数据一致性问题
RAFT 协议
log(日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
Term （任期号）：单调递增，每个Term内最多只有一个Leader
Committed： 日志披复制到多数派节点，即可认为已经被提交
Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态
Paxos 协议
Paxos算法与RAFT算法区别：
- Multi-Paxos 可以并发修改日志，而Raft写日志操作必须是连续的
- Multi-Paxos 可以随机选主，不必最新最全的节点当选Leader
优劣势
- 优势：写入并发性能高，所有节点都能写
- 劣势：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录
三、课后个人总结：
分布式的背后理论支撑是分布式具有高性能的重要基石，要熟记于心
