这是我参与「第四届青训营 」笔记创作活动的的第15天

0x00 分布式系统

0.1 分布式系统面临的挑战

• 数据规模越来越大
• 服务的可用性要求越来越高
• 快速迭代的业务要求系统足够易用

0.2 理想中的分布式系统

• 高性能：可拓展、低时延、高吞吐
• 正确：一致性、易于理解
• 可靠：容错、高可用

0.3 HDFS

0.4 KV

接口：

• Get(key)->value
• BatchPut([k1,k2,...],[v1,v2,...]

0x01 一致性共识算法

1.1 复制协议

• 主副本定期拷贝全量数据到从副本
• 主副本拷贝操作到从副本

1.2 一致性读写定义

• 方案一：
  • 写log被commit了，返回客户端成功
  • 读操作也写入一条log,状态机apply时返client
  • 增加Log量
• 方案二：
  • 写log被commit了，返回客户端成功
  • 读操作先等待所有commited log apply,再读取状态机
  • 优化写时延
• 方案三：
  • 写Log被状态机apply,返回给client
  • 读操作直接读状态机
  • 优化读时延

1.3 什么是一致性

- 对于我们的KV
- 像操作一台机器一样
    - 要读到最近写入的值

• 致性是一种模型(或语义)
  • 来约定一个分布式系统如何向外界（应用）提供服务
  • KV中常见的一致性模型
    • 最终一致性：读取可能暂时读不到但是总会读到
    • 线性一致性：最严格，线性执行

1.4 共识算法

• 共识协议不等于一致性
  • 应用层面不同的一致性，都可以用共识协议来实现
    • 比如可以故意返回旧的值
  • 简单的复制协议也可以提供线性一致性
• 一般讨论共识协议时提到的一致性，都指线性一致性
  • 因为弱一致性往往可以使用相对简单的复制算法实现

0x02 从 Raft 入手

2.1 Paxos

• The Part-Time Parliamen by Lamport 1989
  • 也就是人们提到的Paxos
  • 基本上就是一致性协议的的同义词
  • 该算法的正确性是经过证明的

2.2 Raft

• 2014年发表
• 易于理解作为算法的设计目标
  • 使用了RSM、Log、RPC的概念
  • 直接使用RPC对算法进行了描述
  • Strong Leader-based
  • 使用了随机的方法减少约束
• 正确性
  • 形式化验证
  • 拥有大量成熟系统

2.3 复制状态机（RSM）

• RSM (replicated state machine)
  • Raft中所有的consensus都是直接使用Log作为载体
• Commited Index
  • 一旦Raft更新Commited Index,意味着这个Index前的所有Log都可以提交给状态机了
  • Commited Index是不持久化的，状态机也是volatile的，重启后从第一条Log开始

2.4 Raft角色

2.5 Raft整体流程

2.6 Raft日志复制

2.7 Raft从节点失效

2.7 Raft Term

2.8 Raft Leader failure

0x03 KV改造

3.1 Raft改造

• Raft不保证一直有一个leader
  • 只保证一个term至多有一个leader
  • 可能存在多个term的leader
• Split-brain

• 确定合法的Leadership
  • 方案一：
    • 通过一轮Heartbeat确认Leadership(获取多数派的响应)
  • 方案二：
    • 通过上一次Heartbeat时间来保证接下来的有段时间内follower不会timeout
    • 同时follower在这段时间内不进行投票
    • 如果多数follower满足条件，那么在这段时间内则保证不会有新的Leader产生

• 多个副本只有单个副本可以提供服务
  • 服务无法水平拓展
• 增加更多Raft组
  • 如果操作跨Raft组