Redis 從 antirez 2009 年寫下第一版起，資料平面的核心決策從沒變過——一顆 event loop 順序處理所有指令。這在單核夠快、in-memory KV 還是新概念的年代是聰明選擇：不用擔心 lock、沒有 race condition、multi-key 原子性天生附送。十六年過去，Redis 8 在 2025 年 5 月加了 AGPLv3 授權回到 OSI 認可的開源陣營、Valkey 從社群 fork 撐起 Linux Foundation 護傘、雲廠商各自賣託管服務——這條單執行緒核心依然是資料路徑的骨架。IO thread 跟 cluster mode 都是繞著它疊補丁，主線沒有動。
Dragonfly 是這幾年少數從架構層面重新想這件事的專案。2022 年 GitHub 開源到今天累積接近三萬顆星，drop-in 相容 RESP 協議，但底下換成 shared-nothing thread-per-core 加上 VLL 演算法。同一顆 32 核心 VPS，Redis 主 process 頂多壓一顆 CPU，Dragonfly 可以把每顆核心的算力全部吃進去，而且不需要開 cluster 拆 keyspace。
單執行緒事件迴圈踩到的實體天花板
Redis 官方立場一直很清楚：對 in-memory 資料庫而言，網路 I/O 才是瓶頸，不是 CPU。這個判斷在千兆網卡年代成立。但雲端 VPS 早就標配 10 Gbps 甚至 25 Gbps 網路、NVMe SSD 讓 persistence 不再是慢動作、單機 vCPU 動不動就 16 到 64 顆。單執行緒 event loop 在這個硬體條件下反而變成資源浪費——花大錢租了 32 vCPU 的機器，Redis 主 loop 只吃得動一顆。
Redis 7 加了 IO thread 部分緩解這件事，把 socket 讀寫拆給 worker thread 跑，但指令解析、資料結構操作、回應組裝仍然回到主線序列化執行。Valkey 從 Redis 7.2 fork 出來之後把 IO thread 深化、加了 async writes，但核心資料平面的執行模型沒動——Valkey 的公開路線圖白紙黑字寫著「不會為了 multi-thread 打破現有 module API」。這條路一旦繼續走，多核 CPU 對單一 Redis instance 就是浪費。
實務上要跨過去只剩兩條路。第一條是開 cluster，把 keyspace hash 分成 16384 個 slot 分派到不同 node，服務端得處理 MOVED / ASK redirect，客戶端也得換成支援 cluster 的 driver，跨 slot 的 multi-key 操作要嘛拆開要嘛用 hash tag 硬綁在同一 slot。第二條是垂直堆更多記憶體，然後接受單核天花板。無論哪條，都繞不開一件事：資料量到單機 128 GB 級距、每秒操作壓到十萬起跳，架構就開始擰。
shared-nothing 加 VLL：不用鎖也能撐原子多鍵
Dragonfly 的核心思路是把「單執行緒容易寫」跟「多執行緒有效能」硬拆開來各拿一半。作法是 shared-nothing：每一顆 CPU 綁一條 worker thread、負責固定一段 keyspace 分片，thread 之間不共用可寫記憶體。單一 key 的操作不需要任何鎖，因為只會被一條 thread 摸到。
真正的難點在 MSET、MGET、DEL 多鍵、以及 EVAL 這類跨 key 命令。這些操作在 Redis 天生原子——因為只有一條線程。Dragonfly 要保住這個語意，用的是 Ren、Thomson、Abadi 2013 年在 VLDB 發表的 VLL（Very Lightweight Locking）演算法。原理是每條 thread 維護一份極輕量的 lock table，多鍵命令進來時先把所有目標 key 註冊成 pending，等所有相關 thread 的排程窗口對齊、確認沒有 conflict 之後同步執行。整個過程沒有 mutex、沒有 spinlock，靠的是 cooperative scheduling 加 lock-free 資料結構。
這個結論跟 BIRD 3 走協同多執行緒異曲同工：現代高並行 in-memory 系統要壓榨多核，走傳統 mutex 幾乎必然被 lock contention 反噬，得從結構層面重寫。Dragonfly 官方 benchmark 宣稱單機吞吐相對 Redis 有 25 倍差距，實務測試多半落在 6 到 12 倍——但這是不開 cluster、不動應用程式碼、直接換 binary 就拿得到的紅利。
Dashtable 跟不 fork 的 snapshot
Dragonfly 另一塊被寫成論文的設計是 Dashtable——取代 Redis dict 的底層雜湊表。Redis dict 的 incremental rehash 名聲不好，遇到大 key 遷移會拖尾延遲；Dashtable 走 segment-based extendible hashing，rehash 分攤到毫秒級、無需一次搬完整表、記憶體 fragmentation 也小得多。DragonflyDB 團隊對 Twitter cache workload 的公開測試，同樣資料集用 Dashtable 比 dict 節省 30% 到 40% 記憶體。
Snapshot 這塊差別更明顯。Redis BGSAVE 靠 fork() 產生子 process，copy-on-write 頁面在寫入密集時可能讓實體記憶體用量瞬間翻倍——這是雲上 Redis 動不動 OOM 的常見原因。Dragonfly 完全不 fork：靠 VLL 的一致性保證跑 concurrent seq-scan snapshot，一邊讀資料一邊寫入不會撕裂快照。這件事對記憶體吃緊的 VPS 特別有感——原本要預留兩倍記憶體給 fork 保險的空間，Dragonfly 直接省下。
相容邊界跟該保留 Redis 的情境
Drop-in 這個詞得打折。RESP2 / RESP3 協議、String / List / Hash / Set / ZSet / Stream 這些常見資料型別、Pub/Sub、Pipeline、Transaction（MULTI/EXEC）、Lua scripting、TLS 都完整支援。Dragonfly Search 也把 RediSearch 的 FT.SEARCH 功能覆蓋掉，近期版本補上原生 vector 寬度處理、Cuckoo Filter、Count-Min Sketch、Top-K 等資料型別。
真正的缺口在 Redis Modules。RedisJSON、RedisBloom 這些以 module 形式散發的 Redis 生態工具，Dragonfly 是用重新實作方式對應——多數常見指令都在，冷門邊角行為可能對不上。Redis Cluster 專屬的 CLUSTER SHARDS、CLUSTER LINKS 指令在單機模式下語意不同；Redis Enterprise 的 CRDT、Active-Active geo replication 沒有對應，這塊要留給付費版 Dragonfly Cloud 或社群 Dragonfly Swarm 分片。
還有一個情境該保留 Redis：小量資料、要求極低延遲、部署在 1 到 2 vCPU 的機器。Dragonfly thread-per-core 架構在 2 核以下發揮不出來，反而多一層 scheduling overhead。Redis 單執行緒設計在這個尺寸上依然是最好的選擇。
什麼時候值得換過去
換 Dragonfly 的價值在資料量已經逼近單機 Redis 上限、又不想跳到 cluster 的中間地帶。單機 8 vCPU / 32 GB 記憶體以上、每秒操作壓到十萬起跳、cache workload 為主，這是甜蜜點。實務上 Nextcloud、Sidekiq、Bull queue、Airflow 這類把 Redis 當 broker 或 session store 的服務，切換過去幾乎零改動。
真正要規劃的是持久化跟複製。Dragonfly 支援 RDB 跟 dfs（自家格式）快照，也支援 Redis-style master-replica 複製，但 sentinel、failover 這塊比 Redis 生態成熟度稍差。生產環境上線前值得先在測試機跑 chaos test，觀察 replication lag 跟 failover 時間，確認符合 SLO 再切上正式流量。授權部分 Dragonfly 用的是 Business Source License 1.1（4 年後自動轉 Apache 2.0），一般自架、SaaS 內部使用都不受限，唯獨拿 Dragonfly 出去對第三方賣 DBaaS 才會踩到條款。
多核 CPU 在雲端 VPS 已經是預設配備，一顆機器多開幾條執行緒去接請求本該是理所當然的事。Redis 選擇不改主線，Dragonfly 選擇從底層重寫，這條分岔讓自架團隊終於有選擇——不是「用 Redis 加 cluster」跟「換一個生態系」二選一，而是「同一份客戶端程式碼、不同引擎」的直接切換。
NCSE Network 的臺灣是方電訊機房 VPS 主機採用 Intel Gold CPU 加 NVMe SSD，8 vCPU 以上規格對 Dragonfly 這類 thread-per-core 服務特別友善，配合 IPv6 雙堆疊跟高速網路可以直接把 shared-nothing 架構的紅利拿滿。有興趣了解 VPS 規格或規劃 Redis 遷移到 Dragonfly 的團隊，歡迎到 ncse.tw 進一步了解方案。
