CR论文分析（Lec9）

一、目的

1.Zookeeper是基于raft的，CRAQ（Chain Replication with Apportioned Queries）是另外一种不同于raft的复制方法。
Zookeeper为了能够从任意副本执行读请求，不得不牺牲数据的实时性，因此也就不是线性一致的。CRAQ却可以从任意副本执行读请求，同时也保留线性一致性。
CRAQ用的技巧和zookeeper是类似的，它通过将读请求分给任意replica来提高读请求的吞吐量。
2.论文提出了两个重要特点：一是通过复制实现了容错，二是通过链复制（Chain-Replication）实现了与Raft不同的复制方式。
3.在实际的生产系统中链复制也有比较多的应用，例如在HDFS中就使用链复制来完成块数据的复制。此外CRAQ还能利用所有节点处理读请求提升系统的吞吐性能并且还能保证线性一致，确认让人着迷。

二、链复制CR——CRAQ的前身

1.CRAQ是对CR的改进拓展。
2.CR与Raft都能保证线性一致，但是采用了与Raft不一样的拓扑结构。Raft是由Leader节点将log并行的复制到其他Follower节点，而CR是将所有的副本按照一定顺序组成一条链，第一个副本叫做HEADER,最后一个叫做TAIL。

3.当执行写请求时客户端将写请求发往HEAD节点，在HEAD节点存储完成后继续向下传播，直到将写请求传递到TAIL节点为止，当TAIL节点处理完后就可以认为本次写请求已经提交（Commited），并由TAIL节点完成通知。
4.从性能上看，在CR中由于写请求都是往HEAD节点写，读请求都是从TAIL节点读，相对于RAFT的读写都在LEADER上完成，实际上CR从某种程度上来说分担了读写的压力。但是对于写请求有一个最大的问题就是写延迟，因为CR需要将写请求从HEAD节点依次在链中传递到TAIL节点才算是提交，所以CR的写延迟就是各个副本的写延迟之和。在CR中只要其中一个节点出现问题，最严重的情况会导致整个服务不可用。
5.在CR中，写请求总是从HEAD节点依次传播到TAIL节点。传输有以下情况，一是传递到TAIL节点完成提交，这是正常情况；二是传输过程中某个副本出现故障导致该副本的前驱节点都接收到了写请求，副本的后驱节点都没有收到请求，导致写请求最后无法顺利传递到TAIL节点完成提交。
6.故障恢复分三种情况：（1）head故障（2）tail故障（3）中间节点故障
（1）如果HEAD出现故障，作为最接近的服务器，下一个节点可以接手成为新的HEAD，并不需要做任何其他的操作。
（2）如果TAIL出现故障，处理流程也非常相似，TAIL的前一个节点可以接手成为新的TAIL。所有TAIL知道的信息，TAIL的前一个节点必然都知道，因为TAIL的所有信息都是其前一个节点告知的。
（3）中间节点出现问题就去除故障节点。故障节点的前一个节点或许需要重发最近的一些写请求给它的新后继节点。
7.Chain Replication与Raft进行对比，有以下差别：
（1）从性能上看，raft的leader 需要将数据发送所有副本,Chain Replication只需要发送后继节点 ,所以性能瓶颈来的更晚
（2）raft 的读写都会从leader, CR,写请求走head ,读请求是tail节点发的,所以压力分摊了
（3）故障恢复，Chain Replication也比Raft更加简单,这是主要动力
8.在一个长度为N的链上，理想情况下最多允许N-1次故障。
9.CR无法抵抗网络分区，无法抵抗脑裂。

三、CRAQ（Chain Replication with Apportioned Queries）

1.CRAQ是对CR的改进拓展，一是解决CR存在脑裂的问题，二是能将所有节点都用于处理读请求，提升系统的吞吐量。
2.通常CR都会配合外部权威（External Authority）来决定各个副本的状态，以及确定链的组成（哪些节点组成，什么样的编排顺序）。这个外部的权威通常称为配置管理器（Configuration Manager），是容错的，也不会受脑裂影响。通常配置管理器会基于raft或者paxos，在CRAQ中使用zookeeper来做这个配置管理器。
3.配置管理器的主要目的是检测各副本的活性，如果配置管理器认为副本挂了将会重新生成一套新的配置。
4.因此客户端只需要访问配置管理器既可得到head、tail节点等相关信息。
5.CRAQ能够在保证线性一致的情况下提升读请求的吞吐量，其实CRAQ采用了一个多版本的方案。（读请求在其他节点均返回和tail节点一致的版本）

6.成员变更
（1）对于正常的写传播，CRAQ节点遵循前面的协议。
（2）在恢复过程中，有时需要第二种传播方式，即反向传播。例如链表节点可能会在完成向后传播到头部节点之前失败。由于这些可能的故障状况，当新节点加入系统时，新节点会从其前任节点接收传播消息，并从其后继节点接收反向传播消息，以确保其正确性。新节点拒绝客户端对特定对象的读取请求，直到其与后继对象达成协议为止。

四、总结

1.链复制算法通过限定拓扑结构降低了达成一致性难度，也有着更好的故障恢复能力，这是比较吸引人的点，但是无法抵抗脑裂、网络分区，必须要引入外部权威来解决，例如像vmware ft里面的test server。
2.CRAQ提供了一个提升吞吐率的通用方法，那就是加版本号，这或许是后续对某些场景的优化突破点。
3.某些场合可能更适合用Raft或者Paxos，因为它们不用等待一个慢的副本。而当有一个慢的副本时，Chain Replication会有性能的问题。