A brief introduction to chain replication and CRAQ

本文深入介绍了ChainReplication和CRAQ两种在分布式存储服务中保证高可用、高吞吐量同时保持强一致性的技术方案。详细阐述了ChainReplication的实现原理、数据复制策略、故障处理机制以及CRAQ的优化点,包括多版本对象存储、读取优化和一致性保证。并通过流程图展示了不同节点故障时的服务强一致性保障。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

A brief introduction to chain replication and CRAQ

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

一、关于Chain Replication

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

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

前提:
  1. query、update是按某种顺序执行的
  2. 更新操作生效后,会被后续的查询感知到
  3. 查询操作幂等,更新操作不保证幂等。客户端的更新操作没有收到落地反馈需要重发,客户端不区分发起失败与服务处理失败。由于更新不幂等,客户端需要等待发起的更新操作的反馈,需要控制请求流量。
  4. 一些名词的简介例如:
  • Pedding:待处理的请求序列;
  • Sent:收到请求本地完成但TAIL还没回复完成的请求序列;
  • Hist:收到请求并TAIL也完成的请求序列

1.1. 数据 relication 采用 Chain Replication

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

1.2. Master 主要功能

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

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

1.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 )

2.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.2. 流程图如下:

 

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值