这是我参与「第四届青训营 」笔记创作活动的的第15天。
本节课程主要分为 4 个方面：
1.分布式系统
2.一致性与共识算法
3.从Raft入手
4.实现细节以及未来
一.分布式系统
1.1.分布式系统面临的挑战
■ 数据规模越来越大
■ 服务的可用性要求越来越高
■ 快速迭代的业务要求系统足够易用
1.2.理想中分布式系统
■ 高性能：可拓展、低延时、高吞吐
■ 正确：一致性、易于理解
■ 可靠：容错、高可用
1.3.从HDFS开始
二.一致性与共识算法
2.1.从复制开始
2.2.如何复制
▷ 主副本定期拷贝全量数据到从副本
▷ 主副本拷贝操作到从副本
2.3.如何复制操作
▷ 主副本把所有操作打包成Log
◎ 所有的LOg写入都是持久化的，保存在磁盘上
▷ 应用包装成状态机，只接收Log作为Input
▷ 主副本确认Log已经成功写入到副本机器上，当状态机apply后，返回客户端
2.4.关于读操作
▷ 读操作：
◎ 方案一：直接读状态机，要求写操作进入状态机后再返回
◎ 方案二：写操作复制完成后直接返回，读操作Block等待所有pending log进入状态机
▷ 如果不遵循上述两种方案呢？
◎ 可能存在刚刚写入的值读不到的情况(在Log中)
2.5.什么是一致性
▷ 对于我们的KV
◎ 像操作一台机器一样，要读到最近写入的值
▷ 一致性是一种模型(或语义)
◎ 来约定一个分布式系统如何向外界(应用)提供服务
◎ KV中常见的一致性模型
● 最终一致性：读取可能暂时读不到但是总会读到
● 线性一致性：最严格，线性执行
2.5.1.一致性的分类
▷经常与应用本身有关
▷ Linearizability是最理想的
2.6.复制协议 - 当失效发送
▷当主副本失效
◎ 手动切换
◎ 容错？：不，我们的服务还是停了
◎ 高可用？：也许，取决于我们从发现到切换的过程的有多快
◎ 正确？
● 操作只从一台机器上发起
● 所有操作返回前都已经复制到另一台机器了
2.7.共识算法
▷ 什么是共识算法
◎ 简而言之一个值一旦确定，所有人都认同
◎ 错误总是发生：Non-Byzantine fault
◎ 错误类型很多
● 网络断开，分开，缓慢，重传，乱序
● CPU、IO都机会挺住
◎ 容错(falute-tolerance)
▷ 共识协议不等于一致性
◎ 应用层面不同的一致性，都可以用来共识协议来实现
◎ 简单的复制协议也可以提供线性一致性
▷ 一般讨论共识协议是提到的一致性，都是线性一致性
◎ 因为弱一致性往往可以使用相对简单的复制算法实现
三.从Raft入手
3.1.Paxos
◈ The Part-Time Parliamen by Lamport 1989
◎ 也就是人们提到的Paxos
◎ 基本上就是一致性协议的同义词
◎ 该算法的正确性是经过证明的
3.2.Raft
◈ 2013年发表
◈ 易于理解作为算法的设计目标
◎ 使用了RSM、Log、RPC的概念
◎ 直接使用RPC对算法进行了描述
◎ Strong Leader-based
◎ 使用了随机的方法减少约束
◈ 正确性
◎ 形式化验证
◎ 用于大量成熟系统
3.3.复制状态机(RSM)
◈ RSM
◎ 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
◈ 每个tern之多只有一个leader
◈ 每个节点存储当前的term
◈ 每个节点term从一开始，只增不减
◈ 所有rpc的request reponse都携带term
◈ 只commit本term内的log
3.8.Raft主节点失效
◈ Leader定期的发送AppendEntries RPC是给其余所有节点
◈ 如果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
3.10.1.跨Term
◈ 对于跨Term的安全性
◎ 目标：如果一个log被标记commited，那这个log一定会在未来所有的leader中出现Leader Completeness
◈ 可以证明这个property
◎ Raft选举是会检查Log的是否outdated，只有最小的才能当选Leader
◎ 选举需要多数派投票，而commited log也已经在多数派中(必有overlap)
◎ 新Leader一定持久commited log，且leader永远不会overwrite log
3.10.2.Raft安全性验证
◈ Raft使用TLA+
◎形式验证，以数学的形式对算法进行表达，由计算机程序对算法所有的状态进行遍历。
四.实现细节以及未来
4.1.案例-KV
◯ 利用Raft算法，重新打造我们的KV
4.2.回到共识算法
◯ Raft：关于Log
◎ 论文中给出的方案，当过多的Log占用后，启动snapshot，替换掉Log
◎ 如果对于持久化的状态机，如何快速的产生Snapshot
◎ 多组Raft的应用中，Log如何合流
◯ 关于configuration changev
◎ 论文中给出的joint-consensus以及单一节点变更两种方案
4.3.共识算法的未来
◯ 高性能
◎ 数据中心网络100G，时延约为几个us
◎ RDMA网卡以及programable switch的应用
◎ 我们想要的是：us级别的共识，以及us级别的从错
◎ HovercRaft：P4 programable switch：IP multicast
◎ Much：
● Use one-sided RDMA
● pull based heartbast instead of push-based
◯ 多节点提交(Leaderless)
◎ 节点跨地域，导致节点间的RTT(Round Trip Time)很大
◎ EPaxos：
● 使用了冲突图的方式来允许并行Commit
● 不冲突的情况下1RTT提交时间
◯ Raft Paxos相互移植
◎ Raft由很多成熟的实现
◎ 研究主要关注在Paxos上
◎ 如何关联两种算法：
● On the Parallels between Paxos and Raft,and how to Port Optimizations
● Paxos vs Raft:Have we reached consensus on distracted consensus？
◯ 共识算法作为一个系统
◎ 多数分布式系统都选择共识算法作为底座
◎ 不同一致性协议有不同的特性
◎ Virtual consensus in Delos：
● 对外暴露一致性的LOG作为借口
● 内部对于LOG可以选择不同的实现
