Stripe 的零停机数据转移平台以毫秒级流量切换迁移 PB 级数据

在旧金山 QCon 会议上，Stripe 的主任软件工程师Jimmy Morzaria介绍了公司的零停机数据转移平台（Zero-Downtime Data Movement Platform），这是一种能够进行 PB 级数据库迁移的系统，流量切换通常能够在毫秒内完成。该平台支持 Stripe 的基础设施，每秒处理 500 万次数据库查询，同时保持 99.9995%的可靠性，支持每年 1.4 万亿美元的交易。

该平台的迁移过程遵循一个六阶段的蓝图设计，围绕三个原则实现，即保持数据一致性，停机时间比节点故障事件短；最小化对实时查询的性能影响；适应从小型数据集到数十 TB 的分片。

Stripe 的 DocDB 零停机数据转移阶段

数据迁移始于名为“迁移注册（migration registration）”的步骤，该步骤会更新路由元数据服务以注册新的目标分片及其键范围。在数据移动发生之前，这一步建立了数据的预期目的地。

接下来，在批量数据导入（bulk data import）阶段，使用优化的服务传输主数据集，该服务比标准导入提高了十倍的性能。Morzaria 解释说，团队会重新排序插入操作，从而与 MongoDB 的 B 树存储引擎对齐，通过使用每个分片中最常用的索引对项目进行排序，从而将写入性能提高了 10 倍。

在异步复制（async replication）阶段，会有一个专用的复制服务在源和目标分片之间保持双向同步。这一关键阶段会捕获对源数据的持续更改，同时将修改复制回源分片。双向方法允许在出现问题时完全回滚迁移，为财务数据提供关键的安全机制。

零停机迁移中异步复制步骤的架构概览

复制完成后，验证服务在流量切换之前会对源和目标分片之间的数据进行全面的正确性检查（correctness check）。这种验证确保了迁移边界的数据完整性。

实际的流量切换（traffic switch）步骤代表了平台技术上最复杂的阶段。基于 Morzaria 所说的“版本化门控（versioned gating）”，该机制会协调数据库代理服务、协调器、路由服务和复制服务之间的版本更新。

流量切换阶段基于“版本化门控”，从而能够实现最小的停机时间

该过程从客户端应用程序通过版本一的代理查询开始，该代理路由到源数据库，然后，协调器设置版本二并验证复制同步。在确认后，代理会获取新路由，并开始使用版本二进行查询，将流量导向目标数据库，而源分片接收更新以保持回滚能力。整个协调过程在毫秒级到最多 2 秒内完成，使客户难以察觉中断。

迁移注销（migration deregistration）通过清理元数据和销毁迁移基础设施来结束整个过程。

除了水平扩展，Stripe 还使用该平台进行分片合并、跨多个主版本的 MongoDB 版本的升级和租户模型转换。Morzaria 指出，大量的基础投资使工具能够服务于超出其原始设计范围的场景。

Stripe 选择内部构建其 DocDB 平台，而不是使用托管服务，这主要是因为需要保证安全策略执行、可预测的性能以及基于强制配额的多租户支持。到 2020 年，随着单个分片达到数十 TB，公司需要一种系统化的数据移动方法。Morzaria 强调，40%的客户在支付拒绝后会放弃交易，这使得零停机迁移变得至关重要而非可选的功能。因此，鉴于战略重要性、差异化需求和安全需求，自己构建或购买的决策对 Stripe 来说是至关重要的。

原文链接：

Stripe's Zero-Downtime Data Movement Platform Migrates Petabytes with Millisecond Traffic Switches