概述上一篇文章主要讲了Redis复制的内容，但是Redis复制有一个缺点。当主机Master宕机时，我们需要手动解决切换，比如使用slaveofnoone。实际上并没有实现主从复制。高可用，高可用侧重于备机。利用集群中系统的冗余性，当系统中的一台机器损坏时，其他备份机器可以快速接替它启动服务。主从复制的问题一旦主节点宕机，写服务无法使用，就需要手动切换，重新选择主节点，手动设置主从关系。那么如何解决呢？如果我们有一个监控程序，可以监控每台机器的状态并及时做出调整，那么手工操作就会变成自动化。Sentinel的出现就是为了解决这个问题。sentinel机制原理及实现RedisSentinelRedisSentinel是一个分布式架构，它包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会监听数据节点和其他Sentinel节点，当发现节点不可达时，会将节点标记为离线。如果确定了主节点，它也会与其他Sentinel节点“协商”。当大多数Sentinel节点认为master节点不可达时，会选举出一个Sentinel节点来完成自动故障转移的工作，同时将这一变化实时通知Redis应用端。整个过程完全自动化，不需要人工干预，因此该方案有效解决了Redis的高可用问题。如图：基本故障转移流程1）主节点故障，此时两个从节点与主节点失去连接，主从复制失败。2)每个Sentinel节点通过定时监听发现master节点失效3)多个Sentinel节点就master节点失效达成共识，将推选其中一个节点作为leader负责故障转移。4）Sentinelleader节点进行了failover，整个过程和我们手动调整基本一致，不过是自动完成的。5）故障转移后，整个RedisSentinel结构重新选举了一个新的master节点。该示例使用docker创建以下redis容器。这里可以参考【进阶】docker布置PHP开发环境，linuxdocker-compose实战学习容器技术redis-sentinel1172.10.0.922530->22530sentinelredis-sentinel2172.10.0.1022531->6379sentinelredis-sentinel3172.10.0.1122532->6379sentinelredis-master2172.10.0.56383->6379Masterredis-slave2172.10.0.66384->6379Slaveredis-slave3172.10.0.76385->6379Slave配置Sentinel的核心配置sentinel17.0.002monitor,mymaster0.0027monitor被监控的主节点IP、端口。最后2的意思是如果几个Sentinels发现问题，就会发生failover。例如配置为2，则表示至少有2个Sentinel节点认为master节点不可达，则不可达判断是客观的。设置越小，达到下线的条件越宽松，反之亦然。一般建议设置为Sentinel节点数的一半加1。sentineldown-after-millsecondsmymaster30000这是超时时间（毫秒）。比如你去ping一台机器，如果过了很久还是ping不通，那么就认为是有问题了。sentinelparallel-syncsmymaster1当Sentinel节点集对master节点的故障判断达成共识后，Sentinelleader节点会进行故障转移操作，选择新的master节点，原slave节点会发起复制操作到新的主节点。parallel-syncs用于限制故障转移后每次向新主节点发起复制操作的从节点数量，表示Sentinel是并发还是串行。1表示一次只能复制一个，可以减轻Master的压力。sentinelauth-pass
