分布式——现代架构基石 | 青训营笔记这是我参与「第五届青训营」伴学笔记创作活动的第 16 天，前言，本文笔记主要内容：

这是我参与「第五届青训营」伴学笔记创作活动的第 16 天

前言

本文笔记主要内容：

定义：
- 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
三个假设：
1. 引入协调者(Coordinator)和参与者(Participants),互相进行网络通信
2. 所有节点都采用预写式日志,且日志被写完后即被保持在可靠的存储设备上
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复
正常流程：
1. Prepare阶段
2. Commit阶段
异常流程：
- 参与者宕机导致Prepare阶段失败
  - 需要回滚
- 协调者宕机
  - 需要重新启用新的协调者,待查询状态后,重复二阶段提交
- 双故障重启
  - 没办法了,只能让数据库管理员介入
两阶段提交需解决的问题：
- 性能问题
  - 需要多次网络通信，资源需要等待并锁定
- 新协调者
  - 如何确定状态选出新协调者
- Commit阶段网络分区带来的数据不一致
  - 非所有节点都收到Commit请求

因此,引入了三阶段提交

时间戳的实现
- 物理时钟：Spanner论文提供TrueTime API(一个物理时钟的方式)，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差通常控制在1到7ms之间。
- 逻辑时钟：时间截预言机(TSO)，采用中心化的授时方式，所有协调者向中心化节点获取时钟。优点是算法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟，高性能以及更好的容错性。

NWR模型三要素：
- N：在分布式存储系统中，有多少份备份数据
- W：代表一次成功的更新操作要求至少有w份数据写入成功
- R：代表一次成功的读数据操作要求至少有R份数据成功读取
- 其中为了保证强一致性，需要保证 W+R>N
Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型
思考
- 在读写的并发更新中容易引起一致性问题
  - 读者如果读到副本1和副本2，得出v=3的结论
  - 如果读到副本2和副本3，得出v=2的结论
- 根源:允许数据被覆盖

概述
- Raft协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。
- Raft是使用较为广泛的分布式协议。
- 一定意义上讲,Raft协议也使用了Quorum机制
三种角色
- Leader领导者
  - 通常一个系统中是一主 (Leader) 多从(Follower)。 Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
- Follower跟随者
  - 跟随者，不会发送任何请求。接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志。当Leader出现故障时，主动推荐自己为Candidate。
- Candidate备选者
  - 备选者，Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票，则晋升为Leader。
四种定义：
- Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
- Term（任期号）：单调递增，每个Term内最多只有一个Leader
- Committed：日志被复制到多数派节点，即可认为已经被提交
- Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态
RAFT协议的状态机：

Paxos算法与RAFT算法区别：
- Multi-Paxos 可以并发修改日志，而Raft写日志操作必须是连续的
- Multi-Paxos 可以随机选主，不必最新最全的节点当选Leader
优缺点
- 优势：写入并发性能高，所有节点都能写入
- 劣势：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录
- 示意图:

如图所示

本文主要还是做个笔记，基本上所有的东西都很重要，我也都不是特别太懂，所以还是多看看,多请教请教其他人，还有对于实际的软件应用上我其实不太清楚这种东西具体怎么应用，但概念上还是非常具有学习价值的，明天继续加油努力