Agoda将一级酒店价格缓存迁移至DragonflyDB，性能提升与架构优化

在数字化转型浪潮中，企业对数据存储系统的性能和可扩展性提出了更高要求。近期，旅游平台 Agoda 宣布将其一级酒店价格缓存系统从 Microsoft SQL Server 迁移到内存数据库解决方案 DragonflyDB。这一迁移不仅提升了系统性能，还优化了整体架构设计。

核心迁移背景

Agoda 的一级酒店价格缓存系统此前采用 SQL Server 部署，由 72 个分片构成。该系统存储约 1.5 TB 的易变价格数据，每秒需处理约 30 万次读取和 150 万次写入操作。然而，随着业务规模的扩大，SQL Server 架构逐渐显现出局限性。团队在不到一年内两次扩容硬件容量，但仍接近性能上限。此外，不断增长的工作负载需要额外的清理进程来删除过期供应商数据，进一步增加了运维复杂度。

迁移决策与技术考量

Agoda 首席工程师 Clarkson Chang 表示，继续为 SQL Server 增加资源已不再具有成本效益。团队根据实际工作负载评估了多种方案，最终选择了 DragonflyDB。DragonflyDB 的无共享、多线程架构，以及 Redis 兼容性、基于集群的扩容方式和内置键过期功能，与 Agoda 的价格缓存工作负载高度契合。

具体而言，DragonflyDB 在以下方面展现出优势：

性能提升：迁移后，P99 读取延迟从原来的水平降低至约 8 毫秒（SQL Server 下约为 64 毫秒），改善约八倍。
简化扩容：无需按预先规定的硬件增量进行扩容，且数据迁移过程更加自动化。
减少运维负担：内置键过期功能替代了原有的清理进程，降低了运维复杂度。

迁移实施过程

为了确保平稳过渡，Agoda 采取了分阶段迁移策略。首先，团队使用 memtier_benchmark 复现接近生产环境的 1:6 读写比例，并测试 MGET 操作的性能。随后，部署了一个 1 TB 的 DragonflyDB 实例用于存储热数据，但随着数据自然增长，团队最终扩展至完整的 1.5 TB 数据集。

在切换客户流量之前，Agoda 引入了双重读取机制。Price API 同时从 SQL Server 和 DragonflyDB 获取数据，并通过 Prometheus 指标检查供应商数量和价格数据长度的一致性。当一致性超过 99.9% 后，团队逐步将流量转移到 DragonflyDB。几周后，100% 的流量完成迁移，SQL Server 的读写路径也随之停用。

故障处理与高可用性

为确保系统的高可用性，Agoda 设计了去中心化的故障检测机制。每个应用程序 Pod 独立比较两个集群的缓存命中率，若出现具有统计显著性的差异，则标记其中一个集群为不可读取。在一次故障模拟中，约 40 个应用程序 Pod 在两分钟内自动完成故障切换，无需人工干预。

技术架构对比

图1 展示了 Agoda 迁移前后的架构对比。左侧为 SQL Server 架构，包含 Price API、消息队列和 Price Writer (SQL) 等组件；右侧为 DragonflyDB 架构，引入了 gRPC Gateway 和 Shadow Cache Hit 机制。通过对比可以看出，DragonflyDB 架构更加简洁高效，减少了中间环节，提升了整体性能。

性能表现与影响

迁移完成后，Agoda 的价格缓存系统每秒处理约 160 万次写入，P99 延迟约为 10 毫秒。图2 显示了 B-cluster 在补丁期间的缓存命中率变化，表明系统在故障处理过程中仍能保持较高稳定性。

此次迁移不仅显著提升了系统性能，还带来了更灵活的扩容模式，减少了过期数据处理和故障切换维护工作。Agoda 的成功经验为其他企业在面对类似挑战时提供了有价值的参考。

总的来说，Agoda 的这次迁移展示了如何通过选择合适的数据库解决方案，有效应对快速增长的数据需求，并实现架构的现代化升级。这不仅是技术层面的成功案例，也为行业提供了关于数据基础设施优化的宝贵经验。