Redis叢集方案
Redis叢集方案目前主流的有三種：
- 主從
- SENTINEL
- CLUSTER
SENTINEL
sentinel是redis2.6版本推出的高可用方案，當redis做Master-Slave高可用方案時，master不能提供服務時redis本身不能實現自動的主從切換，因此sentinel承擔了監視器的功能，可以監控整個Master-Slave叢集，並能夠在多個Slave中選中一個坐位master，其他slave追隨新master。
SENTINEL叢集資料同步原理還是延續主從模式:
- 當從節點向主節點發送SYNC命令；
- 主節點接收命令後執行BGSAVE命令儲存快照，並建立持久化檔案，同時將建立持久化檔案期間的命令快取；
- 主節點執行完BGSAVE命令後，將持久化檔案傳送至從節點；
- 從節點接收持久化檔案後開始接收主節點的命令快取；
- 以上步驟均完成後，主節點每執行一個寫入操作，均傳送從節點。
Cluster
cluster是redis3.0版本推出的，是基於redis的一個分散式實現。引入了hash slot概念，支援動態的增加，刪除節點，可線性擴充套件到1000個節點。
多個redis節點之間資料共享，部分節點不可用時叢集仍可使用，資料通過非同步複製。不保證資料的強一致性，具備自動failover，客戶端連線redis server，免去了proxy呼叫的效能損耗。
cluster是一種去中心化的結構，所有節點之間相連，通過gossip協議來發布廣播訊息，間隔時間內互相傳送ping/pong心跳包來檢測其他節點狀態，保持資訊同步，客戶端直接連線任意redis server，並由redis cluster路由轉發客戶端請求到真正的資料處理節點。
cluster叢集資料同步原理延續主從模式，cluster引入hash slot概念，因為cluster內部的master和slave之間是通過一部複製左資料同步的，所以cluster不是強一致實現，所以可能出現複製過程中master掛了資料沒有完全同步到slave上。叢集中每個master負責一部分hash slot，每個key通過hash_slot = crc16(key) % 16384計算屬於哪個節點。
選舉過程
叢集中所有的mater都參與，如果半數以上的master節點與當前master節點通訊超時，則叢集認為此master節點掛掉。
以下情況會導致叢集不可用：
- 叢集任意master掛掉，並且當前master沒有slave，叢集不可用
- 叢集超過半數以上master掛掉，無論是否有slave，叢集不可用
監控方案
對於redis的監控方案大部分採用便利info結果進行資料聚合，展示。一般的指標如：記憶體碎片，分配記憶體總量，消耗記憶體峰值，命中數，未知命中數，連線使用者數，接收總連線數，每秒執行命令數，阻塞使用者數等。
獲取數值方式：
- 通過指令碼方式獲取
- 通過客戶端方