Redis-Sentinel
Redis-Sentinel是redis官方推荐的高可用性解决方案， 当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群， 自动发现master宕机，进行自动切换slave > master。
sentinel主要功能如下：
- 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
- 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
- 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
Sentinel的工作方式：
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。主观下线和客观下线主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
redis主从复制背景问题
Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用：
- 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
- 扩展主节点的读能力，分担主节点读压力。
但是问题是：
- 一旦主节点宕机，从节点上位，那么需要人为修改所有应用方的主节点地址（改为新的master地址），还需要命令所有从节点复制新的主节点
那么这个问题，redis-sentinel就可以解决了
主从复制架构
Redis Sentinel架构
redis的一个进程，但是不存储数据，只是监控redis
redis命令整理
官网地址：http://redisdoc.com/redis-cli info #查看redis数据库信息redis-cli info replication #查看redis的复制授权信息
redis-cli info sentinel #查看redis的哨兵信息
安装与配置
本实验是在测试环境下，考虑到学生机器较弱，因此只准备一台linux服务器用作环境！！
服务器环境，一台即可完成操作
master 192.168.119.10
所有配置文件如下
主节点master的redis-6379.conf
port 6379daemonize yeslogfile "6379.log"dbfilename "dump-6379.rdb"dir "/var/redis/data/"
从节点slave的redis-6380.conf
port 6380daemonize yeslogfile "6380.log"dbfilename "dump-6380.rdb"dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 从属主节点
从节点slave的redis-6381.conf
port 6381daemonize yeslogfile "6380.log"dbfilename "dump-6380.rdb"dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 从属主节点
启动redis主节点
redis-server /etc/redis-6379.conf
测试redis主节点是否通信
redis-cli ping
启动两slave节点
还记得上面超哥的截图吗？总体redis配置文件如下，6379为master，6380和6381为slave
-rw-r--r-- 1 root root 145 Nov 7 17:44 /etc/redis-6379.conf #这个为主，port是6379-rw-r--r-- 1 root root 93 Nov 7 17:42 /etc/redis-6380.conf # 这个是从，port6380，并且得加上新的参数slaveof-rw-r--r-- 1 root root 115 Nov 7 17:42 /etc/redis-6381.conf # 这个是从，port6381，并且得加上新的参数slaveof
redis-6380.conf slave配置文件详解，6381端口的配置文件，仅仅和6380端口不一样
port 6380daemonize yeslogfile "6379.log"dbfilename "dump-6379.rdb"dir "/var/redis/data"# Generated by CONFIG REWRITEslaveof 127.0.0.1 6379
redis.conf详解--补充-- 启动slave从节点的redis服务
[root@master 192.168.119.10 ~]$redis-server /etc/redis-6380.conf[root@master 192.168.119.10 ~]$redis-server /etc/redis-6381.conf
验证从节点的redis服务
[root@master ~]$redis-cli -p 6380 pingPONG[root@master ~]$redis-cli -p 6381 pingPONG
确定主从关系
在主节点上查看主从通信关系
[root@master ~]# redis-cli -p 6379 info replication# Replicationrole:masterconnected_slaves:2slave0:ip=192.168.119.10,port=6380,state=online,offset=407,lag=0slave1:ip=192.168.119.10,port=6381,state=online,offset=407,lag=0master_repl_offset:407repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:406
在从节点上查看主从关系（6380、6379）
[root@slave 192.168.119.11 ~]$redis-cli -p 6380 info replication# Replicationrole:slavemaster_host:192.168.119.10master_port:6379master_link_status:upmaster_last_io_seconds_ago:3master_sync_in_progress:0slave_repl_offset:505slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0
此时可以在master上写入数据，在slave上查看数据，此时主从复制配置完成
开始配置Redis Sentinel
超哥实验的环境是单独一台linux，192.168.119.10
[root@master tmp]# ll /etc/redis-*-rw-r--r-- 1 root root 145 Nov 7 17:44 /etc/redis-6379.conf-rw-r--r-- 1 root root 93 Nov 7 17:42 /etc/redis-6380.conf-rw-r--r-- 1 root root 115 Nov 7 17:42 /etc/redis-6381.conf-rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26379.conf-rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26380.conf-rw-r--r-- 1 root root 556 Nov 7 17:42 /etc/redis-sentinel-26381.conf
redis-sentinel-26379.conf配置文件写入如下信息
// Sentinel节点的端口port 26379 dir /var/redis/data/logfile "26379.log"// 当前Sentinel节点监控 192.168.119.10:6379 这个主节点// 2代表判断主节点失败至少需要2个Sentinel节点节点同意// mymaster是主节点的别名sentinel monitor mymaster 192.168.119.10 6379 2//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达sentinel down-after-milliseconds mymaster 30000//当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点， 原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1sentinel parallel-syncs mymaster 1//故障转移超时时间为180000毫秒sentinel failover-timeout mymaster 180000
redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置仅仅差异是port(端口)的不同。 然后启动三个sentinel哨兵
redis-sentinel /etc/redis-sentinel-26379.confredis-sentinel /etc/redis-sentinel-26380.confredis-sentinel /etc/redis-sentinel-26381.conf
监控拓扑图
此时查看哨兵是否成功通信
[root@master ~]# redis-cli -p 26379 info sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=192.168.119.10:6379,slaves=2,sentinels=3 #看到最后一条信息正确即成功了哨兵，哨兵主节点名字叫做mymaster，状态ok，监控地址是192.168.119.10:6379，有两个从节点，3个哨兵
redis高可用故障实验
大致思路
- 杀掉主节点的redis进程6379端口，观察从节点是否会进行新的master选举，进行切换
- 重新恢复旧的“master”节点，查看此时的redis身份
首先查看三个redis的进程状态
ps -ef|grep redis
检查三个节点的复制身份状态
第一个
[root@master tmp]# redis-cli -p 6381 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6380
第二个
[root@master tmp]# redis-cli -p 6380 info replication# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6381,state=online,offset=54386,lag=0slave1:ip=127.0.0.1,port=6379,state=online,offset=54253,lag=0
第三个
[root@master tmp]# redis-cli -p 6379 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6380
此时，干掉master！！！然后等待其他两个节点是否能自动被哨兵sentienl，切换为master节点
ps -ef|grep 6380 #干掉master进程
此时查看两个slave的状态
精髓就是查看一个参数
master_link_down_since_seconds:13
稍等片刻之后，发现slave节点成为master节点！！
[root@master tmp]# redis-cli -p 6379 info replication# Replicationrole:masterconnected_slaves:1slave0:ip=127.0.0.1,port=6381,state=online,offset=41814,lag=1