A brief introduction to chain replication and CRAQ

本文介绍的是在保证高可用和高吞吐的情况下，不以牺牲强一致性为代价提供分布式存储服务。

一、关于Chain Replication

CAP:对于分布式存储服务，不可能同时满足可用性、一致性和分区容错性（数据分布性的大小对系统的正确性、性能的影响）。由于分区容错性是分布式系统的基本需求，所以，分布式系统一般在可用性和一致性中做权衡。

链式复制期望从Replication的角度，保证系统的高可用和强一致性，其设计思路如下：

前提：

1. query、update是按某种顺序执行的

2. 更新操作生效后，会被后续的查询感知到

3. 查询操作幂等，更新操作不保证幂等。客户端的更新操作没有收到落地反馈需要重发，客户端不区分发起失败与服务处理失败。由于更新不幂等，客户端需要等待发起的更新操作的反馈，需要控制请求流量。

4.一些名词的简介例如：

 

     Pedding：待处理的请求序列；

     Sent：收到请求本地完成但TAIL还没回复完成的请求序列；

     Hist：收到请求并TAIL也完成的请求序列

 

1.数据relication采用Chain Replication

   a. 更新：只能发生在数据头节点,然后更新逐步后移，直到更新到达尾节点，尾节点逐步向前确认已经完成更新，并由尾节点向客户确认更新成功。写操作的向后传播是顺序的，即：每个节点上已完成的更新操作是其predecessor节点的子集。
   b. 查询：为保证强一致性，客户查询只能在尾节点进行

2. Master主要功能

   a. 检测数据节点失败；
   b. 在新增或删除节点时，通知数据节点其新的predecessor及successor；
   c. 告知client 链表的头节点和尾节点。

在作者的原型系统中，采用paxos协调master及其replicas，避免单点故障。

3. 故障

  master节点通过paxos算法保证服务一致性，只讨论数据节点故障。
  在出现故障时，优先考虑一致性，而不是可用行，原文如下：
   Servers are assumed to be fail-stop:
    • each server halts in response to a failure rather than making erroneous state transitions, and
    • a server’s halted state can be detected by the environment

 

   我们看下不同节点故障，如何保证服务的强一致性
   a. Head节点故障：successor节点成为新的Head节点，Head节点中已传播的更新继续传播，未传播的更新可以反馈给用户更新失败，不影响整体服务的强一致性。
   b. 中间节点故障：master故障节点的successor（S+）更新其predecessor，S+ 应答并告诉master S最近发送的update请求的sequence（存放TAIL可能还未处理的update请求，升序的），及通知故障节点的predecessor节点更新successor并知道从哪个sequence开始往S+发送数据，并不影响一致性。流程如下图，S发生故障。

   c. Tail节点故障：Tail节点的predecessor节点成为新的TAIL节点，由于这个predecessor节点已有更新是TAIL节点的超集，从用户的角度看，数据变多了，个人理解在此故障处理完后这个新的Tail可以将原先的Tail没有处理完但是自己已经处理完的请求直接发给client，并不影响用户读一致性。

     Extending a Chain：故障节点被master从chain中摘除后，为了可靠性，需要扩展chain的节点。选择一个节点T+加入chain的尾部，将Hist_T（已处理完update请求的序列）的数据存储到T+。在此操作的同时，T可以继续处理client端的query请求，以及它的perdecessor的update请求并将之放到sent_T（存放TAIL可能还未处理的update请求）。当Hist_T=Hist_T+ 及sent_T的并集时，通知T不再是Tail节点且不再为client提供query处理（更好的方式是将此请求发送给T+），将sent_T的请求都发到T+，master通知新的Tail是T+。通知clients之后的query请求直接发送到T+。

     Tail落地后将ack反向返回到head,各层节点更新Hist和Pending 集合

以上内容有借鉴：链式复制

 

二、关于CRAQ(Chain Replication with Apportioned Queries )

1.基本操作流程

     CRAQ流行于读为主的分布式存储架构中，它通过允许向任意的数据节点发送读请求来增强读的读取速率，同时它依旧提供强一致性的保证。

     相对于Chain Replication的扩展主要有如下：

1. 每个数据节点会存储多版本的object，此版本号为递增且有clean或dirty的状态信息。初始化版本号的状态为clean。
2. 当某个节点接收到一个object的修改操作，即此object带新的版本号。节点append这个最新的版本到它的object list。1）如果这个节点不是Tail节点，将此版本状态标记为dirty，并将请求发送给successor；2）如果是Tail节点，将此版本号提交，向其他节点发送可以提交此版本的ack。
3. 当此ack发送到其他节点的时候，此节点将ack中的提到的版本号状态置为clean，并可以删除之前版本的object。
4. 当某个节点收到read请求的时候：1）此版本是clean状态，则将value返回给client；2）否则，此节点将请求Tail获知最近提交的版本号，然后回复给client。

2.流程图如下：

 本文有3幅图来自Object Storage on CRAQ High-throughput chain replication for read-mostly workloads