上次的Redis連環問問到了Redis是什麼，Redis支援的資料類型，緩存雪崩緩存穿透緩存擊穿，記憶體淘汰政策和持久化政策等。
Redis常見面試題連環問，你能回答到第幾問？（中）
上面是psync的執行流程：
從節點發送psync[runId][offset]指令，主節點有三種響應：
（1）FULLRESYNC：第一次連接配接，進行全量複制
（2）CONTINUE：進行部分複制
（3）ERR：不支援psync指令，進行全量複制
面試官：很好，那你能具體說下全量複制和部分複制的過程嗎？
我：可以
上面是全量複制的流程。主要有以下幾步：
1、從節點發送psync ? -1指令（因為第一次發送，不知道主節點的runId，是以為?，因為是第一次複制，是以offset=-1）。
2、主節點發現從節點是第一次複制，傳回FULLRESYNC {runId} {offset}，runId是主節點的runId，offset是主節點目前的offset。
3、從節點接收主節點資訊後，儲存到info中。
4、主節點在發送FULLRESYNC後，啟動bgsave指令，生成RDB檔案（資料持久化）。
5、主節點發送RDB檔案給從節點。到從節點加載資料完成這段期間主節點的寫指令放入緩沖區。
6、從節點清理自己的資料庫資料。
7、從節點加載RDB檔案，将資料儲存到自己的資料庫中。
8、如果從節點開啟了AOF，從節點會異步重寫AOF檔案。
關于部分複制有以下幾點說明：
1、部分複制主要是Redis針對全量複制的過高開銷做出的一種優化措施，使用psync[runId][offset]指令實作。
當從節點正在複制主節點時，如果出現網絡閃斷或者指令丢失等異常情況時，從節點會向主節點要求補發丢失的指令資料，主節點的複制積壓緩沖區将這部分資料直接發送給從節點，這樣就可以保持主從節點複制的一緻性。補發的這部分資料一般遠遠小于全量資料。
2、主從連接配接中斷期間主節點依然響應指令，但因複制連接配接中斷指令無法發送給從節點，不過主節點内的複制積壓緩沖區依然可以儲存最近一段時間的寫指令資料。
3、當主從連接配接恢複後，由于從節點之前儲存了自身已複制的偏移量和主節點的運作ID。是以會把它們當做psync參數發送給主節點，要求進行部分複制。
4、主節點接收到psync指令後首先核對參數runId是否與自身一緻，如果一緻，說明之前複制的是目前主節點；
之後根據參數offset在複制積壓緩沖區中查找，如果offset之後的資料存在，則對從節點發送+COUTINUE指令，表示可以進行部分複制。因為緩沖區大小固定，若發生緩沖溢出，則進行全量複制。
5、主節點根據偏移量把複制積壓緩沖區裡的資料發送給從節點，保證主從複制進入正常狀态。
-
哨兵
面試官：那主從複制會存在哪些問題呢？
我：主從複制會存在以下問題：
1、一旦主節點當機，從節點晉升為主節點，同時需要修改應用方的主節點位址，還需要指令所有從節點去複制新的主節點，整個過程需要人工幹預。
2、主節點的寫能力受到單機的限制。
3、主節點的存儲能力受到單機的限制。
4、原生複制的弊端在早期的版本中也會比較突出，比如：redis複制中斷後，從節點會發起psync。此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時，可能會造成毫秒或秒級的卡頓。
面試官：那比較主流的解決方案是什麼呢？
我：當然是哨兵啊。
面試官：那麼問題又來了。那你說下哨兵有哪些功能？
Redis Sentinel（哨兵）的架構圖
我：Redis Sentinel（哨兵）主要功能包括主節點存活檢測、主從運作情況檢測、自動故障轉移、主從切換。
Redis Sentinel最小配置是一主一從。Redis的Sentinel系統可以用來管理多個Redis伺服器，該系統可以執行以下四個任務：
1、監控：不斷檢查主伺服器和從伺服器是否正常運作。
2、通知：當被監控的某個redis伺服器出現問題，Sentinel通過API腳本向管理者或者其他應用程式發出通知。
3、自動故障轉移：當主節點不能正常工作時，Sentinel會開始一次自動的故障轉移操作，它會将與失效主節點是主從關系的其中一個從節點更新為新的主節點，并且将其他的從節點指向新的主節點，這樣人工幹預就可以免了。
4、配置中心：在Redis Sentinel模式下，用戶端應用在初始化時連接配接的是Sentinel節點集合，從中擷取主節點的資訊。
面試官：那你能說下哨兵的工作原理嗎？
我：話不多說，直接上圖：
1、每個Sentinel節點都需要定期執行以下任務：哨兵預設每隔十秒向節點發送info，擷取主從伺服器的資訊，及時更新哨兵下的伺服器執行個體；
每個Sentinel以每秒一次的頻率，向它所知的主伺服器、從伺服器以及其他的Sentinel執行個體發送一個PING指令。（如上圖）
2、如果一個執行個體距離最後一次有效回複PING指令的時間超過down-after-milliseconds所指定的值，那麼這個執行個體會被Sentinel标記為主觀下線。（如上圖）
3、如果一個主伺服器被标記為主觀下線，那麼正在監視這個伺服器的所有Sentinel節點，要以每秒一次的頻率确認主伺服器的确進入了主觀下線狀态。
4、如果一個主伺服器被标記為主觀下線，并且有足夠數量的Sentinel（至少要達到配置檔案指定的數量）在指定的時間範圍内同意這一判斷，那麼這個主伺服器被标記為客觀下線。
5、一般情況下，每個Sentinel會以每10秒一次的頻率向它已知的所有主伺服器和從伺服器發送INFO指令，當一個主伺服器被标記為客觀下線時，Sentinel向下線主伺服器的所有從伺服器發送INFO指令的頻率，會從10秒一次改為每秒一次。
6、Sentinel和其他Sentinel協商客觀下線的主節點的狀态，如果處于SDOWN狀态，則投票自動選出新的主節點，将剩餘從節點指向新的主節點進行資料複制。
7、當沒有足夠數量的Sentinel同意主伺服器下線時，主伺服器的客觀下線狀态就會被移除。當主伺服器重新向Sentinel的PING指令傳回有效回複時，主伺服器的主觀下線狀态就會被移除。
注意：一個有效的 PING 回複可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 伺服器 傳回除以上三種回複之外的其他回複，又或者在 指定時間 内沒有回複 PING 指令， 那麼 Sentinel 認為伺服器傳回的回複 無效（non-valid）。
面試官：不錯，面試前沒少下工夫啊，今天Redis這關你過了，明天找個時間我們再聊聊其他的。（露出欣慰的微笑）
我：沒問題。
- 總結
本文在一次面試的過程中講述了Redis是什麼，Redis的特點和功能，Redis緩存的使用，Redis為什麼能這麼快，Redis緩存的淘汰政策，持久化的兩種方式，Redis高可用部分的主從複制和哨兵的基本原理。隻要功夫深，鐵杵磨成針，平時準備好，面試不用慌。雖然面試不一定是這樣問的，但萬變不離其“宗”。
（筆者覺得這種問答形式的部落格很不錯，可讀性強而且讀後記的比較深刻）
參考：
https://juejin.im/post/5dccf260f265da0bf66b626d#heading-8
https://www.cnblogs.com/hello-/articles/9599380.html
https://www.cnblogs.com/kismetv/p/9236731.html
https://juejin.im/post/5b7d226a6fb9a01a1e01ff64