Redis叢集架構，不同的公司可能又不同的架構實現，一般跑不出常用的哪幾種，可能在自己的業務使用上有所改動。我所用過的Redis叢集架構是Redis官方版本：Redis Cluster，這也是Redis4.0+版本的產物，資料顯示，2015年的時候還是試用版本，但是到現在已經是一套非常成熟的Redis叢集架構，又是官方版本，穩定性，維護性都非常高。
這篇文章主要是介紹幾個Redis叢集的架構方案，是在部落格園中看到的一篇文章，所以轉載過來，後面我會針對於Redis Cluster這一官方版的架構再寫一篇文章，詳細介紹一下，並做一個簡單的實驗來說明一下這個架構的優點，當然還有一些缺點。
正文~~~

Replication+Sentinel

這套架構使用的是社群版本推出的原生高可用解決方案，其架構圖如下！

這裡Sentinel的作用有三個:

• 監控:Sentinel 會不斷的檢查主伺服器和從伺服器是否正常執行。
• 通知:當被監控的某個Redis伺服器出現問題，Sentinel通過API指令碼向管理員或者其他的應用程式傳送通知。
• 自動故障轉移:當主節點不能正常工作時，Sentinel會開始一次自動的故障轉移操作，它會將與失效主節點是主從關係的其中一個從節點升級為新的主節點，並且將其他的從節點指向新的主節點。
  工作原理就是，當Master宕機的時候，Sentinel會選舉出新的Master，並根據Sentinel中client-reconfig-script
  指令碼配置的內容，去動態修改VIP(虛擬IP)，將VIP(虛擬IP)指向新的Master。我們的客戶端就連向指定的VIP即可！
  故障發生後的轉移情況，可以理解為下圖
  
  缺陷:
• 主從切換的過程中會丟資料
• Redis只能單點寫，不能水平擴容

Proxy+Replication+Sentinel

這裡的Proxy目前有兩種選擇:Codis和Twemproxy。,這裡以Twemproxy為例說明，如下圖所示

工作原理如下:

• 前端使用Twemproxy+KeepAlived做代理，將其後端的多臺Redis例項分片進行統一管理與分配
• 每一個分片節點的Slave都是Master的副本且只讀
• Sentinel持續不斷的監控每個分片節點的Master，當Master出現故障且不可用狀態時，Sentinel會通知/啟動自動故障轉移等動作
• Sentinel 可以在發生故障轉移動作後觸發相應指令碼（通過 client-reconfig-script 引數配置 ），指令碼獲取到最新的Master來修改Twemproxy配置

缺陷:

• 部署結構超級複雜
• 可擴充套件性差，進行擴縮容需要手動干預
• 運維不方便

Redis Cluster

redis官方推薦的叢集解決方案,多個redis例項同行,採用slot（槽）分割資料，時CRC16與16384取模後分散，主從結構和選舉演算法，保證每個節點的可靠性，客戶端可以連線任意一個node進行操作，而不需要像上面兩種架構一樣來實現叢集。架構圖：

工作原理如下：

• 客戶端與redis節點直連，不需要中間proxy層。客戶端不需要連線叢集所有節點，連線叢集中任何一個可用節點即可
• 根據公式HASH_SLOT=CRC16(key) mod 16384，計算出對映到哪個分片上，然後Redis會去相應的節點進行操作
• 如果一個M伺服器掛掉，叢集會通過在配置的監控時間超時後使用一個類似選舉的演算法立刻將一臺S伺服器升級為M伺服器
• 整個叢集節點的Fail是通過叢集中超過半數的節點檢測失效時才生效

具有如下優點:

• 無需Sentinel哨兵監控，如果Master掛了，Redis Cluster內部自動將Slave切換Master
• 可以進行水平擴容
• 支援自動化遷移，當出現某個Slave宕機了，那麼就只有Master了，這時候的高可用性就無法很好的保證了，萬一Master也宕機了，咋辦呢？ 針對這種情況，如果說其他Master有多餘的Slave ，叢集自動把多餘的Slave遷移到沒有Slave的Master 中。

缺點:

• 批量操作是個坑
• 資源隔離性較差，容易出現相互影響的情況。