【Redis】高可用之二：哨兵（sentinel）

 本文是Redis系列第5篇，前4篇欢迎移步 

【Redis】不卡壳的 Redis 学习之路：从十大数据类型开始入手_AQin1012的博客-CSDN博客关于Redis的数据类型，各个文章总有些小不同，我们这里讨论的是Redis 7.0，为确保准确，我们直接看官网。https://blog.csdn.net/aqin1012/article/details/130365083

【Redis】持久化机制详解：从RDB到AOF，你需要知道的一切_AQin1012的博客-CSDN博客持久化其实就4个单词：加强数据安全Redis支持两种不同的持久化机制，RDB和AOF。https://blog.csdn.net/aqin1012/article/details/130481261

【Redis】不卡壳的 Redis 学习之路：事务_AQin1012的博客-CSDN博客数据库中的事务是指在一次与数据库连接的会话中，所有的SQL语句，要么都成功，要么都失败。在Redis中，事务是指可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会被序列化，按顺序地串行执行而不会被其他命令插入开启：以MULTI开始一个事务入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面执行：由EXEC命令触发事务。https://blog.csdn.net/aqin1012/article/details/131474273?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22131474273%22%2C%22source%22%3A%22aqin1012%22%7D

【Redis】高可用之一：复制（replica）_AQin1012的博客-CSDN博客官网地址: https://redis.io/docs/management/replication/其实就是主从复制，master以写为主，slave以读为主当master数据变化的时候，自动将新的数据异步同步到其它slave数据库主机（master）能读能写，从机（slave）只能读无论主机已经写了多少数据，从机一旦启动，就会全部复制过来，后续主机写，从机跟配置文件🆚命令配置使用配置文件进行主从配置时，如果主机挂了，从机不会变化，还可以提供读的功能，等待主机恢复（重启后主从关系仍在）https://blog.csdn.net/aqin1012/article/details/131531792?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22131531792%22%2C%22source%22%3A%22aqin1012%22%7D

本文目录

什么是哨兵

功能

案例演示实战步骤

架构介绍

具体操作

配置

启动

查看日志

模拟主机宕机

总结

故障转移

选举Leader实施故障转移

故障转移具体步骤

哨兵“食用”建议

---

上一篇我们介绍了复制，正是由于复制的痛点，于是产生了哨兵（sentinel）

什么是哨兵

哨兵会巡查监控后台master主机，查看是否存在故障，如果故障了，就会根据投票数自动将某一个从库转换为新主库，继续对外服务（解决复制的痛点）

官方网址

https://redis.io/docs/management/sentinel/

简单来讲，哨兵就是一种无人值守的运维机制

功能

• 监控redis运行状态，包括master和slave
  • 当master down机，能自动将slave切换成新master

• 主从监控 · Monitoring
  • 监控主从库是否正常运行

• 消息通知 · Notification
  • 可以将故障转移的结果发送给客户端
• 故障转移 · Automatic failover
  • 如果主机异常会进行主从切换，将其中一个从机切换为新的主机
• 配置中心 · Configuration provider
  • 客户端通过连接哨兵来获取当前redis服务的主节点地址

案例演示实战步骤

架构介绍

• 3个哨兵
  • 自动监控和维护集群，不存放数据，只是“吹哨人”

• 1主2从
  • 用于数据读取和存放

具体操作

配置

redis的一主二从配置建议参考

【Redis】高可用之复制（replica）https://blog.csdn.net/aqin1012/article/details/131531792

配置好一主二从后，将解压缩后的Redis/opt目录下的sentinel.conf 复制到自定义的aqinredis文件夹中

接着进行相关配置修改

• bind：服务监听地址，用于客户端连接，默认本机地址
• daemonize：是否以后台daemon方式运行
• protected-mode：安全保护模式
  • Redis 的保护模式（protected mode）是一种安全机制，旨在保护 Redis 实例免受未经授权的访问。当保护模式开启时，Redis 只允许来自本地主机的连接请求，而拒绝来自其他主机的连接请求
    • 保护模式的目的是防止未经授权的访问者远程连接到 Redis 服务器，并避免可能的安全漏洞。如果 Redis 实例暴露在公共网络中并且未开启保护模式，攻击者可能会发起针对 Redis 的恶意操作，例如读取、修改或删除数据，甚至执行系统命令
    • 通过将保护模式设置为开启，Redis 将限制对其服务器的访问，只允许来自本地主机的连接请求。这意味着只有在 Redis 实例运行在本地主机上，或者在本地主机上具有相应权限的客户端才能连接到 Redis。这种限制有助于减少潜在的安全风险，并提供了一层额外的保护
    • 要关闭保护模式，您需要修改 Redis 的配置文件（redis.conf）并将 protected-mode 选项设置为 no。但是，在这种情况下，您应该确保 Redis 实例受到适当的网络和身份验证措施的保护，以防止未经授权的访问。
• port：端口
• logfile：日志文件路径
• pidfile：pid文件路径
• dir：工作目录

（以上都可以按照配置Redis一主二从的文章对配置文件Redis.conf的修改）

设置要监控的主机服务器

• sentinel monitor <master-name> <ip> <redis-port> <quorum>
• quorum参数详解
  • quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
  • 我们知道，网络是不可靠的，有时候一个哨兵会因为网络堵塞而误以为一个Redis主机已经死掉了，在哨兵集群环境下需要多个哨兵互相沟通来确认某个主机是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个哨兵认为这个主机有故障，才会对这个主机进行下线以及故障转移。因为有的时候，某个哨兵节点可能因为自身网络原因，导致无法连接主机，而此时该主机并没有出现故障，所以，这就需要多个哨兵都一致认为该主机有问题，才可以进行下一步操作，这就保证了公平性和高可用。
• sentinel auth-pass <master-name> <password>

下面👇提供需要配置的全部参数（跟着操作的同学🧑🎓直接拷贝即可，注意对应参数的修改）

bind 0.0.0.0
daemonize yes
protected-mode no
port <端口号>
logfile "/aqinredis/sentinel<端口号>.log"
pidfile /var/run/redis-sentinel<端口号>.pid
dir /<自定义存放的文件夹📁>
sentinel monitor mymaster <主机IP> <主机端口号> 2
sentinel auth-pass mymaster <密码>

按本文操作的3台配置分别如下图

bind 0.0.0.0 代表不限制就类似于把bind 127.0.0.1 注释掉

启动

执行redis-sentinel启动（记得添加软连接）

依次使用各自的配置文件启动

启动成功～

查看日志

查看哨兵日志，可以看到其监控的主从信息，以及烧饼集群的信息

原先的配置文件也会自动写入一些内容（下图红框框）

模拟主机宕机

接下来我们模拟主机宕机

此时有以下问题需要注意

• 数据是否还在
• 能否从剩下的两台主机中选出新的主机
• 如果宕机的主机恢复，是否会出现主机冲突

过一段时间以后（给哨兵选举的时间）再尝试获取可以发现，原先的数据还在

尝试插入数据，会发现6381上可以，6380不行（还是只读）

查看下此时两台从机的信息

我们查看下sentinel日志，看看发生了什么

sentinel26379.log

sentinel26380.log

sentinel26381.log

从上面三个哨兵日志可以看到，哨兵在确认主机宕机后（我们的案例配置的quorum是2，即3个哨兵中至少有2个认为主机宕机就确认主机宕机），对从机进行了新主机的投票选举，最终决定将主机从172.17.0.2 6379切换成了172.17.0.4 6381

重启172.17.0.2 6379，并查看其主从信息

可以看到，此时6379变成了6381的从机（不会出现主机冲突）

由于目前6379是从机，因此也无法进行写操作

总结

总结我们上面提到的三个问题：

• 主机宕机，从机数据还在
• 会从剩下的两台主机中选出新的主机
• 如果宕机的主机恢复，不会出现主机冲突，恢复的主机将变为新主机的从机

故障转移

选举Leader实施故障转移

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者（leader），并由该leader进行接下来的故障迁移（failover），那么这个Leader是如何选择出来的呢？

我嫩还是从日志入手

由sentinel26379.log可以看到，sentinel26379的ID是047a7c7a62a803bf8fc63b7033f9b52b4279c9c2，他把票投给了ID为b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc的sentinel26381

由sentinel26380.log可以看到，sentinel26380的ID是a5b3bcfca0e27c760ef4d0b2a88022146600c16c，他把票投给了他自己

由sentinel26381.log可以看到，sentinel26381的ID是b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc，他也把票投给了他自己

此时sentinel26381有2票，sentinel26380有1票，因此，sentinel26381当选leader，并执行后续的故障转移流程选出新的主机

哨兵的Leader是怎么选的？

通过raft算法，这个算值得单独出一篇来讲(￣∇￣)/

故障转移具体步骤

• “新主登基”
  • 某个Slave被选中成为新Master
  • 选出新master的规则（剩余slave节点健康前提下）
    • redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先越高）

    

• • • 复制偏移位置offset最大的从节点
    • 最小Run ID的从节点（字典顺序，ASCII码）

• “群臣俯首”
  • 朝天子一朝臣，换个码头重新拜
  • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
  • Sentinel leader会对选举出的新主机执行slaveof no one操作，将其提升为主节点
  • Sentinel leaderl向其它从节点发送命令，让剩余的从机成为新的主节点的丛节点
• “旧主拜服”
  • 老主机回来也认怂
  • 将之前已下线的老主机设置为新选出的新主机的从节点，当老主机重新上线后，它会成为新主节点的从节点
  • Sentinel leader会让原来的主节点降级为从节点并恢复正常工作。

总结

上述的failover操作均由sentinel自己独立完成，完全无需人工干预

哨兵“食用”建议

• 哨兵节点数量应为多个（集群，保证高可用）
• 哨兵的数量应为基数（便于选举）
• 各个哨兵的配置应该一致（包括硬件等）
• 如果哨兵节点以Docker容器等方式部署，需要注意端口的映射问题
• 哨兵集群+主从复制，并不能保证数据零丢失（选举期间Redis无法写入）

于是我们有了下一篇——集群！敬请期待(￣∇￣)/🎉～～～～～～～～～