Redis集羣與高可用性技術小結

• 客戶端分片，這種方式須要實現特定的客戶端，須要手工配置redis實例並根據算法進行訪問，對於redis實例的增減，調整靈活性不好，通常不推薦。
• 代理分片，常見的有Twemproxy架構（豆瓣建立了codis，未測試過，在此從略）：
• 優勢
  • sharding邏輯對開發透明，讀寫方式和單個redis一致。
  • 能夠做爲cache和storage的proxy（by auto-eject）。
• 缺點
  • 架構複雜，層次多。包括lvs、twemproxy、redis、sentinel和其控制層程序。
  • 管理成本和硬件成本很高。
  • 2 * 1Gbps 網卡的lvs機器，最大能支撐140萬pps。
  • 流量高的系統，proxy節點數和redis個數接近。
  • Redis層仍然擴容能力差，預分配足夠的redis存儲節點。對於redis實例的增減一樣缺少應對靈活性。

  這是twemproxy的架構，客戶端直接鏈接最上面的lvs（LB），第二層是同構的twemproxy節點，下面的redis master節點以及熱備的slave節點，另外還有獨立的sentinel集羣和切換控制程序，twemproxy先介紹到這裏。

• Redis Cluster架構

  在這種機制下，沒有中心節點（和代理模式的重要不一樣之處）。Redis Cluster將全部Key映射到16384個Slot中，集羣中每一個Redis實例負責一部分，業務程序經過集成的Redis Cluster客戶端進行操做。客戶端能夠向任一實例發出請求，若是所需數據不在該實例中，則該實例引導客戶端自動去對應實例讀寫數據。

• 優勢
  • 無中心架構。
  • 數據按照slot存儲分佈在多個redis實例上。
  • 增長slave作standby數據副本，用於failover，使集羣快速恢復。
  • 實現故障auto failover。節點之間經過gossip協議交換狀態信息；投票機制完成slave到master角色的提高。
  • 亦可manual failover，爲升級和遷移提供可操做方案。
  • 下降硬件成本和運維成本，提升系統的擴展性和可用性。
• 缺點
  • client實現複雜，驅動要求實現smart client，緩存slots mapping信息並及時更新。
  • 目前僅JedisCluster相對成熟，異常處理部分還不完善，好比常見的"max redirect exception"。
  • 客戶端的不成熟，影響應用的穩定性，提升開發難度。
  • 節點會由於某些緣由發生阻塞(阻塞時間大於clutser-node-timeout），被判斷下線。這種failover是沒有必要，sentinel也存在這種切換場景。

  cluster的架構以下：

  圖上只有master節點（slave略去），全部節點構成一個徹底圖,slave節點在集羣中與master只有角色和功能的區別。

• 基於keepalived和redis-Sentinel集羣的高可用性方案

  Sentinel是一個管理多個redis實例的工具，它能夠實現對redis的監控、通知、自動故障轉移。sentinel不斷的檢測redis實例是否能夠正常工做，經過API向其餘程序報告redis的狀態，若是redis master不能工做，則會自動啓動故障轉移進程，將其中的一個slave提高爲master，其餘的slave從新設置新的master實例。也就是說，它提供了：

  監控（Monitoring）： Sentinel 會不斷地檢查你的主實例和從實例是否正常。

  通知（Notification）： 當被監控的某個 Redis 實例出現問題時， Sentinel 進程能夠經過 API 向管理員或者其餘應用程序發送通知。

  自動故障遷移（Automatic failover）： 當一個主redis實例失效時， Sentinel 會開始記性一次failover， 它會將失效主實例的其中一個從實例升級爲新的主實例， 並讓失效主實例的其餘從實例改成複製新的主實例； 而當客戶端試圖鏈接失效的主實例時， 集羣也會向客戶端返回新主實例的地址， 使得集羣可使用新主實例代替失效實例。

  Redis Sentinel自身也是一個分佈式系統， 你能夠在一個架構中運行多個 Sentinel 進程， 這些進程使用流言協議（gossip protocols)來接收關於主Redis實例是否失效的信息， 而後使用投票協議來決定是否執行自動failover，以及評選出從Redis實例做爲新的主Redis實例。

  Sentienl工具提供了redis主-從方式的實現，那麼藉助基於VRRP的keepalived，就能實如今redis主-從切換時外部可見的redis實例不變性。除了在切換過程當中，客戶端不會明顯的感知到redis的服務實例變化。

  • 當 Master 與 Slave 均運做正常時, Master負責服務，Slave負責Standby；
  • 當 Master 掛掉，Slave 正常時, Slave接管服務，有寫權限，同時關閉主從複製功能；
  • 當 Master 恢復正常，則從Slave同步數據，同步數據以後關閉主從複製功能，恢復Master身份，同時Slave等待Master同步數據完成以後，恢復Slave身份。

  可是redis也支持客戶端與sentinel直接交互來實現高可用性，可是與1.類似，一樣須要特定客戶端，由於客戶端須要監控sentinel的頻道信息，並自動鏈接新的主節點。通常來講這種方式幾乎無人使用。