在线旅游平台Agoda完成了一次规模可观的基础设施替换：把承载酒店价格数据的一级缓存，从运行在72个分片上的Microsoft SQL Server迁移到内存数据存储DragonflyDB。迁移完成后，缓存承载约1.5TB易变价格数据，每秒处理约30万次读取、150万次写入，P99读取延迟从原有水平降至约8毫秒，改善约八倍。真正值得后端团队关注的，并非这个延迟数字，而是Agoda在没有大规模宕机的前提下走完了整个切换过程。该迁移细节由Agoda工程团队公开，并被InfoQ等媒体报道。

为什么SQL Server在价格缓存场景撑不住了

Agoda此前的架构由应用层负责在72个SQL Server分片之间路由请求，扩容必须按照预设的硬件增量进行，并伴随手动重新映射分片与数据迁移。这套模式暴露出两个硬性瓶颈：一是团队在2024年初把硬件容量翻倍后，不到一年时间又逼近上限，说明容量增长与管理成本并非线性；二是工作负载需要单独的清理进程来删除过期供应商数据，增加了运维面。Agoda首席工程师Clarkson Chang在复盘中直言，继续给SQL Server加资源不是可行且有成本效益的长期策略。当P99延迟直接影响用户在搜索结果页看到的价格报价时，缓存层的伸缩能力就成为业务问题而非纯技术问题。

选型没有依赖公开基准，而是还原线上1:6读写比压测

Agoda的评估方法值得单独拿出来说。团队没有直接对比缓存在线基准的排名，而是用memtier_benchmark复现接近生产环境的读写压力：读写比例约1:6，且MGET操作平均涉及10个键。DragonflyDB被选中的原因正是在这套负载下成立的——无共享多线程架构匹配高并发MGET与SET、兼容Redis协议降低应用改造成本、集群化扩容不再是固定硬件增量、内置键过期直接替掉了独立的清理进程。迁移并非一步到位：团队先部署1TB实例承接热数据，但随着数据自然增长，内存逐渐逼近90%安全阈值，随后改成每集群三分片并按完整1.5TB数据集扩展，最终集群每秒约处理160万次写入，P99延迟约10毫秒。

平稳切换的关键动作：双重读取与运行指标比对

切换流量之前，Agoda引入了双重读取机制：SQL Server继续对外提供请求，PriceAPI异步从DragonflyDB读取同一份数据。团队没有笨拙地逐条比对完整价格数据，而是抽取两个稳定的特征维度——供应商数量与价格数据长度——输出为Prometheus指标。这两项维度在双写比对中一致率都超过99.9%，构成上线放量的前提。随后通过A/B实验逐步切换客户流量，数周后100%流量走DragonflyDB，SQL Server的读写路径才被停用。可以说，在这类迁移里，可观测指标的选择比压测数字本身更决定成败——抽象程度太高会漏掉真实不一致，太低则会放大噪声，让团队无法放量。

去中心化的故障切换替你省掉人工介入

高可用设计也有对应改造。DragonflyDB的A、B两个集群共同承担容灾，每个应用Pod不依赖中央协调器，而是用本地五分钟观测窗口独立对比两个集群的缓存命中率。

规则很直接：当两者命中率差距出现统计显著的10个百分点时，就把落后一方标记为不可读取；恢复上诉求差距收敛到3个百分点以内。按此策略进行故障模拟时，约40个Pod在两分钟内即可完成识别与切换，全程无需人工干预。除了数据库产品的性能特性，这种旁路探测式的自愈设计与迁移过程中的预热机制、数据一致性检查、受控的流量阶梯，构成了同一套工程组合。它本质上是在变相模拟可观测性的门槛：依赖客户端侧的独立归纳、而非中心化的判定规则，系统才能真正“自动”恢复。

工程经验的迁移价值

不论是否用DragonflyDB，该案例在双重读取、维度特征对比、分阶段扩容、去中心化切断和快速检测支持方面展示的工程模式有更高的复制价值。从结果看，更低的延迟与消除应用层分片路由才是第一个层面的收益；拆掉需要固定硬件档位才敢扩容，免除了维护独立过期进程，以及提升故障切换的稳定性，是后续不断累加的更实际的部分。这些并不是与平滑性无关的花絮，而是这次迁移能够发生商业价值，而非停留在指标赛跑的核心工程案例。

小结：Agoda这一案例的价值超出替换一款缓存引擎——以99.9%数据一致性作为安全网，再用带约束的可观测性跑完迁移，这一组合才是替换从PPT愿景进入生产扩展的真正路径。在选择重建缓存的长期策略时，硬件一旦依赖给定档位才能立项：切掉的不只是一层门固速度的配合、不再打补丁的非受扰治理。