喜歡就 關注 我們吧！
簡介：
Hello 各位 ，我是公號「八點半技術站」的創作者 - Bruce.D （姓氏：豆）。
感謝微信給予的個人認證，專注於PHP、數據庫技術領域知識經驗分享。
技術的交流、不僅僅限制於閱讀，在此歡迎各路大神、小白，來「wx技術羣」分享自己的編程經驗心得 與 技術實戰乾貨。
開場白-靈魂拷問
Q：redis 集羣爲了解決什麼問題存在？
A：解決線性擴展性。
Q：redis 集羣誕生以前怎麼解決這個問題？
A：客戶端分片、代理協助分片（Twemproxy）、查詢路由、預分片、一致性哈希、客戶端代理/轉發等。
Q：redis 集羣採用什麼方式保證線性可擴展性、可用性、數據一致性？
A：Hash槽、查詢路由、節點互聯的混合模式。
Q：redis 集羣化面臨的問題是什麼？
A：Redis集羣本身要解決的是可伸縮問題，同時數據一致、集羣可用等一系列問題。前者涉及到了節點的哈希槽的分配(含重分配)，節點的增刪，主從關係指定與變更(含自動遷移)這些具體的交互過程；後者則是故障發現，故障轉移，選舉過程等詳細的過程。
Q：redis 集羣實現的核心思想和思路是什麼？
A： 通過消息的交互（Gossip）實現去中心化(指的是集羣自身的實現，不是指數據)，通過Hash槽分配，實現集羣線性可拓展。
其實當大家認真看完這 5 個話題，我認爲你如果之前不瞭解 redis集羣，那麼現在肯定也有一個新的認知，並且知道如何去學習對應的技術點。
接下來，可以俗稱 “ 鋪墊 ” 吧~~~ 下面內容也很精華，瀏覽吧。
redis 集羣 - 設計目標
redis 集羣是一個distribute、fault-tolerant 的 redis實現。
主要設計目標是達到：線性可擴展性、可用性、數據一致性。
線性拓展：主官方推薦最大的節點數量爲1000，由於Cluster架構中無Proxy層，Master與Slave之間使用異步replication。
數據一致性：客戶端容忍一定程度的數據丟失，集羣儘可能保存Client write操作的數據，保證數據一致性。
可用性：Redis集羣通過partition來提供一定程度的可用性，當集羣中的一部分節點失效或者無法進行通訊時，集羣仍可以繼續提供服務。
redis 集羣 - 容錯
節點失效檢測：跟大部分分佈式框架一樣，Redis Cluster節點間通過持續的心跳來保持信息同步，不過 Redis Cluster節點信息同步是內部實現的，不依賴第三方組件，如zk。
集羣中的 nodes持續交換 ping、pong數據，消息協議使用 Gossip，這兩種 packet數據結構一樣，它們之間通過 type字段區分。
節點定時向其他節點發送 ping命令，它會隨機選擇存儲的其他集羣節點的其中三個進行信息“廣播”，例如廣播的信息包含一項是節點是否被標記爲 PFAIL/FAIL。
PFAIL表示 “ 可能已失效 ”，是尚未完全確認的失效狀態（即可能是某個節點或少數 Master認爲其不可達）；FAIL表示 Node被集羣大多數的Masters認定爲失效（即大多數 Master已認定爲不可達，且不可達的時間已經超過配置的 NODE_TIMEOUT）。
當節點收到其他節點廣播的信息，它會記錄被其他節點標記爲失效的節點。舉個例子，如果節點被某個節點標記爲 PFAIL，集羣中大部份其他主節點也認爲該節點進入了失效狀態，那麼該節點的狀態會被標誌爲 FAIL。
當節點被標誌爲FAIL，這個節點已失效的信息會被廣播至整個集羣，所有集羣中的節點都會將失效的節點標誌爲FAIL。
集羣失效檢測： 當某個 Master或者 Slave不能被大多數Nodes可達時，用於故障遷移並將合適 Slave提升爲 Master。當Slave提升未能成功，集羣不能正常工作。
即集羣不能處理 Client的命令的請求，當 Client發出命令請求時，集羣節點都將返回錯誤內容的 respone。
集羣正常工作時，負責處理16384個slots的節點中，全部節點均正常。反之，若集羣中有一部分 hash slot不能正常使用，集羣亦將停止工作，即集羣進入了FAIL狀態。
對於集羣進入 FAIL狀態，會有以下兩種情況：
至少有一個 hash slot不可用。
集羣中大部份 Master都進入了 PFAIL狀態。
往下拉，有乾貨
和我再戰 n+1 天
同時，爲了方便大家學習，我會把一些源碼、技術乾貨存儲到 github 中，隨時可以在微信羣 進行交流，掃下面二維碼 ，備註 “技術進羣” 就可以通過審覈。
進羣的小夥伴請加右側私人微信（備註：技術進羣）
----投稿分隔線----
投稿，關注公衆號回覆“投稿”，專員對接
-----商務合作分隔線----
商務合作，關注公衆號回覆“商務合作”，專員對接