（一）寫在前面：為什么需要“軍規”
Redis 在測試環境跑得飛快，一到線上就“莫名其妙”抖動；大促前擴容 3 倍，成本卻翻 5 倍；一次主從切換，緩存雪崩導致下游 DB 被打掛；開發說“Redis 是緩存，丟點數據無所謂”，結果用戶下單重復扣款。
這些問題背后，是缺乏體系化的方法論。本文以“軍規”形式，總結 40 條血淚經驗，覆蓋容量、性能、高可用、成本、監控、演練、治理七大主題。
（二）容量規劃 6 條軍規
軍規 1：不要用“峰值 QPS × 平均 value 大小”估算內存。
真實公式：
memory = (key 總數 × (key 長度 + value 長度 + 56B 元數據)) × 1.3（碎片因子） + 復制 backlog + client 緩沖區 + AOF 重寫緩沖區。
軍規 2：提前 6 個月規劃 TTL。
業務方往往拍腦袋寫 86400s，結果 90% key 3 小時后就無訪問。TTL 減半，內存立省一半，但需評估擊穿風險。
軍規 3：冷熱分級。
把 30 天未訪問的 key 遷移到 SSD Redis 或 OSS，接口延遲從 1 ms 漲到 5 ms，但內存成本降 70%。
軍規 4：預分配集群槽位。
不要等 1000 個節點再擴容，提前按業務域分池，避免跨槽事務。
軍規 5：預留 20% 內存給復制與 AOF。
主從全量同步時，子進程瞬時內存翻倍，云主機 OOM Killer 會無情降臨。
軍規 6：定期跑 redis-cli --bigkeys。
10 KB 的 value 用 hash 拆分，>1 MB 的直接打回業務方。
（三）性能調優 8 條軍規
軍規 7：slowlog 閾值不要設 10 ms，請設 1 ms。
一次 Lua 腳本 50 ms，會拖慢整個事件循環。
軍規 8：避免 keys *、flushdb。
用 SCAN + pipeline，或者把命令改寫成 Lua。
軍規 9：監控 used_cpu_sys 與 used_cpu_user 比例。
比例 > 3 說明系統調用開銷大，檢查是否頻繁 fork、swap。
軍規 10：開啟 io-threads 前，先用 redis-benchmark 壓測。
單核 QPS 已 > 8 萬且 value > 4 KB 時才生效。
軍規 11：TLS 不是洪水猛獸。
在 AWS Nitro Enclaves 上，TLS 握手延遲 < 0.2 ms，CPU 消耗 < 5%，安全合規收益遠高于性能損耗。
軍規 12：關閉 THP。
Transparent Huge Page 會導致 30 ms 級延遲毛刺。
軍規 13：NUMA 綁核。
在多 socket 服務器上，把 Redis 綁到同一個 NUMA node，避免跨 node 訪存。
軍規 14：避免 swap。
vm.overcommit_memory=1，關閉 swap，或把 swapiness 調到 1。
（四）高可用與故障演練 10 條軍規
軍規 15：哨兵至少 3 節點，且跨機架。
兩節點“腦裂”時，業務永遠選錯主。
軍規 16：cluster-require-full-coverage=no。
當 1/16384 槽位異常時，集群仍可服務。
軍規 17：每月一次“機房斷電”演練。
用 iptables 隨機 drop 500 ms 包，模擬網絡抖動；用 tc 注入 200 ms 延遲，驗證客戶端重試策略。
軍規 18：故障演練前先跑 redis-check-aof 與 redis-check-rdb。
AOF 尾部寫壞時，可用 redis-check-aof --fix 截斷到最近合法命令。
軍規 19：配置 client-output-buffer-limit replica 256mb 64mb 60。
防止 replica 讀取慢導致 master 緩沖區堆積。
軍規 20：設置 min-replicas-to-write 1。
極端情況下，拒絕寫請求，保護數據。
軍規 21：使用 redis-cli --rdb 做異地冷備。
RDB 流式傳輸，無需停機。
軍規 22：Prometheus 采集間隔 5 s，不要 30 s。
故障窗口 30 s 足以讓熔斷失效。
軍規 23：告警分級。
P0：master 宕機；P1：replica 延遲 > 1 s；P2：used_memory > 85%。
軍規 24：灰度升級。
先在只讀實例升級，跑 24 h 無異常再升級主庫。
（五）成本治理 7 條軍規
軍規 25：開啟內存壓縮。
listpack + 32 位編碼，可省 40% 內存。
軍規 26：使用 Spot 實例跑 replica。
Spot 被回收時，自動提升其他 replica。
軍規 27：購買云上預留實例，不要按量。
3 年期預留比按量便宜 60%。
軍規 28：定期回收僵尸 key。
寫腳本掃描 TTL=-1 且 idle > 7 天的 key，發工單給業務 owner。
軍規 29：避免跨 AZ 流量費。
同地域多 AZ 部署，用 VPC Endpoint 走內網。
軍規 30：把日志壓縮后轉存 OSS。
AOF 重寫后 7 天自動打包 gzip，節省 90% 存儲。
軍規 31：按業務域拆分集群。
A 業務 20 G、B 業務 200 G，放一起會導致 A 被迫付 10 倍成本。
（六）監控與可觀測性 5 條軍規
軍規 32：用 redis_exporter + Grafana，而不是自己寫腳本。
社區已支持 200+ 指標，覆蓋 99% 場景。
軍規 33：關注 master_last_io_seconds_ago。
replica 延遲不是看 offset，而是看主從最后一次交互時間。
軍規 34：記錄 executed_commands_total。
突增 10 倍，可能是業務死循環或爬蟲。
軍規 35：用 keyspace_misses / (hits + misses) 計算命中率。
不要只看 info stats 的 keyspace_hits。
軍規 36：開啟 latency-monitor-threshold 100。
記錄 > 100 μs 的操作棧，方便火焰圖定位。
（七）客戶端與業務協同 4 條軍規
軍規 37：禁止 keys、monitor、flushall 命令。
用 ACL 屏蔽，或重命名為隨機字符串。
軍規 38：連接池大小 = (峰值 QPS × 平均 RTT) / (1 - 連接利用率)。
不要拍腦袋設 200。
軍規 39：重試策略必須帶 jitter。
固定 1 s 重試會導致 thundering herd。
軍規 40：重大活動前 2 周凍結 Redis 配置變更，并做壓測。
變更窗口不跨 0 點，方便回滾。
（八）結語
Redis 的門檻不在安裝，而在“如何不踩坑”。40 條軍規不是教條，而是“踩坑—復盤—固化”的循環產物。愿你在下一次故障來臨前，已把它們變成肌肉記憶。
)
)
)
