概述

Redis是個內存數據庫，速度很快，但單台服務器的內存、處理能力都是有限的。如果數據量太大（比如幾十GB），單台機器存不下；或者訪問量太高（比如每秒幾十萬次請求），單台機器扛不住。這時候就需要多台Redis一起工作，也就是"集羣"相關的技術。

另外，單台機器萬一宕機了，數據就沒了，服務也停了，所以還需要"備份"和"自動恢復"的機制，這就是主從複製和哨兵模式的作用。

1. 主從複製（Master-Slave Replication）

解決的問題

數據備份 + 分擔讀壓力。

原理

• 選一台Redis當"主庫（Master）"，其他的當"從庫（Slave）"。
• 主庫負責"寫操作"（增刪改），寫完之後會把數據同步給所有從庫。
• 從庫只能"讀操作"，用户查數據就去從庫查，主庫就不用管那麼多讀請求了。

例子

就像一個老闆（主庫）管發號施令（寫數據），幾個員工（從庫）抄錄老闆的指令（同步數據），客户來諮詢（讀數據）就找員工，老闆專心處理新指令。

好處

• 數據有備份（從庫有完整數據），主庫掛了，從庫能頂上（需要手動切換）。
• 讀請求分散到從庫，主庫壓力小了。

2. 哨兵模式（Sentinel）

解決的問題

主從複製的"自動故障轉移"（主庫掛了不用手動切換）。

原理

• 專門搞幾個"哨兵"進程，它們不存數據，就盯着主庫和從庫的狀態。
• 哨兵們會定期給主庫、從庫發"心跳"，檢查它們活沒活着。
• 如果主庫掛了，哨兵們會投票選一個從庫升級成新主庫，然後讓其他從庫去跟新主庫同步數據，整個過程自動完成，不用人管。

例子

哨兵就像監控攝像頭+自動調度員，盯着老闆（主庫）和員工（從庫）。老闆突然暈倒了，攝像頭髮現後，調度員立刻從員工裏選一個當新老闆，其他員工改聽新老闆的。

好處

主庫故障時自動恢復，保證服務不中斷，比主從複製更可靠。

3. Redis分片（Sharding）

解決的問題

單台Redis內存不夠用（比如數據量太大，超過單台機器內存）。

原理

• 把所有數據"拆分成小塊"，不同的塊存在不同的Redis服務器上。
• 比如按用户ID分片：ID 1-10000存到Redis服務器A，10001-20000存到服務器B，以此類推。
• 客户端查數據時，先算一下這個數據該存在哪台服務器，再去對應的服務器操作。

例子

就像圖書館的書太多，一個書架放不下，就分成多個書架，按書的編號範圍放，找書時先看編號屬於哪個書架，再去那個書架找。

好處

數據分散存儲，突破單台機器的內存限制，同時也能分擔讀寫壓力（不同分片在不同機器）。

4. Redis集羣（Redis Cluster）

解決的問題

整合分片、主從、故障轉移的"一站式方案"。

原理

• 它是Redis官方提供的集羣方案，自帶分片功能（數據自動分到不同節點），每個分片又有主從複製（主節點負責寫，從節點備份+讀），還內置了類似哨兵的故障轉移機制（主節點掛了，從節點自動頂上）。
• 整個集羣有多個"主節點"（每個主節點對應一個分片），每個主節點可以有多個從節點。
• 客户端連接集羣時，不用自己算數據該去哪台機器，集羣會自動指引。

例子

相當於一個大型圖書館，有多個書架（分片主節點），每個書架有備份書架（從節點），還有管理員（內置哨兵功能）負責監控書架狀態，哪個書架倒了，管理員就把備份書架頂上，讀者借書時不用自己找書架，管理員會告訴你去哪找。

好處

一站式解決了數據分片、高可用（主從+自動故障轉移）、負載均衡的問題，適合大規模數據和高併發場景。

它們的關係總結

• 主從複製：基礎的備份和讀分擔，手動切換主庫。
• 哨兵模式：在主從複製之上，加了自動故障轉移，更可靠。
• 分片：解決數據量大的問題，把數據拆分到多台機器。
• Redis集羣：官方集成了分片、主從、自動故障轉移，是最完整的集羣方案。

從簡單到複雜：主從複製 → 哨兵模式（主從+自動切換） → 分片（解決大數據） → Redis集羣（整合所有功能）。

公司實際部署Redis集羣的方式

公司裏部署Redis集羣的方式，會根據業務規模、數據量、可用性要求來定，常見的有幾種方案，從簡單到複雜都有：

1. 中小公司/業務初期：哨兵模式（主從+哨兵）

適用場景

數據量不算特別大（單主庫能存下），但需要高可用（服務不能隨便掛），比如日均請求百萬級以內。

部署方式

• 1個主庫（Master）+ 2個從庫（Slave）：主庫負責寫，從庫同步數據並分擔讀請求。
• 3個哨兵（Sentinel）：單獨部署在不同機器上，監控主從狀態，主庫掛了自動選新主庫。
• 機器要求：至少3台服務器（比如主庫1台，從庫+哨兵混布2台，或5台機器更穩妥）。

例子

電商小平台，商品庫存、用户購物車數據量不大，用這套足夠。主庫掛了，哨兵10秒內就能切換從庫頂上，服務幾乎不停。

2. 中大型公司/數據量大：Redis Cluster（官方集羣）

適用場景

數據量大（單台機器存不下，比如幾十GB甚至上百GB），併發高（每秒幾萬到幾十萬請求），比如電商大促、社交平台。

部署方式

• 至少3個主節點（每個主節點是一個分片），每個主節點配1-2個從節點（備份+讀分擔）。比如3主3從（共6台機器），或6主6從（12台），主從分開部署在不同機器。
• 集羣自動分片：數據按哈希算法分到不同主節點，客户端不用管分片邏輯。
• 內置高可用：主節點掛了，它的從節點自動升級為主節點，類似哨兵但更集成。

例子

某電商平台，商品數據有50GB，單台機器存不下，就分3個主節點，每個存17GB左右。大促時，讀請求分散到從節點，寫請求由主節點處理，某台主庫掛了，從庫自動頂上，不影響下單。

3. 超大規模：Redis Cluster + 代理層（可選）

適用場景

超大規模集羣（比如幾十上百個節點），或需要更靈活的路由、限流、監控等功能，比如互聯網大廠的核心業務。

部署方式

• 基礎還是Redis Cluster（多主多從），但在集羣前面加一層代理（比如Twemproxy、Codis）。
• 代理的作用：統一入口（客户端只連代理），處理分片路由、負載均衡，甚至加限流、讀寫分離策略。

例子

某社交App，日活億級，Redis集羣有20個主節點，客户端通過代理連接，代理會根據用户ID計算該訪問哪個分片，還能限制單用户的請求頻率，保護集羣。

部署時的通用注意點

1. 機器隔離

主從節點、哨兵/集羣節點儘量部署在不同物理機/虛擬機，避免一台機器掛了多個節點一起掛。

2. 配置優化

• 內存：主庫內存別用滿（留20%-30%緩衝，避免頻繁淘汰數據）。
• 持久化：開AOF+RDB（AOF保證數據不丟，RDB方便快速恢復）。
• 網絡：節點間用內網通信，帶寬要夠（主從同步、集羣心跳需要流量）。

3. 監控告警

用Prometheus+Grafana監控節點狀態、內存使用率、同步延遲，出問題及時告警（比如主從同步延遲超過10秒、內存使用率超80%）。

4. 擴容準備

Redis Cluster支持在線加節點（新增主從，遷移部分數據過去），提前規劃好擴容方案，避免數據量暴增時手忙腳亂。

總結

• 小業務：哨兵模式（簡單、夠用）。
• 中大規模：Redis Cluster（官方方案，省心）。
• 超大規模：Cluster+代理（更靈活可控）。

核心都是圍繞"數據不丟、服務不停、能扛住併發"這三個目標，根據業務體量選合適的方案，沒必要一上來就搞最複雜的～