这是我参与「第四届青训营」笔记创作活动的的第15天
01.分布式系统
1.1 分布式系统面临的挑战
1）数据规模越来越大
2）服务的可用性要求越来越高
3）快速迭代的业务 要求系统足够易用
1.2 理想中的分布式系统
➢ 高性能:可拓展、低时延、高吞吐
➢ 正确:一致性、易于理解
➢ 可靠:容错、高可用
1.3 从 HDFS 开始
1.4 案例 - KV
1）从最简单机KV开始
2）接口:
（1）Get(key) -> value
（2）BatchPut([k1, k2, .]，[v1, v2, ..])
3）第一次实现
（1）RPC
（2）DB Engine
1.4 案例- KV
1）可靠性: 容错? 高可用?
2）正确性: ▪️ 单进程，所有操作顺序执行
02.一致性与共识算法
2.1 从复制开始
既然一台机器会挂
如果两个副本都能接受请求
2.2 如何复制
1）主副本定期拷贝全量数据到从副本
2）主副本拷贝操作到从副本
2.3如何复制操作
➢主副本把所有的操作打包成Log
所有的Log写入都是持久化的，保存在磁盘上
➢应用包装成状态机，只接收Log作为Input
➢主副本确认Log已经成功写入到副本机器.上，当状态机apply后，返回客户端
2.4 关于读操作
➢读操作
1）方案一:直接读状态机，要求写操作进入状态机后再返回client
2）方案二:写操作复制完成后直接返回，读操作Block等待所有pending log进入状态机
➢如果不遵循上述两周方案呢?
1）可能存在刚刚写入的值读不到的情况(在Log中)
2.5 什么是一致性-1
● 对于我们的KV
1）像操作一台机器一样
（1）要读到最近写入的值
● 一致性是一种模型( 或语义)
1）来约定一个分布式系统如何向外界( 应用)提供服务
2）KV中常见的一致性模型
（1）最终一致性:读取可能暂时读不到但是总会读到
（2）线性一致性:最严格，线性执行
2.5 什么是一致性-2
1）一致性的分类
（1）经常与应用本身有关
2） Linearizability是最理想的
2.6复制协议 -当失效发生
➢ 当主副本失效
1）手动切换
2）容错?
（1）不，我们的服务还是停了
3）高可用?
（1）也许，取决于我们从发现到切换的过程的有多快
4）正确?
（1）操作只从一台机器上发起
（2）所有操作返回前都已经复制到另一台机器了
2.6 复制协议 - 小结
➢当主副本失效时，为了使得算法简单
1）我们人肉切换，只要足够快
（1）我们还是可以保证较高的可用性。
➢但是如何保证主副本是真的失效了呢?
1）在切换的过程中，主副本又开始接收client端的请求
2）两个主副本显然是不正确的，log 会被覆盖写掉
3）我们希望算法能在这种场景下仍然保持正确
➢要是增加到三个节点呢?
1）每次都等其他节点操落盘性能较差
2）能不能允许少数节点挂了的情况下，仍然可以工作
（1）falut- tolerance
2.7 共识算法
▪️ 什么是共识算法
1）"The consensus problem requires agreement among a number of processes (or agents) for a single data value. Some of the processes agents) may fail or be unreliable in other ways, so consensus protocols must be ault tolerant or resilient"
2）简而言之一一个值一旦确定，所有人都认同。
2.7 共识算法
● 有文章证明是一一个不可能的任务( FLP impossibility ) "In this paper, we show the surprising result thatepetely a synchronous consensus protocol can tolerate even a single unannounced process . We do not consider Byzantine failures, and we assume that the message system is reliableit delivers all messages correctly and exactly once." --- JACM 85 [1]
● 错误总是发生
1）Non-Byzantine fault
● 错误类型很多
1）网络断开，分区，缓慢，重传，乱序
2）CPU、l0都机会停住
● 容错(falute-tolerance）
2.7 共识算法
➢共识协议不等于一致性
1）应用层面不同的一致性，都可以用共识协议来实现
（1）比如可以故意返回旧的值
2）简单的复制协议也可以提供线性一致性
➢ 一般讨论共识协议时提到的一致性，都指线性一致性
1）因为弱一致性往往可以使用相对简单的复制算法实现
03.一致性协议案例: Raft
3.1 Paxos
● The Part-Time Parliamen by Lamport 1989
1）也就是人们提到的Paxos
2）基本上就是一致性协议的的同义词
3）该算法的正确性是经过证明的
● 那么问题解决了吗?
1）Paxos是出了名的难以理解，L amport本人在01年又写了一篇Paxos Made Simple
（1）“The Paxos Algorighm, when presented in plain English, is very simple. ”
2）算法整体是以比较抽象的形式描述，工程实现时需要做一些修改
3）Google在实现Chubby的时候是这样描述的
（1）here are significant gaps between the description of the Paxos algorithm and the needs of a real-world system...the final system will be based on an unproven protocol.
3.2 Raft
● 2014年发表
● 易于理解作为算法的设计目标
-
使用了RSM、Log、RPC的概念
-
直接使用RPC对算法进行了描述
-
Strong Leader-based
-
使用了随机的方法减少约束
● 正确性
-
形式化验证
-
拥有大量成熟系统
3.3 复制状态机(RSM)
- RSM ( replicated state machine )
(1)Raft中所有的consensus都是直接使用Log作为载体
-
Commited Index
-
一旦Raft更新Commited Index,意味着这个Index前的所有Log都可以提交给状态机了
-
Commited Index是不持久化的，状态机也是volatile 的，重启后从第一条Log开始
3.4 Raft角色
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向剩余节点请求投票
(1) raft在检查是否可以投票时，会检查log是否outdated,至少不比本身旧才会 投给对应的Candidate
(2)如果多数派节点投给它，则成为该term的leader
3.9 Raft Leader failure
3.10 Raft 安全性 - 同Term
➢ 对于Term内的安全性
- 目标:
(1)对于所有已经的commited的<term, index>位置上至多只有一条log
➢ 由于Raft的多数派选举，我们可以保证在一个term 中只有一个leader
- 我们可以证明一条更严格的声明:在任何<term,index>位置上，至多只有一条log
3.10 Raft安全性 一 跨Term
- 对于跨Term的安全性
(1)目标:
▪️ 如果一个log被标记commited,那这个log一定会在未来所有的leader中出现 Leader completeness
2）可以证明这个property
1）Raft选举时会检查Log的是否outdated,只有最新的才能当选L eader
2）选举需要多数派投票，而commited log也已经在多数派中( 必有overlap )
3）新Leader一定持有commited log,且Leader永远不会overwrite log
3.10 Raft安全性验证
● 真的安全吗
1）Raft使用TLA+进行了验证
（1）形式验证( Formal Method )
以数学的形式对算法进行表达，
由计算机程序对算法所有的状态进行遍历
04. 回到KV
4.1 案例 一 KV
● 利用Raft算法，重新打造我们的KV
● 回顾一下一致性读写的定义
1）方案一:
（1）写log被commit了，返回客户端成功，
（2）读操作也写入一条log,状态机apply时返回client
（3）增加Log量
2）方案二:
（1）写log被commit了，返回客户端成功
（2）读操作先等待所有commited log apply,再读取状态机
（3）优化写时延
3）方案三:
（1）写Log被状态机apply,返回给client
（2）读操作直接读状态机
（3）优化读时延
● Raft不保证一-直有一个leader
1）只保证一个term至多有一个leader
2）可能存在多个term的leader
● Split- brain
● 确定合法的Leadership
1）方案一:
（1）通过一轮Heartbeat确认Leadership ( 获取多数派的响应)
2）方案二:
（1）通过上一次Heartbeat时间来保证接下来的有段时间内follower不会timeout
（2）同时follower在这段时间内不进行投票
（3）如果多数follower满足条件，那么在这段时间内则保证不会有新的Leader产生
● 结合实际情况选择方案二或方案三
1）取决于raft的实现程度以及读写的情况
多个副本只有单个副本可以提供服务
1）服务无法水平拓展
● 增加更多Raft组
1） 如果操作跨Raft组
4.2 回到共识算法
1）Raft:关于Log
（1）论文中就给出的方案，当过多的Log占用后，启动snapshot,替换掉Log
（2）如果对于持久化的状态机，如何快速的产生Snapshot
（3）多组Raft的应用中，Log如何合流
2）关于configuration change
（1）论文中给出的joint-consensus以及单一节点变更两种方案
Raft是正确的，但是在工程世界呢?
1）真实世界中不是所有的错误都是完美fail-stop 的
2）cloudflare的case, etcd 在partial network下，outage 了6个小时[1]
● 高性能
1）数据中心网络100G，时延约为几个us
2）RDMA网卡以及programable switch的应用
3）我们想要的是: us级别的共识，以及us级别的容错
4）HovercRaft
（1）P4 programable switch: IP multicast
5）Mu
（1）Use one sided RDMA
（2）pull based heartbeat instead of push-based.
● 多节点提交(Leaderless)
1）节点跨地域，导致节点间的RT T(Round Trip Time)很大
2）EPaxos[1]
（1）使用了冲突图的方式来允许并行Commit
（2）不冲突的情况下1RTT提交时间
4.3 共识算法的未来
1）Raft Paxos相互移植
（1）Raft有很多成熟的实现
（2）研究主要关注在Paxos上
（3）如何关联两种算法
i) On the Parallels between Paxos and Raft, and how to Port Optimizations[1]
ii) Paxos Vs Raft: Have we reached consensus on distributed consensus?[2]
4.3 共识算法的未来
▪️ 共识算法作为一个系统
1）多数分布式系统都选择共识算法作为底座
2）不同一致性协议有不同的特性
3）Virtual consensus in delos[1]
（1）对外暴露一致性的I .OG作为借口
（2）内部对于LOG可以选择不同的实现
