哨兵的主要功能
- 监控。监控redis 中master与slave是否正常工作
- 通知。提供通知API，告知管理员或者其他应用，被监控的redis示例出现了哪些问题，
- 自动故障转移。如果master服务不可用，sentinel可以进行故障转移，将故障master移除，提升slave作为主，并重新配置其他slave的归属关系。通知使用redis的其他应用使用新的连接地址
- 配置提供者。sentinel作为客户端服务发现权威来源。客户端链接sentinel，以便获取可用的reids服务地址。发生故障后，哨兵可报告新的连接地址。
哨兵的结构
sentinel哨兵sentinel是一个分布是系统，多个sentinel进程协同工作。其优点如下
- 当多个sentinel认定master不可用时，才会执行故障检测流程。降低了误报的可能性
- 多个sentinel协同工作，本身就具有抗故障能力。
部署哨兵
redis-sentinel /path/to/sentinel.conf
或者
redis-server /path/to/sentinel.conf --sentinel
这两者方法其实是一样，如果仔细观察，可以发现，其实redis-sentinel 就是redis-server的一个软链接
要使用sentinel，必须要有配置文件。一般情况下sentinel监听26379端口。
至少要有三个哨兵实例才能做健壮部署。
sentinelsentinel要部署在相互独立的计算机或者虚拟机上。
主观下线与客观下线
Redis Sentinel 有两个不同的关于下线的概念，一个叫做主观下线(Subjectively Down condition，SDOWN) ，指的是一个Sentinel 实例自身检测到master下线宕机状态。另一种称为“客观下线”(ODOWN) ，当有足够多的 Sentinels (至少是sentinel配置文件中quorum的数量)具有 SDOWN 条件并使用 SENTINEL is-master-Down-by-addr 命令从其他 Sentinels 获得反馈时，就会达到 ODOWN 条件。
sentinel配置
配置文件基本内容如下
port 26379
sentinel monitor mymaster 192.168.0.191 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1简单的解释一下这个配置文件
port就是sentinel哨兵运行的端口
sentinel monitor {masterName} {masterIp} {masterPort} {quorum}sentinel monitor是sentinelsentinel最核心的配置，在前文讲述部署sentinel节点时已说明，其中：masterName指定了主节点名称，masterIp和masterPort指定了主节点地址。quorum是判断master客观下线的sentinel数量阈值：当判定master下线的哨兵数量达到quorum时，对master进行客观下线。建议取值为哨兵数量的一半加1。
sentinel down-after-milliseconds {masterName} {time}sentinel down-after-milliseconds与主观下线的判断有关：sentinel使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，sentinel就会将其进行主观下线。该配置对master、slave和sentinel节点的主观下线判定都有效。 down-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。
sentinel failover-timeout {masterName} {time}
sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。 failover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。
sentinel parallel-syncs {masterName} {number}sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。 parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。
除上述几个参数外，还有一些其他参数，如安全验证相关的参数等
实操演示
基本结构
使用3个节点分别部署 redis 服务与sentinel，其中192.168.0.191作为主。在操作过程中注意保证防火墙开放了相应的端口。
192.168.0.191
192.168.0.192
192.168.0.193redis与sentinel配置
redis的master节点配置如下
bind 127.0.0.1 192.168.0.191
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile "/var/log/redis.log"
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yesslave 服务器上的配置基本相同只是额外添加上
replicaof 192.168.0.191 6379sentinel部署在所有三个节点上
port 26379
sentinel monitor mymaster 192.168.0.191 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile "sentinel.log"
dir /var/log/启动流程
先启动master 192.168.0.191，再启动两个slave。
启动完成后，查看redis的replication状态口令
master
slave
然后再依次启动sentinel 并 观察sentinel的运行日志
redis-sentinel /usr/local/etc/redis-sentinel.conf &
tail -f /var/log/sentinel.log随着三个sentinelsentinel的启动，日志上也会逐一发现所有所有的sentinel节点。
模拟故障
salve停服
关闭单台slave，然后恢复slave，并观察sentinel日志。
slave停止时，被sentnel标注为+sdonw（主观下线开始，+表示状态开始）
slave重启，被sentient标注为+reboot，几乎同时也被标注为-sdown（主观下线结束，-表示状态结束）
单台slave重启没有触发选举机制，sentient只是记录了slave的状态。
master停服
关闭master，并观察sentinel日志
从日志可以看出，master被停附后，sentient先是认为master为+sdown（主观下线），然后+odown（客观下线），开始新时代+new-epoch
接下来就是决定failover，这个过程需要先选举，在接下来的过程中有两个sentinel选择了同一节点，符合sentinel配置文件中quorum的设置，接下来就是角色转变的一些操作。原有的master被变为slave，而且因为是停服状态所以还是+sdown。此时重启原master，会有如下信息输出。原master 状态为-sdonw，身份为slave
此时观察三个节点的redis与sentinel配置文件，会发现配置文件被自动修改。
sentinel的添加与移除
添加哨兵
添加新的 Sentinel 很简单，因为 Sentinel 实现了自动发现机制。所需要做的就是启动新的 Sentinel 配置来监视当前活动的master。sentinel将在10秒内获得其他sentinel成员的名单以及连接在主机上的一组复制品。
移除哨兵
移除一个Sentinel有点复杂: Sentinel永远不会忘记已经见过Sentinel，即使他们很长一段时间不可达。
因此，为了删除 Sentinel，应该在没有网络分区的情况下执行以下步骤:
- 停止要移除的的Sentinel进程。
- 发送一个 SENTINEL RESET * 命令给所有其他 SENTINEL 实例(*指的是sentinel配置文件中的masterName，上文示例为mymaster)。一个接一个，在实例之间至少等待30秒。
- 通过检查sentinel master masterName，确认所有sentinel同意当前活跃的sentinel数量。
移除slave节点
与移除sentinel类似，sentinel也不会忘记已经被发现的slave节点。要移除slave节点也要使用SENTINEL RESET {masterName}命令。同样的，也是要在sentinel上一个接一个的执行。
