这是我参与「第四届青训营 」笔记创作活动的第12天
1. 分布式系统
1.1. 分布式系统面临的挑战
- 数据规模越来越大
- 服务的可用性要求越来越高
- 快速迭代的业务要求系统足够易用
1.2. 理想中的分布式系统
- 高可用：可拓展、低延时、高吞吐
- 正确：一致性、易于理解
- 可靠：容错、可用性
1.3. 从HDFS开始
1.4. 案例 - KV
- 从最简单机KV开始
- 接口：
- Get(key) -> value
- BatchPut([K1,k2,...],[v1,v2,...])
- 第一次实现
- RPC
- DB Engin
2. 一致性与共识算法
2.1. 从复制开始
2.2. 如何复制
- 主副本定期拷贝全量数据到从副本
- 主副本拷贝操作到从副本
2.3. 如何复制操作
- 主副本把所有的操作打包成Log
- 所以的Log写入都是持久化的，保存在磁盘上
- 应用包装成状态机，只接收Log作为Input
- 主副本确认Log已经成功写入到副本机器上，当状态机apply后，返回给客户端
2.4. 关于读操作
- 读操作
- 方案一：直接读状态机，要求写操作进入状态机后再返回client
- 方案二：写操作复制完成后直接返回，读操作Block等待所有pending log进入状态机
- 如果不遵循上述两种方法呢？
- 可能存在刚刚写入的值读不到的情况（在Log中）
2.5. 什么是一致性 - 1
- 对于我们的KY
- 像操作一台机器一样
- 要读到最近写入的值
- 像操作一台机器一样
- 一致性是一种模型（或语义）
- 来约定与i个分布式系统如何向外界（应用）提供服务
- KV中常见的一致性模型
- 最终一致性：读取可能暂时读不到但是总会读到
- 线性一致性：最严格，线性执行
2.5. 什么是一致性 - 2
- 一致性的分类
- 经常与应用本身有关
- Linearizability是最理想的
2.6. 复制协议 - 当失效发生
- 当副本失效
- 手动切换
- 容错？
- 不，我们的服务还是停了
- 高可用？
- 也许，取决于我们从发现到切换过程的有多快
- 正确？
- 操作只从一台机器上发起
- 所有操作返回前都已经复制到另一台机器了
2.7. 共识算法
3. 从Raft入手
3.1. Paxos
3.2. Raft
3.3. 复制状态机（RMS）
- RSM（replicated state machine）
- Raft中的所有consensus都是直接使用Log作为载体
- Commited Index
- 一旦Raft更新Committed 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 response都携带term
- 只commit本term内的log
3.8. Raft主节点失效
3.9. Raft Leader failure
3.10 Raft安全性 - 同Term
3.10. Raft安全性 - 跨Term
3.10. Raft安全性验证
4. 实现细节以及未来
4.1. 案例 - KV
- 利用Raft算法，重新打造我们的KV
4.2. 回到共识算法
- Raft：关于Log
- 论文中就给出的方案，，当过多的Log占用后，启动snapshot，替换掉Log
- 如果对持久化的状态机，如何快速的产生Snapshot
- 多组Raft的应用中，Log如何河流
- 关于configuration change
- 论文中给出的joint-consensus以及单一节点变更两种方案
