Delta：基于链式复制的高可用、强一致性存储系统（2022年）

# Delta：采用链式复制的高可用强一致性存储服务 来源：https://engineering.fb.com/2022/05/04/data-infrastructure/delta/ 多年来，Meta投资了多种存储服务产品，以满足不同的应用场景和工作负载特性。在此过程中，我们致力于精简并融合存储领域的各类系统。同时，为关键软件包工作负载提供专用解决方案能让各方更满意。这一方案的实现对于我们的灾难恢复和引导策略至关重要。正是基于这一认识，加上Meta构建和分发工件对存储的业务需求，催生了全新的对象存储服务——Delta。 请参考Delta在Meta基础设施栈中的定位（如下图所示）。它位于最底层，为上层基础设施的可用性和可恢复性提供基础原语。对于引导系统而言，只有当复杂性能提升解决方案的可靠性时才值得引入。我们仅需最低限度地关注方案的性能和效率。引导系统的另一个考量因素是引导过程本身——工程师通过访问一组小型机器来恢复其余基础设施，这一流程帮助我们快速恢复产品服务。此外，引导数据需要备份以应对灾难发生时的恢复需求。 本文将探讨Delta的设计目标、架构核心理念、生产应用场景、作为恢复服务的发展历程以及未来工作方向。 ## 什么是Delta？ Delta是一个简单、可靠、可扩展、低依赖的对象存储系统。它仅提供四种高层操作：上传（put）、获取（get）、删除（delete）和列表（list）。Delta通过牺牲延迟和存储效率来换取简单性与可靠性。作为水平扩展系统，Delta仅依赖最少的外部组件，并为软依赖配置了相应的故障转移策略。 Delta**不是**： - **通用存储系统：** Delta的核心原则是韧性与数据保护，专为低依赖系统设计使用。 - **文件系统：** Delta作为简单的对象存储系统，不暴露POSIX等文件系统语义。 - **极致优化存储效率的系统：** 以韧性为首要原则并聚焦关键系统，Delta不以优化存储效率、延迟或吞吐量为目标。 ## Delta的架构 Delta将链式复制技术投入生产，这是一种协调故障停止型存储服务器集群的方法。它旨在支持大规模存储服务，在不牺牲强一致性保证的前提下实现高吞吐量与高可用性。 在深入探讨Delta如何利用链式复制复制客户端数据之前，我们先了解链式复制的基础知识。 ### 链式复制 链式复制从本质上将服务器以线性方式组织成链。类似链表结构，每条链包含一组主机，这些主机冗余地存储对象副本。 每条链由一系列服务器组成，首台服务器称为头部（head），末台称为尾部（tail）。下图展示了包含四台服务器的链式示例。所有写请求定向至头部服务器，更新沿链从头部流向尾部。当所有服务器持久化更新后，尾部向写请求返回响应。读请求仅定向至尾部服务器。客户端从链尾读取的数据已在整条链上复制完成，从而保证强一致性。 ### 链式复制与法定数复制的对比 了解链式复制基本原理后，我们来探讨其与其他主流复制策略的差异： - **存储效率：** 链式复制并非最高效的存储复制策略。它在链中所有主机上存储完整的冗余数据副本。更高效的方法可通过纠删码技术智能复制数据片段。 - **容错能力：** 在最优桶布局中，链式复制能提供与法定数复制机制相当或更优的容错能力。因为包含`n`个节点的链在不超过`n – 2`个节点故障时仍可保持可用。相比之下，基于法定数的复制系统需要至少`w`台主机处理写操作，`r`台主机处理读操作（`w`和`r`分别代表写法定数规模和读法定数规模）。 - **性能表现：** 在某些复制策略（如主备复制）中，所有备份服务器均可处理读操作，从而提升读吞吐量。而原生链式复制仅允许尾部服务读请求（我们已对此优化，后文将详述）。与法定数复制机制类似，链式复制中所有写操作均定向至主节点（链头）。但链式复制仅在整条链确认更新后才响应写请求，因此平均写延迟通常高于法定数复制系统。 - **法定数共识：** 基于法定数的系统需要复杂的共识与领导者选举机制来维持法定数。而链式复制系统的法定数共识范围可简化为链-主机映射关系。例如，链头始终作为处理写操作的领导者，无需显式选举。 综合以上差异，链式复制虽然在跨机器复制数据时存储效率较低，且平均写延迟高于法定数系统（仅当整条链持久化更新后才认为写入成功），但其简单性以及同等容错与一致性保证使其仍具价值。 ## Delta桶的构造 了解链式复制基础后，我们来探讨Delta如何利用它在多台服务器间复制数据。 每个Delta桶包含多条链。每条链通常由四台或更多服务器组成（数量取决于所需复制因子）。每条链作为独立的副本集，服务于数据分片和流量，可视为客户端数据集的逻辑分片。特定链中的服务器会分散部署在不同故障域（如电力、网络等）中。这种分布方式确保在单个或多个故障域不可用时，客户端数据仍能保持持久性和可用性。我们维护桶配置作为权威的链-主机映射关系，当增减服务器或链时会相应更新配置。 当客户端访问Delta桶内的对象时，系统通过对象名称的一致性哈希选择目标链。写操作始终定向至目标链的头部：头部将数据写入本地存储，并转发至链中下一主机。仅当链末主机持久化存储数据后，写操作才被确认。读操作始终定向至链尾，这确保只有完全复制的数据可被读取，从而保证强一致性。 Delta通过向桶中添加新服务器并智能重平衡链来支持水平扩展，此过程不影响服务可用性和吞吐量。例如，采用策略让持有最多链的服务器将部分链迁移至新服务器以实现负载均衡。新的桶布局仍需遵循故障域分布原则，并在重平衡链和扩展桶容量时应用。 ## Delta的故障与恢复模式 故障可能源于主机宕机、网络分区、计划维护、操作失误或其他意外事件。在链式复制的适当实现中，我们假设服务器为故障停止型（fail-stop），即： - 每个服务器在故障时会停止响应，而不会进行错误的状态转换； - 服务器的停止状态可被环境检测。 考虑包含`n`条链的Delta桶，每条链包含>1台主机。当任何主机行为异常或与网络隔离时，共享该链的上下游兄弟主机会检测到异常并上报。 兄弟主机可通过简单的心跳检测，或通过遇到链上/下游确认/请求传输失败来发现异常主机。当多台主机怀疑特定目标主机异常时，该主机会被踢出所有相关链并送修，桶配置也会相应更新。 检测主机异常行为时需进行以下决策与权衡： - **超时设置：** 我们通过多次性能测试确定最佳超时阈值。在怀疑主机异常前，需谨慎评估链中各连接间的超时时间。超时不宜过短（避免误判瞬时网络问题），也不宜过长（否则会影响操作延迟，甚至导致客户端因等待响应而超时）。 - **可疑主机投票阈值：** 需确定多少台主机投票认定目标异常后，才将其踢出链。阈值不能为1（避免链中两台主机相互投票导致双故障），也不能过大（否则异常主机会长期滞留集群并影响服务性能）。每台主机属于多条链，与上下游节点保持频繁连接，因此将投票阈值设为2对我们效果良好。此外，我们已实现故障主机修复流程自动化，这允许我们配置敏感阈值并容忍一定误报率。 故障主机恢复后，可重新加入之前所在的桶内所有链。新主机始终添加至链尾。重新加入时，主机需同步其离线期间链上的所有更新：扫描上游主机的对象，复制缺失或版本过期的数据。值得注意的是，在重建期间该主机仍可接受上游新写入，但在完全同步前需将读请求转发至上游。 该流程同样适用于引入新容量至Delta桶。 ## Delta的发展历程 ### 分片查询 从上述描述可见，链式复制在服务读请求时存在主要缺陷： - 尾部作为同时处理读写的唯一节点，可能成为热点； - 所有读请求由链尾处理限制了读吞吐量。 为缓解这些限制，我们可采用**分片查询链式复制**技术，允许链中所有节点处理读请求。 基本思路：每个节点处理读请求，但在响应前进行关键检查：验证所请求对象的本地副本是否为“干净”状态（即已被链中所有服务器提交）。若检测为“脏”状态（即对象未在所有服务器复制完成），服务器可返回对象的最终已提交版本，确保客户端仅获取经全链提交的版本，从而保留链式复制的强一致性保证。尾部节点作为特定对象最新干净版本的权威来源。 如上所述，链中每个非尾部连接需向链尾发起额外网络调用以获取干净版本，再响应客户端读请求。这一额外调用价值显著：它使读吞吐量与链带宽随链长线性扩展。此外，对象版本检查调用的成本远低于实际客户端读取，因此不会显著影响客户端延迟。 ### 自动修复 尽管硬件故障或网络分区看似罕见，但在大规模集群中频繁发生。因此，故障检测、主机修复与恢复流程应实现自动化以减少人工干预。 我们构建了控制平面服务（CPS）负责Delta集群的自动化管理。每个CPS实例监控指定的Delta桶列表，主要职责包括修复存在缺失链接的链。 修复过程中，CPS采用以下技术以实现效率最大化： - 修复桶时，CPS必须维持所有链的故障域分布，确保主机均匀分布于各故障域。 - CPS需保证所有服务器的链分布均匀，避免部分服务器因承载过多链而过载。 - 当链缺失链接时，CPS优先尝试用原始主机修复而非新主机。因为相比修复后主机的部分链内容同步，向新主机同步全链内容计算开销更大。 - 主机加入链前，CPS会执行详细健全性检查，确保健康主机被重新加入桶。 - 除管理桶内服务器外，CPS还维护健康备用主机池。当链缺失超过50%主机时，CPS会向该链添加全新备用主机，防止严重主机不足的链影响桶可用性。在此过程中，CPS将尽力应用上述原则。 ### 全局复制 在Delta初始实现中，当客户端因数据安全考虑需在多区域存储对象时，需向各区域分别请求。这对用户显然不理想。Delta用户不应承担追踪对象位置的责任，同时需具备...