Chain Replication 论文阅读

本文最后更新于:7 个月前

前言

对于 raft、paxos 这类共识算法,leader 节点需要将客户端的写请求编号并发送给所有 follower 以期望达成共识,这一定程度上导致写性能无法随节点个数线性增长,因为 leader 同步的数据量会随着节点数的增长而增长,从而使得主节点承载着更大的压力,往往成为了瓶颈。

2004 年,Chain Replication (之后简称 cr)方案被提出,其也能够保证多副本间的线性一致性。具体思路是每个节点只负责向后续节点进行备份,从而将压力分摊到整个链上。因为其与上述的共识协议相比,其每个节点的写入负载几乎一致,从而不存在单节点负载很高影响性能的问题。

以上都是论文中的吹的说法,我个人持怀疑态度:首先 raft 的 leader 向所有 follower 发送是并行的,而 cr 是串行的,因此就性能上,个人不觉得后者会更快;其次随着节点数增多,虽然 raft 的 leader 负载会更大可能增大延迟,但是 cr 一定会增加延迟(多一轮 RTT),因此就写扩展性上,我也没看到 cr 有什么明显的优势。至于说什么拆分读写负载,只能说 raft 早就提出 follower read 的解决方案了,cr 做的也不过是把读放到了另一个节点上,并无扩展性,craq 才相对做到了一定程度的读性能的可扩展性。

但不论如何,很多顶级产品比如 Ceph,Parameter Server 等都用到了 cr,所以了解一下 cr 还是有必要的,其能够拓宽我们对共识协议的了解边界。毕竟其实现线性一致性的方式还是比较巧妙的,而且设计也比较简单,没 raft 那么多 corner case。

内容

有关 CR,可以参考此 博客
有关 CRAQ,可以参考此 博客 和此 博客

CR 能够以很简单的设计实现多副本的线性一致性,不过其不能自己处理脑裂和分区的问题,因而还需要另一个高可用的配置服务器集群来协作提供高可用服务。

CRAQ 相比 CR 做了读性能优化,使得读性能可以线性扩展且保证线性一致性。

总结

简单记录了 cr 和 craq 的工作原理。

相关资料