劃指南)
適用版本Redis Open Source 8.2.28.2 為長期支持版本 LTS文檔定位可落地的設計與部署操作手冊編制日期2026 年 9 月1. 概述與設計目標1.1 為什么需要 Redis 分布式Redis 以內(nèi)存讀寫、亞毫秒延遲著稱常被用作緩存、會話存儲、分布式鎖、排行榜、輕量消息與限流組件。單實例 Redis 在生產(chǎn)環(huán)境中存在兩類不可接受的風險。其一是可用性風險進程崩潰、服務器宕機、機房斷電都會使訪問 Redis 的業(yè)務鏈路整體受阻緩存不可用時還可能引發(fā)請求全部回源、壓垮后端數(shù)據(jù)庫的“緩存雪崩”。其二是容量與擴展風險單實例的內(nèi)存容量與單核處理能力存在物理上限業(yè)務數(shù)據(jù)增長或突發(fā)流量到來時縱向升級硬件成本高且有天花板。分布式通過“數(shù)據(jù)分片 多副本”同時解決這兩類問題把鍵空間切分到多個主節(jié)點容量與吞吐隨節(jié)點近線性增長每個主節(jié)點配備副本主節(jié)點故障時副本自動接管實現(xiàn)高可用。1.2 設計目標高可用主節(jié)點故障時自動完成故障轉(zhuǎn)移無需人工切換目標恢復時間RTO為秒級。數(shù)據(jù)可靠主從復制配合持久化主節(jié)點故障盡量不丟數(shù)據(jù)目標數(shù)據(jù)丟失量RPO趨近于零。水平擴展通過增加主節(jié)點并遷移槽位在線擴容業(yè)務無感知容量與 QPS 近線性增長。故障隔離主從副本跨物理機、跨機架、跨可用區(qū)分布避免單機、單柜故障導致主從同時丟失。容量可預測節(jié)點數(shù)由 QPS 與數(shù)據(jù)量通過公式反推預留統(tǒng)一余量、觸水位再擴容。1.3 Redis 8.2 的關鍵特性Redis 8.2 為長期支持版本LTS在開源版本中已正式發(fā)布GA支持周期長適合作為生產(chǎn)標準化版本。性能與內(nèi)存相比 8.0部分命令延遲降低、整體吞吐提升并優(yōu)化了鍵與 JSON 的內(nèi)部存儲、顯著降低內(nèi)存占用。Streams 增強新增 XACKDEL、XDELEX 等命令簡化消費組管理與流生命周期處理。位圖增強BITOP 新增 DIFF、DIFF1 等邏輯運算符可在一條命令內(nèi)完成更復雜的集合運算?？捎^測性新增按槽位per-slot的用量指標與基礎數(shù)據(jù)類型的鍵大小分布便于容量治理。能力內(nèi)置8.x 默認集成搜索、JSON、時序、Bloom 等能力并提供原生向量集合Vector Set以支持語義檢索與 RAG。版本與許可提示本指南命令、參數(shù)與默認值均以 Redis Open Source 8.2.2 為準。Redis 8.x 采用 RSALv2 與 SSPLv1 雙許可對云托管轉(zhuǎn)售場景有約束企業(yè)內(nèi)部自用通常不受影響若有合規(guī)疑慮可評估基于寬松許可的開源分支。集群槽位總數(shù)在 8.2 中仍為 16384。2. 核心概念與部署模式選型2.1 四種部署模式對比部署模式數(shù)據(jù)分片自動故障轉(zhuǎn)移容量 / 吞吐適用場景單機 standalone無無受限于單機開發(fā)測試、非關鍵場景主從復制無需人工或腳本讀可擴展、寫仍單點讀多寫少、可接受人工切換Sentinel 哨兵無有哨兵投票寫仍單點、內(nèi)存單機數(shù)據(jù)量小、只需高可用原生 Cluster16384 槽分片有集群內(nèi)置隨主節(jié)點近線性擴展生產(chǎn)大容量、高并發(fā)推薦2.2 主從復制原理主從復制中副本replica通過replicaof舊稱slaveof指向主節(jié)點。首次連接時進行全量同步主節(jié)點生成 RDB 快照發(fā)送給副本副本加載后追平之后通過復制積壓緩沖區(qū)replication backlog持續(xù)進行增量同步。網(wǎng)絡中斷恢復后若偏移量仍在積壓緩沖范圍內(nèi)則只補增量否則重新全量。復制默認為異步主節(jié)點寫成功即返回副本稍后追平因此極端情況下主節(jié)點宕機可能丟失尚未復制的少量寫入。可使用無盤復制repl-diskless-sync直接通過套接字發(fā)送 RDB降低主節(jié)點磁盤壓力。WAIT命令可阻塞等待指定數(shù)量副本確認用于在關鍵寫入上增強一致性但會犧牲部分延遲。2.3 Sentinel 的定位與邊界Sentinel 是獨立部署的哨兵進程通過監(jiān)控、通知、自動故障轉(zhuǎn)移與配置提供四項能力。主節(jié)點故障時多個 Sentinel 經(jīng)主觀下線SDOWN、客觀下線ODOWN判定后選舉領導者將一個副本提升為主并通知客戶端更新地址。Sentinel 不做分片Sentinel 只解決“單點故障自動切換”數(shù)據(jù)仍全部集中在一個主節(jié)點上內(nèi)存與寫吞吐無法水平擴展。當數(shù)據(jù)量或?qū)?QPS 超過單機能力時應直接使用原生 Cluster而非 Sentinel。2.4 為什么生產(chǎn)選擇原生 Cluster同時具備分片與高可用16384 槽均分到多個主節(jié)點每個主節(jié)點掛副本容量、讀寫均可水平擴展。故障轉(zhuǎn)移內(nèi)置無需額外部署 Sentinel集群節(jié)點通過 gossip 互相探測并投票完成切換。在線擴縮容新增主節(jié)點只需遷入部分槽位下線節(jié)點只需遷出槽位過程業(yè)務無感。生態(tài)成熟Lettuce、Jedis、redis-py 等主流客戶端均原生支持集群路由與自動刷新。3. Redis Cluster 分片與高可用原理3.1 16384 個哈希槽與鍵定位Redis Cluster 不使用一致性哈希而是把全部鍵空間固定劃分為16384 個哈希槽。鍵所屬槽位由 CRC16 校驗值對 16384 取模得到slot CRC16(key) mod 16384 # 例3 個主節(jié)點時槽位均分redis-cli --cluster 自動分配 # master-A: slots 0-5460 # master-B: slots 5461-10922 # master-C: slots 10923-16383槽位數(shù)固定為 16384不隨節(jié)點數(shù)變化。這樣在增刪節(jié)點、遷移槽位時鍵到槽位的映射保持穩(wěn)定只需在節(jié)點間搬運槽位無需對全部鍵重新哈希。官方取 16384 的原因之一是節(jié)點心跳會攜帶本節(jié)點負責槽位的位圖16384 位約 2KB在建議的集群規(guī)模約千節(jié)點內(nèi)網(wǎng)絡開銷可控。3.2 Gossip 協(xié)議與集群總線集群中每個節(jié)點定期通過 gossip 向其他節(jié)點發(fā)送 PING/PONG消息中攜帶部分節(jié)點的狀態(tài)存活、槽位、主從、復制偏移等最終所有節(jié)點收斂到一致的集群拓撲。節(jié)點間通過集群總線端口通信端口號默認為客戶端端口 10000如 6379 對應 16379需在防火墻 / 安全組放通?？蛻舳硕丝?379接收業(yè)務命令總線端口16379只用于節(jié)點間通信二者協(xié)議不同。3.3 故障檢測PFAIL 與 FAILPFAIL主觀下線節(jié)點 A 在cluster-node-timeout內(nèi)未收到節(jié)點 B 的 PONGA 在本地把 B 標記為 PFAIL僅 A 自己可見不可信。FAIL客觀下線當集群中“負責槽位的主節(jié)點”里有超過半數(shù)都報告 B 為 PFAIL任一節(jié)點把 B 升級為 FAIL并通過 gossip 向全集群廣播。3.4 自動故障轉(zhuǎn)移故障主節(jié)點的副本檢測到主為 FAIL該主的多個副本按復制偏移數(shù)據(jù)新舊、優(yōu)先級等排序確定候選候選副本向集群中其他健康主節(jié)點請求投票獲得多數(shù)主節(jié)點投票的副本當選當選副本執(zhí)行提升相當于SLAVEOF NO ONE接管原主全部槽位新主通過 gossip 廣播新拓撲客戶端按重定向刷新路由原故障節(jié)點恢復后作為副本重新加入并追平數(shù)據(jù)。副本是自動切換的前提若故障主節(jié)點沒有任何存活副本則其槽位無主。cluster-require-full-coverage為 yes默認時整個集群停止對外服務設為 no 時僅該部分槽位不可用、其余槽位繼續(xù)。因此每個主節(jié)點至少配備一個副本是高可用的硬性要求。3.5 MOVED 與 ASK 重定向MOVED槽位已永久歸屬另一個節(jié)點。客戶端收到后應更新本地槽位路由表并向正確節(jié)點重試該命令。ASK槽位正處于在線遷移過程中僅本次臨時重定向到目標節(jié)點客戶端不應更新本地路由表。支持集群的客戶端Lettuce、Jedis Cluster、redis-py Cluster會自動處理重定向并在拓撲變化時刷新業(yè)務通常無感知。3.6 Hash Tag 與多鍵約束集群要求多鍵命令MGET/MSET、事務 MULTI、Lua 腳本涉及的鍵必須位于同一槽位否則返回CROSSSLOT錯誤。通過 Hash Tag即鍵名中第一個花括號{ }內(nèi)的子串參與槽位計算可把一組相關鍵強制歸到同一槽位# 只有 { } 內(nèi)的部分參與 CRC16下列鍵落在同一槽位可原子操作user:{100}.base user:{100}.profile user:{100}.counters# 注意集群模式只使用 db0不支持 SELECT 切換多個邏輯庫3.7 副本拓撲與機架分布每個主節(jié)點可配置一個或多個副本副本不直接對外提供寫讀可經(jīng)READONLY在副本上分攤。主節(jié)點與它的副本必須分散在不同物理機、機架最好跨可用區(qū)避免單機、單柜故障同時摧毀主從。Redis Cluster 不內(nèi)置機架感知標簽需通過部署規(guī)劃、調(diào)度反親和保證K8s 用podAntiAffinity。4. 容量規(guī)劃公式容量規(guī)劃要回答四個問題需要多少個主節(jié)點、每個主配幾個副本、共多少實例、是否需要拆分多集群。主節(jié)點數(shù)由“QPS”和“內(nèi)存數(shù)據(jù)量”兩條線分別反推取較大值。4.1 關鍵輸入指標輸入指標符號說明 / 采集方式峰值總 QPSQ讀寫每秒命令數(shù)取業(yè)務高峰峰值其中寫 / 讀 QPSW / Rq寫不可由副本分攤讀可在只讀副本擴展熱數(shù)據(jù)量DGB需駐留內(nèi)存的鍵與數(shù)據(jù)結構總字節(jié)單實例內(nèi)存上限m通用 25GB大內(nèi)存機型可取 40GB數(shù)據(jù)增長周期g按 6~12 個月增長預留納入余量4.2 單節(jié)點能力基線能力單元經(jīng)驗安全值取值依據(jù)單主承載 QPS6 萬GET/SET 混合、適度 pipeline理論峰值約 8~10 萬按 60% 取安全值單實例內(nèi)存上限25GB大內(nèi)存機 40GB實例越小RDB/AOF 重寫、重啟加載與故障轉(zhuǎn)移越快能力值必須壓測校準單節(jié)點能力隨命令復雜度、讀寫比例、是否開啟多線程 I/O、持久化策略與硬件而變化。正式規(guī)劃應在目標硬件上用redis-benchmark壓測用實測值替換公式中的 60000 與 25。4.3 主節(jié)點數(shù)公式# QPS 線按單主安全 6 萬 M_qps ceil( Q / 60000 ) # 內(nèi)存線按單實例 m GB默認 25 M_mem ceil( D / m ) # 主節(jié)點數(shù)兩條線取大且集群至少 3 個主節(jié)點 M max( M_qps, M_mem, 3 )4.4 副本數(shù)與讀擴展公式# 基礎高可用每個主至少 1 個副本 # 讀擴展副本執(zhí)行 READONLY 后可分擔讀異步復制可能讀到略舊數(shù)據(jù) # 保守起見把主節(jié)點讀能力留給突發(fā)讀壓力由副本承擔 每主副本數(shù) R max( 1, ceil( Rq / (M × 60000) ) ) # 不可重建的關鍵數(shù)據(jù)會話、分布式鎖可取 R 24.5 實例總數(shù)與物理內(nèi)存核算實例總數(shù) M × (1 R) # maxmemory 建議 ≤ 物理內(nèi)存的 60%為內(nèi)存碎片、AOF 重寫 # 的寫時復制COW、客戶端與復制緩沖留足空間 單機所需物理內(nèi)存 單機承載數(shù)據(jù)量 / 0.6 # 例單機 1主1從、每實例 25GB # 需 (2525)/0.6 ≈ 83GB工程取 96/128GB 機型4.6 集群數(shù)量公式單集群主節(jié)點過多會放大 gossip 通信與故障切換的影響面。工程上建議單集群主節(jié)點控制在約16~20 個以內(nèi)超過則按業(yè)務域拆分為多套獨立 Cluster。集群數(shù) K max( 1, ceil( M / 16 ) ) # 多集群之間不自動同步數(shù)據(jù)鍵與多鍵操作必須在設計上按業(yè)務域隔離 # 跨集群復制需借助外部同步任務不能像單集群那樣透明訪問4.7 容量余量與水位統(tǒng)一預留25%~30%余量用于突發(fā)流量與數(shù)據(jù)增長。QPS / CPU 水位70% 關注、80% 擴容、85%~90% 緊急限流。內(nèi)存通過maxmemory與淘汰策略maxmemory-policy兜底緩存場景一般用allkeys-lru。擴容周期長的物理機 / 內(nèi)存應在 70% 水位即啟動采購避免高水位被動。5. 完整推算算例本章給出五個算例完整演示如何把業(yè)務負載代入第 4 章公式逐步推算主節(jié)點、副本、實例與集群數(shù)。前四個對應 S/M/L/XL 四檔基線第五個演示讀多寫少場景下用副本而非主節(jié)點做讀擴展。5.1 算例一小型2 萬 QPS30GB輸入總 QPS Q20000熱數(shù)據(jù) D30GBm25GB步驟 1 兩條線 M_qps ceil(20000/60000) 1 M_mem ceil(30/25) 2 步驟 2 主節(jié)點M max(1, 2, 3) 3 步驟 3 副本與實例R1實例 3×(11) 6 步驟 4 集群K ceil(3/16) 1結論1 套集群、3 主 3 從共 6 實例建議 3 臺物理機、單機 1主1從64GB 機型。每主約 10GB、承載約 6700 QPS余量充裕。5.2 算例二中型10 萬 QPS200GB輸入Q100000D200GBM_qps ceil(100000/60000) 2 M_mem ceil(200/25) 8 M max(2, 8, 3) 8 R1實例 8×2 16集群 K1結論1 套集群、8 主 8 從共 16 實例建議 8 臺物理機、單機 1主1從128GB。該規(guī)模由“內(nèi)存”主導QPS 線只需 2 主內(nèi)存線需 8 主每主恰好約 25GB。5.3 算例三大型40 萬 QPS500GB輸入Q400000D500GBM_qps ceil(400000/60000) 7 M_mem ceil(500/25) 20 M max(7, 20, 3) 20 R1實例 20×2 40集群 K1 Redis 8.2.2 分布式集群設計與容量規(guī)劃指南
適用版本Redis Open Source 8.2.28.2 為長期支持版本 LTS文檔定位可落地的設計與部署操作手冊編制日期2026 年 9 月1. 概述與設計目標1.1 為什么需要 Redis 分布式Redis 以內(nèi)存讀寫、亞毫秒延遲著稱常被用作緩存、會話存儲、分布式鎖、排行榜、輕量消息與限流組件。單實例 Redis 在生產(chǎn)環(huán)境中存在兩類不可接受的風險。其一是可用性風險進程崩潰、服務器宕機、機房斷電都會使訪問 Redis 的業(yè)務鏈路整體受阻緩存不可用時還可能引發(fā)請求全部回源、壓垮后端數(shù)據(jù)庫的“緩存雪崩”。其二是容量與擴展風險單實例的內(nèi)存容量與單核處理能力存在物理上限業(yè)務數(shù)據(jù)增長或突發(fā)流量到來時縱向升級硬件成本高且有天花板。分布式通過“數(shù)據(jù)分片 多副本”同時解決這兩類問題把鍵空間切分到多個主節(jié)點容量與吞吐隨節(jié)點近線性增長每個主節(jié)點配備副本主節(jié)點故障時副本自動接管實現(xiàn)高可用。1.2 設計目標高可用主節(jié)點故障時自動完成故障轉(zhuǎn)移無需人工切換目標恢復時間RTO為秒級。數(shù)據(jù)可靠主從復制配合持久化主節(jié)點故障盡量不丟數(shù)據(jù)目標數(shù)據(jù)丟失量RPO趨近于零。水平擴展通過增加主節(jié)點并遷移槽位在線擴容業(yè)務無感知容量與 QPS 近線性增長。故障隔離主從副本跨物理機、跨機架、跨可用區(qū)分布避免單機、單柜故障導致主從同時丟失。容量可預測節(jié)點數(shù)由 QPS 與數(shù)據(jù)量通過公式反推預留統(tǒng)一余量、觸水位再擴容。1.3 Redis 8.2 的關鍵特性Redis 8.2 為長期支持版本LTS在開源版本中已正式發(fā)布GA支持周期長適合作為生產(chǎn)標準化版本。性能與內(nèi)存相比 8.0部分命令延遲降低、整體吞吐提升并優(yōu)化了鍵與 JSON 的內(nèi)部存儲、顯著降低內(nèi)存占用。Streams 增強新增 XACKDEL、XDELEX 等命令簡化消費組管理與流生命周期處理。位圖增強BITOP 新增 DIFF、DIFF1 等邏輯運算符可在一條命令內(nèi)完成更復雜的集合運算?？捎^測性新增按槽位per-slot的用量指標與基礎數(shù)據(jù)類型的鍵大小分布便于容量治理。能力內(nèi)置8.x 默認集成搜索、JSON、時序、Bloom 等能力并提供原生向量集合Vector Set以支持語義檢索與 RAG。版本與許可提示本指南命令、參數(shù)與默認值均以 Redis Open Source 8.2.2 為準。Redis 8.x 采用 RSALv2 與 SSPLv1 雙許可對云托管轉(zhuǎn)售場景有約束企業(yè)內(nèi)部自用通常不受影響若有合規(guī)疑慮可評估基于寬松許可的開源分支。集群槽位總數(shù)在 8.2 中仍為 16384。2. 核心概念與部署模式選型2.1 四種部署模式對比部署模式數(shù)據(jù)分片自動故障轉(zhuǎn)移容量 / 吞吐適用場景單機 standalone無無受限于單機開發(fā)測試、非關鍵場景主從復制無需人工或腳本讀可擴展、寫仍單點讀多寫少、可接受人工切換Sentinel 哨兵無有哨兵投票寫仍單點、內(nèi)存單機數(shù)據(jù)量小、只需高可用原生 Cluster16384 槽分片有集群內(nèi)置隨主節(jié)點近線性擴展生產(chǎn)大容量、高并發(fā)推薦2.2 主從復制原理主從復制中副本replica通過replicaof舊稱slaveof指向主節(jié)點。首次連接時進行全量同步主節(jié)點生成 RDB 快照發(fā)送給副本副本加載后追平之后通過復制積壓緩沖區(qū)replication backlog持續(xù)進行增量同步。網(wǎng)絡中斷恢復后若偏移量仍在積壓緩沖范圍內(nèi)則只補增量否則重新全量。復制默認為異步主節(jié)點寫成功即返回副本稍后追平因此極端情況下主節(jié)點宕機可能丟失尚未復制的少量寫入。可使用無盤復制repl-diskless-sync直接通過套接字發(fā)送 RDB降低主節(jié)點磁盤壓力。WAIT命令可阻塞等待指定數(shù)量副本確認用于在關鍵寫入上增強一致性但會犧牲部分延遲。2.3 Sentinel 的定位與邊界Sentinel 是獨立部署的哨兵進程通過監(jiān)控、通知、自動故障轉(zhuǎn)移與配置提供四項能力。主節(jié)點故障時多個 Sentinel 經(jīng)主觀下線SDOWN、客觀下線ODOWN判定后選舉領導者將一個副本提升為主并通知客戶端更新地址。Sentinel 不做分片Sentinel 只解決“單點故障自動切換”數(shù)據(jù)仍全部集中在一個主節(jié)點上內(nèi)存與寫吞吐無法水平擴展。當數(shù)據(jù)量或?qū)?QPS 超過單機能力時應直接使用原生 Cluster而非 Sentinel。2.4 為什么生產(chǎn)選擇原生 Cluster同時具備分片與高可用16384 槽均分到多個主節(jié)點每個主節(jié)點掛副本容量、讀寫均可水平擴展。故障轉(zhuǎn)移內(nèi)置無需額外部署 Sentinel集群節(jié)點通過 gossip 互相探測并投票完成切換。在線擴縮容新增主節(jié)點只需遷入部分槽位下線節(jié)點只需遷出槽位過程業(yè)務無感。生態(tài)成熟Lettuce、Jedis、redis-py 等主流客戶端均原生支持集群路由與自動刷新。3. Redis Cluster 分片與高可用原理3.1 16384 個哈希槽與鍵定位Redis Cluster 不使用一致性哈希而是把全部鍵空間固定劃分為16384 個哈希槽。鍵所屬槽位由 CRC16 校驗值對 16384 取模得到slot CRC16(key) mod 16384 # 例3 個主節(jié)點時槽位均分redis-cli --cluster 自動分配 # master-A: slots 0-5460 # master-B: slots 5461-10922 # master-C: slots 10923-16383槽位數(shù)固定為 16384不隨節(jié)點數(shù)變化。這樣在增刪節(jié)點、遷移槽位時鍵到槽位的映射保持穩(wěn)定只需在節(jié)點間搬運槽位無需對全部鍵重新哈希。官方取 16384 的原因之一是節(jié)點心跳會攜帶本節(jié)點負責槽位的位圖16384 位約 2KB在建議的集群規(guī)模約千節(jié)點內(nèi)網(wǎng)絡開銷可控。3.2 Gossip 協(xié)議與集群總線集群中每個節(jié)點定期通過 gossip 向其他節(jié)點發(fā)送 PING/PONG消息中攜帶部分節(jié)點的狀態(tài)存活、槽位、主從、復制偏移等最終所有節(jié)點收斂到一致的集群拓撲。節(jié)點間通過集群總線端口通信端口號默認為客戶端端口 10000如 6379 對應 16379需在防火墻 / 安全組放通?？蛻舳硕丝?379接收業(yè)務命令總線端口16379只用于節(jié)點間通信二者協(xié)議不同。3.3 故障檢測PFAIL 與 FAILPFAIL主觀下線節(jié)點 A 在cluster-node-timeout內(nèi)未收到節(jié)點 B 的 PONGA 在本地把 B 標記為 PFAIL僅 A 自己可見不可信。FAIL客觀下線當集群中“負責槽位的主節(jié)點”里有超過半數(shù)都報告 B 為 PFAIL任一節(jié)點把 B 升級為 FAIL并通過 gossip 向全集群廣播。3.4 自動故障轉(zhuǎn)移故障主節(jié)點的副本檢測到主為 FAIL該主的多個副本按復制偏移數(shù)據(jù)新舊、優(yōu)先級等排序確定候選候選副本向集群中其他健康主節(jié)點請求投票獲得多數(shù)主節(jié)點投票的副本當選當選副本執(zhí)行提升相當于SLAVEOF NO ONE接管原主全部槽位新主通過 gossip 廣播新拓撲客戶端按重定向刷新路由原故障節(jié)點恢復后作為副本重新加入并追平數(shù)據(jù)。副本是自動切換的前提若故障主節(jié)點沒有任何存活副本則其槽位無主。cluster-require-full-coverage為 yes默認時整個集群停止對外服務設為 no 時僅該部分槽位不可用、其余槽位繼續(xù)。因此每個主節(jié)點至少配備一個副本是高可用的硬性要求。3.5 MOVED 與 ASK 重定向MOVED槽位已永久歸屬另一個節(jié)點。客戶端收到后應更新本地槽位路由表并向正確節(jié)點重試該命令。ASK槽位正處于在線遷移過程中僅本次臨時重定向到目標節(jié)點客戶端不應更新本地路由表。支持集群的客戶端Lettuce、Jedis Cluster、redis-py Cluster會自動處理重定向并在拓撲變化時刷新業(yè)務通常無感知。3.6 Hash Tag 與多鍵約束集群要求多鍵命令MGET/MSET、事務 MULTI、Lua 腳本涉及的鍵必須位于同一槽位否則返回CROSSSLOT錯誤。通過 Hash Tag即鍵名中第一個花括號{ }內(nèi)的子串參與槽位計算可把一組相關鍵強制歸到同一槽位# 只有 { } 內(nèi)的部分參與 CRC16下列鍵落在同一槽位可原子操作user:{100}.base user:{100}.profile user:{100}.counters# 注意集群模式只使用 db0不支持 SELECT 切換多個邏輯庫3.7 副本拓撲與機架分布每個主節(jié)點可配置一個或多個副本副本不直接對外提供寫讀可經(jīng)READONLY在副本上分攤。主節(jié)點與它的副本必須分散在不同物理機、機架最好跨可用區(qū)避免單機、單柜故障同時摧毀主從。Redis Cluster 不內(nèi)置機架感知標簽需通過部署規(guī)劃、調(diào)度反親和保證K8s 用podAntiAffinity。4. 容量規(guī)劃公式容量規(guī)劃要回答四個問題需要多少個主節(jié)點、每個主配幾個副本、共多少實例、是否需要拆分多集群。主節(jié)點數(shù)由“QPS”和“內(nèi)存數(shù)據(jù)量”兩條線分別反推取較大值。4.1 關鍵輸入指標輸入指標符號說明 / 采集方式峰值總 QPSQ讀寫每秒命令數(shù)取業(yè)務高峰峰值其中寫 / 讀 QPSW / Rq寫不可由副本分攤讀可在只讀副本擴展熱數(shù)據(jù)量DGB需駐留內(nèi)存的鍵與數(shù)據(jù)結構總字節(jié)單實例內(nèi)存上限m通用 25GB大內(nèi)存機型可取 40GB數(shù)據(jù)增長周期g按 6~12 個月增長預留納入余量4.2 單節(jié)點能力基線能力單元經(jīng)驗安全值取值依據(jù)單主承載 QPS6 萬GET/SET 混合、適度 pipeline理論峰值約 8~10 萬按 60% 取安全值單實例內(nèi)存上限25GB大內(nèi)存機 40GB實例越小RDB/AOF 重寫、重啟加載與故障轉(zhuǎn)移越快能力值必須壓測校準單節(jié)點能力隨命令復雜度、讀寫比例、是否開啟多線程 I/O、持久化策略與硬件而變化。正式規(guī)劃應在目標硬件上用redis-benchmark壓測用實測值替換公式中的 60000 與 25。4.3 主節(jié)點數(shù)公式# QPS 線按單主安全 6 萬 M_qps ceil( Q / 60000 ) # 內(nèi)存線按單實例 m GB默認 25 M_mem ceil( D / m ) # 主節(jié)點數(shù)兩條線取大且集群至少 3 個主節(jié)點 M max( M_qps, M_mem, 3 )4.4 副本數(shù)與讀擴展公式# 基礎高可用每個主至少 1 個副本 # 讀擴展副本執(zhí)行 READONLY 后可分擔讀異步復制可能讀到略舊數(shù)據(jù) # 保守起見把主節(jié)點讀能力留給突發(fā)讀壓力由副本承擔 每主副本數(shù) R max( 1, ceil( Rq / (M × 60000) ) ) # 不可重建的關鍵數(shù)據(jù)會話、分布式鎖可取 R 24.5 實例總數(shù)與物理內(nèi)存核算實例總數(shù) M × (1 R) # maxmemory 建議 ≤ 物理內(nèi)存的 60%為內(nèi)存碎片、AOF 重寫 # 的寫時復制COW、客戶端與復制緩沖留足空間 單機所需物理內(nèi)存 單機承載數(shù)據(jù)量 / 0.6 # 例單機 1主1從、每實例 25GB # 需 (2525)/0.6 ≈ 83GB工程取 96/128GB 機型4.6 集群數(shù)量公式單集群主節(jié)點過多會放大 gossip 通信與故障切換的影響面。工程上建議單集群主節(jié)點控制在約16~20 個以內(nèi)超過則按業(yè)務域拆分為多套獨立 Cluster。集群數(shù) K max( 1, ceil( M / 16 ) ) # 多集群之間不自動同步數(shù)據(jù)鍵與多鍵操作必須在設計上按業(yè)務域隔離 # 跨集群復制需借助外部同步任務不能像單集群那樣透明訪問4.7 容量余量與水位統(tǒng)一預留25%~30%余量用于突發(fā)流量與數(shù)據(jù)增長。QPS / CPU 水位70% 關注、80% 擴容、85%~90% 緊急限流。內(nèi)存通過maxmemory與淘汰策略maxmemory-policy兜底緩存場景一般用allkeys-lru。擴容周期長的物理機 / 內(nèi)存應在 70% 水位即啟動采購避免高水位被動。5. 完整推算算例本章給出五個算例完整演示如何把業(yè)務負載代入第 4 章公式逐步推算主節(jié)點、副本、實例與集群數(shù)。前四個對應 S/M/L/XL 四檔基線第五個演示讀多寫少場景下用副本而非主節(jié)點做讀擴展。5.1 算例一小型2 萬 QPS30GB輸入總 QPS Q20000熱數(shù)據(jù) D30GBm25GB步驟 1 兩條線 M_qps ceil(20000/60000) 1 M_mem ceil(30/25) 2 步驟 2 主節(jié)點M max(1, 2, 3) 3 步驟 3 副本與實例R1實例 3×(11) 6 步驟 4 集群K ceil(3/16) 1結論1 套集群、3 主 3 從共 6 實例建議 3 臺物理機、單機 1主1從64GB 機型。每主約 10GB、承載約 6700 QPS余量充裕。5.2 算例二中型10 萬 QPS200GB輸入Q100000D200GBM_qps ceil(100000/60000) 2 M_mem ceil(200/25) 8 M max(2, 8, 3) 8 R1實例 8×2 16集群 K1結論1 套集群、8 主 8 從共 16 實例建議 8 臺物理機、單機 1主1從128GB。該規(guī)模由“內(nèi)存”主導QPS 線只需 2 主內(nèi)存線需 8 主每主恰好約 25GB。5.3 算例三大型40 萬 QPS500GB輸入Q400000D500GBM_qps ceil(400000/60000) 7 M_mem ceil(500/25) 20 M max(7, 20, 3) 20 R1實例 20×2 40集群 K1