这是我参与「第四届青训营 」笔记创作活动的第4天
分布式系统
面临的挑战
- 数据规模越来越大
- 服务的可用性要求越来越高
- 快速迭代的业务要求系统足够易用
理想中的分布式系统
- 高性能:可拓展、低时延、高吞吐
- 正确:一致性、易于理解
- 可靠:容错、高可用
HDFS
一致性与共识算法
如何复制
- 主副本定期拷贝全量数据到从副本
- 主副本拷贝操作到从副本
如何复制操作
- 主副本把所有的操作打包成Log
- 所有的Log 写入都是持久化的，保存在磁盘上
- 应用包装成状态机，只接收Log作为Input
- 主副本确认Log 已经成功写入到副本机器上，当状态机 apply后，返回客户端
读操作
- 方案一:直接读状态机，要求写操作进入状态机后再返回client
- 方案二:写操作复制完成后直接返回，读操作Block等待所有pending log进入状态机
如果不遵循上述两周方案呢? —— 可能存在刚刚写入的值读不到的情况(在Log中)
共识算法
共识协议不等于一致性
- 应用层面不同的一致性，都可以用共识协议来实现
- 比如可以故意返回旧的值
- 简单的复制协议也可以提供线性─致性
一般讨论共识协议时提到的一致性，都指线性━致性
- 因为弱一致性往往可以使用相对简单的复制算法实现
一致性案例：Raft
Paxos
Raft
复制状态机
RSM (replicated state machine)
- Raft 中所有的consensus都是直接使用Log作为载体 Commited Index
- 一旦Raft更新Commited Index，意味着这个Index前的所有Log 都可以提交给状态机了
- Commited Index是不持久化的，状态机也是volatile的，重启后从第一条Log开始
Raft角色
回到KV
回到共识算法
Raft :关于Log
- 论文中就给出的方案，当过多的Log占用后，启动snapshot，替换掉Log
- 如果对于持久化的状态机，如何快速的产生Snapshot
- 多组Raft的应用中，Log 如何合流
关于configuration change
- 论文中给出的joint-consensus以及单一节点变更两种方案
共识算法的未来
Raft Paxos相互移植
- Raft有很多成熟的实现
- 研究主要关注在Paxos 上
- 如何关联两种算法
- On the Parallels between Paxos and Raft, and how to Port Optimizations
- Paxos vs Raft: Have we reached consensus on distributed consensus?
共识算法作为一个系统
- 多数分布式系统都选择共识算法作为底座
- 不同一致性协议有不同的特性
- Virtual consensus in delos
- 对外暴露一致性的LOG作为借口
- 内部对于LOG 可以选择不同的实现
