浅谈分布式一致性协议笔记（一）| 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的第21天
一、分布式系统
1. 分布式系统面临的挑战
- 数据规模越来越大
- 服务的可用性要求越来越高
- 快速迭代的业务要求系统足够易用
2. 理想中的分布式系统
- 高性能：可拓展、低时延、高吞吐
- 正确：一致性、易于理解
- 可靠：容错、高可用
3. 从 HDFS 开始
4. 案例 - KV
-
从最简单机KV开始
-
接口：
- Get(key) -> value
- BatchPut([k1, k2, ...], [v1, v2, ...])
-
第一次实现
- RPC
- DB Engine
-
可靠性：
- 容错？
- 高可用？
-
正确性：
- 单进程，所有操作顺序执行
5. 小结
- 背景：数据规模的不断增加，我们需要大规模分布式系统
- 维度：对于一个分布式系统，希望能有哪些特征
- 从KV入手，看看我们如何满足分布式系统的要求
二、一致性与共识算法
1. 从复制开始
- 既然一台机器会挂
- 如果两个副本都能接受请求
2. 如何复制
- 主副本定期拷贝全量数据到从副本
- 主副本拷贝操作到从副本
3. 如何复制操作
- 主副本把所有的操作打包成Log
- 所有的Log写入都是持久化的，保存在磁盘上
- 应用包装成状态机，只接收Log作为Input
- 主副本确认Log已经成功写入到副本机器上，当状态机apply后，返回客户端
4. 关于读操作
-
方案一：直接读状态机，要求写操作进入状态机后再返回 client
-
方案二：写操作复制完成后直接返回，读操作 Block 等待所有 pending log 进入状态机
-
如果不遵循上述两周方案呢？
- 可能存在刚刚写入的值读不到的情况（在 Log 中）
5. 什么是一致性
-
对于我们的 KV
-
像操作─台机器─样
- 要读到最近写入的值
-
-
一致性是一种模型（或语义）
-
来约定一个分布式系统如何向外界（应用）提供服务
-
KV中常见的一致性模型
- 最终一致性：读取可能暂时读不到但是总会读到
- 线性一致性：最严格，线性执行
-
-
一致性的分类
- 经常与应用本身有关
-
Linearizability 是最理想的
6. 复制协议
6.1 当失效发生
当主副本失效
-
手动切换
-
容错？
- 不，我们的服务还是停了
-
高可用？
- 也许，取决于我们从发现到切换的过程的有多快
-
正确？
- 操作只从一台机器上发起
- 所有操作返回前都已经复制到另一台机器了
6.2 小结
-
当主副本失效时，为了使得算法简单
-
我们人肉切换，只要足够快
- 我们还是可以保证较高的可用性。
-
-
但是如何保证主副本是真的失效了呢？
- 在切换的过程中，主副本又开始接收client端的请求
- 两个主副本显然是不正确的，log会被覆盖写掉
- 我们希望算法能在这种场景下仍然保持正确
-
要是增加到三个节点呢？
-
每次都等其他节点操落盘性能较差
-
能不能允许少数节点挂了的情况下，仍然可以工作
- falut-tolerance
-
7. 共识算法
-
共识协议不等于一致性
-
应用层面不同的一致性，都可以用共识协议来实现
- 比如可以故意返回旧的值
-
简单的复制协议也可以提供线性一致性
-
-
一般讨论共识协议时提到的一致性，都指线性一致性
- 因为弱一致性往往可以使用相对简单的复制算法实现
