認識 HotKV

HotKV 是一套以現代 C++ 從零開始撰寫、相容 Redis 的多執行緒資料儲存系統，目標是以盡可能低的成本，從現代多核心伺服器中榨出最高的速度。我是 Norbert E. Boros，HotKV Ltd 的創辦人暨執行長。這篇文章要說明我為什麼打造它、它現在能做什麼，以及它的測量結果。

簡而言之。 HotKV 在單一行程內同時以多個執行緒執行指令，並支援 Redis 協定 RESP2 與 RESP3。在我們 2026 年 10 月以 160 個 vCPU 進行的單一執行個體基準測試中，我們測量的 12 個指令裡，它在 11 個取得最高吞吐量，第 12 個則與 Dragonfly 持平。測試設定與其限制說明如下。

我為什麼打造 HotKV

我在做的每一件事上都在乎速度。網站、工具或伺服器都應該立即回應，而當它沒有時，我想知道原因。從我開始寫軟體以來，這個習慣一直影響著我的工作。

多年來，C 與 C++ 一直是我主要使用的語言。近十年間，我開發過在成千上萬名玩家的電腦上執行的遊戲反作弊軟體。它必須掃描記憶體找出作弊程式，同時盡可能少用 CPU 與記憶體，因為它花掉的每一個週期，都是從遊戲那裡搶來的。那段工作教會我要測量一切、圍繞硬體進行設計，並把低資源使用本身視為一項功能。

同時，我也在許多需要快速快取的專案中使用 Redis 與 Valkey：工作階段儲存、防火牆封鎖的 IP 位址清單，以及放在數億筆 SQL Server 記錄前面的快取。它們都是出色的工具。它們也讓我好奇，如果一個鍵值儲存系統從一開始就是為今天我們執行的多核心伺服器所設計，會是什麼樣子。

HotKV 就是我得出的答案。我以現代 C++ 從零開始撰寫，為的是以盡可能低的成本，從硬體中榨出盡可能多的速度。下方的基準測試顯示了它目前的位置，而我預期還有更多進步的空間。

AI 的成本

還有第二個原因。執行 AI 應用程式正變得昂貴，對我來說如此，從開發者們在網路上分享的內容來看，對許多人也是如此。這筆成本的一大部分，往往來自對模型送出它已經回答過的問題。一個能辨識出重複或相似的問題，並從快取回答的快速儲存系統，是降低這筆帳單最直接的辦法之一，這也是為什麼針對 AI 工作負載的快取是 HotKV 的核心部分。

HotKV 的用途

HotKV Ltd 的存在，是為了讓這類軟體更有效能、也更經濟實惠。現代伺服器擁有許多核心，資料儲存系統就該用上它們，讓您以盡可能低的成本，獲得盡可能高的速度。

第二個想法，是把更多技術堆疊放在同一個地方。以 LLM 建構應用的團隊，往往最後得運行快取、向量資料庫，以及存放代理記憶體的地方，中間還夾著一大堆黏合程式碼。我希望快取，以及圍繞它的 AI 工作，都能放在同一個引擎裡，就在您的資料旁邊：模型呼叫的精確與語意快取、向量搜尋、代理記憶體與 Token 預算。要運行的系統變少，應該就意味著活動零件變少、帳單變低。AI 頁面列出了目前提供的功能，Token 節省基準測試則顯示在我們的測試中，快取模型呼叫省下了多少。

HotKV 保留了 Redis 協定與大家熟悉的用戶端函式庫。

問題所在

在核心很多的機器上，單一的指令執行緒可能成為瓶頸。圍繞單一執行緒執行指令所設計的資料儲存系統，通常要靠運行多個執行個體或叢集，才能用上機器的其餘部分，而這也帶來了部署上的取捨與維運工作。我希望 HotKV 從另一端出發，讓指令在單一執行個體內並行執行，讓單一行程就能用上整台機器。

HotKV 有什麼不同

HotKV™ 以 C++20 撰寫，設計上讓指令同時在多個核心上執行，因此單一執行個體就能用上整台機器。我們在下方進行基準測試的 Dragonfly，也採取了多執行緒的做法。

• 多個核心，一個執行個體。 指令在機器的各個核心上並行執行，所以一個執行個體就能用上大型伺服器，而不需要好幾台較小的。
• 熟悉的用戶端與協定。 HotKV 支援 RESP2 與 RESP3，因此大家熟悉的用戶端函式庫都能連線。支援交易 (MULTI/EXEC) 與 Lua 腳本。支援的指令及任何差異，請參閱指令文件。

如何建構與測試

HotKV 由我自己建構，並在有幫助的地方使用 AI 輔助。比一行程式碼是怎麼寫出來的更重要的，是它經不經得起考驗，所以引擎經過嚴格測試。它有超過 2,000 個自動化測試，並能在 AddressSanitizer、ThreadSanitizer 與 UndefinedBehaviorSanitizer 下建置。它也針對協定解析器、指令分派、RDB 與 AOF 載入、複寫串流與叢集匯流排，準備了模糊測試目標。

基準測試的設定、限制與完整結果都在效能頁面上，讓您自己判斷這些數字。

基準測試快照

2026 年 10 月更新：本文最初發布的數字，來自我們後來發現有瑕疵的基準測試執行（其中之一是每個負載產生器都使用相同的隨機種子），因此我們以重建後的基準測試結果取而代之。

2026 年 10 月：HotKV、Redis、Valkey 與 Dragonfly

這項基準測試由 HotKV Ltd 執行。我們測量了從原始碼建置的 HotKV，並與 Redis 8.10.2、Valkey 9.1.2 及 Dragonfly 2.0.2 比較。每台伺服器單獨運行，以單一執行個體使用 Azure D160alds_v7（AMD EPYC 9V45）的全部 160 個 vCPU，並關閉持久化。三台各有 64 個 vCPU 的獨立機器以 memtier_benchmark 產生負載：256 位元組的值、深度為 30 的管線，以及 5,000,000 個預先填入的鍵。每個數字都是三次 10 秒執行的中位數。

12 個指令中，HotKV 在 11 個取得最高吞吐量。相較於 Redis 或 Valkey，依指令與伺服器不同，它測得的吞吐量是對方的 8.6 倍至至少 69.7 倍；相較於 Dragonfly，在那 11 個指令上為 1.97 倍至 4.41 倍，其中有數個是下限值。在 PING 上，Dragonfly 的測量值領先 0.6%。我們視為持平，因為負載產生器已接近它們自己的上限。資料指令上最高的數字是每秒 9,080 萬次 INCR 操作。INCR 與 PING 搬動的資料很少，受限於負載產生器，所以 HotKV 自身在這兩項的數字可能更高。

如何解讀這張表

MGET 每個指令讀取八個鍵，MSET 每個指令寫入四組鍵值對，而吞吐量計算的是指令數。報告標記了七個 HotKV 數字（GET 與六個寫入指令），因為它們達到了報告設定的 85% 網路使用率門檻，另標記 PING，因為負載產生器的 CPU 超過 85%。以它們為基礎的比值是下限值，以 ≥ 標示。GET 與 PING 是真正的上限。對於那六個寫入指令，報告中的網路使用率數字把入站與出站流量相加，再與出站上限比較，因此高估了它們距離上限有多近。其中最吃重的 SETNX，最多只用掉實測入站上限的約 80%。我們出於保守的慣例，仍在它們上面保留 ≥。完整的表格、旗標與方法說明，請見效能頁面。

基準測試的範圍

• 建置與調校。 HotKV 針對測試用的 CPU 以 -march=native 編譯，而其他伺服器則是其標準的發行版本。
• 執行緒設定。 每台伺服器都分配到機器的所有核心：HotKV --threads 160、Dragonfly 160 個 proactor 執行緒、Valkey io-threads 160，以及 Redis io-threads 128（其上限）。Redis 與 Valkey 在單一執行緒上執行指令，使用較少的 I/O 執行緒時可能有更高的吞吐量，因此它們的數字可能低於其最佳表現。我們沒有運行它們的叢集或多個執行個體。
• 範圍。 十二個指令、一種值大小、一種管線深度，沒有 TLS，也沒有持久化。LPOP 與 RPOP 沒有測量，因為在這樣的速率下，具破壞性的讀取會在 10 秒內清空任何記憶體裝得下的清單。報告記錄了延遲與記憶體用量，但我們在此不做比較。各伺服器在每次 10 秒的執行中所做的工作量差異極大，所以記憶體數字並非同等條件的比較。混合工作負載並未測量。
• 變異。 Redis 在其三次執行之間，有數個指令的變動很大，HSET 上最快與最慢的一次相差最高達 7.2 倍，而中位數把這點掩蓋了。若改與每個競爭者最快的一次執行（而非中位數）比較，HotKV 在全部 11 個指令上仍然領先。

Redis、Valkey 與 Dragonfly 是其各自所有者的商標。提及它們只是為了識別我們所測量的軟體，並不表示任何贊助、背書或隸屬關係。

目前提供的功能

核心指令家族包括字串、清單、集合、雜湊、有序集合、串流、地理空間索引、位元圖、HyperLogLog、發布/訂閱與 Lua 腳本。AI 模組與企業功能在授權方案上運行。價格頁面列出了每個方案包含的內容。目前支援的指令範圍請參閱文件。除了 Redis 指令集之外：

• 鍵標籤： 為鍵加上任意標籤，並依標籤查詢（TAG.SET、TAG.MEMBERS 及另外五個指令）。
• 奈秒級 TTL： NEXPIRE、NTTL 與 NEXPIREAT 以奈秒設定及讀取到期時間，因此期限可以比一毫秒更精細。過期的鍵會由背景清掃回收，並在被存取時回收。
• 選用的值壓縮： 針對超過大小門檻（預設為 512 位元組）的值，除非您開啟，否則預設關閉。
• 免 fork 的快照： BGSAVE 在背景執行緒上寫入，而不是 fork 出的行程。快照不是某個時間點的複本。每個鍵都以快照進行到它時的狀態儲存。重寫僅追加檔案則確實會 fork。
• Prometheus 指標： 內建的 HTTP 端點，預設關閉，以 metrics-port 啟用，因此不需要外部 exporter。

HotKV 也內建以 HNSW 索引的向量搜尋（VSIM.CREATEINDEX、VSIM.SET、VSIM.SEARCH）。我們在向量搜尋：HotKV 對 Redis 8 向量集合，從 1 到 100 個用戶端中，與 Redis 8 做過測量。

請從 HotKV Cloud 開始，或聯絡業務，洽詢在您自己的伺服器上運行 HotKV。