9、sentinel哨兵
前言
Redis主从复制下，一旦主节点由于故障不能提供服务需要人工将从节点晋升成主节点，因为代码中可能还是以主节点开发的，需要修改代码修改主节点。同时需要将其他节点的主节点要复制过来，这样肯定是不行，因为需要人工的干预
基本概念
对于Redis许多概念都有不同的名词解释，所以解释Redis Sentinel，Redis高可用实现方案
1、主从复制的问题
1、前言中介绍过
下面这两个属于redis分布式问题
2、主节点写能力受到单机的限制
3、主节点的存储能力受到单机的限制
2、Redis Sentinel高可用
它是一个分布式架构，其中包多个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达的时候，会节点做下线标识，如果被标识的是主节点，它还会和其他Sentinel商量，当大部分人为主节点不可用的时候，会选举出一个Sentinel节点用来完成主节点的自动故障转移的工作，同时将这个变化通知给应用方，整个过程是自动的。不需要人工来介入
配置客户端体用这，客户端初始化的时候连接的Sentinel集合从中获取主节点信息，所以才有上面通知应用方，从而获取主节点信息
安装和部署
准备工作：
这里部署3个Sentinel（26379、26380、26381）、1个master（6379）、2个slave（6380、6381）
1、配置主节点
解释：daemonize
daemonize:redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时，代表开启守护进程模式。在该模式下，redis会在后台运行，并将进程pid号写入至redis.conf选项pidfile设置的文件中，此时redis将一直运行，除非手动kill该进程。
但当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出。
1、配置
daemonize yes
logfile "6379.log" //也就是说redis-server启动之后的日志放到了dir目录下的6379.log
dbfilename "dump-6379.rdb"
dir "/usr/local/redis/dir"2、启动
MacBook-Pro:src healerjean$ redis-server ../redis.conf观察/usr/local/redis/dir 目录下面文件6379.log
5928:M 19 Apr 21:01:18.903 * Increased maximum number of open files to 10032 (it was originally set to 256).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.9 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 5928
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
5928:M 19 Apr 21:01:18.907 # Server started, Redis version 3.2.9
5928:M 19 Apr 21:01:18.907 * The server is now ready to accept connections on port 63793、测试下主节点是否可用
healerjean$ redis-cli -h 127.0.0.1 -p 6379 ping
PONG2、启动两个从节点
6580 和 6381 两个从节点一模一样
2.1、配置从节点
redis.conf
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/usr/local/redis/dir"
slaveof 127.0.0.1 6379
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/usr/local/redis/dir"
slaveof 127.0.0.1 6379
2.2、测试从节点是否启动
MacBook-Pro:src healerjean$ redis-cli -h 127.0.0.1 -p 6380 ping
PONG
MacBook-Pro:src healerjean$ redis-cli -h 127.0.0.1 -p 6381 ping
PONG
2.3、确定主从关系
2.3.1、从视角角度
可以看到从节点8081的主节点为6379
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:435
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
2.3.2、主视角角度
可以明显的看到下面两个从节点
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=547,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=547,lag=0
master_repl_offset:547
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:546
127.0.0.1:6379>
3、部署Sentinel节点
3.1、配置
三个节点的配置完全一致，只不过是端口不同
daemonize yes
logfile "26379.log"
dbfilename "dump-26379.rdb"
dir "/usr/local/redis/dir"
# 2、代表主节点失败至少需要两个sentinel同意
# mymaster为主节点别名 剩下的以后说明
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
3.2、启动Sentinel节点
healerjean$ redis-sentinel ../redis.conflog文件中
360:X 19 Apr 21:40:23.377 * Increased maximum number of open files to 10032 (it was originally set to 256).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.9 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26381
| `-._ `._ / _.-' | PID: 6360
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
6360:X 19 Apr 21:40:23.382 # Sentinel ID is b38f8218f0d136dc6f2b18391a88859aafee6a11
6360:X 19 Apr 21:40:23.382 # +monitor master mymaster 127.0.0.1 6379 quorum 2
6360:X 19 Apr 21:40:23.383 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
6360:X 19 Apr 21:40:23.385 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
3.3、查看启动的Sentinel节点信息
可以观察到主节点有一个并且知道了端口号
从节点有2个
Sentinel有3个
info Sentinel
127.0.0.1:26379> info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
127.0.0.1:26379> 3、建议
1、生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机器上
2、配置和优化
1、上面Sentinel中的redis.conf配置如下
daemonize yes
logfile "26379.log"
dbfilename "dump-26379.rdb"
dir "/usr/local/redis/dir"
# 2、代表主节点失败至少需要两个sentinel同意
# mymaster为主节点别名 剩下的以后说明
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
2、其实当我们利用上面的redi.conf启动的时候，就会根据自身监控到的进行修改redi.conf
# 2、代表主节点失败至少需要两个sentinel同意
# mymaster为主节点别名 剩下的以后说明
sentinel myid 3a29be18951c20683dc54c85a79fd8d3eec79ea1
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381
sentinel known-sentinel mymaster 127.0.0.1 26381 b38f8218f0d136dc6f2b18391a88859aafee6a11
sentinel known-sentinel mymaster 127.0.0.1 26380 6f3b48dd910ae93566b52f7adfac2a5ef46e52bb
sentinel current-epoch 03、Redis安装目录下有个sentinel.conf是默认的Sentinel节点的配置文件，下面开始以它作为例子进行讲解，其实再启动redis.conf的时候，就会将它也进行了修改，只不过没有写入监听信息Generated by CONFIG REWRITE
daemonize yes
logfile "26379.log"
dbfilename "dump-26379.rdb"
dir "/usr/local/redis/dir"
# 2、代表主节点失败至少需要两个sentinel同意
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 1、sentinel monitor
sentinel monitor mymaster 127.0.0.1 6379 2
1、一帮情况下我们将它设置为Sentinel的一半+1，这样就保证绝大多数同意下线标识。
2、还记得上面我们说的领导者吧。至少有max（quorun,num(sentinel)/2）+1)个节点参与选举才可以选出领导者，例如 有5个Sentinle节点，quorun 为4，则为至少需要 max（4，3） = 4 才能进行领导者选举
3、虽然这里没有看到基恩空其余从节点和Sentinel信息，因为他会通过主节点获取有关从及其他节点的信息
2、sentinel down-after-milliseconds mymaster 30000
这个是对节点不可达判断的依据， 每个Sentinel节点定期发送ping命令来判断Redis节点和其他Sentinel节点是否可达，如果超过了这个时间就认为是不可达的，条件太严格有误判风险，宽松则更不好
sentinel down-after-milliseconds mymaster 30000
3、sentinel parallel-syncs mymaster 1
当Sentinel节点集合对主节点故障判断一致的时候，Sentinel领导者节点会做出故障转移操作。选出新的主节点，原来的从节点会向新的主节点发起复制操作，这里的参数则是向新的主节点发起复制操作的从节点个数，配置如果比较大则从节点同时向主节点发起复制操作，但是不好，因为比较拥挤。等于1的时候，则从节点会轮询发起复制
sentinel parallel-syncs mymaster 14、sentinel failover-timeout mymaster 180000
故障转移超时时间，，如果第一次失败了，则下次其实超时时间为他的2倍
sentinel failover-timeout mymaster 180000
5、sentinel auth-pass
如果监控的主节点配置了密码，则需要配置主节点的额密码，防止对主节点无法监控
sentinel auth-pass 123456 6、sentinel notification-script mymaster /var/redis/notify.sh
当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
sentinel notification-script mymaster /var/redis/notify.sh
7、sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
当一个master由于failover故障转移结束的时候，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:
是用来和旧的master和新的master(即旧的slave)通信的。这个脚本应该是通用的，能被多次调用，不是针对性的。
配置示例：
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh8、也可以监控多个主节点
3、部署技巧
1、Sentinel节点不应该部署在一台物理机上，尽管可能通过虚拟机的方式，造成ip不同但是万一电脑出了故障，所有的Sentinel都会受影响
2、部署至少3个且奇数个数的Sentinel节点,提高准确性
3、合理选择监控多个主节点。比如是监控多个主节点或者是监控一个主节点，如果是监控多个zhu
4、API
Sentinel节点是一个特殊的Redis节点，有自己专属的API，
1、sentinel master
展示所有被监控的主节点的状态已经相关统计信息
有可能监控多个主节点，则展示指定的master则后面加上 mymaster 名字
127.0.0.1:26379> sentinel masters
1) 1) "name"
2) "mymaster"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6379"
7) "runid"
8) "5b2cb1975b0e2cdbe531e6169dcf5da93fab3524"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "435"
19) "last-ping-reply"
20) "435"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "4852"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "350587255"
29) "config-epoch"
30) "0"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "180000"
39) "parallel-syncs"
40) "1"
127.0.0.1:26379>
2、sentinel slaves mymaster
展示置顶master主节点相关的从节点信息
127.0.0.1:26379> sentinel slaves mymaster
1) 1) "name"
2) "127.0.0.1:6380"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6380"
7) "runid"
8) "72702995a478ab9986d5eb6f5e4c05002b97fd92"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "250"
19) "last-ping-reply"
20) "250"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "9088"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "350691871"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "127.0.0.1"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "2760782"
2) 1) "name"
2) "127.0.0.1:6381"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6381"
7) "runid"
8) "d478ed3a435c6995db2dd1b8824bc61c25b30636"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "250"
19) "last-ping-reply"
20) "250"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "9088"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "350691870"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "127.0.0.1"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "2760782"
127.0.0.1:26379> 3、展示置顶master的Sentinel集合
127.0.0.1:26379> sentinel sentinels mymaster
1) 1) "name"
2) "b38f8218f0d136dc6f2b18391a88859aafee6a11"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "26381"
7) "runid"
8) "b38f8218f0d136dc6f2b18391a88859aafee6a11"
9) "flags"
10) "sentinel"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "320"
19) "last-ping-reply"
20) "320"
21) "down-after-milliseconds"
22) "30000"
23) "last-hello-message"
24) "1030"
25) "voted-leader"
26) "?"
27) "voted-leader-epoch"
28) "0"
2) 1) "name"
2) "6f3b48dd910ae93566b52f7adfac2a5ef46e52bb"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "26380"
7) "runid"
8) "6f3b48dd910ae93566b52f7adfac2a5ef46e52bb"
9) "flags"
10) "sentinel"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "320"
19) "last-ping-reply"
20) "320"
21) "down-after-milliseconds"
22) "30000"
23) "last-hello-message"
24) "77"
25) "voted-leader"
26) "?"
27) "voted-leader-epoch"
28) "0"
127.0.0.1:26379>
4、sentinel reset mymaster
对当前sentinel节点关于主节点mymaster的配置进行重置，包含清除主节点状态(例如：故障转移)，重新发现从节点和主节点
sentinel reset mymaster5、sentinel failover mymaster
可以说相当有用，对指定主节点进行故障转移，（不商量）当故障转移完成之后，其他sentine按照故障转移结果进行更新自身配置，这个命令在后期运维中非常有用
sentinel failover mymaster5、实现原理
1、三个定时监控任务
1、每隔10秒，每个Sentinel节点会向主节点和从节点发送info replication命令来获取最新的拓扑结构
作用：
1、用来感知其他新加入的主从节点
2、故障转移之后用来更新拓扑信息
2、每隔2秒会对主节点的频道发送该Sentinel及诶单对于主节点的判断以及当前Sentinel的信息。同时也会订阅该频道，来了解他们各自关于节点的判断
作用：
1、发现新的Sentinel节点并建立连接
1、交换主节点的信息
3、每隔1秒，每隔sentinel节点会向主、从、sentinel及诶单发送ping命令，来确认是不是可达的。
6、主观下线和客观下线
6.1、主观下线
本章之前介绍到，每个Sentinel每隔1秒对主节点、从节点、其他sentinel节点发送ping命令来做心跳检测，当这些超过down-after-millisencondme没有有效回复，则对该节点做失败判定，这个行为就叫做主观下线，那么可以知道这个是当前的sentinel节点的一家之言，有误判的额可能
6.2、客观下线
当判定为的时候，需要和其他的节点进行商量，才会做出下线处理。这个判断就是客观的。
当一个sentinel节点对主节点做主观下线判断后，回、会向其他sentinel节点发送如下命令
SENTINEL is-master-down-by-addr <masterip> <masterport> <sentinel.current_epoch> <runid>
sentinel.current_epoch 当前配置纪元
runid这个参数有两种类型
* 与sentinel节点交换关于主节点下线的判断
当runId 等于当前Sentinel节点的runid时候，是当前sentinel节点希望其他sentinel节点成为领导者的请求举例;发送如下命令，返回结果会包含三个参数
SENTINEL is-master-down-by-addr 127.0.0.1 6379 0 *
返回结果
down_state 目标sentinel节点对主节点的下线判断，1下线，0在线
leader_runid :当leader_runid等于* 时候、，代表返回结果是用来同意主节点是否不可达，当ledader_runid 等于具体的id代表目标节点同意runid成为领导者
leader_epoch 领导者纪元6.3、领导者选举
故障转移实际上是一个sentinel节点完成的，所以会进行领导者选举。
1、每个在线的sentinel节点都有资格成为领导者，当他确认主节点主观下线的时候，回向其他节点发送sentinel is-master-down-by-addr 命令要求将自己设置为领导者
2、受到命令的sentinel节点，如果没有同意过其他sentinel节点，将同意它，否则拒绝
3、如果该sentinel节点发送自己得票大于max(quorum,(sentinel)/2+1) 难免他将成为领导者
4、如果没有选出则，将进行下一场选举
7、故障转移
7.1、挑选一个从节点
1、过滤掉不健康的，主观下线，断线，等
2、选择从节点优先级高的slave-proprity，如果存在则返回，不存在则继续
3、选择复制偏移量最大的，存在则返回，不存在则接续
4、选择runid最小的从节点
7.2、将从节点执行slaveof no one命令让他成为主节点
7.3、sentinel会向其它从节点发送命令，让他们成为新主节点的从节点，复制规则和parallel-syncs参数有关
7.4、sentinel结合将原来的主节点更新为从节点，保持它的关注，当其恢复后复制新的主节点信息
8、故障处理
1、节点下线
临时下线
暂时将节点关掉，之后还会重新启动，继续提供服务
永久下线
节点关掉之后不再提供服务，需要做一下清理工作，如删除配置文件，持久化文件，日志文件
主节点下线
在任意一个sentinel节点上执行下面的命令即可，则会自动进行故障转移工作
sentinel fialover mymaseter 从节点和sentinel下线
下线之后sentinel还会对她进行监控，会造成一定的网络资源浪费
7.2、从节点上线
添加方法：只要加上slaveof [masterip] [masteport] 启动即可 （定时监控10秒）
7.3、添加sentinel节点
添加方法同上，也是配置相关信息即可，sentinel会自动发现（定时监控2秒）
7.4、添加主节点
因为主节点不好掌控，如果需要替换则使用命令手动故障转移
sentinel fialover mymaseter 8、高可用
在应用方初始化的时候，连接的的是sentinel集合。那么在客户端的时候应该连接从节点集群。这里后期再解释吧！
如果满意，请打赏博主任意金额，感兴趣的请下方留言吧。可与博主自由讨论哦
| 支付包 | 微信 | 微信公众号 |
|---|---|---|
 |
 |
 |
