Redis如何处理VIP漂移导致的连接异常_结合Keepalived与脚本实现虚拟IP随主库切换-Redis-PHP中文网

先确认VIP是否绑定成功，再检查ARP缓存、防火墙、Keepalived配置及Redis角色状态，最后优化客户端超时重试逻辑。

redis如何处理vip漂移导致的连接异常_结合keepalived与脚本实现虚拟ip随主库切换

Keepalived 切换时 Redis 客户端连不上 `192.168.10.100`？先确认 VIP 真的绑上了

很多问题根本不是 Redis 本身的问题，而是 Keepalived 没把虚拟 IP 成功绑定到新主节点的网卡上。用 ip addr show 在新主上查一遍，看 192.168.10.100 是否出现在 eth0（或对应网卡）的输出里。没出现就别急着调 Redis 配置——脚本没跑、priority 设错、network namespace 隔离、甚至 SELinux 拦了 vrrp 协议都可能让 VIP 停在旧机器上不动。

常见错误现象：connect ETIMEDOUT 或 Connection refused，但 telnet 192.168.10.100 6379 在新主本机能通，在客户端不通——大概率是 ARP 缓存没刷新或防火墙 DROP 了 VRRP 包。

检查 /etc/keepalived/keepalived.conf 中 vrrp_script 的 weight 和 fall/rise 是否合理，避免抖动误切
确认两台机器的 state 配置：一台 MASTER，另一台必须是 BACKUP，不能都设成 MASTER
启用 notify_master /path/to/redis-failover.sh 脚本前，先手动执行一遍，看是否真能 redis-cli -h 127.0.0.1 shutdown 或 slaveof no one

Redis 主从切换后，客户端还在往旧主发写请求？靠 `readonly` + 连接池自动重试不够

Redis 本身不主动通知客户端“我已降级”，readonly 只防读，不拦写；连接池（比如 Jedis、Lettuce）默认也不会在 MOVED 或 ASK 错误后自动跳转——因为 Redis Sentinel 才管重定向，纯 Keepalived + VIP 方案下，客户端看到的始终是同一个 IP 地址，它根本不知道背后主库换了人。

所以关键不是“怎么让 Redis 告诉客户端”，而是“怎么让客户端感知失败并重建连接”。这得靠客户端自己做超时+重连逻辑，而不是依赖服务端返回特殊错误码。

把连接超时（connectTimeout）和读超时（soTimeout）设短一点，比如 1–2 秒，避免卡在旧主 FIN_WAIT 状态里等 30 秒
禁用连接池的 testOnBorrow（太重），改用 testWhileIdle + 合理的 timeBetweenEvictionRunsMillis（如 5000）定期探活
写操作必须包裹重试逻辑：捕获 IOException、JedisConnectionException，最多重试 2 次，每次间隔 100ms，别无脑循环

`notify_master` 脚本里该不该执行 `slaveof no one`？看 Redis 版本和角色状态

Redis 6.2+ 支持 ROLE 命令返回当前角色，而老版本只能靠 INFO replication 解析文本。直接硬写 redis-cli slaveof no one 很危险：如果脚本被重复触发，或者旧主还没完全下线就切回来，可能把刚升主的新实例又降成从库。

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

正确做法是加状态判断。不要信配置文件里的“我应该是主”，要信 redis-cli role 的实时输出。

#!/bin/bash
ROLE=$(redis-cli -h 127.0.0.1 role | head -n1 | tr -d '"')
if [ "$ROLE" = "slave" ]; then
  redis-cli -h 127.0.0.1 slaveof no one > /dev/null 2>&1
fi

Redis 7+ 可用 replicaof no one 替代 slaveof，更语义清晰
脚本末尾加 sleep 0.5，防止 Keepalived 连续触发多次 notify
别忘了给脚本加可执行权限：chmod +x /opt/redis-failover.sh，否则 Keepalived 日志只报 “failed to exec” 不报具体原因

为什么 `arping -U` 发包后客户端还是连不上？ARP 缓存和交换机学习延迟才是真瓶颈

VIP 漂移后，即使新主绑上了 IP，客户端所在机器的 ARP 表可能还记着旧主的 MAC 地址，交换机的 MAC 地址表也可能没及时更新。这时候光靠 arping -U -I eth0 192.168.10.100 是不够的——它只告诉局域网“这个 IP 现在我用”，但不强制客户端清缓存。

真正有效的是组合动作：新主发免费 ARP（arping），同时客户端侧主动刷新（arp -d 192.168.10.100 或重启网卡），中间交换机如果启用了 ARP 学习老化时间（默认 300s），那就只能等，或者进交换机清 MAC 表。

Keepalived 配置里加上 notify_master "/usr/sbin/arping -U -I eth0 192.168.10.100"，确保每次切主都广播一次
测试环境可在客户端执行 watch -n1 'arp -n | grep 192.168.10.100'，观察 MAC 地址是否变化
生产环境别指望客户端配合清 ARP，得靠连接层容错——也就是前面说的短超时 + 快重试

VIP 漂移看着只是 IP 换了个地方，但 Redis 连接恢复实际卡在三个地方：内核网络栈（ARP）、Redis 实例角色状态（是否真接管了写）、客户端连接池行为（是否愿意放弃旧连接）。任何一个环节断了，都会表现为“连得上但写不了”或者“一会通一会不通”。