这是我参与「第四届青训营 」笔记创作活动的第4天
浅谈分布式一致性协议
分布式系统
分布式系统面临的挑战
- 数据规模越来越大
- 服务的可用性要求越来越高
- 快速迭代的业务要求系统足够易用
理想中的分布式系统
- 高性能:可拓展、低时延、高吞吐
- 正确:一致性、易于理解
- 可靠:容错、高可用
从HDFS开始
简单KV机
- 接口Get，BatchPut
- 第一次实现RPC，DB Engine
什么是一致性协议
KV中常见的一致性模型
- 最终一致性：读取可能暂时读不到但是总会读到
- 线性一致性：最严格，线性执行
复制协议
- 主副本定期拷贝全量数据到从副本
- 主副本拷贝操作到从副本
主副本把所有的操作打成Log包
所有的Log写入都是持久化的，保存在硬盘上
应用包装成状态机，只接受Log作为Input
主副本确定Log已经成功写入到副本机器上，当状态机apply之后，返回客户端
共识算法
简而言之一个值一旦确认，所有人都认同
共识是个不可能的任务，因为
- 错误总是会发生
- 错误的类型有很多，比如网络断开，分区，缓慢，重传，乱序，cpu停滞
- 容错
共识算法不等于一致性，应用层面不同的一致性都可以用共识协议来实现。简单的复制协议也可以提供线性一致性。
弱一致性能够使用简单的复制算法实现，共识协议提到的一致性是线性一致性
以 Raft 为例子了解一致性协议是如何工作的
Raft是一个分布式共识算法
- Raft于2014年发表
- 以易于理解作为算法的设计目标
- 使用了RSM、Log、RPC的概念
- 直接使用RPC对算法进行了描述
- Strong Leader-based
- 使用了随机的方法减少约束
- 正确性
- 形式化验证
- 拥有大量成熟系统
Raft角色
- 假设在集群有A、B、C三个节点。初始状态下，所有的服务器都是跟随者（Follower）的状态，而没有领导者状态（Leader)
- 集群中每个节点都有一个选举超时时间（election timeout），每个节点的选举超时时间都是150ms~300ms的一个随机数，每当节点的选举超时时间到了就会触发它成为候选者。假设A节点的等待超时时间最小（150ms),它会最先因为没有等到领导者的心跳信息，发生超时。此时A节点的状态会由Follower转换成为Candidate状态。
- A转换了自己的状态为Candidate，它会立即开始如下动作进行选举：
- 增加了自己的term
- 先给自己投上一票
- 重置选举超时时间
- 然后向其他节点发送请求投票RPC消息，请它们选举自己为领导者。如果候选人在选举超时时间内赢得了大多数选票，它将成为本届任期内新的领导者
Raft整体流程
Raft的Term
- 每个Leader服务于一个term
- 每个term至多只有一个leader
- 每个节点存储当前的term
- 每个节点term从一开始，只增不减
- 所有rpc的request reponse都携带term
- 只commit本term内的log
Raft的安全性
-
对于Term内的安全性
- 目标：如果一个log被标记commited,那这个log一定会在未来所有的leader中出现Leader completeness
-
可以证明这个property
- Raft选举时会检查Log是否outdated，只有最新的才能当选Leader
- 选举需要多数派投票，而commited log也已经在多数派中（必有overlap）
- 新Leader一定持有commited log，且Leader永远不会overwrite log
