由于主从复制存在一个问题：master宕机，需要选中一个slave，执行“slaveof no one”，然后对其余slave执行“slaveof new master”，客户端选择读写新的master，可手动转移，也可写脚本（实现复杂），从而出现Redis Sentinel架构，实现监控节点异常，故障转移，通知客户端的功能，对于客户端来说不会去记录redis地址，而是记录sentinel地址，与sentinel通信。

配置

我的redis目录结构，其中，各种自定义的配置都放在config目录下，日志等放在data下

redisson nacos配置 redis sentinel配置_服务器


先配置主从redis，参见

redisson nacos配置 redis sentinel配置_sentinel_02


其中，7000端口为master，7001和7002为slave

Sentinel主从配置主要部分：

1 port 26379
  2 daemonize yes
  3 pidfile /var/run/redis-sentinel.pid
  4 dir /usr/local/redis/redis-5.0.4/data/
  5 logfile "sentinel-26379.log"
  # 2 的意思是当两个 sentinel monitor发现master有问题时则认定该master有问题
  6 sentinel monitor mymaster 127.0.0.1 7000 2   
  #ping了30000毫秒还没ping通则认定master有问题
  7 sentinel down-after-milliseconds mymaster 30000
  #选择新的master后，slave要对新的master进行复制，1表示并发，每次复制一个，减轻master压力
  8 sentinel parallel-syncs mymaster 1
  #180000表示故障转移时间
  9 sentinel failover-timeout mymaster 180000
 10 sentinel deny-scripts-reconfig yes

将redis目录下的sentinel.conf文件复制一份到config目录下，在利用以下命令将sentinel.conf中的代码去掉注释和空行后的代码输入到redis-sentinel-26379.conf文件中，然后做简单的修改就生成上述代码。

cat sentinel.conf | grep -v "#"| grep -v "^$" > redis-sentinel-26379.conf

需要的配置文件如下

redisson nacos配置 redis sentinel配置_sentinel_03


7000端口监听主redis，7001和7002端口监听从redis，其余三个是sentinel的配置文件

输入命令 redis-cli -p 26380 info查看sentinel信息

redisson nacos配置 redis sentinel配置_sentinel_04


可以看到，sentinels=3，slaves=2

再次输入命令netstat -ntlp查看启动状态

redisson nacos配置 redis sentinel配置_redis_05

测试

现在，kill -9 4667，也就是模拟7000端口的redis宕机

然后查看7001端口redis的日志，其尝试连接7000失败后，受到命令MASTER MODE enabled…，即让它成为主redis

redisson nacos配置 redis sentinel配置_sentinel_06


可以看到，7001成为主redis

redisson nacos配置 redis sentinel配置_服务器_07


再看7002端口redis的日志

redisson nacos配置 redis sentinel配置_客户端_08

Sentinel小结

Sentinel是Redis高可用性的一种解决方案：有一个或多个Sentinel实例组成Sentinel系统可以监视任意多个从服务器，并在被监视的主服务器下线时，自动将主服务器下的某个从服务器升级为新的主服务器，然后又新的主服务器代替已下线的主服务器继续处理命令请求。

Redis Sentinel故障转移步骤：

  1. 多个sentinel发现并确认master有问题
  2. 选举一个sentinel作为领导
  3. 选举一个slave作为master
  4. 通知其余slave成为新的master的slave
  5. 通知客户端主从变化
  6. 等待老的master复活成为新master的slave
    下图是一个Sentinel系统：

    当Sentinel察觉到主服务器下线时：

    当server1的下线时长超过用户设定的下线时长上限时，Sentinel系统就会对server1执行故障转移操作。下图为Sentinel重写选举新的master：

    下图为旧的master重新上线：

    这样就完成了整个故障转移的工作。

相关概念

定时任务

  1. 获取主服务器信息
    Sentinel默认会以每10s一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息以及从服务器的信息。
  2. 获取从服务器信息
    当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接。
    发现slave节点、确认主从关系
  3. 每2ssentinel通过master节点的channel交换信息，达成共识
    如加入一个sentinel节点的时候，其他节点都会知道加入新的节点
    其通信方法是Sentinel通过命令连接向所有监视的主从服务器通过一个_sentinel _ :hello的管道，sentinel将消息发布到这个管道，并且订阅这个管道。
  4. 检测主观下线状态
    Sentinel会以每秒一次的频率向所有与他创建了命令连接的实例（包含主服务器、从服务器、其他Sentinel在内）发送ping命令，并通过结果判断实例是否在线。
  5. 检测客观下线状态
    Sentinel将一个主服务器判断为主观下线状态后，为了确认这个主服务器是否真的下线，会向它同样监视这一主服务器的其他Sentinel进行询问，看他们是否也认为主服务器以及下线（可以是主观下线或者客观下线）。当Sentinel从其他Sentinel哪里接受到足够数量的已下线判断之后，Sentinel就会将服务器判定为客观下线，并对主服务器执行故障转移操作。
    领导者选举
    因为只有一个sentinel节点能够完成故障转移，所以通过选举，选出这个领头sentinel故障转移

    选择slave当做新的master