HotKV vs Dragonfly

正面實測的 Dragonfly 替代方案

兩台伺服器都是多執行緒，也都支援 Redis 協定，因此 Dragonfly™ 替代方案必須在細節上證明值得更換。執行緒如何共用資料、資料如何持久化，以及伺服器內建了什麼。HotKV Ltd 在一台 160 vCPU 的機器上，以相同負載測量了這個 Dragonfly 替代方案與 Dragonfly，並公開每一個數字，包括持平的那一個。

申請搶先體驗 查看測量結果

Dragonfly

每個執行緒一個分片

MGET a b c

HotKV

一份共用儲存

MGET a b c
示意圖，不是測量結果。Dragonfly 給每個執行緒自己的一塊鍵空間，因此鍵落在多個區塊的指令需要跨執行緒協調。HotKV 讓每個執行緒都在同一份共用儲存上運行。

這個 Dragonfly 替代方案以單一執行個體在一台 160 vCPU 的機器上運行，對照 Dragonfly 2.0.2 時在 12 個指令中的 11 個領先，吞吐量為對方的 2.0x 到 4.4x。HotKV 是針對該 CPU 從原始碼建置。Dragonfly 2.0.2 則以其原版建置運行。在小型機器上差距較小。

隨插即用

改用這個 Dragonfly 替代方案，哪些維持不變

HotKV 實作 Redis 線路協定。從 Dragonfly 搬移通常只需更改主機與認證資訊。核心集合以外的部分請查閱指令參考。

相同的協定

RESP2 與 RESP3，支援 HELLO 協商。HotKV 向用戶端回報 Redis 版本 8.4.0，因此程式庫會據此選擇功能。連線字串、管線、pub/sub 與交易都和現在一樣運作。

相同的用戶端與工具

Redis 與 Valkey 用戶端程式庫、redis-cli、redis-cli --cluster 與 GUI 工具在核心指令上不需更改程式碼即可連到 HotKV。

相同的核心指令

300 個核心指令、Lua 腳本與函式庫，加上您需要時可用的 HotKV 自有指令家族。

您現有的用戶端
$ redis-cli -h <your-hotkv-host> -p 6379 --tls --user app --askpass
> HELLO 3
1# "server" => "hotkv"
2# "version" => "8.4.0"
3# "proto" => (integer) 3
   ... (另外四個欄位)
> SET session:4821 "same protocol, every core"
OK
> GET session:4821
"same protocol, every core"
> TAG.SET session:4821 tenant:acme   # 需要時可用的 HotKV 指令
(integer) 1

選擇 Dragonfly 替代方案 的理由

團隊為何尋找 Dragonfly 替代方案

促使團隊尋找 Dragonfly 替代方案 的 Dragonfly 文件化特性，於 2026年10月21日 查核。

01

無共用的分片

Dragonfly 將鍵空間切分為每個執行緒一個分片。觸及多個分片中鍵的指令，例如 MSET 或 MGET，需要跨執行緒協調。HotKV 讓每個執行緒都在同一份共用儲存上運行。這個差異正是這個 Dragonfly 替代方案的核心。

02

沒有僅附加檔案

Dragonfly 以時間點快照進行持久化。其文件指出目前不支援 AOF。具備僅附加檔案的 Dragonfly 替代方案補上了這個缺口。HotKV 提供快照與 AOF。

03

以 BSL 1.1 提供原始碼

Dragonfly 以 Business Source License 1.1 授權。其授權允許在您自己的產品或服務內使用。不允許作為記憶體內資料儲存產品或服務使用，也不允許將 Dragonfly 作為與 DragonflyDB 競爭的託管服務提供。程式碼會在其變更日期轉為 Apache 2.0，就目前的授權文字而言為 2030 年 11 月 1 日。HotKV 是依其自身授權條款的商業軟體。

04

向量搜尋是內建的，AI 快取則不是

Dragonfly 有向量搜尋。提示詞快取、語意快取、代理記憶體與 LLM 成本追蹤都不是伺服器的一部分。

實測，而非宣稱

這個 Dragonfly 替代方案的實測結果。HotKV vs Dragonfly 2.0.2，同一台機器

HotKV Ltd 在同一台 160 vCPU 的機器上，以單一執行個體逐一運行 HotKV 與 Dragonfly 2.0.2。每一個都獲得相同的負載與全部核心。HotKV Ltd 連同測試方法與原始資料公開了每一個數字。

11 共 12 個
HotKV 對照 Dragonfly 測得最高吞吐量的指令
2.0x 至 4.4x
HotKV 的吞吐量相對於 Dragonfly 的倍數，涵蓋其領先的 11 個指令（MGET 至 INCR）
PING
Dragonfly 測得高出 0.6%，在負載產生器的限制範圍內，因此視為持平

HotKV Ltd 針對此 CPU 從原始碼建置 HotKV。Dragonfly 以其原版正式建置運行。兩者都以單一執行個體運行。執行緒數量依各產品文件中的全核心設定，未針對個別產品調校。在核心數少的機器上差距較小。

SET3.4x
HotKV
50.5M*
Dragonfly
15.0M
GET2.7x
HotKV
36.6M*
Dragonfly
13.4M
MGET2.0x
HotKV
4.6M*
Dragonfly
2.3M
SETNX3.8x
HotKV
55.3M*
Dragonfly
14.4M
APPEND2.8x
HotKV
25.1M
Dragonfly
8.9M
INCR4.4x
HotKV
90.8M
Dragonfly
20.6M
LPUSH3.0x
HotKV
31.6M
Dragonfly
10.6M
RPUSH4.0x
HotKV
43.8M
Dragonfly
11.0M
SADD4.2x
HotKV
50.6M*
Dragonfly
12.0M
HSET3.0x
HotKV
29.0M*
Dragonfly
9.8M
MSET3.8x
HotKV
11.3M
Dragonfly
2.9M
PING0.99x
HotKV
125.2M†
Dragonfly
126.0M

每秒操作數，3 次各 10 秒執行的中位數。每一對長條都以該指令中較快的伺服器為基準按比例繪製。

* 受網路限制: 此結果受執行個體的網路所限，因此伺服器本身的上限更高。

† 受負載產生器限制: 負載產生器機器的 CPU 使用率超過 85%，因此這是它們的上限，而不是伺服器的上限。

Azure D160alds_v7（AMD EPYC 9V45 (Turin)，160 個 vCPU），測量於 2026年10月9日。256 位元組的值，管線深度 30，預先填入 5,000,000 個鍵並以均勻隨機方式讀取。三台專用的負載產生器機器。每台伺服器都單獨以單一執行個體運行，並關閉持久化。每一台都獲得全部核心（Redis 為 128 個 I/O 執行緒，即其最大值）。HotKV Ltd 針對此 CPU 從原始碼建置 HotKV，Dragonfly 則以其原版正式建置運行。 完整測試方法與結果 · 測試工具與原始資料

並列比較

這個 Dragonfly 替代方案與 Dragonfly，逐項功能比較

功能HotKVDragonfly
指令執行多執行緒。每個核心都在同一份共用儲存上讀取、解析並執行指令多執行緒，每個執行緒一個鍵空間分片（無共用）
協定RESP2 與 RESP3，支援 HELLO 協商。向用戶端回報 Redis 版本 8.4.0RESP2 與 RESP3
語言C++20，從零打造C++
授權商業授權（HotKV Cloud，或地端部署授權）BSL 1.1
持久化快照與 AOF僅快照，無 AOF
免 fork 快照是。由背景執行緒寫入快照，不 fork 子處理程序是
向量相似度搜尋內建（HNSW、VSIM.*），所有方案內建
LLM 提示詞與語意快取內建（PCACHE.*、SCACHE.*），HotKV Cloud 的 Performance 及以上方案否
AI 代理記憶體內建（AMEM.*），HotKV Cloud 的 Performance 及以上方案否
LLM Token 與成本追蹤內建（LLMBUDGET.*、LLMSTATS.*），HotKV Cloud 的 Performance 及以上方案否
Prometheus 端點內建。設定 metrics-port 後，伺服器會自行提供 /metrics（地端部署）內建
逐指令延遲直方圖逐指令，內建（LATENCY HISTOGRAM）需自行啟用的延遲追蹤旗標。LATENCY HISTOGRAM 列為不支援
鍵標籤是（TAG.*）否
奈秒級 TTL是（NEXPIRE、NTTL）否。毫秒級 TTL
伺服器平台Linux（x86_64 與 ARM64）Linux（x86_64 與 ARM64）
部署方式HotKV Cloud（Google Cloud，42 個區域）或憑授權地端部署自行管理或 Dragonfly Cloud

持平而論

Dragonfly 領先這個 Dragonfly 替代方案之處，或單純不同之處

這個 Dragonfly 替代方案頁面只有在也說明這部分時才有用。

  • 在 PING 上，Dragonfly 的測量值比 HotKV 高 0.6%。兩者的負載產生器 CPU 使用率都超過 80%，因此 HotKV Ltd 視為持平。無論如何，表格中都會顯示。
  • Dragonfly 的快照與 HotKV 一樣是免 fork 的，而且它自行提供 Prometheus 指標。
  • 在 BSL 1.1 下，Dragonfly 可在您自己的產品內免費自行託管，而 Dragonfly Cloud 是成熟的託管服務。作為 Dragonfly 替代方案的 HotKV Cloud 目前為搶先體驗階段。

搬移過來

從 Dragonfly 到這個 Dragonfly 替代方案的四個步驟

切換到 Dragonfly 替代方案在實務上涉及哪些事。

  1. 1

    建立執行個體

    在 HotKV Cloud 主控台選擇區域與方案。該執行個體是一台專屬於您的機器，由我們負責佈建、修補與監控。

  2. 2

    將用戶端指向它

    沿用您現有的用戶端程式庫。把主機、連接埠與認證資訊從 Dragonfly 改為 HotKV 執行個體。TLS 與密碼驗證從一開始就啟用，並提供 ACL 使用者。使用相同協定的 Dragonfly 替代方案，在核心指令上不需要改動用戶端。

  3. 3

    搬移資料

    使用您已熟悉的工具。DUMP 與 RESTORE、MIGRATE，或重放您的寫入都可以，因為 HotKV 實作了這些指令。

  4. 4

    啟用原本缺少的功能

    向量搜尋與鍵標籤是所有方案的核心指令。提示詞與語意快取、代理記憶體與 LLM 成本追蹤，在 Performance 及以上方案中是同一台伺服器的指令。不需要模組、sidecar 或第二個服務。這正是 Dragonfly 替代方案應該加上的。

常見問題

關於這個 Dragonfly 替代方案的問題

兩者都是多執行緒。這個 Dragonfly 替代方案有什麼不同？

Dragonfly 給每個執行緒自己的一塊鍵空間分片，因此鍵落在多個分片的指令需要跨執行緒協調。HotKV 讓每個執行緒都在同一份共用儲存上工作，因此多鍵指令與單鍵指令走相同的路徑。

兩者在基準測試中相比如何？

在一台 Azure D160alds_v7 上，以單一執行個體運行，HotKV 對照 Dragonfly 2.0.2 在 12 個指令中的 11 個記錄到最高的中位數吞吐量。倍數從 MGET 的至少 2 倍到 INCR 的至少 4.4 倍。PING 在負載產生器的限制範圍內持平。每一個數字、測試方法與原始資料皆已公開。

HotKV 有 AOF 嗎？

有。HotKV 以快照與僅附加檔案進行持久化。Dragonfly 的文件指出目前不支援 AOF。

我可以不改程式碼就從 Dragonfly 搬移嗎？

兩台伺服器都支援 RESP2 與 RESP3，因此在核心指令上，相同的用戶端程式庫可以連到這個 Dragonfly 替代方案。用 DUMP 與 RESTORE、MIGRATE，或重放您的寫入來搬移資料。核心集合以外的部分請查閱指令參考。

用您現有的用戶端來測試這個 Dragonfly 替代方案

HotKV Cloud 正分批開放。這個 Dragonfly 替代方案 的每個執行個體都是搭載多執行緒引擎的專屬機器。AI 指令家族隨 Performance 與 Scale 方案提供。

申請搶先體驗 價格