Redis集羣（主從模式）

主從模型

  在Redis的集羣當中，每一個節點（實例）都有一個身份：Master或者Slave，Master：主要負責數據寫入，Slave通常提供數據讀取，Master與Slave之間是一對多關係，Master對應的Slave是其數據副本（replication），所以每次Master數據更新時同時要更新Slave中的內容。

  可是在Master下屬的Slave過多時，給對應的Slave分發數據更新請求會佔用Master不少的帶寬資源，所以在此基礎上，須要一個Master-slave，其做爲Master的下屬Slave，功能除了和其餘Slave同樣提供數據讀取服務以外，須要接納一部分的Slave，爲Master分擔發送數據更新通知任務，減輕Master信息發送負擔。

缺陷

• 一旦Master宕機失效，須要手動將Slave角色提高爲Master，不然這個子集羣將不可用。從自動性可用性角度來看，這個效果很是不盡人意。而在下一篇中將介紹Redis解決這個問題使用的哨兵（sentinel）機制。
  

  
  

• Redis Cluster不保證強一致性（Strong Consistency），設想這樣一個場景：
  • 1.Master A從Client獲取寫請求WRITE_INFO並寫入
  • 2.Master A返回OK
  • 3.Master A將寫入（或者是更新）請求傳播給Slave A1，A2，A3
    其中2,3是異步執行的，因爲這個緣由，即便Slave沒有寫入或者更新數據（請求丟失或者I/O錯誤等），2中仍是返回OK。固然也能夠若是強制2,3同步執行，等待Slave寫入成功後再返回OK，但這樣會形成效率低下。

參考文獻

  [1]redisLab.[EB/OL]. https://redis.io/topics/cluster-tutorial. 2019.01-2019.03.