Sentinel节点本质上是一个特殊的Redis节点， 所以也可以通过info命令来查询它的相关信息， 从下面info的Sentinel片段来看， Sentinel节点找到了主节点127.0.0.1： 6379， 发现了它的两个从节点， 同时发现Redis Sentinel一共有3个Sentinel节点。 这里只需要了解Sentinel节点能够彼此感知到对方， 同时能够感知到Redis数据节点就可以了：
$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3至此Redis Sentinel已经搭建起来了， 整体上还是比较容易的， 但是有2点需要强调一下：
1） 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。
2） Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别， 只不过是添加了一些Sentinel节点对它们进行监控。
配置优化
了解每个配置的含义有助于更加合理地使用Redis Sentinel，Redis安装目录下有一个sentinel.conf， 是默认的Sentinel节点配置文件， 下面就以它作为例子进行说明。
1.配置说明和优化
port 26379
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#sentinel auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>port和dir分别代表Sentinel节点的端口和工作目录， 下面重点对sentinel相关配置进行详细说明。
（1） sentinel monitor 配置如下：
sentinel monitor <master-name> <ip> <port> <quorum>Sentinel节点会定期监控主节点， 所以从配置上必然也会有所体现， 本配置说明Sentinel节点要监控的是一个名字叫做<master-name>， ip地址和端口为<ip><port>的主节点。 <quorum>代表要判定主节点最终不可达所需要的票数。 但实际上Sentinel节点会对所有节点进行监控， 但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置， 那是因为Sentinel节
点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。
例如某个Sentinel初始节点配置如下：
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000当所有节点启动后， 配置文件中的内容发生了变化， 体现在三个方面：
·Sentinel节点自动发现了从节点、 其余Sentinel节点。
·去掉了默认配置， 例如parallel-syncs、 failover-timeout参数。
·添加了配置纪元相关参数。
启动后变化为：
port 26379
daemonize yes
logfile "26379.log"
dir "/opt/soft/redis/data"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
#发现两个slave节点
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381
#发现两个sentinel节点
sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada741
24140d6f53
sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a61a8e39ae031192f1fe
ae7eb5b2be
sentinel current-epoch 0<quorum>参数用于故障发现和判定， 例如将quorum配置为2， 代表至少有2个Sentinel节点认为主节点不可达， 那么这个不可达的判定才是客观的。对于<quorum>设置的越小， 那么达到下线的条件越宽松， 反之越严格。 一般建议将其设置为Sentinel节点的一半加1。
同时<quorum>还与Sentinel节点的领导者选举有关， 至少要有max（quorum， num（sentinels） /2+1） 个Sentinel节点参与选举， 才能选出领导者Sentinel， 从而完成故障转移。 例如有5个Sentinel节点， quorum=4， 那么至少要有max（quorum， num（sentinels） /2+1） =4个在线Sentinel节点才可以进行领导者选举。
（2） sentinel down-after-milliseconds 配置如下：
sentinel down-after-milliseconds <master-name> <times>每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达， 如果超过了down-after-milliseconds配置的时间且没有有效的回复， 则判定节点不可达， <times>（单位为毫秒） 就是超时时间。 这个配置是对节点失败判定的重要依据。
优化说明： down-after-milliseconds越大， 代表Sentinel节点对于节点不可达的条件越宽松， 反之越严格。 条件宽松有可能带来的问题是节点确实不可达了， 那么应用方需要等待故障转移的时间越长， 也就意味着应用方故障时间可能越长。 条件严格虽然可以及时发现故障完成故障转移， 但是也存在一定的误判率。
运维提示：
down-after-milliseconds虽然以<master-name>为参数， 但实际上对Sentinel节点、 主节点、 从节点的失败判定同时有效。
（3） sentinel parallel-syncs 配置如下：
sentinel parallel-syncs <master-name> <nums>当Sentinel节点集合对主节点故障判定达成一致时， Sentinel领导者节点会做故障转移操作， 选出新的主节点， 原来的从节点会向新的主节点发起复制操作， parallel-syncs就是用来限制在一次故障转移之后， 每次向新的主节点发起复制操作的从节点个数。 如果这个参数配置的比较大， 那么多个从节点会向新的主节点同时发起复制操作， 尽管复制操作通常不会阻塞主节点，
但是同时向主节点发起复制， 必然会对主节点所在的机器造成一定的网络和磁盘IO开销。 图展示parallel-syncs=3和parallel-syncs=1的效果， parallelsyncs=3会同时发起复制， parallel-syncs=1时从节点会轮询发起复制。
failover-timeout通常被解释成故障转移超时时间， 但实际上它作用于故障转移的各个阶段：
a） 选出合适从节点。
b） 晋升选出的从节点为主节点。
c） 命令其余从节点复制新的主节点。
d） 等待原主节点恢复后命令它去复制新的主节点。
failover-timeout的作用具体体现在四个方面：
1） 如果Redis Sentinel对一个主节点故障转移失败， 那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。
2） 在b） 阶段时， 如果Sentinel节点向a） 阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障） ， 当此过程超过failover-timeout时， 则故障转移失败。
3） 在b） 阶段如果执行成功， Sentinel节点还会执行info命令来确认a）阶段选出来的节点确实晋升为主节点， 如果此过程执行时间超过failovertimeout时， 则故障转移失败。
4） 如果c） 阶段执行时间超过了failover-timeout（不包含复制时间） ，则故障转移失败。 注意即使超过了这个时间， Sentinel节点也会最终配置从节点去同步最新的主节点。