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的这个模式