这是我参与「第四届青训营」笔记创作活动的的第15天，以下是我的课堂笔记。 本次课程主要分为四个大板块：
1.分布式系统
2.一致性与共识算法
3.从 Raft入手
4。实现细节以及未来
1.分布式系统
1.1 理想中的分布式系统
高性能:可拓展、低时延、高吞吐
正确:一致性、易于理解
可靠:容错、高可用
1.2 从 HDFS 开始
2.一致性与共识算法
2.1从复制开始
既然一台机器会挂
如果两个副本都能接受请求
2.2如何复制
主副本定期拷贝全量数据到从副本主副本拷贝操作到从副本
2.3如何复制操作
- 主副本把所有的操作打包成Log √所有的Log 写入都是持久化的，保存在磁盘上\
- 应用包装成状态机，只接收Log 作为Input
- 主副本确认Log 已经成功写入到副本机器上，当状态机 apply后，返回客户端
2.4关于读操作
- 读操作
√方案一:直接读状态机，要求写操作进入状态机后再返回client
√方案二:写操作复制完成后直接返回，读操作 Block 等待所有 pending log进入状态机 - 如果不遵循上述两周方案呢?
√可能存在刚刚写入的值读不到的情况(在Log中)
2.5什么是一致性
·对于我们的KV像操作一台机器一样要读到最近写入的值
.一致性是一种模型（(或语义)来约定一个分布式系统如何向外界(应用)提供服务. KV中常见的一致性模型
·最终一致性:读取可能暂时读不到但是总会读到
·线性一致性:最严格，线性执行
·一致性的分类经常与应用本身有关
·Linearizability是最理想的
2.6复制协议-当失效发生
当主副本失效
·手动切换·容错?
·不，我们的服务还是停了
·高可用?
·也许，取决于我们从发现到切换的过程的有多快
·正确?
·操作只从一台机器上发起
·所有操作返回前都已经复制到另一台机器了
2.7共识算法
·什么是共识算法
."The consensus problem requires agreement among a number of processes (or agents) fora single data value. Some of the processes (agents) may fail or be unreliable in other ways,so consensus protocols must be fault tolerant or resilient"
·简而言之一个值一旦确定，所有人都认同。
3.一致性协议案例:Raft
3.1 Paxos
The Part-Time Parliamen by Lamport 1989
·也就是人们提到的Paxos
·基本上就是一致性协议的的同义词
·该算法的正确性是经过证明的
3.2 Raft
·2014年发表
·易于理解作为算法的设计目标
·使用了RSM、Log、RPC的概念
·直接使用RPC 对算法进行了描述
.Strong Leader-based
·使用了随机的方法减少约束
·正确性
·形式化验证
·拥有大量成熟系统
3.3复制状态机(RSM)
.RSM (replicated state machine)
· Raft中所有的consensus都是直接使用Log 作为载体
. Commited Index
。一旦Raft更新Commited Index，意味着这个Index前的所有Log 都可以提交给状态机了
. Commited Index是不持久化的，状态机也是volatile的，重启后从第一条Log开始
3.4 Raft角色
3.5 Raft日志复制
3.6 Raft从节点失效
3.7 Raft Term
√每个Leader 服务于一个term
√每个term至多只有一个 leader
√每个节点存储当前的term
√每个节点term从一开始，只增不减
√所有rpc的request reponse都携带term
√只commit本 term内的log
3.8 Raft主节点失效
. Leader定期的发送AppendEntries RPCs给其余所有节点
· 如果Follower有一段时间没有收到Leader的 AppendEntries，则转换身份成为
Candidate
. Candidate自增自己的term，同时使用RequestVote RPCs向剩余节点请求投票
. raft在检查是否可以投票时，会检查log是否outdated，至少不比本身旧才会
投给对应的Candidate
·如果多数派节点投给它，则成为该term的 leader
3.9 Raft Leader failure
3.10 Raft安全性-同Term
- 对于Term内的安全性
·目标:
·对于所有已经的commited 的<term, index>位置上至多只有一条log\ - 由于Raft的多数派选举，我们可以保证在一个term中只有一个leader
·我们可以证明一条更严格的声明:在任何<term,index>位置上，至多只有一条log
·真的安全吗
. Raft使用TLA+进行了验证
·形式验证(Formal Method)以数学的形式对算法进行表达，
由计算机程序对算法所有的状态进行遍历
4. 回到KV
4.1案例-KV
利用Raft算法，重新打造我们的KV
·回顾一下一致性读写的定义
·方案一:
·写log被commit 了，返回客户端成功，
·读操作也写入一条log，状态机 apply时返回client
·增加Log量
·方案二:
·写log 被commit了，返回客户端成功
·读操作先等待所有commited log apply，再读取状态机
·优化写时延
·方案三:
·写Log被状态机 apply，返回给client
·读操作直接读状态机
·优化读时延
·Raft 不保证一直有一个leader
·只保证一个term至多有一个leader
·可能存在多个term的leader
.Split-brain
·确定合法的Leadership
·方案一:
·通过一轮 Heartbeat确认Leadership(获取多数派的响应)
·方案二:
·通过上一次 Heartbeat时间来保证接下来的有段时间内follower不会timeout
·同时follower在这段时间内不进行投票
·如果多数follower满足条件，那么在这段时间内则保证不会有新的Leader产生
·结合实际情况选择方案二或方案三
·取决于raft的实现程度以及读写的情况
多个副本只有单个副本可以提供服务
·服务无法水平拓展
·增加更多Raft组
·如果操作跨Raft组
4.2回到共识算法
. Raft :关于Log
. 论文中就给出的方案，当过多的Log占用后，启动snapshot，替换掉Log
· 如果对于持久化的状态机，如何快速的产生Snapshot
. 多组 Raft的应用中，Log 如何合流
· 关于configuration change
· 论文中给出的joint-consensus以及单一节点变更两种方案
. Raft是正确的，但是在工程世界呢?
· 真实世界中不是所有的错误都是完美fail-stop的
. cloudflare的case,etcd在partial network下，outage了6个小时
·高性能
数据中心网络100G，时延约为几个us
RDMA网卡以及programable switch的应用
我们想要的是:us级别的共识，以及us级别的容错
. HovercRaft
.P4 programable switch: lPmulticast
. Mu
. Use one-sided RDMA
.pull based heartbeat instead of push-based.
·多节点提交(Leaderless)
·节点跨地域，导致节点间的RTT(Round Trip Time)很大
·EPaxos
·使用了冲突图的方式来允许并行Commit
不冲突的情况下1RTT提交时间\
4.3 共识算法的未来
· Raft Paxos相互移植
. Raft有很多成熟的实现
·研究主要关注在 Paxos 上
·如何关联两种算法
. On the Parallels between Paxos and Raft, and how to Port Optimizations[1]
. Paxos vs Raft: Have we reached consensus on distributed consensus?[2]
[1] Wang, Zhaoguo, et al."On the Parallels between Paxos and Raft, and how to Port Optimizations." Proceedings ofthe 2019 ACM Symposium on Principles of Distributed Computing. 2019.
[2] Howard, Heidi, and Richard Mortier. "Paxos vs Raft: Have we reached consensus on distributed consensus?."Proceedings of the 7th Workshop on Principles and Practice of Consistency for Distributed Data.2020.
·共识算法作为一个系统
·多数分布式系统都选择共识算法作为底座
·不同一致性协议有不同的特性
.Virtual consensus in delos
·对外暴露一致性的LOG作为借口
·内部对于LOG可以选择不同的实现
