摘要：面試官要不你來講講你最近在看的點唄可以拉出來一起討論下今天我也不知道要問什么候選者最近在看相關的內容面試官嗯，我記得已經問過的基礎和持久化了面試官要不你來講講你公司的是什么架構的咯候選者我前公司的架構是分片集群，使用的是層來對進行分流到不同

面試官：要不你來講講你最近在看的點唄？可以拉出來一起討論下(今天我也不知道要問什么)

候選者：最近在看「Redis」相關的內容

面試官：嗯，我記得已經問過Redis的基礎和持久化了

面試官：要不你來講講你公司的Redis是什么架構的咯？

候選者：我前公司的Redis架構是「分片集群」，使用的是「Proxy」層來對Key進行分流到不同的Redis服務器上

候選者：支持動態擴容、故障恢復等等...

面試官：那你來聊下Proxy層的架構和基本實現原理？

候選者：抱歉，這塊由中間件團隊負責，具體我也沒仔細看過

候選者：...

面試官：....

候選者：不過，我可以給你講講現有常見開源的Redis架構（：

面試官：那只能這樣了，好吧，你開始吧

候選者：那我從基礎講起吧？

候選者：在之前提到了Redis有持久化機制，即便Redis重啟了，可以依靠RDB或者AOF文件對數據進行重新加載

候選者：但在這時，只有一臺Redis服務器存儲著所有的數據，此時如果Redis服務器「暫時」沒辦法修復了，那依賴Redis的服務就沒了

候選者：所以，為了Redis「高可用」，現在基本都會給Redis做「備份」：多啟一臺Redis服務器，形成「主從架構」

候選者：「從服務器」的數據由「主服務器」復制過去，主從服務器的數據是一致的

候選者：如果主服務器掛了，那可以「手動」把「從服務器」升級為「主服務器」，縮短不可用時間

面試官：那「主服務器」是如何把自身的數據「復制」給「從服務器」的呢？

候選者：「復制」也叫「同步」，在Redis使用的是「PSYNC」命令進行同步，該命令有兩種模型：完全重同步和部分重同步

候選者：可以簡單理解為：如果是第一次「同步」，從服務器沒有復制過任何的主服務器，或者從服務器要復制的主服務器跟上次復制的主服務器不一樣，那就會采用「完全重同步」模式進行復制

候選者：如果只是由于網絡中斷，只是「短時間」斷連，那就會采用「部分重同步」模式進行復制

候選者：（假如主從服務器的數據差距實在是過大了，還是會采用「完全重同步」模式進行復制）

面試官：那「同步」的原理過程可以稍微講下嘛？

候選者：嗯，沒問題的

候選者：主服務器要復制數據到從服務器，首先是建立Socket「連接」，這個過程會干一些信息校驗啊、身份校驗啊等事情

候選者：然后從服務器就會發「PSYNC」命令給主服務器，要求同步（這時會帶「服務器ID」RUNID和「復制進度」offset參數，如果從服務器是新的，那就沒有）

候選者：主服務器發現這是一個新的從服務器（因為參數沒帶上來），就會采用「完全重同步」模式，并把「服務器ID」(runId)和「復制進度」(offset)發給從服務器，從服務器就會記下這些信息。

面試官：嗯...

候選者：隨后，主服務器會在后臺生成RDB文件，通過前面建立好的連接發給從服務器

候選者：從服務器收到RDB文件后，首先把自己的數據清空，然后對RDB文件進行加載恢復

候選者：這個過程中，主服務器也沒閑著（繼續接收著客戶端的請求）

面試官：嗯...

候選者：主服務器把生成RDB文件「之后修改的命令」會用「buffer」記錄下來，等到從服務器加載完RDB之后，主服務器會把「buffer」記錄下的命令都發給從服務器

候選者：這樣一來，主從服務器就達到了數據一致性了（復制過程是異步的，所以數據是『最終一致性』）

面試官：嗯...

面試官：那「部分重同步」的過程呢？

候選者：嗯，其實就是靠「offset」來進行部分重同步。每次主服務器傳播命令的時候，都會把「offset」給到從服務器

候選者：主服務器和從服務器都會將「offset」保存起來（如果兩邊的offset存在差異，那么說明主從服務器數據未完全同步）

候選者：從服務器斷連之后，就會發「PSYNC」命令給主服務器，同樣也會帶著RUNID和offset（重連之后，這些信息還是存在的）

面試官：嗯...

候選者：主服務器收到命令之后，看RUNID是否能對得上，對得上，說明這可能以前就復制過一部分了

候選者：接著檢查該「offset」是否在主服務器記錄的offset還存在

候選者：（這里解釋下，因為主服務器記錄offset使用的是一個環形buffer，如果該buffer滿了，會覆蓋以前的記錄）

候選者：如果找到了，那就把從缺失的一部分offer開始，把對應的修改命令發給從服務器

候選者：如果從環形buffer沒找到，那只能使用「完全重同步」模式再次進行主從復制了

面試官：主從復制這塊我了解了，那你說到現在，Redis主庫如果掛了，你還是得「手動」將從庫升級為主庫啊

面試官：你知道有什么辦法能做到「自動」進行故障恢復嗎？

候選者：必須的啊，接下來就到了「哨兵」登場了

面試官：開始你的表演吧。

候選者：「哨兵」干的事情主要就是：監控（監控主服務器的狀態）、選主（主服務器掛了，在從服務器選出一個作為主服務器）、通知（故障發送消息給管理員）和配置（作為配置中心，提供當前主服務器的信息）

候選者：可以把「哨兵」當做是運行在「特殊」模式下的Redis服務器，為了「高可用」，哨兵也是集群架構的。

候選者：首先它需要跟Redis主從服務器創建對應的連接（獲取它們的信息）

候選者：每個哨兵不斷地用ping命令看主服務器有沒有下線，如果主服務器在「配置時間」內沒有正常響應，那當前哨兵就「主觀」認為該主服務器下線了

候選者：其他「哨兵」同樣也會ping該主服務器，如果「足夠多」（還是看配置）的哨兵認為該主服務器已經下線，那就認為「客觀下線」，這時就要對主服務器執行故障轉移操作。

面試官：嗯...

候選者：「哨兵」之間會選出一個「領頭」，選出領頭的規則也比較多，總的來說就是先到先得(哪個快，就選哪個)

候選者：由「領頭哨兵」對已下線的主服務器進行故障轉移

面試官：嗯...

候選者：首先要在「從服務器」上挑選出一個，來作為主服務器

候選者：（這里也挑選講究，比如：從庫的配置優先級、要判斷哪個從服務器的復制offset最大、RunID大小、跟master斷開連接的時長...)

候選者：然后，以前的從服務器都需要跟新的主服務器進行「主從復制」

候選者：已經下線的主服務器，再次重連的時候，需要讓他成為新的主服務器的從服務器

面試官：嗯...我想問問，Redis在主從復制的和故障轉移的過程中會導致數據丟失嗎

候選者：顯然是會的，從上面的「主從復制」流程來看，這個過程是異步的（在復制的過程中：主服務器會一直接收請求，然后把修改命令發給從服務器）

候選者：假如主服務器的命令還沒發完給從服務器，自己就掛掉了。這時候想要讓從服務器頂上主服務器，但從服務器的數據是不全的（：

候選者：還有另一種情況就是：有可能哨兵認為主服務器掛了，但真實是主服務器并沒有掛( 網絡抖動)，而哨兵已經選舉了一臺從服務器當做是主服務器了，此時「客戶端」還沒反應過來，還繼續寫向舊主服務器寫數據

候選者：等到舊主服務器重連的時候，已經被納入到新主服務器的從服務器了...所以，那段時間里，客戶端寫進舊主服務器的數據就丟了

候選者：上面這兩種情況（主從復制延遲&&腦裂），都可以通過配置來「盡可能」避免數據的丟失

候選者：（達到一定的閾值，直接禁止主服務器接收寫請求，企圖減少數據丟失的風險）

面試官：要不再來聊聊Redis分片集群？

候選者：嗯...分片集群說白了就是往每個Redis服務器存儲一部分數據，所有的Redis服務器數據加起來，才組成完整的數據（分布式）

候選者：要想組成分片集群，那就需要對不同的key進行「路由」（分片）

候選者：現在一般的路由方案有兩種：「客戶端路由」(SDK)和「服務端路由」(Proxy)

候選者：客戶端路由的代表（Redis Cluster），服務端路由的代表（Codis）

面試官：要不來詳細講講它們的區別唄？

候選者：今天有點兒困了，要不下次唄？

本文總結：

• Redis實現高可用：

  • AOF/RDB持久化機制
  • 主從架構（主服務器掛了，手動由從服務器頂上）
  • 引入哨兵機制自動故障轉義

• 主從復制原理：

  • PSYNC命令兩種模式：完全重同步、部分重同步
  • 完全重同步：主從服務器建立連接、主服務器生成RDB文件發給從服務器、主服務器不阻塞（相關修改命令記錄至buffer）、將修改命令發給從服務器
  • 部分重同步：從服務器斷線重連，發送RunId和offset給主服務器，主服務器判斷offset和runId，將還未同步給從服務器的offset相關指令進行發送

• 哨兵機制：

  • 哨兵可以理解為特殊的Redis服務器，一般會組成哨兵集群
  • 哨兵主要工作是監控、告警、配置以及選主
  • 當主服務器發生故障時，會「選出」一臺從服務器來頂上「客觀下線」的服務器，由「領頭哨兵」進行切換

• 數據丟失：

  • Redis的主從復制和故障轉移階段都有可能發生數據丟失問題（通過配置盡可能避免）

歡迎關注我的微信公眾號【Java3y】來聊聊Java面試，對線面試官系列持續更新中！

【對線面試官-移動端】系列 一周兩篇持續更新中！

【對線面試官-電腦端】系列 一周兩篇持續更新中！

原創不易！！求三連！！