当前位置：首页 > 问答 > 正文

红帽子里怎么弄Redis的浮动IP，配置上有啥要注意的地方啊

瞿欣合
问答
2025-12-27 23:34:56
5

你问的“Redis浮动IP”本身不是一个Redis软件自带的功能，Redis主从复制本身不负责IP地址的切换，这个浮动IP（也常叫虚拟IP或VIP）是高可用性方案中的一个组成部分，目的是当主Redis服务器宕机时，让客户端仍然能通过一个固定的IP地址连接到新的主服务器，而这个IP会“浮动”到健康的服务器上，在红帽系（包括CentOS、RHEL、Fedora等）Linux上，实现这个目标通常需要借助额外的工具，最经典和常见的是配合Keepalived来实现。（来源：基于常见的Linux高可用性实践）

会围绕“如何使用Keepalived为Redis主从切换配置浮动IP”来展开，并重点说明配置中的关键点和容易踩坑的地方。

基础环境准备

在开始配置之前,有几件事必须确保已经做好：

至少两台服务器：假设我们有两台红帽系统的服务器，主机名分别为redis-node-01和redis-node-02，它们需要有固定的静态IP地址，比如192.168.1.10和192.168.1.11。
Redis主从复制已搭建：在两台服务器上都已经安装并启动了Redis服务，你需要明确设定其中一台（比如redis-node-01）为Master，另一台（redis-node-02）为Slave，并且从节点已经成功连接到主节点，数据同步正常，检查命令是在Redis从节点上执行INFO replication，看到role:slave和master_link_status:up就算成功。（来源：Redis官方文档关于复制的部分）
规划一个浮动IP：这个IP必须和你的两台服务器在同一个网段，并且是当前没有被任何设备占用的IP，我们可以规划使用192.168.1.100作为浮动IP。
防火墙和SELinux：要确保Redis端口（默认6379）和Keepalived用于健康检查的VRRP协议通信端口（通常是IP协议号112）在防火墙是放行的，SELinux可以先设置为permissive模式来排除干扰，等一切调试成功后再研究严格策略。

Keepalived配置的核心要点

Keepalived是这个方案的大脑,它负责：

在两台服务器之间通信,判断对方是否活着。
根据预设的优先级（priority）决定谁应该持有这个浮动IP。
执行你自定义的脚本,来更精确地判断Redis服务本身是否健康，而不仅仅是服务器网络通不通。

配置Keepalived时,主要在它的配置文件/etc/keepalived/keepalived.conf里下功夫，这里面的坑最多。

状态（state）参数：这个参数只是初始状态，你可以在主服务器上配置state MASTER，在备服务器上配置state BACKUP，但要注意，这不代表MASTER就一定会抢到IP，最终决定权在于优先级（priority），一定要把主Redis服务器的priority值设得比备服务器高，比如主设100，备设90。
认证（authentication）：authentication块里的auth_pass必须一致，否则两台Keepalived无法建立通信，会各自认为对方宕机，导致出现“脑裂”（两个服务器都声称自己有浮动IP）。
虚拟IP（virtual_ipaddress）：这里配置你规划的浮动IP（192.168.1.100）、子网掩码和绑定的网卡（如eth0），确保网卡名用ip addr命令查看清楚，写错了IP就绑不上。
最关键的：自定义健康检查脚本（vrrp_script）：这是整个配置的灵魂所在！Keepalived默认只能检查服务器本身是否在线（比如通过ping网关），但它不知道你服务器上的Redis服务是否正常，服务器网络是通的，但Redis进程卡死了，这时Keepalived认为主服务器还活着，不会切换，但客户端已经无法访问Redis了。

你必须写一个脚本,让Keepalived定期执行，来检测Redis的健康状况，这个脚本通常要做几件事：
- 连接本地Redis：使用redis-cli ping命令，如果返回PONG，说明Redis进程响应正常。
- 判断主从角色（可选但推荐）：在脚本里，可以通过redis-cli info replication解析出当前节点的角色，如果你是Backup节点，但发现自己变成了Master（因为原Master的Redis挂了，它被提升为主），这个脚本应该返回成功（0），告诉Keepalived“我是健康的”，这样Keepalived才会把浮动IP抢过来。
- 脚本的返回值：这是硬性规定，脚本必须返回0（成功）表示本机健康，返回非0（如1）表示本机不健康，如果Keepalived执行健康检查脚本返回非0，它会降低本机的优先级（通常减去一个你设定的weight值），如果优先级变得低于备份服务器，就会触发IP切换。
示例脚本逻辑很简单：
```
#!/bin/bash
if redis-cli -h 127.0.0.1 -p 6379 ping | grep -q PONG; then
  exit 0
else
  exit 1
fi
```
把这个脚本保存（比如/etc/keepalived/check_redis.sh），并赋予可执行权限（chmod +x /etc/keepalived/check_redis.sh）。
在VRRP实例中调用脚本：配置好脚本后，要在vrrp_instance里用track_script块来调用它，这样Keepalived才会定期去跑这个脚本。
通知脚本（notify）：这是一个高级但很有用的功能，你可以配置notify_master、notify_backup、notify_fault等参数，指定一些脚本，当本机状态发生变化时（比如从备机变为主机）自动执行，当Backup节点切换为Master时，你可以在notify_master脚本里执行redis-cli config set slave-read-only no，确保新的主库是可写的（因为Redis从库默认是只读的）。

配置后的测试和常见问题

配置完成后,启动两台服务器的Keepalived服务（systemctl start keepalived）。

脑裂问题：最可怕的问题，现象是两台服务器上都绑定了浮动IP，原因通常是防火墙挡住了VRRP协议（112端口），导致两台Keepalived无法通信；或者认证密码不一致，一定要用ip addr show命令分别在两台机器上检查浮动IP的实际所在。
切换延迟：Keepalived默认的检查间隔是1秒，如果连续失败次数（fall）设为3次，那从故障发生到切换完成大概需要3秒，你可以调整interval（间隔）、fall（失败次数）、rise（成功次数）这些参数来平衡敏感度和性能，但别设得太短，避免网络抖动导致频繁切换。
脚本执行权限和环境变量：确保你写的健康检查脚本有可执行权限，并且脚本中使用的命令（如redis-cli）在Keepalived的运行环境（通常是root）下可以直接找到路径，最好在脚本里使用绝对路径（如/usr/local/bin/redis-cli）。
原主库恢复后的抢占：默认情况下，如果原主库（priority更高）恢复健康，它会重新抢回浮动IP和Master角色，这通常是期望的行为，如果你不希望自动抢占，可以将原主库的配置中加上nopreempt参数，但这样配置会变得更复杂，需要谨慎处理。