LSMT存储引擎浅析 | 青训营笔记

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

上节课我们讲解了LSM Tree,这是目前大部分的存储系统都运用的存储结构，同时也讲了以往常常使用的B-Tree，也举了几个例子，今天我们来讲解一下分布式一致性协议。

分布式系统

分布式大家都很熟悉了，这里就不多赘述了。现如今的分布式系统面临着一个巨大的挑战，那就是数据规模越来越大，数据增长的速度也越来越快，对机器和系统的要求越来越大。同时对服务器的高可用性要求越来越高，对快速迭代的业务要求系统足够易用，要减少上手的难度

理想的分布式系统要做到高性能、正确、可靠。要可扩展、低时延、高吞吐，同时也要有一致性、易于理解，具有容错、高可用

HDFS的结构可以用一图来解释：

小结

• 背景：数据规模的不断增加，我们需要大规模分布式系统
• 维度：对于一个分布式系统，希望能有哪些特征
• 从KV入手，看看我们如何满足分布式系统的要求

一致性与共识算法

我们具有一台分布式系统，对于高可用的要求是很高的，那么如果我们有两台、三台，这个要求感觉上好像可以减少。那么我们如何同步这几台机器之间的状态呢？

如果我们让多台机器之间都能接受请求，那么势必就会增加成本，所有我们就选择主副本定期拷贝全量数据到从副本，即主副本把所有的操作打包成log(这里的log写入都是持久化的，保存在磁盘上)，然后应用包装成状态机，只接收LOG作为Input,主副本确认log已经成功写入到副本机器上，当状态机apply后，返回客户端

关于读操作

方案一：直接读状态机，要求写操作进入状态机后在返回client 方案二：写操作复制完成后直接返回，读操作Block等待所有pending log进入状态机

如果不遵循上述两种方案的话可能存在刚刚写入的值读不到的情况

复制协议

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

小结

• 使用副本的方式设计了KV
• 了解了什么是一致性
• 了解了什么是共识算法
• 设计一个正确且容错的一致性是一个难题

一致性协议案例：Raft

The Parttime Parliamen by Lamport 1989,也就是人们提到的Paxos，基本上就是一致性协议的同义词，该算法的正确性是经过证明的，但Paxos是出了名的难以理解，算法整体是以比较抽象的形式描述，工程实现时需要做一些修改

Raft是一种更为简单方便易于理解的分法，主要解决了分布式中的一致性问题。相比传统的Paxos算法，Raft将大量的计算问题分解成为了一些简单的相对独立的子问题。它使用了RSM、Log、RPC的概念，直接使用RPC对算法进行了描述，同时使用了随机额方法减少约束

Raft扮演的角色可以一言蔽之

Raft安全性

对于Term内的安全性，在任何<term,index>位置上，至多只有一条log 对于跨term的安全性，如果一个log被标记commited，那这个log一定会在未来所有的leader中出现leader completeness

课程总结

• 了解了一致性的定义
• 了解什么是共识算法
• Raft的基本工作原理
• 一致性协议的未来方向