我先給你講個故事。前幾年我剛進一家公司，業務漲得特別猛，一開始我們用 Redis 就是很“樸素”的：一個 Redis 實例，所有請求都懟上去。

剛開始很爽，QPS 上千感覺自己是扛着服務器在飛。結果有一天，大促來了。凌晨兩點，監控報警。Redis CPU 飆到 90%，延遲肉眼可見地抖，接口 RT 從 30ms 飆到 800ms。

那一刻我就懂了一個真理：

單點 Redis，再強，也終有扛不住的一天。

於是我們開始考慮三個問題：

1. 讀請求太多，怎麼扛？
2. Redis 掛了，業務怎麼辦？
3. 能不能不停機擴展能力？

這三個問題，剛好對應主從的三個核心價值：

讀壓力大？分擔！

很多業務場景下：

• 寫請求其實很少
• 90% 都是讀，比如查詢用户信息、商品信息、緩存配置等

如果所有讀寫都打給一個 Redis，你等於讓一個人同時當客服 + 快遞 + 會計 + 電工，那不崩才怪。

主從出來的第一目標，就是：

主寫，從讀，讓讀分擔壓力。

害怕單點？提高可用性！

如果 Redis 只有一個節點，只要這個宕了，緩存直接雪崩，數據庫跟着遭殃，重則整站崩潰。

主從架構允許你：

• 主節點掛了
• 從節點還能讀
• 後面還能接管

雖然這不是強一致的高可用，但至少不是“一死全死”。

未來漲流量？橫向擴！

當業務成長，流量爆炸，你不可能一直升級一台服務器。主從架構就是為水平擴展打基礎的第一步。

一主多從，讀節點隨便加，只要機器頂得住，流量就能頂住。

Redis Replication→ 主從架構 → 讀寫分離 → 扛住高併發

在面試中，這一串邏輯你一定要能講出來，而且要講得像故事一樣順。一句話幫你串起來：

Redis 通過 replication（複製）機制實現主從架構，進而實現讀寫分離，從而通過擴展從節點來支撐高併發讀場景。

拆開聊：

• Redis replication：核心就是數據同步機制
• 在此基礎上，形成：主從架構
• 進而可以做：讀寫分離
• 最後達到：通過橫向擴展從節點抗住大量讀請求

這個邏輯説通了，面試官至少給你 7 分起步。

Redis replication 的核心機制講清楚

現在我們進入技術區，小米給你拆開講，不廢話堆概念。

Redis replication，説人話就是：

從節點不斷“抄作業”主節點。

主節點負責接收寫命令，從節點呢，就一直同步主節點的數據，保證自己儘量接近主節點狀態。

它的幾個核心特性：

1. 異步複製

Redis 的主從複製是異步的，也就是説：

• 主節點寫成功就返回客户端
• 不會等從節點同步完成
• 好處是：性能好
• 壞處是：可能存在短暫數據不一致

但是大多數緩存場景是可以接受的。

2. 全量 + 增量 兩種複製方式

Redis 的複製分為兩種：

2.1、全量複製

第一次建立主從時，從節點需要完整同步主節點所有數據。步驟是：

1. 從節點發送 PSYNC 或 SYNC
2. 主節點創建 RDB 快照
3. 把快照發送給從節點
4. 從節點加載 RDB
5. 主節點再發送後續產生的新寫操作

這是一次比較“重”的操作，很消耗主節點資源。

2.2、增量複製

後續如果連接中斷、網絡閃斷，只需要同步中斷期間的命令增量，這就是增量複製。

要不要全量，看你有沒有同步中斷期間的“複製偏移量”。

3. 複製偏移量和複製積壓緩衝區

這裏是面試高頻點。Redis 內部維護着一個東西：複製積壓緩衝區（replication backlog）

裏面保存着最近的一部分寫命令。從節點斷線重連後，會帶着它上次同步到的“偏移量”回來。如果主節點 backlog 裏還保存着那段數據，就可以進行增量同步。否則，只能重新來一波全量複製。

Redis 主從架構的核心原理

主從關係怎麼建立？核心就靠一句配置：

replicaof <master_ip> <master_port>

從節點啓動後，會主動向主節點發起復制請求。然後就是主從建立的大致流程：

1. 從節點連接主節點
2. 發送 PSYNC 命令
3. 主節點判斷是全量還是增量同步
4. 開始數據同步
5. 後續保持心跳 + 命令流同步

同步完成後，從節點就進入“在線同步”狀態，主節點每寫一條命令，都會推給從節點。

這一點你可以類比為：

主節點在直播，從節點在實時跟播。

Redis 主從複製過程原理（詳細版）

我們用一個場景串起來講。假設你新建了一個從節點 slave1：

第一步：建立連接

slave1 啓動後，主動連接 master，發送同步請求。

第二步：判斷複製方式

master 根據 slave1 提供的信息判斷：

• 是斷線重連？→走增量
• 是新來的？→走全量

第三步：執行全量複製

如果是全量複製：

1. master 開始執行 BGSAVE，生成 RDB
2. 同時把新的寫命令先緩存到 replication buffer
3. RDB 生成完，發送給 slave
4. slave 加載 RDB 數據
5. master 把剛才緩存的寫命令發送給 slave

第四步：進入命令複製階段

之後每當 master 執行寫命令：

• 一方面寫入本地
• 一方面異步推給所有從節點

從節點接收到命令後，按順序執行，完成數據同步。

到這裏，一個完整的主從複製鏈路就跑起來了。

你在面試時，可以用一個詞總結：命令傳播模型

Redis 主從架構的缺點（別隻吹優點！）

真正能讓面試官點頭的，是你能講清楚缺點。因為很多人只會背“它好牛逼”，卻講不清“它哪裏不行”。我給你總結幾個硬傷：

1. 主庫壓力大

• 所有寫請求都集中在主節點，寫多的場景下，主節點壓力會非常大。
• 主從架構只能擴展讀能力，寫是沒法橫向擴展的。

2. 數據是“最終一致”

• 由於是異步複製，從節點的數據一定有延遲。
• 如果業務對強一致性要求極高，Redis 主從並不適合做核心存儲。

3. 存在數據丟失風險

在以下場景下可能出現數據丟失：

• 主節點宕機，部分數據還沒同步到從節點
• 從節點剛同步完，主庫又炸了

這部分數據就直接“消失”了。

4. 不具備自動故障轉移能力

原生 Redis 主從是不帶自動故障轉移的。如果主掛了，需要手動切換，或者藉助：

• Redis Sentinel
• Redis Cluster

單靠主從複製，是不夠高可用的。

5. 擴展寫能力有限

• 主從架構只能靠一個主節點寫，你寫流量上來後，很容易遇到天花板。這也是 Redis Cluster 存在的意義之一。

幫你總結一套面試話術

如果你在面試中被問：“説説 Redis 主從架構？”

你可以這麼回答（自己按場景調整用詞）：

Redis 主從架構主要是通過 replication 機制實現的。

主節點負責處理寫請求，同時將寫命令異步同步給多個從節點，從節點主要承擔讀請求，從而實現讀寫分離，提升系統整體吞吐能力。

在複製機制上，Redis 採用了全量複製和增量複製相結合的方式，通過複製偏移量和複製積壓緩衝區來減少不必要的全量同步。

不過主從架構本身也有一些侷限，比如主節點寫壓力集中、數據只能保證最終一致、存在一定的數據丟失風險，而且本身不具備自動故障轉移能力，需要結合 Sentinel 或 Cluster 才能實現高可用和高擴展。

説完這段，基本面試官都會點頭。

END

我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！