Redis: Sentinel哨兵监控架构及环境搭建

概述

• 在主从模式下，我们通过从节点只读模式提高了系统的并发能力
• 并发不断增加，只需要扩展从节点即可，只要主从服务器之间，网络连接正常
• 主服务器就会将写入自己的数据同步更新给从服务器，从而保证主从服务器的数据相同
• 在这种架构下，它仍然是有一些缺点的，比如说它的可靠性保证不是很好，因为主从模式下，主节点故障了便无法提供写入的服务
• 现在，我们通过哨兵来解决这个问题
  • 然后，主节点其实写的压力也是并没有被释放的
  • 包括主从之间的数据是相同的，它还有数据冗余一个问题
  • 后面集群也会解决这个问题
• 现在，我们主要解决的问题是：主节点挂机了，从节点可以晋升为主节点
  • 在之前，我们需要人工干预，手动去修改应用的主节点地址
  • 然后自己通过命令，让所有的从节点去布置新的主节点
• 哨兵模式把这个过程自动的完成故障转移
• 注意，我们需要知道：
  • 哨兵监控的一个完整流程的搭建
  • 哨兵的一个工作原理，它的机制，包括它是怎么实现故障转移的
  • 如何结合它来改造升级我们的应用项目
  • 主观和客观下线，仲裁如何选取新的主节点的
  • 故障迁移的流程
  • 日志如何分析
  • 常用指令

哨兵监控架构

• 在主从模式中，主节点宕机之后，从节点是可以作为主节点顶上来继续提供服务
• 但是这个过程是需要人工干预的，比如我们要自己去修改主节点地址
• 然后再让其他的从节点去复制新的主节点，于是，Redis@2.8引入了哨兵的概念
• 在主从复制的基础之上，哨兵实现了自动化故障恢复
• 如上面这张图，左边是我们的哨兵，右边是我们 Redis 的主从
• 在这张图中，我们的 Redis 就分为了两部分
  • 一部分是哨兵节点
  • 一部分是数据节点
• 哨兵节点，它就是特殊的 Redis 节点，只不过不存储数据而已
• 数据节点就是原来的主从模式，里面存储的我们项目中的数据
• Redis 它是一种分布式系统的架构模式
• 哨兵主要的作用就是监控 Redis 的主从服务器提供主服务器下线时自动故障转移的功能

1 ）监控 (Monitoring)

• 监控的意思，就是会不断的检查你的主服务器和从服务器是否运作正常

2 ) 提醒 (Notification)

• 被监控的某个 Redis 服务器，如果出现了问题，可以通过api向管理员，或者其他应用程序发送通知，提醒我们

3 ) 自动故障迁移 (Automatic failover)

• 自动故障迁移指的是当一个主服务器不能正常工作时，会开启一次自动故障迁移的操作

4 ) 配置提供者 (Configuration provider)

• 配置提供者指的是我们客户端，它其实不需要直接连到主从，而是连接到哨兵
• 因为哨兵给客户端提供了一个服务发现的功能，客户端连到哨兵之后，就可以直接获取到主从节点的相关信息，如果发生了故障迁移，重新发生新的主节点
• 哨兵也会把新的主节点的信息通知给客户端
• 这就是哨兵监控架构的组成部分，以及它的一些特性

Sentinel 的分布式特性

• 现在我们来看一下它的分布式特性都有哪些点
• 首先第一个就是它降低了误报的可能性
  • 这个意思就是说我们的 Sentinel 实际上它是一个分布式的架构系统
  • 就是说在一个架构中，我们是可以运行多个 Sentinel 进程的
  • 如果有多个 Sentinel 进程，那么当我的master不再可用的时候，我们就降低了误报可能性
  • 为什么呢？因为只有一个 Sentinel 的话，假如说现在发生了网络迁移，我认为这个主节点不可用了
  • 实际上人家是可用的，只不过网络延迟，你跟主节点没有通信，那你就不能说它就宕机了
  • 这个时候，假如有多个 Sentinel 进程，你觉果它不可用了
  • 但是其他的 Sentinel 觉得它是可用的，就不会产生这个误报，它降低了误报的可能
• 第二个就是降低了对客户端的影响
  • 在不同服务器上，我们可以运行多个 Sentinel 进程
  • 然后将 Sentinel 做成集群，那么其中一个故障了
  • 我们仍然是可以进行主从切换的，它可以帮我们去自动的故障迁移
  • 降低了对客户端的影响，提升了系统的健康性
• 第三就是任意的 Sentinel 都可对外提供服务
  • Redis 的客户端，你可以连接到任意的 Sentinel 来使用
  • Redis 不需要特定的去连某一个节点

部署 Redis Sentinel 之前的准备

• 首先第一个就是端口，Sentinel 运行，默认监听的端口是 26379
• 第二个就是至少三个 Sentinel 实例
  • 它指的就是一个健壮的部署至少需要三个 Sentinel 实例，为什么呢？
  • 我们的 Sentinel 在决定我们的 Redis 主节点是否可用？
  • 实际上它是一个少数服从多数的一个仲裁的过程
  • 如果说我只有一个，连不上你，我可能认为你是故障了，但实际上可能是网络延迟导致的。
  • 部署了两个的话，我说没有，你说有，我要听谁的呢？
  • 这样，最好就来个奇数，这样就可以产生大于1/2的结果
  • 那比如说有两个觉得它没连上, 就可以故障迁移
  • 一般建议都是奇数的，3,5,7，最少需要3个 Sentinel 的识别
• 第三就是运行 Sentinel 必须指定配置文件
  • 如果你不指定配置文件的话，它会拒绝启动
  • 因为我们的系统是使用这个文件来保存当前的一个主从状态的
  • 你启动了 Sentinel 的时候，要指定配置文件
  • 是因为它要从配置文件里边去加载当前的环境状态
  • 并且它会把更改故障迁移之后的一些主从信息状态也会写入到配置里边
  • 所以，你不指定配置，它会拒绝启动
• 第四个就是独立的虚拟机或物理机中运行
  • 我们如果在一个虚拟机或者物理机中运行 Sentinel 多个进程的话
  • 实际上是一种非常不妥善不好的方法
  • 如果说这个机器故障了，多个 Sentinel 都被挂掉
  • 所以，最好的还是不要节省资源
  • 把申请脑部署在相对独立的多个虚拟机或者物理机当中
• 第五就是可配置 Sentinel 允许丢失有限的写入
  • 因为 Sentinel 在做切换的时候啊，它肯定是有一部分的数据丢失的
  • 而且 Redis 使用的是一种异步的复制机制
  • 所以说， Sentinel 加 Redis，它不能保证故障期间保留已确认的写入
  • 但是我们是可以配置它允许丢失有限的写入
• 第六就是客户端要支持 Sentinel
  • 你现在用了哨兵，你的客户端必须得支持
  • 现在大部分热门的第三方都是支持 Sentinel 的
• 第七，经常要在测试环境中测试
• 第八，在 Docker 、端口映射或网络地址转换的环境中配置的时候要格外小心
  • 因为在重新映射端口的情况下，真实的端口可能与转发的端口不同
  • 就会破坏 Sentinel 自动发现其他 Sentinel 进程

Sentinel 的优缺点

1 ）优点

• 哨兵模式是基于主从模式的，所以说主从的优点哨兵都有
• 然后主从可以自动切换，系统的可用性能高，不用再去像之前一样人为的去切换
• Sentinel 会不断的检查你的主服务器和从服务器是否运作正常，当被监控的某个 Redis 服务器出现问题时，Sentinel 可以通过 API 向管理或者其他应用程序发送通知

2 ）缺点

• 主从切换的时候是需要时间的，这部分可能会丢失数据
• 还是没有解决主节点写的压力，后面集群分片会解决这个问题
• 主节点写的能力，存储能力都是受到单机的限制
  • 就是说你这个主节点部署在这台服务器上
  • 它肯定通过这台主机的一个性能限制的
• 动态扩容困难复杂
  • 在节点管理中如何在一个运行正常的环境下去动态的添加或者删除
  • 尤其是在删除的时候，会稍微的麻烦一点。如果操作不当，可能还会有影响

监控环境的搭建

1 ）节点准备

角色	IP
Master	192.168.10.101
Slave	192.168.10.102
Slave	192.168.10.103

2 ) 编写配置文件

• 三个节点分别创建 sentinel.conf 并添加以下配置
• $ vi /usr/local/redis/conf/sentinel.conf

  # 放行所有IP限制
  bind 0.0.0.0
  # 进程端口号
  port 2379
  # 后台启动
  daemonize yes
  # 日志记录文件
  logfile "/usr/local/redis/log/sentinel.log"
  # 进程编号记录文件
  pidfile /var/run/sentinel.pid
  # 指示 Sentinel 去监视一个名为 mymaster 的主服务器 后面的 2 表示仲裁 3/2 + 1 = 2 其中3是总计三台机器
  sentinel monitor mymaster 192.168.10.101 6379 2
  # 访问主节点的密码
  sentinel auth-pass mymaster 123456
  # Sentinel认为服务器已经断线所需的毫秒数 默认值是30秒 这里改成10秒 PING PONG 中 返回 PONG 的时间
  sentinel down-after-milliseconds mymaster 10000
  # 若Sentinel 在该配置值内未能完成 failover 操作，则认为本次 failover失败 最终的超时时间 这里设置3分钟
  sentinel failover-timeout mymaster 180000
  

3 ）启动

3.1 先启动 3 台 Redis 服务

• $ /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf 3台分别启动
• 在 主从服务器分别连接进入，查看 主从复制信息 $ info replication

3.2 再启动 3 个 Sentinel 服务

• $ /usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel.conf --sentinel 主服务器
• $ /usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel.conf 2个从服务器

3.3 查看日志

• 主服务器：$ tail -f /usr/local/redis/log/sentinel.log

  1216:X 1 Oct 2024 14:42:14.647 # Configuration loaded
  1216:X 1 Oct 2024 14:42:14.670 * Increased maximum number of open files to 10032 (it was originally set to 024).
  1216:X 1 Oct 2024 14:42:14.671 * Running mode=sentinel, port=26379.
  1216:X 1 Oct 2024 14:42:14.671 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
  1216:X 1 Oct 2024 14:42:14.672 # Sentinel ID is ef7901d7ce89fde9a48501ab0194a0702fb7a6b9
  1216:X 1 Oct 2024 14:42:14.672 # +monitor master mymaster 192.168.10.101 6379 quorum 2
  1216:X 1 Oct 2024 14:42:14.673 * +slave slave 192.168.10.102:6379 192.168.10.102 6379 @ mymaster 192.168.10.101 6379
  1216:X 1 Oct 2024 14:42:14.675 * +slave slave 192.168.10.103:6379 192.168.10.103 6379   @ mymaster  192.168.10.101 6379
  1216:X 1 Oct 2024 14:42:28.835 * +sentinel sentinel 8a0b821f46e52b6c843b993d837c30802b966dbf 192.168.10.102 26379 @ mymaster 192.168.10.101 6379
  1216:X 1 Oct 2024 14:42:40.427 * +sentinel sentinel ca57497475e5317d43c08c3e6c112567c82f725e 192.168.10.103 26379 @ mymaster 192.168.10.101 6379
  

• 由此，整个 sentinel 环境搭建完成