CRAQ 论文总结

前言

今天粗看了CRAQ这篇论文，有些小感悟，总结在此，便人便己。

一、概述

这篇论文主要讲的是链式复制（chain replication），或者说更准确些，是对链式复制的改进。和raft、paxo一致性算法中的副本复制不同，链式复制在副本复制的时候是按照一个顺序进行复制。如下图所示。

对于CR系统来说，所有的写操作都是从Head结点开始，然后依次往下传递，直到最后的Tail结点，然后在依次返回。 所有的读操作则由Tail结点负责。

可以看出，对于链式复制来说，其过程相对来说比较简单。而且可以提供强一致性的保证。这种强一致性的保证，简单来说是因为如果Tail结点收到了Write请求，那么就可以保证前面的结点都收到了Write请求,（所以从某种程度上说，Tail结点的状态代表了整个CR系统最旧的状态，如果Tail结点接收到Write请求，那么这个Write请求就已经处于commit状态了。）因此，对于读请求来说，Client从Tail结点读到的数据一定是commit之后的数据。

以上就是基本的CR过程。

---

对于CRAQ(Chain Replication with Apportioned Queries),可以译为分散请求的链式复制。其改进了CR系统，使其在保证强一致性的情况下可以不单单从Tail结点读取数据，而且可以从其他任意结点读取数据。其基本的流程如下：

对于这种改进版的CRAQ是如何保证强一致性的呢？
其实说起来也不复杂，说到底就是一句话，
“你不是Tail 结点保存的是整个系统最旧的状态吗？"
"不是只有Tail结点收到了Write请求，才能表示commit处于提交状态吗？”

那如果中间的某个结点收到了读请求，它就向Tail结点询问一下，最近的状态是什么，然后从自己的状态集合中寻找到对应的状态数据，回复给客户端？

以上只是一种通俗的说法，具体的实现过程还稍微复杂些，需要每个结点保存未 commit 的Object 的版本，然后根据版本是clean还是dirty 来选择是否需要向Tail请求状态。（如果是clean就不需要请求了）

基本的流程如下图所示：

详细的过程可以参照论文，在此就不赘述了。

二、总结

下面简单总结下CRAQ系统，

既然，这个CRAQ这么好，算法过程又简单，又能保证强一致性，那为什么很多系统没有采用CRAQ呢？

对于CRAQ来说，其也有不少缺点：
（1）、它不像raft等majority类型的系统一样，只需要大多数结点同意即可回复client。对于CRAQ,它全部的结点都需要参与复制过程，如果一个结点出现不可达到的情况，整个系统都必须等待。
（2）、CRAQ系统没有很好的解决“brain split”问题。（虽然额外补充zookeeper类似的 configuration manager 可以从某种程度上解决这个问题，但毕竟带来了复杂性）
…

---

最后说说，学习CRAQ系统的一点小感悟：
（1）、在我看来，CR系统是强制性的使复制过程按照一定的顺序，来简化达到强一致性的难度。从一个更高的层次上说，其对一致性系统添加了限制，使得其变成了线性结构，而不是像raft 那样的星型结构。
（2）、对于给一个对象来说，可以给其加上一个版本号作为其属性字段。有个这个字段，则可以更好的跟踪对象的状态变化，尤其是在锁系统中（比如说，在Lock UnLock 然后 Lock, 在第二个Lock的时候，可以通过版本号字段判断对象是否在第一个Unlock的时候状态被其他线程修改了）。

---

最后的最后，还有两个问题没搞懂，希望有朋友了解的，可以解惑一下。
（1）、Tail结点向前传递ACK 是顺级传递的，传到Head结点之后，由Head结点回复CLient。会不会存在这样一种情况：即ACK消息还未传到Head结点之时，后面的结点已经开始向下一个读请求回复了？这样会有什么影响吗？
（如下图所示，ACK消息刚传到N2时，N3已经回复下一个读请求了）

（2）、Tail的ACk 消息还有必要按级传递吗？直接通过广播消息不行吗

说实话，我对对分布式的内容了解的也不是很深，以上部分如果有出错的，请不吝赐教。