MIT 6.824 CRAQ论文精读

Introduction

现有的为object storage system提供服务的CR机制存在的缺陷：

• 所有read operations都由chain tail node完成，性能较差
• 在负载均衡问题方面没有好的解决方案

本文提出的针对CRAQ的解决措施，将读操作分摊到不同节点，并还能保证系统的强一致性。

Basic System Model

Interface and Consistency Model

object storage system通常为用户提供以下两种基本操作：

• write(objID, V): The write (update) operation stores the value V associated with object identifier ob jID
• V read(objID): The read (query) operation retrieves the value V associated with object id ob jID

两种基本的一致性模型：

• 线性一致性（强一致性）：不同client的读写操作的按照一定的线性顺序执行，且每次的读操作都能获取到数据的最新更新值。
• 最终一致性：读操作可以返回过时的数据结果，但是当所有节点同步完成后，读操作会最终返回最新的结果。

Chain Replication

CR中把所有节点连接成链式结构，head node只负责write request，tail node只负责read request。 当head node收到write request后，会将write request沿着链表向后传递，直至传达到tail node后将结果进行commit。CR一定是强一致性模型，因为所有的read request都有tail node处理，且所有的write request只有到达tail node后才会进行提交并返回，因此write/read的执行顺序均由tail node决定。

CR机制相比于Raft，Zab等强一致性协议的优点是，CR机制将通信开销分摊到了不同的节点之间，不必像Raft、Zab等协议由Leader将信息传输到所有的replicated nodes上。

Chain Replication with Apportioned Queries

CRAQ主要在以下几个方面进行了扩展：

• 每个node会存储<object, list<version>>的相关结构，version是单调递增，且每个version具有dirty和clean两个标志位，每个version初始时为clean。
• 当node收到上游传来的object new version，node会将new version添加到list中：
  – 如果该node不是tail node，则将new version标记为dirty，并向下传递
  – 如果该node为tail node，则将new version标记为clean，表明已提交。tail node会沿链反向发送acknowledge message通知其它node该new version已被提交。
• 当node收到下游传来的acknowledge message，node会将commit version标记为clean，并删除list列表中在其前面的所有version。
• 当node收到read request：
  – 如果该node所存储的最新的version为clean，则可以返回对应的数据
  – 否则，node会询问tail node最新的commit version，并将最新的数据返回。
  
  
  在以下两个不同的场景下，CRAQ都比CR具有更高的吞吐量：
• Read-Mostly Workloads：在这种场景下，大部分的node所包含的最新version都为clean，因此read request可以被均摊到链上所有的节点上。
• Write-Heavy Workloads：在这种场景下，大部分的node所包含的最新version都为dirty，但是作者认为向tail node查询版本号所需要的数据传输量远远小于直接向tail node获取object数据的传输量。

通过以上机制，client可以选择距离最近的datacenter中的node进行读操作。

Consistency Model on CRAQ

为了满足不同的应用需求，CRAQ针对读操作支持三种不同的一致性模型：

• Strong Consistency：默认设计。
• Eventual Consistency：每个node允许读取当前存储的最新version对应的数据。这种情况下，后续的读取操作可能读取到更旧的数据。

Failure Recovery in CRAQ

CRAQ的故障恢复策略与CR相似，类似于双向链表的数据结构，具体策略如下：

• 如果head node故障，则将其后继节点作为新的head node。
• 如果tail node故障，则将其前继节点作为新的tail node。
• 如果middle node 故障，则删除middle node。

Scaling CRAQ

Chain Placement Strategies

在实际应用中，存储的需求可能有以下不同的情况：

• 某个object的大量写操作最终只会体现在一个单一的datacenter中。
• 某些objects只与部分datacenters有关。
• 经常被访问的objects应该进行大量备份，反之访问频率低的object只需要进行少量备份。

CRAQ对每个object设计了两层命名空间来支持CRAQ在datacenter上的不同布局以适应上述的不同需求，每个object包含chain identifier和key identifier两个标识。 chain identifier决定了datacenters中的哪些node构成了chain，key identifier决定了chain的唯一名字。

CRAQ的placement strategy主要有以下几种：

1. Implicit Datacenters & Global Chain Size

接口：{num_datacenters，chain_size}

该方法中，规定了chain中存储的datacenters的数量和每个datacenters中的chain_size。

2.Explicit Datacenters & Global Chain Size

接口：{chain_size，dc1，dc2，…，dcN}

该方法中，每个datacenter中使用相同的chain_size保存副本，head node被分配在dc1中，tail node被分配才dcN中。使用一致性哈希算法来决定每个datacenter中的哪些节点来构成chain。

3. Explicit Datacenter Chain Sizes

接口：{dc1，chain_size1，…， dcN，chain_sizeN}

该方法中规定了每个datacenter中不同的chain_size，允许为每个datacenter分配不同的负载。

在方法2和方法3中，dc1通常被设置为master datacenter。当chain中包含的某些datacenter出现故障时，只有向master datacenter发起写入操作才被允许。 当dc1出现故障时，dc2会成为新的tail node和master datacenter，直至dc1恢复。

CRAQ within a Datacenter

如何在一个datacenter内部署多个chain，有两种方式：

• 使用一致性哈希算法将不同的chain identifier映射到一个相同的头节点中。
• 每个chain包含不同节点，但是当部署在coodinator service如ZooKeepr中时，需要额外的存储信息。但是该方法可以增加系统的容错能力。

CRAQ Across Multiple Datacenters

clinet可以选择距离最近的datacenters读取数据，可以将chain的存储位置进行优化选取，这样可以减少chain跨越的datacenters次数。