目录

哨兵概念

配置与启动哨兵

哨兵工作原理

• 哨兵概念

• 首先来看一个业务场景：
• 如果redis的master宕机了，此时应该怎么办？
• 那此时可能需要从一堆的slave中重新选举出一个新的master
• 那这个操作过程是什么样的呢？这里面会有什么问题出现呢？
• 要实现这些功能，就需要redis的哨兵
• 那哨兵是什么呢？
• 哨兵
• 哨兵(sentinel)是一个分布式系统
• 用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
• 哨兵的作用：
• 监控：
  • 监控master和slave
  • 不断的检查master和slave是否正常运行
  • master存活检测、master与slave运行情况检测
• 通知（提醒）：
• 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
• 自动故障转移：
• 断开master与slave连接，选取一个slave作为master，将其它slave连接新的master，并告知客户端新的服务器地址
• 注意：哨兵也是一台redis服务器，只是不提供数据相关服务，通常哨兵的数量配置为单数

• 配置与启动哨兵

• 配置一拖二的主从结构（利用之前的方式启动即可）
• 配置三个哨兵（配置相同，端口不同），参考sentinel.conf
• 1：设置哨兵监听的主服务器信息， sentinel_number表示参与投票的哨兵数量
• sentinel monitor master_name master_host master_port sentinel_number
• 2：设置判定服务器宕机时长，该设置控制是否进行主从切换
• sentinel down-after-milliseconds master_name million_seconds
• 3：设置故障切换的最大超时时长
• sentinel failover-timeout master_name million_seconds
• 4：设置主从切换后，同时进行数据同步的slave数量，数值越大，要求网络资源越高，数值越小，同步时间越长
• sentinel parallel-syncs master_name sync_slave_number
• 启动哨兵
• redis-sentinel filename

• 哨兵工作原理

• 哨兵在进行主从切换过程中经历三个阶段
  • 监控
  • 通知
  • 故障转移
• 阶段一：监控
• 用于同步各个节点的状态信息
  • 获取各个sentinel的状态（是否在线）
  • 获取master的状态
    • master属性
      • runid
      • role：master
    • 各个slave的详细信息
  • 获取所有slave的状态（根据master中的slave信息）
    • slave属性
      • runid
      • role：slave
      • master_host、master_port
      • offset
      • ....
• 阶段二：通知
• sentinel在通知阶段要不断的去获取master/slave的信息，然后在各个sentinel之间进行共享
• 例其中一个sentinel抢先给每个节点发送hello，看有没有那个服务器宕机了，如果一切正常，就给其它sentinel通知正常
• 阶段三：故障转移
• 确认master是否真的宕机
  • sentinel1一直向master发送hello，发现没有响应
  • sentinel1获取到flags:SRI_S_DOWN的信息，主观判断master已经挂了
  • 给其它的sentinel发送SENTINEL is-master-down-by-addr ........ ，也就是说，告诉其它sentinel，master已经挂了
  • 其它sentinel不轻易相信sentinel1，于是好奇，给master发送hello，探测一下master是不是真的挂了
  • 由于超过半数的sentinel都说master挂了，那么master就真的挂了
  • 更新SentinelRedisInstance的master信息为flags:SRI_O_DOWN
• 投票选举一个sentinel去进行主从切换的处置操作
  • 五个哨兵在微信群上各自发送一条消息，每个哨兵既参与竞选又参与投票
  • 投票规则是这样的：在一个时刻里面，谁先收到哪个发送者的信息，谁就投票给哪个发送者
  • 假设在极短的时间内，只有sentinel1和sentinel4的网络状态非常良好，于是比其它sentinel先发出消息了
  • 这时候，sentinel2最先接收到sentinel1的信息，sentinel4慢了一步，所以sentinel2会给sentinel1投票，sentinel1的票数+1
  • 按照这个规则去投票，票数最多的那个sentinel被安排主从切换的处置操作
• 主从切换的处置操作
  • 备选原则如下列表：
  • 服务器列表中挑选备选master
    • 在线的（保留）
    • 响应慢的（被OUT）
    • 与原master断开时间久的（被OUT）
  • 优先原则
    • 优先级（优先级高的保留）
    • offset（偏移量小的保留）
    • runid（runid小的保留）
  • 发送指令
  • 向新的master发送slaveof no one，告知新的master，恭喜你，你当上领导了
  • 向其它slave发送slaveof 新master的IP和端口，告知各位slave兄弟们，你们去连接新的master吧