为什么我把 Redis 换成了 Dragonfly

迁移存储层是个得罪人的活——跑得好好的东西,换它干嘛?但当我看到那台 256GB 的 Redis 集群内存占用长期在 70% 以上、扩容又意味着多花一倍机器时,我开始认真考虑 Dragonfly。

为什么要换

我们的场景:用户行为流水的实时聚合,高峰 QPS 12 万,数据量约 400GB。用 Redis Cluster 分了 16 个分片,每片 32GB。

痛点很直接:

• 内存效率低。Redis 单线程模型 + 数据结构开销,实际有效负载只占内存的 60% 左右。
• 扩容麻烦。Redis Cluster reshard 又慢又需要人工盯着,半夜扩容是常态。
• 单核瓶颈。每片单线程,大 key 扫描时整个分片卡顿。

Dragonfly 是什么

Dragonfly 是个 Redis/Memcached 兼容的内存数据存储,核心卖点是多线程共享内存架构。它用了一套叫 "shared-nothing" 的线程模型,每个线程管一部分 key,配合高效的内存数据结构(dash table),目标是"同样内存能装更多数据,同样数据跑得更快"。

真实对比

迁完之后跑了一个月的对比数据(同等负载):

指标	Redis Cluster (16 分片)	Dragonfly (4 节点)
总内存	512 GB	220 GB
有效负载	~400 GB	~400 GB
内存利用率	78%	55%
峰值 QPS	120k	120k
p99 延迟	2.1 ms	1.4 ms
机器数量	16 台 32GB	4 台 64GB

内存占用直接砍掉一半多,机器数从 16 台降到 4 台,p99 还更好了。

迁移过程的坑

不是没代价,记录几个真实的坑:

1. 协议兼容不是 100%。Dragonfly 兼容绝大多数 Redis 命令,但有些边缘命令(比如 CLUSTER 相关的部分子命令、某些 SCRIPT 行为)有差异。迁移前要 grep 一遍代码里用到的命令列表。
2. pipeline 行为差异。Redis 的 pipeline 在单线程下是顺序执行的;Dragonfly 多线程下,同一 pipeline 里不同 key 可能落到不同线程,执行顺序不保证。如果你的逻辑依赖 pipeline 内的顺序,要注意。
3. 监控要重接。INFO 输出字段不一样,Prometheus exporter 也不一样,告警规则得重写。

怎么决策

我的判断标准很简单:

• 如果是小规模、对延迟极致敏感、重度依赖 Redis 特有行为(比如 Lua 脚本里的复杂逻辑、Streams 的高级用法)——继续用 Redis,别折腾。
• 如果是大规模、内存成本敏感、以 KV / 缓存 / 简单数据结构为主——Dragonfly 值得认真评估,内存和运维收益是实打实的。

我们这个场景属于后者,所以迁了。迁完省下的机器钱,够再养半个服务了。