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

1. 分布式系统

分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。也就是说分布式系统背后是由一系列的计算机组成的，但用户感知不到背后的逻辑，就像访问单个计算机一样。
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。

1.1 挑战

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

1.2 理想分布式系统

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

1.3 简单KV

Client提供RPC发起请求，将数据存储在DBEngine再返回。

无容错
无高可用
正确性：单进程，所有操作顺序进行

2. 一致性与共识算法

2.1 复制协议

当主副本失效时，为了使得算法简单
- 可以人肉切换，只要足够快
  - 还是可以保证较高的可用性
如何保证主副本是真的失效了呢
- 在切换的过程中，主副本又开始接收client端的请求
- 两个主副本显然是不正确的，log会被覆盖写掉
- 我们希望算法能在这种场景下仍然保持正确
假如增加到三个节点呢
- 每次都等其他节点操落盘性能较差
- 能不能允许少数节点挂了的情况下，仍然可以工作
  - falut-tolerance

2.2 共识算法

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

2.3 共识算法的未来

Raft Paxos相互移植
- Rat有很多成熟的实现
- 研究主要关注在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可以选择不同的实现

3. 回到KV

3.1 利用Raft，重新打造KV

RAFT加rocksdb已经逐渐成为分布式KV领域的一种普适性架构，通过整合RAFT log还有rocksdb的WAL可以在一定程度上降低数据的写放大问题。目前该部署方式的应用场景也比较广泛，耳熟能详的比如TiKV、NebulaGraph还有美团的Cellar，在部署方式的选择上主要是基于share nothing架构，其中rocksdb充当了RAFT状态机的角色。

3.2 一致性读写的定义

方案一：

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

3.确定合法的Leadership

方案一：通过一轮Heartbeat确认Leadership（获取多数派的响应）
方案二：通过上一次Heartbeat时间来保证接下来的有段时间内follower不会timeout，同时follower在这段时间内不进行投票，如果多数follower满足条件，那么在这段时间内则保证不会有新的leader产生结合实际情况旋转方案二/三

总结

了解了什么是一致性协议；
以 Raft 为例子了解一致性协议是如何工作的；
了解如何使用一致性协议构建一个 KV 系统；
了解一致性协议的发展方向；

参考

【大数据专场学习资料六】第四届字节跳动青训营 - 掘金 (juejin.cn)

什么是分布式系统？分布式系统的应用是怎样的？ (huaweicloud.com)

远程过程调用 - 维基百科，自由的百科全书 (wikipedia.org)

浅谈分布式一致性协议 | 青训营笔记