Keepalived可通过自定义脚本检测Redis哨兵主节点状态并动态调整VRRP优先级，实现VIP漂移至当前master所在主机，从而完成故障转移而非负载均衡。
Keepalived 本身不直接支持 Redis 哨兵（Sentinel）状态的原生监控，也不具备七层（应用层）协议解析能力，无法像 HAProxy 或 Nginx 那样主动连接 Sentinel 查询 SENTINEL get-master-addr-by-name 或判断主从切换结果。但它可以通过自定义健康检查脚本 + VRRP 主备控制，间接实现“基于 Redis 哨兵状态的 VIP 漂移”，从而支撑数据库访问层的高可用切换——这常被误称为“负载均衡”，实则是故障转移驱动的读写入口收敛。
要达成目标，核心思路是：
✅ 让 Keepalived 的 VIP 绑定在当前 Redis 主节点所在宿主机上；
✅ 通过脚本实时探测本地是否为哨兵选出的 master；
✅ 若不是，则主动降低优先级或触发故障转移，让 VIP 漂移到真正持有 master 角色的机器。
以下分三部分说明关键实现：
一、前置条件与架构约束
- Redis 部署为 3 节点哨兵集群（至少 1 主 2 从 + 3 Sentinel），所有 Redis 实例和 Sentinel 进程运行在物理机或 Docker 宿主机（非容器网络隔离环境）；
- Keepalived 安装在每台 Redis 服务器宿主机上（即与 Redis + Sentinel 共存），而非独立 LB 节点；
- VIP（如
192.168.3.200）绑定在宿主机网卡（如eth0），客户端直连该 VIP 访问 Redis； - Redis 配置中
bind 0.0.0.0且protected-mode no（或配密码），确保 VIP 流量可到达； - 禁用
vrrp_strict，避免因缺少 VIP 或单播配置导致启动失败。
二、编写 Redis 哨兵状态检测脚本
在每台 Redis 服务器上创建 /etc/keepalived/check_redis_master.sh：
#!/bin/bash
# 检查本机 Redis 是否为哨兵认定的 master（以 mymaster 为例）
MASTER_IP=$(redis-cli -h 127.0.0.1 -p 26379 SENTINEL get-master-addr-by-name mymaster | head -n1 | tr -d '\r\n')
LOCAL_IP=$(hostname -I | awk '{print $1}')
if [ "$MASTER_IP" = "$LOCAL_IP" ]; then
exit 0 # 是 master，健康
else
exit 1 # 不是 master，标记为不健康
fi赋予执行权限：
chmod +x /etc/keepalived/check_redis_master.sh
⚠️ 注意：
mymaster是你在sentinel.conf中配置的监控名；若使用密码，需加-a <password></password>参数；脚本超时建议加timeout 3包裹。
三、Keepalived 配置（每台均部署，仅 state/priority 差异）
编辑 /etc/keepalived/keepalived.conf：
global_defs {
router_id redis_master_ha
}
vrrp_script chk_redis {
script "/etc/keepalived/check_redis_master.sh"
interval 2 # 每2秒检查一次
weight -20 # 检测失败时，优先级减20（触发降级）
fall 2 # 连续2次失败才判定异常
rise 2 # 连续2次成功才恢复
}
vrrp_instance VI_REDIS {
state BACKUP # 所有节点初始设为 BACKUP（避免脑裂）
interface eth0
virtual_router_id 88
priority 100 # 初始优先级统一设为100（实际由脚本动态调整）
advert_int 1
authentication {
auth_type PASS
auth_pass redispw123
}
virtual_ipaddress {
192.168.3.200/24 dev eth0 label eth0:0
}
track_script {
chk_redis
}
}- 启动后，Keepalived 会持续运行检测脚本；
- 当某台机器成为哨兵选举出的 master，其脚本返回 0 → 优先级保持 100 → 成为 VRRP Master，VIP 自动绑定；
- 其他机器脚本返回 1 → 优先级变为 80 → 保持 BACKUP 状态，VIP 不绑定；
- 若原 master 故障，哨兵重新选举，新 master 上脚本恢复返回 0 → 优先级回升 → VIP 漂移完成。
四、客户端访问方式
- 应用连接
redis://192.168.3.200:6379（VIP）； - 写操作始终落在当前 VIP 所在节点（即真实 Redis master）；
- 读操作也可走 VIP，但若需读从库，需额外在应用层通过 Sentinel 获取从节点地址 —— Keepalived 不参与读负载分发。
本质上，这不是传统意义的“负载均衡”，而是强一致性主节点服务入口的自动漂移。真正的 Redis 读负载均衡需配合客户端 SDK（如 JedisPool + Sentinel 支持）或中间件（如 Twemproxy、Redis Cluster、或 HAProxy + Lua 脚本）实现。
不复杂但容易忽略。
