深入raft-通过etcd的实现理解raft
简述
raft作为最易懂的生产级分布式一致性/共识协议,是大部分新生代分布式系统的基石:etcd、consul、TiDB及阿里、Google、华为等大厂自研的很多系统都用了raft。而raft有些概念,会让初学者感到迷惑。本文结合raft在etcd的实现来帮助初学者理解其部分概念。
注:本文适合对raft有初步了解的同学
raft初心
客户端可放心地将集群(含有多个节点)当作1个节点来使用:这是所有分布式一致性协议的初心。只有多个节点的数据都是一致时,客户端才能把它们当成1个节点对待,记住这一点,我们可更加理解很多细节为何是那么设计。
Replicated state machine
比较学术的词语。初学者容易混淆这个概念,以为raft提到的leader、follower等state就是Replicated state machine(后续简称rsm)的state。其实rsm是指节点存储的数据,如下图蓝色部分:
etcd用BBolt存数据,下图红框是etcd的rsm(即BBolt):
注:以上图片来自Jingyi Hu在KubeCon China 2019的分享。
按这个思路,TiKV用RocksDB存数据,TiKV的rsm就是下图红框部分:
Commit和Apply
- Commit是针对Raft log(Replicated WAL)的操作,表示新增请求已存入集群多数节点的raft log
- Apply是针对RSM到操作,发生在commit之后,表示将新增请求转发到RSM处理
下图是etcd客户端一次请求,在etcd各节点的内部流转的示意图,其中蓝色步骤是commit,红色是Apply。读者仔细阅读可更深刻理解commit和apply区别。
Quorum
属于配置参数。一个Raft Log 被至少 quorum 个节点接受,我们就可以认为这条日志被 committed 了。一般来说3副本(replica)时quorum=2,5副本时quorum=3