Redis 哨兵模式的一些思考

为什么会出现哨兵模式

 Redis主从复制模式下，如果主节点出现故障将不能再继续提供服务，需要人为将从节点提升为主节点，同时还需要通知各个应用新的主节点的地址，这个在很多场景下是不能接受的，哨兵模式能很好的解决这个问题

• Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态

• 在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用（HA）

• 其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。

 哨兵的作用

• 监控(Monitoring): 哨兵(sentinel) 会不断地检查集群中的Master和Slave是否运作正常。

• 提醒(Notification):当被监控的某节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

• 自动故障迁移(Automatic failover)：当一个Master客观下线时，哨兵(sentinel) 会开始一次自动故障迁移操作。

  • 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；

  • 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

  • Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

哨兵进程的工作方式

• 每个Sentinel进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel进程发送一个 ping 命令。
• 如果一个实例（instance）距离最后一次有效回复 ping 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）。
• 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有Sentinel进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。
• 当有足够数量的 Sentinel（个数可配置）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
• 在一般情况下， 每个Sentinel进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 info命令。
• 当Master主服务器被 Sentinel进程标记为客观下线（ODOWN）时，Sentinel进程向下线的 Master主服务器的所有 Slave从服务器发送 info命令的频率会从 10 秒一次改为每秒一次。
• 若没有足够数量的 Sentinel进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel进程发送 ping命令返回有效回复，Master主服务器的主观下线状态就会被移除。

哨兵服务理想部署方案 

 

进程如下 

# 在单台机器上做的测试
root     31363     1  0 7月28 ?       00:01:51 /mnt/redis/bin/redis-server 0.0.0.0:6380
root     31375     1  0 7月28 ?       00:01:57 /mnt/redis/bin/redis-server 0.0.0.0:6381
root     31387     1  0 7月28 ?       00:01:55 /mnt/redis/bin/redis-server 0.0.0.0:6382
root     31552     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26380 [sentinel]
root     31557     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26381 [sentinel]
root     31563     1  0 7月28 ?       00:02:31 /mnt/redis/bin/redis-sentinel 0.0.0.0:26382 [sentinel]

哨兵服务发现和健康检查流程及故障切换流程

 

哨兵的启动和配置

# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的
# sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0

# 后台运行
daemonize yes

# 默认yes，没指定密码或者指定IP的情况下，外网无法访问
protected-mode no

# 哨兵的端口，客户端通过这个端口来发现redis
port 26380

# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信
# sentinel announce-ip

# 临时文件夹
dir /tmp

# 日志
logfile "/mnt/redis/logs/sentinel-26380.log"

# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 192.168.16.40 6380 2

# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000

# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel failover-timeout mymaster 3000

# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1

什么是主观下线

• 使用ping命令
• 主观下线：单个哨兵自身认为redis实例已经不能提供服务
• 监测机制：哨兵向redis发送ping请求，+PONG、-LOADING、-MASTERDOWN这三种情况视为正常，其他回复均视为无效
•  对应配置项：sentinel down-after-milliseconds mymaster 1000

哨兵如何知道Redis主从信息

•  使用 redis-cli -p 6380 info Replication命令去获取主从关系
• 对应配置信息

  
  # Generated by CONFIG REWRITE
  pidfile "/var/run/redis.pid"
  user default on nopass ~* +@all
  sentinel failover-timeout mymaster 3000
  sentinel config-epoch mymaster 3
  sentinel leader-epoch mymaster 3
  sentinel known-replica mymaster 192.168.16.40 6381 #记录了从属节点6381
  sentinel known-replica mymaster 192.168.16.40 6382 #记录了从属节点6382   
  sentinel known-sentinel mymaster 192.168.16.40 26381 4cabf69629c1401289b6d3d239eba18b45da0041
  sentinel known-sentinel mymaster 192.168.16.40 26382 20d8240e06a10cd887b752026c00de0318761eb8
  sentinel current-epoch 3
  

   

什么是客观下线

• 使用SENTINEL is-master-down-by-addr命令询问其他哨兵master节点是否已经下线
• 客观下线：一定数量之的哨兵认为master已经下线，即可判定为master客观下线
• 检测机制：当哨兵主观认为master下线后，会通过SENTINEL is-master-down-by-addr命令询问其他哨兵是否master已经下线，如果达成共识(达到quorum个数)，就认为master节点客观下线，开始故障转移流程
• 对应的配置项：sentinel monitor mymaster 192.168.16.40 6380 2

哨兵之间如何通信(发布订阅机制)

• slaveof 主从连接
•  sentinel 向Master 发送 SUBSCRIBE 命令，订阅 Master 的 Hello Channel （SUBSCRIBE __sentinel__:hello），等待接收消息
•  sentinel 向 Master 发送 INFO 命令，获取服务信息，及发现主从关系（获取到 Slave 信息）
•  sentinel 向 Master/Slave 发送 SUBSCRIBE 命令，与 2 类似（这次有了Slave节点）。如果之前已有的连接正常，则不会再次重复连接，因此正常情况下这一步只会连接新加入的Slave节点。
•  sentinel 向 Master/Slave 发送INFO命令，与 3 类似。
•  sentinel 向 Master/Slave 发送PUBLISH命令，扩散消息（当前Sentinel/Master 信息 ）。sentinel 接收到了 Master/Slave 中 Hello Channel 中的消息，得到其他的Sentinel 信息，然后保存到对应Master 下的 Sentinels 列表中。至此，整个 sentinel 结构中的节点数据基本完善。
•  sentinel 向 Master/Slave/Sentinel 发送 PUBLISH命令，扩散消息。
  在经过多次的消息扩散之后，每个 master 下的 sentinels 列表会逐渐增多。最终，每个 sentinel 中将保存着所有 Sentinel/Master/Slave 信息，并且不断进行心跳监测，信息同步。

 哨兵领导选举机制

• 基于Raft算法实现的选举机制
•  拉票阶段：每个哨兵节点都希望自己成为leader
• sentinel节点收到拉票命令后，如果没有收到或者是同意其他sentinel节点的请求，就同意该节点的请求(每个节点只有一个同意票)
• 如果sentinel节点发现自己的票数已经超过一半的数值，那么它就成为leader，去执行故障转移
• 投票结束后，如果超过failover-timeover时间，没进行实际的故障转移操作，则重新拉票选举

RedisMaster选举方案(从slave中选出)

• 首先，slave节点状态： 非S_DOWN，O_DOWN，DISCONNECED 状态才能满足
  • 判断规则： (down-after-milliseconds*10)+milliseconds_since_master_is_in_SDOWN-state
  • SENTINEL slaves mymaster
•  其次，查看优先级
  • redis.conf中的配置项：slave-prioprity值越小，优先级越高
• 再次，数据同步情况
  • Replication offset processed
• 最后，最小的run id
  • run id 比较方案：字典顺序，ASCII码

最终主从切换过程 

• 针对即将成为master的slave节点，将其撤出主从集群
  • 执行命令： slaveof NO ONE
•  针对其他slave节点，使它们成为新的master从属节点
  • 执行命令：slaveof 192.168.16.40 6381