凌晨两点，某个跨境电商平台的运维值班群突然刷屏。大促预热刚开始三十分钟，缓存层的 Redis 实例 CPU 占用直接冲到了报警线，接口响应时间从几十毫秒拉长到了两三秒。值班的工程师一边加实例扩容，一边在心里犯嘌咕：明明上周做过压测，怎么流量刚起来就顶不住了。
这种场景在做高并发系统的团队里并不罕见。Redis 用了十几年，几乎是”缓存”这个词的代名词，成熟、稳定、生态庞大，几乎所有语言都有现成的客户端库，云厂商也都提供托管服务。但它也有一个从设计之初就带着的先天限制：单线程模型。不管你的服务器有多少核，Redis 处理命令这件事本质上是一个线程在跑，多核 CPU 的其他核心大部分时间在旁边看戏。这在早些年数据量不大、QPS 不高的时候不是问题，但到了今天动辄百万级 QPS 的场景下，单核瓶颈就成了很多团队夜里睡不着觉的原因。
也正是在这个背景下，Dragonfly 这个项目冒了出来。它在 GitHub 上已经积累了三万多颗星，标签写得很直接：”A modern replacement for Redis and Memcached”，翻译过来就是一个现代化的 Redis 和 Memcached 替代品。听起来像是又一个”卷”性能的项目，但真正让人好奇的是，它到底解决了什么问题，又在哪些地方需要你付出代价。这篇文章想把这两个东西放在一起，看看它们各自适合什么样的团队和场景。
从协议兼容开始说起
选型这件事最怕的不是性能差距，而是迁移成本。如果换一个数据库意味着把所有客户端代码重写一遍，那多数团队宁可忍受现有的瓶颈,也不愿意冒着上线风险去做迁移。这也是 Dragonfly 团队在设计之初就想清楚的问题：他们没有发明一套新协议,而是选择在协议层完全兼容 Redis 和 Memcached。
具体来说,Dragonfly 实现了 Redis 的通信协议（RESP），也支持了 Memcached 的协议。这意味着如果你现在用的是 redis-py、ioredis、Jedis 这些主流客户端库,理论上不需要改一行业务代码,只需要把连接地址指向 Dragonfly 实例即可完成切换。这种”drop-in replacement”（直接替换）的定位,直接消除了迁移决策里最大的一块顾虑，不用担心因为换数据库导致整个应用层的连接逻辑、序列化逻辑都要推倒重来。
当然,协议兼容不代表命令集合百分之百对齐。Redis 这么多年迭代出了大量命令,包括一些相对小众的模块功能(比如 RedisSearch、RedisGraph 这类扩展模块)。Dragonfly 主打的是核心数据结构和常用命令的兼容,如果你的业务重度依赖某些冷门模块或者 Lua 脚本的复杂用法,在迁移前最好先做一次命令覆盖度的核对,而不是想着”协议兼容了肯定都能跑”就直接上生产。
单线程和多线程,到底差在哪
Redis 的单线程模型不是设计失误,而是当年的一个权衡取舍。单线程意味着不需要处理复杂的锁竞争问题,每条命令执行都是原子的,不会有并发写导致的数据竞争,这也是 Redis 长期以来”简单可靠”口碑的重要来源。Redis 官方后来也意识到了这个瓶颈,陆续引入了多线程处理网络 I/O 的能力,但核心的命令执行逻辑依然保持单线程,这是它架构里比较难绕开的一部分。
Dragonfly 走的是另一条路。它采用了一种叫 shared-nothing 的多线程架构,把数据按照分片(shard)拆开,每个线程独立负责一部分分片的读写,线程之间尽量不共享状态、不互相抢锁。这套设计思路借鉴了另一个开源项目 seastar 的一些理念,目标就是让 CPU 的每个核心都真正参与到请求处理里,而不是像 Redis 那样让大部分核心闲置。
这种架构差异带来的实际影响,在压力测试报告里能看到明显的区别:在多核服务器、高并发写入的场景下,Dragonfly 官方给出的一些基准测试显示出比 Redis 更高的吞吐量和更低的延迟抖动。但这里需要提一个容易被忽略的前提：这类基准测试的结果高度依赖测试环境、数据集大小、命令类型的选择,官方给出的数字和你自己业务场景里跑出来的数字,大概率不会完全一致。如果你打算做选型决策,最靠谱的方式还是拿自己真实的流量模型去做一次对照压测,而不是直接照搬任何一方公布的基准数据。
内存管理这件”看不见”的事
除了吞吐量,内存效率是另一个容易被低估的维度。Redis 在处理大量小对象时,会因为每个对象都带有一定的元数据开销(比如对象头、过期时间字段、引用计数等)而产生所谓的内存膨胀问题。当你的业务场景里存的是几百万甚至上千万个小 key-value 时,这部分”隐性”内存开销累积起来相当可观,很多团队第一次做内存容量规划时都会被这个问题坑一次。
Dragonfly 在内存管理上做了针对性优化,采用了更紧凑的数据结构存储方式,官方宣称在存储海量小对象的场景下内存占用会明显低于 Redis。这对于那些内存成本敏感、又需要缓存大量细粒度数据的团队(比如需要给每个用户、每个会话单独存一份小状态的应用)来说,可能意味着实打实的服务器成本下降。不过这个优势的幅度同样和具体的数据结构、value 大小密切相关,存的是简单字符串还是复杂的 hash、set,结果会有差异,不能一概而论。
另外值得一提的是 Dragonfly 在持久化机制上的设计。Redis 的 RDB 快照和 AOF 日志这套组合,在保存大数据集快照时,传统实现里经常需要 fork 一个子进程来做写时复制(copy-on-write),如果实例内存本身就很大,fork 这个操作本身可能造成短暂的延迟毛刺,这也是 Redis 用户社区里长期被讨论的一个痛点。Dragonfly 针对这个问题重新设计了快照机制,试图在保存快照的同时减少对在线请求延迟的影响。这算是一个针对已知痛点的定向优化,如果你的业务对延迟毛刺特别敏感(比如实时交易、游戏状态同步这类场景),这个改进可能比单纯的吞吐量数字更值得关注。
授权协议:一个容易被忽略却很现实的问题
技术参数聊完了,还有一个经常被工程师忽略、但被公司法务和采购部门格外关心的问题，开源许可证。
Redis 项目本身经历过许可证变动的风波。早些年 Redis 采用的是相对宽松的 BSD 三条款许可证,但从某个版本开始,Redis Labs(后来的 Redis 公司)调整了部分模块和核心项目的许可策略,转向了更严格的许可证组合,这个变动在当时的开源社区引发了不小的讨论,一些云厂商甚至因此推出了自己维护的 Redis 分支(比如 Valkey 项目就是在这个背景下由 Linux 基金会牵头成立的)。这段历史提醒我们,选型不能只看技术指标,协议变动的风险同样需要纳入长期考量,尤其是当你的产品需要面向企业客户、涉及到二次分发或者托管服务转售的时候。
Dragonfly 项目采用的是 BSL(Business Source License,商业源码许可证)。BSL 的核心逻辑是:代码是开源可见的,你可以自由查看、修改、在自己的业务里部署使用,但如果你想拿它去做”提供托管数据库服务”这类竞争性的商业行为(说得直白点,就是你想开一家云厂商去卖 Dragonfly 托管实例赚钱),则需要额外的商业授权。BSL 通常还带有一个”到期后转为宽松许可证”的条款,比如若干年后自动转为 Apache 2.0 之类的开源协议。
这意味着对于绝大多数只是把 Dragonfly 部署在自己服务器上、用来给自己的应用做缓存或者存储的团队来说,BSL 基本不会带来额外的合规负担,可以像用任何开源软件一样正常使用。但如果你所在的公司本身就是云服务提供商,或者未来有计划把基于 Dragonfly 的服务对外转售,在动手之前最好先仔细读一遍具体的许可证条款细节,必要时找法务确认边界,避免后续产生纠纷。
生态成熟度:新项目绕不开的现实
聊完了技术亮点,也得说说另一面：生态这件事,时间是没法作弊的。
Redis 从诞生到现在已经运行了十几年,这十几年里积累下来的东西远远不止”性能稳定”这一项。围绕 Redis 的监控工具(比如各种 Redis 专用的 Grafana 面板、Prometheus exporter)、管理工具、集群方案(Redis Cluster、Redis Sentinel)、周边的模块生态(RedisJSON、RedisSearch、RedisTimeSeries)、以及无数经过多年生产环境验证的最佳实践文档和踩坑记录,构成了一套非常厚实的护城河。当你在生产环境遇到一个诡异问题时,大概率已经有人在 Stack Overflow 或者 GitHub issue 里遇到过并给出了解决方案,这种”前人踩坑后人乘凉”的隐性价值,很难在基准测试报告里体现出来,但在真正运维一套系统的时候却异常重要。
Dragonfly 作为一个相对年轻的项目,虽然协议层兼容 Redis,能够复用大量现成的客户端库,但围绕它自身的运维工具链、社区问答积累、云厂商托管选项,相比 Redis 还处在追赶阶段。这不是说它不可靠,而是说如果你的团队本身运维能力有限,高度依赖社区文档和现成工具来排障,选择一个更年轻的项目意味着你可能需要更多依靠自己去摸索、去读源码、去直接在 GitHub issue 里提问题,而不是简单搜一下就能找到标准答案。
到底该怎么选
把前面这些维度放在一起看,其实答案已经不难得出，这两个东西并不是简单的”谁更好”,而是分别站在了不同的权衡点上。
如果你的团队已经在生产环境稳定运行了 Redis,业务对稳定性、生态成熟度、成熟的运维工具链依赖较深,当前的性能瓶颈还没有到”逼得团队睡不着觉”的程度,那么继续留在 Redis 的生态里、通过合理的分片、集群、读写分离来应对增长,大概率是更稳妥的选择，没有必要为了追一个还没真正遇到的性能问题,提前承担新项目带来的不确定性。
但如果你的团队正在经历真实的单线程 CPU 瓶颈,监控面板里 Redis 实例的 CPU 利用率长期只有一个核心在高负载、其余核心却闲置,同时业务场景里存在大量小对象带来的内存膨胀问题,又恰好不涉及需要转售托管服务这类会触碰 BSL 边界的场景,那么 Dragonfly 提供的协议兼容能力,让你有机会用较低的迁移成本去验证一次:同样的硬件,是不是真的能跑出更高的吞吐量、更低的延迟毛刺。
最稳妥的做法,永远是先拿自己的真实流量模型,在测试环境里搭一套 Dragonfly 实例跑一次对照压测,而不是直接被任何一份基准测试报告说服。毕竟凌晨两点报警群里刷屏的,从来不是 GitHub 星标数字,而是那条迟迟不肯降下来的延迟曲线。
延伸阅读
Stay updated with our latest AI insights
