Redis[7] Redis节点高可用监控之Sentinel

Redis 节点高可用监控之Sentinel

背景
前面搭建了主从，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，人工干预费事费力，还会造成一段时间内服务不可用
哨兵模式介绍
- Redis提供了哨兵的命令，是一个独立的进程
- 原理哨兵通过发送命令给多个节点，等待Redis服务器响应，从而监控运行的多个Redis实例的运行情况
- 当哨兵监测到master宕机，会自动将slave切换成master，通过通知其他的从服务器，修改配置文件切换主机
Sentinel三大工作任务
- 监控（Monitoring）
  - Sentinel 会不断地检查你的主服务器和从服务器是否运作正常
- 提醒（Notification）
  - 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知
- 自动故障迁移（Automatic failover）
  - 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器
  - 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器
问题
- 一个哨兵进程对Redis服务器进行监控，可能会出现问题
- 一般是使用多个哨兵进行监控，各个哨兵之间还会进行监控，形成多哨兵模式
多哨兵模式下线名称介绍
- 主观下线（Subjectively Down，简称 SDOWN）
  - 是单个 Sentinel 实例对服务器做出的下线判断，比如网络问题接收不到通知等
  - 一个服务器没有在 down-after-milliseconds 选项所指定的时间内，对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply），那么 Sentinel 就会将这个服务器标记为主观下线
- 客观下线（Objectively Down，简称 ODOWN）
  - 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断
  - 一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线
  - 客观下线条件只适用于主服务器
- 仲裁 qurum
  - Sentinel 在给定的时间范围内，从其他 Sentinel 那里接收到了【足够数量】的主服务器下线报告，那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线
  - 这个【足够数量】就是配置文件里面的值，一般是Sentinel个数的一半加1，比如3个Sentinel则就设置为2
  - down-after-milliseconds 是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用
  - 当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover

Sentinel哨兵

核心流程
- 每秒ping，超过时间不响应则认为主观下线
- 满足多个，则认为是客观下线
- 投票选择主节点
- 如果没有足够的节点同意master下线，则状态会被移除

主从+Sentinel哨兵集群

启动哨兵集群

./redis-server /usr/local/redis/conf/sentinel-1.conf --sentinel

./redis-server /usr/local/redis/conf/sentinel-2.conf --sentinel

./redis-server /usr/local/redis/conf/sentinel-3.conf --sentinel

网络安全组需要开放端口
优点
- 主从可以自动切换，可用性更高
缺点
- 主从切换会丢失短暂数据
- 主节点的写能力和存储能力受限