有一次，我去參加一個大廠社招面試。
下午三點，會議室冷氣開得像北極，我穿着優衣庫薄外套，手裏捏着簡歷，感覺像剛被從 Redis 緩存裏淘汰出來的過期 key。
面試官很穩重，敲了兩下桌子，開口問了第一句：
“來，説説 Redis 集羣的主從複製模型，你在項目裏怎麼用的？”
那一瞬間，我的腦子像 Redis 重啓，先冷、再熱、最後進入高性能模式。
今天，就把我當時腦內風暴 + 實戰經驗 + 面試教訓，原封不動講給你聽。
先講故事：為什麼 Redis 要搞主從複製？
你想象一下。
你現在在做一個電商系統，首頁商品列表、購物車、秒殺庫存、用户會話，全壓在 Redis 上。白天沒事，晚上雙十一，流量像喪屍一樣往你服務器衝過來。
如果你只有一個 Redis：
- 它一掛，全站卡成 PPT。
- 它一慢，用户直接走人。
- 它一被打爆，你老闆直接打爆你。
所以，Redis 的第一個目標：高可用 + 高併發 + 可擴展
這時候，主從複製模型就登場了。
Redis 主從複製模型，本質是什麼？
用人話講就是一句話：
一個 Redis 主節點（Master），多個 Redis 從節點（Slave），主負責寫，從負責讀，主把數據同步給從。
你可以把它想成一個“班主任 + 答題小組”模型。
- 班主任：負責批改、發題（寫操作）
- 小組成員：負責幫忙答題（讀操作）
所有作業先交給班主任，再由班主任分發給每個小組成員備份。這樣：
- 一個節點掛了，還有別的節點頂上
- 讀壓力被分攤
- 系統整體性能上去
Redis 主從複製的核心目標
這個模型，主要解決三件事：
- 讀寫分離：寫在 Master，讀在 Slave，降低單節點壓力
- 數據備份：Slave 是一份實時備份，Master 宕機也能救命
- 高可用基礎：為後續哨兵模式和 Redis Cluster 做鋪墊
主從複製是怎麼“複製”的？
面試官特別愛問：“你説主從複製沒問題，那 Redis 是怎麼同步數據的？”
這個時候，你要拆成三個階段講，面試官會瘋狂點頭。
第一階段：建立連接 & 發送同步請求
當你啓動一個 Slave，
- 並配置：replicaof 192.168.1.10 6379
- 或者舊版本是：slaveof 192.168.1.10 6379
它會主動去連 Master：
- 建立 TCP 連接
- 發送 PSYNC 命令，表示：我要同步你的數據
第二階段：全量複製（Full Sync）
如果是第一次連，或者斷線時間太久：
Master 會：
- fork 一個子進程
- 把當前數據庫數據生成 RDB 快照
- 把這個 RDB 文件發送給 Slave
- Slave 清空自己舊數據，然後加載這個新 RDB
這個過程叫：全量複製
這個過程時間比較長，但是是絕對完整的。你可以理解為：
班主任把一整本作業冊子，重新複印發給你。
第三階段：增量複製（Incremental Sync）
關鍵來了。
在生成 RDB 過程中，Master 並不會停，它還在處理新的寫請求。
這時怎麼辦？Redis 設計了一個東西：複製積壓緩衝區（Replication Backlog Buffer）
Master 會把新增的寫命令記錄下來，RDB 發送完後，再把這部分增量數據發送給 Slave。之後，進入實時狀態：Master 每寫一條命令，就立刻同步給所有 Slave。
這階段就叫：增量複製
斷線重連：部分複製機制
面試官還有一個很陰險的問題：
“如果 Slave 網絡抖動，斷了一會再連，Redis 會重新全量同步嗎？”
標準答案：
不一定，會優先嚐試部分重同步（Partial Resync）
Redis 會維護一個：
- replication offset（複製偏移量）
- backlog buffer
Slave 重連後，會告訴 Master 自己同步到哪裏了。如果 backlog 裏還保留着這部分數據：
- 那就增量補上
- 如果被覆蓋沒了，只能全量同步
所以在大流量場景中，backlog buffer 的大小很關鍵！
從讀寫分離角度看主從模型
你的項目中，最常見用法一定是：
- 寫：走 Master
- 讀：走 Slave
你可以這樣跟面試官説一句非常加分的話：
“我們線上通過中間件實現讀寫分離，寫流量走 Master，查詢流量走從節點，通過負載均衡分攤讀壓力，提升吞吐能力。”
特別加分。但你也要説風險：數據延遲問題
因為複製是異步的：
- Master 寫成功了
- Slave 可能還沒同步到
- 這時候讀從節點，可能讀到舊數據
所以，對強一致性場景（比如金額、庫存）：我們會強制走 Master
一個典型的主從複製架構
給你一個你可以在面試現場用嘴畫出來的場景：
你在面試現場配合手勢，這圖基本能在面試官腦中浮現。
主從複製的優點
總結給你幾個面試用點：
- 支持讀寫分離，提升吞吐量
- 提供數據備份能力
- 支撐高可用架構（哨兵/集羣基礎）
- 多從節點可橫向擴展讀能力
主從複製的侷限和問題
真正有經驗的人，不能只説優點，還要敢説問題。你可以説幾點缺陷：
1. 主節點單點問題
- 如果只有主從複製，沒有哨兵：Master 掛了，系統就廢了。
- 所以生產環境一般都會搭配：Redis Sentinel（哨兵模式），實現自動故障轉移。
2. 數據一致性問題
因為是異步複製：
- 可能丟失少量數據
- 強一致性無法保證
所以：
- 金融類、強一致要求場景要謹慎
- 有時要走雙寫或強制主節點
3. 網絡和性能壓力
主節點要給多個從節點同步數據：
- 從節點越多
- 主節點壓力越大
高併發場景下，有可能反而拖慢主節點。
面試實戰高分回答模板（你可以直接背）
給你一版我當年整理的“標準面試答案”，你可以直接口述出來：
Redis 的主從複製模型是通過一個 Master 節點和多個 Slave 節點來實現數據同步。寫請求統一走 Master 節點，由 Master 異步將數據複製到所有 Slave，從節點主要承擔讀請求，實現讀寫分離，提高系統的併發能力和可用性。
主從複製分為全量複製和增量複製，第一次連接為全量同步，後續通過 replication backlog 實現增量同步，並支持斷線後的部分重同步。同時，這種模型也存在數據延遲和主節點單點問題，因此在生產中通常會結合 Redis 哨兵或 Redis Cluster 架構一起使用。
這段話，我面過 5 家，一説出來，對方基本點頭。
真實經驗
最後跟你説個真實場景。
我之前在一個教育行業做直播課項目，晚上上萬人搶課，Redis QPS 直接飆爆。剛開始只有單機，後來直接：
- 加主從
- 做讀寫分離
- 導入哨兵
- 最後升級 Cluster
那天晚上系統沒炸，我站在公司天台吹風，覺得自己像救過一次服務器的命。那種爽，不是發工資能比的。
END
我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！
