Agoda将1.5TB价格缓存迁移至DragonflyDB

Agoda将一级酒店价格缓存从由72个分片组成的Microsoft SQL Server部署迁移到DragonflyDB。该缓存保存约1.5TB易变价格数据，每秒承担约30万次读取和150万次写入。迁移后，在每秒约30万请求的负载下，读取P99延迟降至约8毫秒，较原架构改善约8倍。

原有系统需要应用程序负责在72个SQL Server分片之间路由请求，扩容也必须按照固定硬件规格增加资源，再手动完成分片重映射和数据迁移。团队在2024年初将硬件容量扩大一倍，但不到一年便再次接近上限；与此同时，还要运行独立清理进程删除过期的供应商数据。Agoda首席工程师Clarkson Chang认为，持续为SQL Server堆叠资源并非长期可行且具成本效益的方案。

团队没有只参考公开基准，而是使用真实业务特征评估DragonflyDB。它的无共享多线程架构、Redis兼容能力、集群扩展方式和内置键过期机制，适合大量使用MGET与SET的价格缓存。测试通过memtier_benchmark模拟接近生产环境的1:6读写比例，平均每次MGET涉及约10个键。

迁移过程采用分阶段方式。最初部署的DragonflyDB实例容量为1TB，用于承载热点数据；随着数据自然增长，内存占用逐渐逼近90%的安全阈值。随后团队改为每个集群包含三个分片，并继续扩容，最终覆盖完整的1.5TB数据集。完成调整后，集群每秒写入约160万次，P99延迟约为10毫秒。

在正式承接客户流量前，Agoda先启用双重读取：SQL Server继续响应请求，Price API则异步从DragonflyDB读取对应数据。团队没有逐项比对全部价格内容，而是检查供应商数量和价格数据长度，并将结果转化为Prometheus指标；两项一致率均超过99.9%。之后通过A/B实验逐步放量，数周后完成100%流量迁移，并关闭SQL Server读写路径。

故障处理也同步改造为双集群方案。DragonflyDB集群A、B共同提供高可用能力，每个应用Pod依据本地近五分钟观测数据，独立比较两个集群的缓存命中率，不依赖中央协调器。当差异达到统计显著的10个百分点时，Pod会将其中一个集群标记为不可读；差异缩小到3个百分点以内后才恢复。在一次故障演练中，约40个Pod在约两分钟内完成检测和切换，无需人工介入。

这次替换同时引入了生产一致性校验、受控流量迁移、明确的缓存预热流程和去中心化故障检测。除降低延迟外，新架构还减少了应用层分片路由、手动扩容、过期数据清理以及故障切换维护工作。