部署Sentinel
sentinel.conf主要配置如下：
（1）bind 192.168.67.138
（2）port 26379 （Sentinel节点的默认端口是26379）
（3）daemonize yes
（4）logfile "/opt/redis/data/sentinel.log"
（5）sentinel monitor mymaster 192.168.67.138 6379 2
释义：Sentinel节点会定期监控主节点，Sentinel节点要监控的是一个名字叫做mymaster，ip地址和端口为192.168.67.138：6379的主节点。2代表要判定主节点最终不可达所需要的票数（票数建议是Sentinel节点的一半加1）。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。
（6）sentinel down-after-milliseconds <master-name> <milliseconds> （默认是30秒）
释义：要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达。
down-after-milliseconds越大，代表Sentinel节点对于节点不可达的条件越宽松，反之越严格。条件宽松有可能带来的问题是节点确实不可达了，那么应用方需要等待故障转移的时间越长，也就意味着应用方故障时间可能越长。条件严格虽然可以及时发现故障完成故障转移，但是也存在一定的误判率。
down-after-milliseconds虽然以<master-name>为参数，但实际上对Sentinel节点、主节点、从节点的失败判定同时有效。
（7）sentinel parallel-syncs <master-name> <numreplicas>
当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销。parallel-syncs=3和parallel-syncs=1的效果，parallel-syncs=3会同时发起复制，parallel-syncs=1时从节点会轮询发起复制。
（8）sentinel failover-timeout <master-name> <milliseconds>
释义：故障转移超时时间，但实际上它作用于故障转移的各个阶段
a）选出合适从节点。
b）晋升选出的从节点为主节点。
c）命令其余从节点复制新的主节点。
d）等待原主节点恢复后命令它去复制新的主节点。
1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。
2）在a阶段时，如果Sentinel节点向a阶段选出来的从节点执行 slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过failover-timeout时，则故障转移失败。
3）在b阶段如果执行成功，Sentinel节点还会执行info命令来确认a阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover- timeout时，则故障转移失败。
4）如果c阶段执行时间超过了failover-timeout（不包含复制时间），则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从节点去同步最新的主节点。
（9）sentinel auth-pass
如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。
部署的注意事项：
（1）Sentinel节点之间不能部署在同一台物理“机器”上。
（2）部署至少三个且奇数个的Sentinel节点。
3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。
（3）一套Sentinel和每个主节点配置一套Sentinel
一套Sentinel
一套Sentinel，一定程度上降低了维护成 本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进行管理就可以了。但是这同时也是它的缺点，如果这套Sentinel节点集合出现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响。
每个主节点配置一套Sentinel
多套Sentinel，显然这种方案的优点和缺点和上面是相反的，每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点也很明显，每套Redis Sentinel都是彼此隔离的。
总结：如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用一套Sentinel、否则一般建议采用每个主节点配置一套Sentinel。
启动：
src/redis-sentinel sentinel.conf
