Redis 8.4 在性能與開發體驗上全面升級，並引入全新的混合搜索能力，讓構建 AI 應用的速度和便捷性再上一個台階。其推出的混合搜索（hybrid search）功能，將全文搜索與向量搜索融為一體，實現更靈活、更智能的查詢，同時在性能與內存利用率上帶來顯著提升。通過對 Redis Streams 邏輯的優化和一系列新增原子操作，Redis 在大規模場景下的運維也變得更加簡單可靠。

混合搜索重磅登場

從檢索增強生成（RAG）系統到自主助理，智能體的性能取決於上下文質量。真正的挑戰不在於獲取數據，而在於理解數據——識別哪些信息是當前相關的、哪些存儲於記憶、哪些可為決策提供推理依據。智能體需以語義方式搜索“記憶”，而非依賴字面召回，並將符號推理與語義相似度結合。

Redis 一直是實時決策與上下文檢索的核心，開發者長期利用混合策略預先過濾候選集，以高效縮小向量搜索空間。

過去，全文與向量相似度的融合方法複雜繁瑣，需多步操作，並在精度與性能間權衡，導致延遲上升、檢索體驗割裂。Redis 8.4 通過全新的 FT.HYBRID 命令解決了這些問題——這一統一的引擎內混合檢索 API 通過評分融合（倒數排序融合或線性組合）在一次查詢中合併全文與向量相似度結果，生成單一排序列表，同時捕捉語義和字面匹配。這意味着無需在精度與間取捨，也無需外部評分合並。FT.HYBRID 可直接在查詢中表達上下文意圖，便捷優先檢索近期記憶，利用 GEO 和 GEOSHAPE 限定地理範圍，並融合語義、模糊與精確匹配，為新一代智能體構建一致、高速且具備語義感知的檢索管道。

史上最快、資源效率最高的 Redis

Redis 8.4 繼續踐行 Redis 對持續性能優化的承諾。下圖展示了 Redis 在典型緩存工作負載下，吞吐量（每秒操作數）在各版本間的穩步增長趨勢。

8.4 版本延續這一趨勢，相比 Redis 8.2，緩存場景（90% GET、10% SET）的吞吐量提升超過 30%。

通過在分佈式查詢中引入多線程 I/O 處理，Redis 查詢引擎在高負載環境下實現了顯著的性能提升。在從多個分片檢索大規模結果時，併發 I/O 線程可並行處理分片響應，而非依次執行。這有效消除了單線程瓶頸帶來的 CPU 飽和與吞吐受限問題，並緩解了大型集羣中的長時間排隊現象，從而使系統能夠充分發揮各分片的計算潛力，降低資源競爭，提升查詢扇出與結果聚合的流暢性。

基準測試表明，這些改進為 FT.SEARCH 和 FT.AGGREGATE 操作帶來了端到端的顯著提升，新增的 FT.HYBRID 自然也受益於此。在大規模搜索工作負載下，並行 I/O 處理使吞吐量提升達 4.7 倍，同時同比例降低查詢延遲。涉及額外後處理的聚合操作同樣獲益，吞吐量提升約 1.4 倍，並在併發負載下縮短響應時間。在這兩種場景下，多線程 I/O 為工作線程騰出了更多空間來執行實際的搜索或聚合邏輯，確保集羣資源得到更均衡的利用，並在搜索與向量工作負載中實現更快響應。

Redis 還優化了查詢執行的內存分配管理，讓 Redis 查詢引擎更加健壯。開發者現在可以自定義內存溢出（OOM）時的行為。通過新增配置項 search-on-oom，可全面管理內存消耗方式及引擎應對策略。

Redis 繼續投入降低 JSON 數據類型的內存佔用。Redis 8.2 通過內聯數值實現了大幅縮減，Redis 8.4 則進一步內聯短字符串（最多 7 字節）。例如，包含 500 個鍵值元素的 JSON 數組，若所有鍵值均為短字符串，內存佔用將減少 37%：

更重要的是，Redis 如今能夠更高效地存儲同質 JSON 數值數組。在 8.4 版本之前，JSON 數組的每個元素都需分別存儲類型和值。現在，當數組為同質（即所有元素數據類型一致）時，僅需為整個數組存儲一次元素類型。對於數值數組，Redis 會自動選擇最高效的元素類型（I8、U8、I16、U16、I32、U32、I64、U64、BF16、FP16、FP32 或 FP64），保證所有值均在範圍內且無精度損失。例如，對於包含 100 萬個數值的 JSON 數組，內存佔用可減少 50% 至 92%。

用一條命令消費空閒待處理消息與新增消息

在 Redis Streams 中，待處理消息是指已投遞至消費者組內的消費者但尚未確認的消息，這些消息會一直保留，直到被確認或刪除。若消息長時間處於待處理狀態，通常意味着出現異常——可能是消費客户端在處理或發送確認前崩潰，可能是消息本身存在問題（如引發死鎖或處理耗時過長），也可能是消費客户端與 Redis 之間的通信發生故障。

在正常流程中，應用期望每條消息在消費後的一定時間內完成確認。若未確認，則被視為空閒待處理消息，可嘗試重新投遞。鑑於流式消息處理易出錯，需要簡潔且可靠的恢復機制。

因此，消費者既應（1）監控待處理消息列表、認領並處理空閒消息，也應（2）處理新流入的消息。

在 Redis 8.4 之前，客户端必須實現複雜邏輯才能同時消費這兩類消息。

Redis 8.4 為 XREADGROUP 命令引入了簡潔而強大的擴展，允許客户端用單條命令消費空閒待處理消息與新增消息。

字符串鍵新增原子 compare-and-set 與 compare-and-delete 命令

Compare-and-set（又稱 check-and-set、compare-and-swap）和 compare-and-delete 是實現單鍵樂觀併發控制的原子方法。使用 compare-and-set 時，客户端可以：

1. 從服務端獲取值，在應用側保存為"舊值"
2. 在本地修改該值副本
3. Compare-and-set：僅在服務端值未被其他客户端修改時（即服務端值仍等於舊值），將本地變更應用到服務端

假設存在一個 Product:Description 字符串鍵，用於讓用户編輯產品描述（如通過網頁表單）。由於每個產品描述的修改頻率較低，可採用樂觀併發控制，僅在該值自獲取後未被其他客户端更改時才更新。

在舊版 Redis 中，若需原子化執行此過程的第三步，必須編寫自定義 Lua 腳本。自 Redis 8.4 起，客户端可通過單條命令（在 SET 中使用 IFEQ、IFNE、IFDEQ 或 IFDNE 選項）在字符串鍵值未發生變化時直接更新，更加簡潔高效。類似地，引入了單條命令 XDELEX 實現比較並刪除，即僅在字符串鍵值未變時原子刪除。

原子設置多個字符串鍵並更新過期時間的新命令

批量設置多個鍵並統一設置過期時間是常見需求，通常還要求僅在所有指定鍵已存在或均不存在時才執行設置操作。

在 Redis 8.4 之前，這一常見需求需要自定義 Lua 腳本支持。

Redis 8.4 引入了更簡單快速的方案。新的單條命令 MSETEX 可條件性地批量設置或更新多個字符串鍵的值與過期時間。

原子槽遷移簡化集羣運維

Redis 集羣是一種為實現高可用、可擴展性與容錯能力而設計的分佈式架構。它將多個 Redis 節點連接起來，使數據與流量得以分佈到各個節點。Redis 集羣通過 16,384 個哈希槽自動拆分並分發數據，每個節點負責持有部分哈希槽，從而支持遠超單機規模的數據集。

在兩種主要場景下需要改變槽與節點的映射關係，即必須在節點間遷移鍵：

• ​集羣重平衡​：添加新節點後，集羣需將部分哈希槽（及其中鍵）遷移至新節點，使數據分佈更均衡。移除節點前，同樣需將其槽重新分配給其他節點。
• ​處理過載節點​：由於鍵內容與訪問模式，特定槽或節點可能需要更多資源（內存、算力、每秒操作數或網絡吞吐量）。當節點過載時，可將其槽重新分配以實現更好的性能與資源利用率，這需要從過載節點向負載較輕節點遷移槽。

此前的槽遷移是非原子的。遷移過程中，鍵逐個移動到目標節點再從源節點刪除，這會帶來諸多潛在問題：

• ​重定向與客户端複雜度​：遷移期間，部分鍵可能已移動而其他尚未移動。若客户端訪問已遷移的鍵，會收到 -ASK 回覆，必須轉向目標節點重試，增加複雜度與網絡延遲，還會破壞簡單的管道操作。
• ​多鍵操作在 Resharding 時不可靠​​：在 MGET key1 key2 等多鍵命令中，若部分鍵已遷移，客户端會收到 TRYAGAIN 回覆，必須等待整個槽遷移完成才能執行命令。
• ​遷移失敗導致異常狀態​：部分鍵已移動，但因目標節點內存不足等原因未能刪除剩餘鍵時，Redis 會陷入需手動修復的異常狀態，常導致數據丟失。
• ​複製問題​：副本不一定知道槽正在遷移，可能將鍵視為普通刪除而非發出 -ASK 重定向。
• ​性能​：逐鍵遷移速度慢。傳統方法中鍵實際上逐個移動，因額外查找和網絡往返而效率低下。

Redis 8.4 引入原子槽遷移（ASM）解決所有這些運維問題。ASM 類似於槽級別的全量同步複製，它會將完整槽內容複製到目標節點，加上實時增量流（類似複製積壓）。僅在複製完成後，Redis 才執行單次原子所有權交接。複製過程中客户端仍與源節點通信，不會遇到上述遷移中期的任何問題，從而極大提升了大規模運維 Redis 開源版的管理體驗。

立即開始使用 Redis 8.4

所有上述增強功能現已在 Redis 8.4 開源版中正式發佈。

關注並私信“艾體寶IT”，立即下載 Redis 8.4 開始使用！