在现代分布式系统中,高可用性是衡量系统稳健性的核心指标之一，对于广泛使用的内存数据库Redis而言，当单个Redis实例因故障或维护而停机时，整个应用服务可能面临中断风险，为了解决这一单点故障问题，Redis官方提供了哨兵模式，本文将深入探讨在CentOS 7环境下，如何部署、配置和管理Redis哨兵模式，以构建一个具备自动故障转移能力的高可用Redis集群。
哨兵机制核心概念
Redis Sentinel（哨兵）是Redis高可用性的解决方案，它是一个分布式系统，由一个或多个Sentinel实例组成，这些Sentinel实例会监控主从复制的Redis服务器集群，其核心功能主要体现在以下四个方面：
- 监控： Sentinel会持续不断地检查你的主服务器和从服务器是否正常运行。
- 通知： 当被监控的Redis服务器出现问题时，Sentinel可以通过API向系统管理员或其他应用程序发送通知。
- 自动故障转移： 当主服务器无法正常工作时，Sentinel会开始一次自动故障转移操作，它会将其中一个从服务器升级为新的主服务器，并让其他从服务器重新复制新的主服务器。
- 配置提供者： Sentinel在完成故障转移后，会向Redis客户端提供新主服务器的地址信息，客户端无需手动修改配置即可连接到新的主节点。
实战部署：在CentOS 7上配置哨兵模式
在CentOS 7上部署哨兵模式，通常需要一个一主二从的Redis环境，以及至少三个Sentinel实例（奇数个，以避免脑裂问题），这里假设Redis主从环境已经配置完毕。
第一步：配置Sentinel节点
我们将在三台不同的服务器（或同一台服务器的不同端口）上部署Sentinel，创建并编辑Sentinel配置文件sentinel.conf，以下是一个关键配置示例：
# sentinel.conf # 端口，默认26379 port 26379 # 告诉Sentinel去监控一个名为mymaster的主服务器， # 其IP为192.168.1.101，端口为6379， # 最后的2表示当至少2个Sentinel认为主服务器下线时，才客观认为其已下线，并开始故障转移。 sentinel monitor mymaster 192.168.1.101 6379 2 # 设置主服务器在多少毫秒内无响应即被视为主观下线（SDOWN） sentinel down-after-milliseconds mymaster 5000 # 设置故障转移超时时间（毫秒） sentinel failover-timeout mymaster 180000 # 在执行故障转移时，最多可以有多少个从服务器同时同步新的主服务器 sentinel parallel-syncs mymaster 1 # 如果设置了密码，需要配置 # sentinel auth-pass mymaster <your-password> # Sentinel生成的配置文件会保存在这里，重启后会自动加载 dir /tmp/sentinel
将此配置文件复制到其他两个Sentinel节点,并根据实际情况修改port和dir。sentinel monitor指令在所有节点上必须保持一致。
第二步：启动Sentinel服务
在每个Sentinel节点上,使用以下命令启动Sentinel：
redis-sentinel /path/to/your/sentinel.conf
为了实现服务化管理和开机自启,我们推荐将其配置为systemd服务，创建一个服务文件/etc/systemd/system/redis-sentinel.service：
[Unit] Description=Redis Sentinel After=network.target [Service] Type=notify User=redis Group=redis ExecStart=/usr/local/bin/redis-sentinel /etc/redis/sentinel.conf ExecStop=/bin/kill -s QUIT $MAINPID Restart=always LimitNOFILE=65536 [Install] WantedBy=multi-user.target
然后重新加载systemd并启动服务：
systemctl daemon-reload systemctl start redis-sentinel systemctl enable redis-sentinel
故障转移工作流程
当主节点宕机时,Sentinel集群会执行以下自动化流程：
- 发现主节点主观下线（SDOWN）： 某个Sentinel实例在
down-after-milliseconds时间内未收到主节点响应，会将其标记为SDOWN。 - 确认主节点客观下线（ODOWN）： 该Sentinel会向其他Sentinel询问是否也认为主节点下线，当足够数量（达到
quorum值）的Sentinel确认后，主节点被标记为ODOWN。 - 选举领头Sentinel： 确认ODOWN后，Sentinel们会选举出一个领头者来负责执行故障转移。
- 执行故障转移： 领头Sentinel从从节点列表中选择一个最佳的从节点（根据数据同步优先级、复制偏移量等），向其发送
SLAVEOF NO ONE命令，将其提升为新的主节点。 - 重新配置其他从节点： 领头Sentinel让其他从节点去复制新的主节点。
- 更新配置： 原下线的旧主节点恢复后，Sentinel会自动将其配置为新主节点的从节点。
下表小编总结了关键配置参数的作用：
| 配置参数 | 格式 | 作用说明 |
|---|---|---|
sentinel monitor | <master-name> <ip> <port> <quorum> | 定义监控的主节点信息及法定人数 |
sentinel down-after-milliseconds | <master-name> <milliseconds> | 主观下线判断时间 |
sentinel failover-timeout | <master-name> <milliseconds> | 整个故障转移过程的超时时间 |
sentinel parallel-syncs | <master-name> <num> | 故障转移后同时进行同步的从节点数量 |
客户端如何连接哨兵模式
应用程序不应直接连接Redis主节点的IP,而是应该连接Sentinel集群，主流的Redis客户端（如Jedis, Lettuce, StackExchange.Redis）都提供了对哨兵模式的支持，客户端初始化时会向Sentinel列表请求当前主节点的地址，获取地址后直接与主节点通信，当主节点发生变更时，客户端会收到Sentinel的通知，并自动更新连接，从而实现对上层应用的透明切换。
相关问答FAQs
Q1: 哨兵节点的数量应该如何选择？为什么推荐是奇数个？
A1: 哨兵节点的数量应根据系统对高可用的要求来定，最少需要3个，推荐使用奇数个（如3、5、7）是为了避免“脑裂”问题，在分布式系统中，当网络分区发生时，如果哨兵节点是偶数个，可能会出现两个分区内的哨兵节点数量相等，各自选举出领头哨兵，导致出现两个“主节点”，数据写入会不一致，而奇数个节点可以确保在任何网络分区下，只有一个分区能获得超过半数的票数，从而选举出唯一的领头哨兵，保证数据一致性。
Q2: 如果哨兵节点本身宕机了怎么办？
A2: 这正是哨兵模式需要部署多个哨兵实例的原因，单个哨兵节点宕机不会影响整个Redis集群的可用性，只要存活的哨兵节点数量仍然能够达到quorum（法定人数）的要求，监控、通知和故障转移功能依然可以正常工作，在quorum为2的3哨兵节点集群中，即使有1个哨兵宕机，剩下的2个哨兵依然可以达成共识并执行故障转移，为了保证哨兵系统自身的可靠性，应将哨兵实例部署在不同的物理机或虚拟机上，避免单点故障。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复