Agoda 将其一级酒店价格缓存从采用 72 个分片的 Microsoft SQL Server 部署迁移至 DragonflyDB。DragonflyDB 是一种内存数据存储系统，此次迁移旨在应对不断增长的读写量，并简化扩容。该缓存存储约 1.5 TB 的易变价格数据，每秒处理约 30 万次读取和 150 万次写入。迁移后，Agoda 报告称，P99 读取延迟改善了约八倍；DragonflyDB 在每秒处理约 30 万个请求时，P99 延迟约为 8 毫秒。
Agoda 此前的架构需要由应用程序在 72 个 SQL Server 分片之间进行路由。扩容需要按预先规定的硬件增量进行，并手动重新映射分片和迁移数据。团队在 2024 年初将硬件容量翻倍后，不到一年又接近容量上限。不断增长的工作负载还需要一个单独的清理进程来删除过期的供应商数据。
Agoda 首席工程师 Clarkson Chang 指出了这一问题：
很明显，继续为 SQL Server 增加资源并不是一种可行或具有成本效益的长期策略。
团队根据实际工作负载评估了 DragonflyDB，而非仅依赖公开的基准测试。其无共享、多线程架构、Redis 兼容性、基于集群的扩容方式和内置的键过期功能，与大量使用 MGET 和 SET 的价格缓存工作负载相吻合。Agoda 首先使用 memtier_benchmark 复现接近生产环境的 1:6 读写比例，以及平均涉及 10 个键的 MGET 操作。
DragonflyDB 集群模式（来源：Agoda 博客文章）
迁移是有意分阶段进行的。Agoda 最初部署了一个 1 TB 的 DragonflyDB 实例来存储热数据，但数据自然增长，使数据集逐渐接近 90% 的内存安全阈值。随后，团队改用每个集群三个分片的设计，并扩展 DragonflyDB，使其容纳完整的 1.5 TB 数据集。最终的集群每秒处理约 160 万次写入，P99 延迟约为 10 毫秒。
在切换客户流量之前，Agoda 引入了双重读取。SQL Server 继续提供请求服务，同时 Price API 异步从 DragonflyDB 获取相应数据。团队没有比较完整的价格数据，而是检查供应商数量和价格数据长度，并将结果作为 Prometheus 指标输出。这两个维度的一致率均超过 99.9%。
随后，Agoda 通过 A/B 实验逐步将客户流量转移到 DragonflyDB。几周后，100% 的流量完成迁移，SQL Server 的读写路径也随之停用。
最后一项架构变更针对故障处理。DragonflyDB 集群 A 和 B 共同提供高可用性。每个应用程序 Pod 不依赖中央协调器，而是根据本地五分钟的观测数据，独立比较两个集群的缓存命中率。如果两者出现具有统计显著性的 10 个百分点差异，就将其中一个集群标记为不可读取；恢复则要求差异缩小至 3 个百分点以内。在一次故障模拟中，约 40 个应用程序 Pod 在大约两分钟内检测到故障并完成故障切换，无需人工干预。
维护 B 集群期间的缓存命中率跟踪（来源：Agoda 博客文章）
Agoda 在迁移数据存储系统的同时，实施了生产数据一致性检查、受控的流量迁移、明确的缓存预热机制和去中心化的故障检测。最终成果不仅是更低的延迟，还包括更灵活的扩容模式，以及更少的过期数据处理和故障切换维护工作。
原文链接：https://www.infoq.com/news/2026/09/agoda-price-cache-dragonflydb/