A brief introduction to chain replication and CRAQ

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

 

 

猜你喜欢

转载自synchronized-lala.iteye.com/blog/2063302