Chain Replication 论文阅读
本文最后更新于：3 年前
前言
对于 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 的工作原理。