带你读《对象存储实战指南》第二章协调和复制2.2复制（二）

3. 数据副本维度的一致性分类

服务端数据副本维度的一致性，定义服务端多个数据副本的不同对象访问表现及相同   对象并发访问表现，如图 2-15所示。2007年，AndrewTanenbaum 在 DistributedSystemsPrinciplesandParadigms一书中定义如下典型类型。

图2-15     数据副本一致性模型对比

·   顺序一致性 ( SequentialConsistency)   。所有请求在多个数据副 本间按相同顺序执行。例如， W1(X)表示对象 X的写请求 1, R2(X)表示对象 X的读请求 2, W3(Y)表示对象 Y的写请求 3,如果数据副本 l按 1~3顺序执行，表示为 Wi(X)-＞凡(X)-> W3(Y), 那么 所有数据副本都必须按该顺序。此时服务端需要进行全局序列化控制，对所有请求进行    访问排序，类似千提供全局的锁，对性能有较大影响。

·  因果一致性(CausalConsistency) 。存在先后 依赖关系 的写（因果关系），必须在所有数据副本中都表现为相同的顺序，而没有因果关系 的写在不同数据副本中 则可以表现为不同的顺序。例如，W1(X)表示对象X的写请求1,   W2(X)表示对象X的写请求2'      如果 昭(X) 和 W2(X) 存在因果关系 ， 并且 川(X)先千 咒(X) 发生 ， 表示为旷 (X)-＞咒(X) , 那么所有数据副本存储的顺序为 W1(X)-＞伲(X)。如果有 W3( Y)表示对象 Y的写请求 3同时发生 ，则数据副本 1写入顺序可以表示为 川(X)-＞咒(X)-＞ 叭(Y),而 数据副本 2写入顺序可以表示为 W1(X)->W3(Y)- > W2(X)。相比较于顺序一致性，因果一致性只需要在相同对象   上控制并发，无须对所有对象的请求做并发控制，类似细粒度的锁，从而提供更好的性能 。

·  最终一致性 ( EventualConsistency ) 。多个数据副本不需要全部同时更新完毕才返回 ，只需要最后将所有数据副本更新为相同值即可。例如，服务端 3个数据副本收到更新对象X的值为 101,  只需要 2个数据副本完成更新就可以返回客户端，第 3个数据副本可能在 lmin后更新 为 101。相比前面的一致性模型要求所有数据副本 必须全部更新完才返回，最终一致性可以降低数据更新开销 ，在某数据副本发生异常时保证时延。

尽管服务端数据副 本为最终一致性，但只要服务端读／写 控制得当，在客户端读请求就只能得到最新写入数据 ，客户端因而有更高的一致性。

2.2.3复制协议 

服务端数据副本维 度的一致性和复 制协议紧密 相关，复制协议控制多个 请求的顺序，以及单个请求的持久化保存成功 的决策。客户端 维度的数据一致性也和复制协议紧密 相关，因为复制协议控制 请求的响应返回逻辑。

2007年，AndrewTanenbaum在 DistributedSystems:PrinciplesandParadigms一书中定义如下典型类型的复制协议： 基千主复制协议 ( PrimaryBasedProtocols) 、客户端写复制协议 ( ClientReplicateWriteProtocols )，如图 2-16所示

图 2-16复制协议对比

从图 2-16中可见，正常情况下，基于主复制 协议完成请求至少需要 2跳（第 1跳由客户端发送请求给主 ( Primary) ,   第 2跳由主并行将请求发给多个副本）。客户端写复制协议完成

请求需要 l跳（客户端并行发送请求给多个副本）。因此客户端写复制协议的时延更 短，但在并发冲突时代价很大。而基于主复制协议增加了时延，但是高效地解决了并发冲突问题。

1.    . 基于主复制协议

基于主复制协议要求所有客户端将请求发给主，由主节点为请求编号，如图2-16  ( a)    所示。W1(X)的序列号为 l、W2(X)的序列号为 2、W3(Y)的序列号为 3，由主将请求发给其他副本， 其他副本根据数据副本 的一致性模型 （顺序一致性、因果一致性、最终一致性）执行请求。

同时主节点控制请求返回的决策 机制。例如，复制副本总数为   N   时，采用最终一致性模型，保证主写入 W1(X)成功，并且主收到其他副 本写入 叭(X)的响应。如果成功 响应的总数?   N/2+1，则返回客户 端 叭(X)写入成功，在后端保证所有副本都写入 川(X)。当节点出现故障时 ，甚至主节点出现故障时 ，基千 投票机制仍然保证能返回最新的 W1(X)写入数据，从而在客户端维度体现为强一 致性。

为了保证基千主复制协议在节点出现故障后能够快速恢复，可以采用日志复制技术，在实现上 YR/RAFT是非常 好的参考算法。

2.    客户端写复制协议

客户端写复制协议要求 客户端部署复制逻辑代码实现数据复制，并且所 有客户端能够并发地执行写入请求。由于不像基千主复制协议那样，由主节点负责请求的顺序性，因此并发冲突是客户端写复制协议的挑战，它只适合并发冲突较少的场景。为了解决并发冲突，客户端写复制协议提供了以下 2种方案。

·   主动复制 ( ActiveReplication)。为了控制客户端并发冲突，客户端指定专用的协调节点生成序列号，由该协调节点负责为所有客户端请求 生成序列号，序列号就是逻辑时钟( LogicalClock)  技术，从而可以保证所有请求的先后顺序。但是该方法 存在扩展性问题，因为所有客户端的请求都需要向它申请序列号，所以非常容易形成系统瓶颈。

·   投票复制 ( Quorum-basedReplication) 。投票 是解决冲突的机制，定义系统的副本总数为 N, 读该对象时成功返回 的副本数为读 投票 RQ，写 该对象时成功返回的副本 数为写投票 WQ，那么 必须满 足如下 条件。

条件 l:  RQ+ WQ>N 

条件 2:  Wq> N/2 

由于RQ+ WQ> N，表示读、写存在重叠，因此能够读到最新数据。同时 WQ> N/2,表示写入超过一半成功 ，因此在副本节点出现故障后 仍然能够让系统最终更新为最新值。如果写入冲突少，则投票复制非常好；如果冲突较多，则将带来复杂的冲突处理，并影响系统性能。

2.2.4存储领域的复制技术应用 

1.    SAN/NAS的复制技术

对于 SAN的块和 NAS的文件，应用需要复制时间点 兀～E的数据，基于复制数据源可以分为如下两种复制类型。

·   基于快照的复制。在 T1时刻对块／文件打快照 1, T2 时刻对块／文件打快照 2, 只需要复制快照 l和快照 2的差量数据。

·   基千 IO日志的复制。记录兀时刻 到 兀时 刻之间的数据更新 IO请求，并把它记录到日志（对于文件系统来说，通常是文件变化日志），然后根据日志进 行数据 复制，技术上类似 VR的日志复制。

从技术角 度分析，基千快照的复制可以节约复制带宽，因为在 兀 时刻到兀时 刻之间可能多次更新相同的数据块／文件（如 1000次更新 100MB文件 A) ，此时就只需要复制 1次

（文件 A只占用 100MB带宽）。基千 IO日志的复制，可以实现更细粒度的时间点的恢复，业界基于 该技术实现持续数据保护( ContinuousDataProtection, CDP) 功能。因为每次更 新数据块／文件都需要复制，所以需要消耗更大的带宽。

针对数据从位置 A复制到位置 B的需求，基于业务定义的恢复点目标 ( RecoveryPointObjective, RPO) 和恢复时间目标( RecoveryTimeObjective, RIO) ，又分为如下 2 种复制方法。

·    同步复制。请求写入时 ，必须同时写入位置A和位置 B的存储，即使位置 A的存储发生故障 ，位置B存储上的数据仍然存在，从而实 现“零＂恢复点目标。

·   异步复制。请求写入时，只要位置A存储成功就 返回客户 端成功，在后端写入位置B存储，在位置 A的存储发生故障后，位置 B存储上的数据还能继续使用 ，但可能几分钟前的数据因未复制到 B而丢失，从而实现分钟级的恢复点目标。

2.    对象存储的复制技术

开源系统 CEPH的对象存储构建在底层 RADOS( ReliableAutonomicDistributed ObjectStore) 技术上 ，其核心是基千 OSD( ObjectStorage Device) 的数据复制，而 OSD采用的就是基千主复 制协议，如图 2-17所示。客户端将所 有写请求都会发送给主 OSD, 由主 OSD向从 OSD复制数据，当所有从 OSD完成写请求处理并成功响应后 ，主 OSD才返回 ，客户端写请求完成。客户端读请求为保证强一致性，也会通过主 OSD来执行，而不能去从 OSD读数据，这尽管会增加主 OSD的负载，但也保证能够 读到最新的数据 。

图 2-17      CEPH的数据复制技术

CEPH的 RADOS采用基于主复制协议保证强一 致性，因为块和文件存储语义上 有迫切的强一致性要求 ，从而方便在此 基础上支待 CEPH块存储、文件存储、对象存储，但是强一致性会带来如下的不足。

·   主节点的性能瓶颈。所有客户端 的写、读请求都会到主节点，再加上主节点还要负责往多个从节点复制数据，因此主节点必然承受更大的性能压力。

·    时延增加。客户端的写请求有 2次网络转发 ，第 1次到主节点，第 2次到从节点，再加上网络往返，会增加请求的时延。

然而对象存储具有不可修改 ( Immutable  )  属性，写入的对象无法更新写，只能全部覆盖写，该特性决定对象的数据可以设计为无须支持并发写，只有对象的元数据存在并发写。   也就是说，在整个数据路径上不需要所有环节 都具备强一致性，所以可以进行如下 优化。

·基千主复制协议、客户端写复制协议分场景组合使用优化性能。对象元数据存在并     发请求访问 ，采用基于主复 制协议实现强一致性，尽管会增加时延，但是会 降低并发请求的处理难度。因为对象存储数据不可以修改，所以采用客户端写复制协议，它只需 1次网络转 发，而且可降低网 络时延。综合起来，元数据的强一致性、数据的不可修改属性，使得对象存储具备强 一致性。

·优化投票，减少错误时的抖动。数据冗余复制时，默认所有冗余数据被成功保存后再 返回成功，但是分布式系统中网络异常、服务器故障、硬盘亚健康是常态，为了减少错误带来的抖动，可允许投票时无须所有冗余数据都完成处理的响应就可以返回成   功，从而减少 异常对时延的影 响。例如，3副本时可 以完成 2副本就返回 （多数完成），RAID和纠删码的N+M冗余(N份数据块  、M份校验块）时可以完成(N+M)/2+1块就返回（校验块多 数完成），从而可以快速响应请求 ，减少抖动。

·   优化读并发，提高带宽。由千对象 数据的不可修改属性，客户端可以并行地 向多个副本读取数据 ，提高访问带宽。例如，客户端读取 3MB数据，可以在主节点读取 1MB数据，在另外两 个从节点并行读取其他 2MB数据，从而快速从三个节点议取数据，比只在一个节 点读取数据性能优化了3倍。

公共 云对象存储服务面 对的场景和负载众多，通常会在不同 的场景对本章所讲解的技术进行优化 ，保证对应场景应用的使用体验。

对象存储的同城冗余存储和跨地域复制特性 ，从功能定义层面类似千 SAN/NAS存储的同步复制和异步复制，它们都关注复制的恢复点目标和恢复时间目标。