实战：DragonflyDB 用线程分片跑出百万 QPS 的亚毫秒内存数据库

实战：DragonflyDB 用线程分片跑出百万 QPS 的亚毫秒内存数据库

【免费下载链接】dragonflyA modern replacement for Redis and Memcached项目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly

Redis 单线程在 16 核服务器上跑不满核，高并发下延迟飙升、吞吐见顶。DragonflyDB 用 shared-nothing 线程分片把内存数据库的吞吐拉到核数线性扩展，响应压到亚毫秒。

它到底怎么跑起来的？

传统内存数据库靠单线程模型保证原子性，代价是整台机器的核都挤在一条指令流上，核越多越浪费。DragonflyDB 因为多线程引入锁会成为新瓶颈，所以改用 shared-nothing 架构：把键空间按哈希切成若干 shard，每个 shard 绑死在一根专用线程（proactor）上，核与核之间互不共享数据。

单键操作天然落在单线程内，不碰任何锁就保证了原子性；多键写操作靠一个无锁的多版本锁管理器（源自 VLL 论文）在几个 shard 间协调，同样不碰互斥锁。客户端连上来后，每条命令走 hiredis 的 RESP 解析器增量喂入（见 resp_parser.h），解析出的命令直接路由到对应 shard 的线程执行。

三个环节串成一条因果链：因为核间不共享数据，所以没有缓存行乒乓；因为执行路径上没有锁，所以延迟抖动被压在微秒级；最终导致整库吞吐随核数近似线性扩展——这正是单线程 Redis 到不了的地方。

DragonflyDB 三个工程上值得看的设计

Dash 哈希表。核心存储没沿用 Redis 的 dict，而是自研 DASH（Dynamic And Scalable Hashing），把大哈希表拆成一组小 segment，用无冲突探测替代传统拉链法。这么做是因为拉链法的指针跳转对 CPU 缓存不友好，而 segment 的局部性更好。效果是 CPU 与内存占用都更低，还顺手支撑了零内存开销的淘汰算法和高效 TTL 过期，见 dash.h。

内存分配与无 fork 快照。全局内存走 mimalloc，项目给它打了补丁，让分配器上报每个内存页的使用率与状态标志。动分配器的原因是：内存库的碎片率和页利用率直接决定真实内存开销。配合增量式的 fork-less 快照算法，备份不再依赖 fork 整块内存，避开了 COW 造成的瞬时内存翻倍，见 1_add_stat_type.patch。

线程-per-core 模型。每根 proactor 线程独占一个 shard，事件驱动，无跨线程共享可变状态。不选线程池加锁，是因为锁竞争和上下文切换在百万 QPS 下就是延迟的敌人。单键与多键原子操作因此共用一套无锁执行路径。

五分钟跑起来

git clone https://gitcode.com/GitHub_Trending/dr/dragonfly cd dragonfly make ./build-release/dragonfly redis-cli -p 6379 set mykey "hello dragonfly" redis-cli -p 6379 get mykey

DragonflyDB 和 Redis 差在哪？

适合拿单台多核机扛高并发缓存或会话存储、想从 Redis 平滑迁移的团队；如果你的业务强依赖 Redis 独有数据结构、或需要严格的持久化 ACID 语义，把它当缓存层而非主存储，落地前先评估持久化需求。

【免费下载链接】dragonflyA modern replacement for Redis and Memcached项目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly