這篇文章帶給大家的內容是介紹Redis的哨兵機制，讓大家了解哨兵機制的原理和如何實現。有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
概述
#Redis的複製有一個缺點，當主機Master 宕機以後，我們需要人工解決切換，例如使用slaveof no one 。實際上主從複製並沒有實現，高可用， 高可用側重備份機器， 利用集群中系統的冗餘，當系統中某台機器發生損壞的時候，其他後備的機器可以迅速的接替它來啟動服務。
主從複製的問題
#一旦主節點宕機，寫入服務無法使用，就需要手動去切換，重新選取主節點，手動設定主從關係。
那麼要如何解決呢？如果我們有一個監控程序能夠監控各個機器的狀態及時調整，將手動的操作變成自動的。 Sentinel的出現就是為了解決這個問題。
哨兵機制的原則及實作
#Redis Sentinel
## Redis Sentinel 是分散式架構，其中包含若干個Sentinel 節點和Redis 資料節點，每個Sentinel 節點會對資料節點和其餘Sentinel 節點進行監控，當它發現節點不可達時，會對節點做下線標識。如果被識別的是主節點，它也會和其他Sentinel 節點進行“協商”，當大多數Sentinel 節點都認為主節點不可達時，它們會選出一個Sentinel 節點來完成自動故障轉移的工作，同時會將這個變化即時通知給Redis 應用方。整個過程完全是自動的，不需要人工來介入，所以這套方案有效地解決了 Redis 的高可用問題。 如圖所示：
#基本的故障轉移流程
1）主節點發生故障，此時兩個從節點與主節點失去連接，主從複製失敗。
實例
#使用docker建立如下redis容器redis-sentinel1 172.10.0.9 22530 -> 22530 sentinel redis-sentinel2 172.10.0.10 22531 -> 6379 sentinel redis-sentinel3 172.10.0.11 22532 -> 6379 sentinel redis-master2 172.10.0.5 6383 -> 6379 Master redis-slave2 172.10.0.6 6384 -> 6379 Slave redis-slave3 172.10.0.7 6385 -> 6379 Slave登入後複製
配置
Sentinel 的核心配置sentinel monitor mymaster 127.0.0.1 7000 2
sentinel down-after-millseconds mymaster 30000
sentinel parallel-syncs mymaster 1
当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。
sentinel auth-pass <master-name> <password></password></master-name>
如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。
sentinel failover-timeout mymaster 180000
表示故障转移的时间。
技巧
1）Sentinel 节点不应该部署在一台物理“机器”上。
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。
2）部署至少三个且奇数个的 Sentinel 节点。
3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。
【相关文章】
以上就是本篇文章的全部内容，希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目！！！
以上是Redis哨兵機制的原理介紹（圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！
