Redis: Sentinel节点管理，故障迁移一致性以及TILT模式

节点管理

• 节点管理指的是在我们环境正常的情况下，我们想要动态的去添加或者删除节点

1 ）添加 Sentinel

添加单个 Sentinel

• 如果在一个环境中，我们想要去添加 Sentinel，实际上是非常简单的
• 因为基于 Sentinel 自动发现的机制
  • 我们只需要启动配置了 sentinel monitor mymaster 这个配置项的一个新的 Sentinel 即可
• 在10秒内 Sentinel 将会获得其他 Sentinel 列表以及被监控的 master 的所有内部的相关信息
  • 这就是它的便捷之处
  • 因为他们内部要 PING 和 PONG, 要 INFO
  • 有定时任务在那，所以你只需要把配置文件配好
  • 启动这个Sentinel就十秒内一般就集成到这个环境中

添加多个Sentinel

• 有时候我们可能想要添加多个，建议一个一个去添加
• 因为我们每添加一个Sentinel的时候
  • 我们要保证它跟我们环境中其他的Sentinel节点都已经完全建立了通信关系
  • 再去添加下一个，否则频繁的快速的添加多个的时候，可能会导致有的Sentinel就会增加失败
  • 这样可能就会导致环境出问题
• 如果你想要有效的保证大多数的 Sentinel 都是正常的
  • 一般建议每30秒添加一个，尤其是添加完了以后
  • 最好是使用 SENTINEL MASTER mastername 这个命令
    • 这个 mastername 替换成自己配置的，比如 mymaster
    • 在返回中，有相关的信息，可以查看对比
    • 检查所有Sentinel是否已经完全获取到所有 Master 信息
    • 去查看一下你当前Sentinel的节点和你的主从的信息

2 ）删除 Sentinel

• Sentinel 不会完全清除已经添加过的Sentinel信息
  • 因为你如果要删 Sentinel，Sentinel的配置文件里边记入了所有的Sentinel相关环境的信息
  • 启动 Sentinel 的时候，要指定配置文件，否则它会拒绝启动
  • 因为它要通过配置文件来读取当前的环境，因为他把环境全部写到这个配置文件里边去了
  • 比如说我要删除一个节点，这个配置文件里边有它找到的其他的Sentinel节点的信息
  • 正因为这个机制，它不会频繁的去修改自己的配置
  • 它内部尽量减少 Sentinel 配置版本的一个更新
  • 所以，即使咱们的 Sentinel 很长时间无法访问，它也不会把这个信息给清掉
• 如果说我们真的要删这些信息，应遵循以下步骤
  • 第一步，停止要删除的 Sentinel 进程
  • 第二步，SENTINEL RESET * 向其他的Sentinel实例发送重置命令。
    • 这个 * 代表的是你要重置的一个主机
    • 可以用确切的主机来代替
    • 如果要删除多个，则一个接一个的去执行，就跟添加一样
    • 我建议是30秒，最好删完了去查看一下，每个Sentinel之间的数据数量是不是一致了
    • 再去执行下一个，这样的话得重置一下，配置就会相当于重新的去添加一下
    • 就会永久的把你想删的Sentinel给删掉了
    • 否则它内部的机制是不会频繁去修改配置的
    • 这个需要谨慎操作
• 一般我们就是在最初的时候确定好环境了，就不再动它了
  • 尽可能就是添加，那万一删除操作不当可能会对我们环境会有很大的影响

3 ）删除旧的 Master 或者无法访问的 Slave

• 比如说, 按照我们的主从环境，并发上来了之后是可以动态的去添加从节点的
• 而且添加从节点也非常简单，只需要启动一个新的Redis，其配置文件里边有 slaveof 或 replicaof
  • 就是让它去复制谁，它就会加入到咱们的主从环境里
• 现在我想要把它删除掉，同样的配置文件里边，它会记住这些信息
• 这里和上面一样，谨慎操作，遵循以下步骤
  • 将当前无用的 Slave 进程停止后，向所有 Sentinel 发送命令 SENTINEL RESET mastername
  • 重置 mastername 所有状态信息，重置当前主从信息，停掉的 Slave 就不会被加载进来了

故障迁移一致性

• 这里用到了分布式一致性的算法 Raft 共识算法，就是怎样选举 Sentinel 节点为领头节点

1 ) Sentinel自动故障迁移使用Raft算法来选举领头(leader)Sentinel, 从而确保在一个给定的周期(epoch)里，只有一个领头产生

2 ) 这表示在同一个周期中，不会有两个Sentinel同时被选中为领头，并且各个Sentinel在同一个节点中只会对一个领头进行投票

3 ) 更高的配置节点总是优于较低的节点，因此每个Sentinel都会主动使用更新的节点来代替自己的配置。

简单来说，我们可以将Sentinel配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出 (last-write-wins) 的方式（也即是，最新的配置总是胜出) 传播至所有其他 Sentinel

TILT模式

• 因为Sentinel是比较严重的依赖系统时间的，在配置文件里边，它有很多跟时间相关的配置

• 如果拿不到系统时间，我怎么判断这个时间是不是超时了

• 怎么判断这个故障迁移是不是已经超出了规定时间

• 它一般会记录最后一次回复PING的时间，并和当前的时间进行判断

• 但是假如现在系统时间出了问题了，比如说某些原因，服务器压力很大

• 因为你获取系统时间，它际际上也是一个进程，可能会被阻塞，拿不到系统时间

• 为了确保这个问题能得到有效的解决, Redis 的作者就增加了一个TILT模式

• 该模式是一种特殊的保护模式，就是说如果有一个Sentinel 节点拿不到系统时间了

• 然后就会让这个节点抓紧进入TITL模式，它实际上是一种保护模式

• 当处于TITL模式，Sentinel 或持续监控所有状态，但：

  • 停止处理请求
  • 当有实例向这个Sentinel发送 SENTINEL is-master-down-by-addr 命令时，Sentinel返回负值：因为这个Sentinel所进行的下线判断已经不再准确

• 如果TILT可以正常维持30秒钟 (SENTINEL_TILT_PERIOD时长，默认为30s), 那么Sentinel 退出TILT模式，TITL模式是Sentinel的被动模式

• 如果说退出之后，仍然还是拿不到系统时间，可能还是有问题，它就会再重新进去。

  • 假如说，现在在TILT模式里边，我们可能还要去做一些跟时间相关的判断
  • 无法判断，它就会延长TILT的模式的一个时长，默认是30秒

总结

• raft 共识算法保证了故障迁移一致性
  • 在同一个周期里边，不会产生多个领头者
  • 也就不会产生多个故障迁移
  • 保证了故障迁移的一致性
• TILT模式
  • 是当前节点如果服务器压力大，或者说因为某些其他的原因导致获取不到系统时间
  • 没有办法有效的做出命令的回复的一个间隔判断，那么它就会进入TILT这个保护模式
  • 当这个保护模式正常运行 30 秒钟，它就会退出
  • 如果在这个保护模式期间仍然要做时间判断，还是没有办法去处理，它会延长TILT的这个模式