這期內容當中的小編將會給大家帶來有關redis中的哨兵模式和集群模式，以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
哨兵模式
它是一種高可用的解決方案，sentinel本身是一個獨立運行的進程，可以部署在其他與Redis集群可通訊的機器中監控Redis集群。
監控：哨兵會定時監控redis是否良好運行。
提醒：如果哨兵發現某個redis節點出現狀況，能夠通知另一個進程（如他的客戶端）
自動故障遷移：在master宕機后會進行主備切換。當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。如果master恢復了，那么會成為slave。
Redis哨兵是一個分布式系統，采用Gossip協議接收master是否下線，采用投票協議決定是否執行故障遷移（在投票數超過所配置的值時會執行，執行時還需要得到一半以上的哨兵認可后才能執行），以及選擇哪個slave作為master。
主觀下線：當一個哨兵進程監控master無法連接了，那么他認為master下線了。
客觀下線：當收到其他哨兵進程的master信息，判斷是否真實下線。
每個哨兵向master、slave、其他哨兵每秒發送ping請求。
集群模式
由于哨兵不支持平滑的擴容，增加節點，那么自己要手動遷移數據。為此，Reids官方提供Redis Cluster實現分布式解決方案。分布式集群首要解決把整個數據集按照分區規則映射到多個節點的問題，即把數據集劃分到多個節點上，每個節點負責整個數據的一個子集。
我覺得跟一致性hash一樣。既然計算key的hash，獲取到分片，那么集群模式缺陷就是無法進行key的批量操作了。因為這個key可能在不同的redis實例上。
集群的故障發現也是通過Gossip來通知各個redis節點的，兩兩節點互相ping、pong。
刪除、增加節點則需要數據遷移。
上述就是小編為大家分享的redis中的哨兵模式和集群模式了，如果您也有類似的疑惑，不妨礙參照上述分析進行理解。如果想了解更多相關內容，請關注億速云行業資訊。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
