redis集群主从切换后需自动化重载应用配置以保障服务连续性，核心步骤为：监听切换事件、动态提取新主节点信息、安全更新并重载应用配置、闭环验证与回滚。
Redis集群主从切换后，应用若仍连接旧的主节点或未及时更新配置，会导致写失败、数据不一致等问题。自动化重载应用配置是保障服务连续性的关键环节。核心思路是：监控切换事件 → 获取新主节点信息 → 更新应用配置（如连接地址、密码）→ 优雅重启或热重载应用进程。
一、监听Redis主从状态变化
不能依赖被动轮询，应结合Redis自身机制主动感知切换：
- 启用Redis的CLIENT TRACKING或订阅__sentinel__:hello频道（若使用Sentinel）；更常用的是在Sentinel部署中配置sentinel notification-script，在故障转移完成时触发Shell脚本
- 若用Redis Cluster，可通过redis-cli --cluster check或定期调用CLUSTER NODES解析节点角色，用awk提取带master标记且无fail的节点
- 示例判断逻辑：redis-cli -h $node -p $port CLUSTER NODES | awk '$3 ~ /master/ && $2 !~ /fail/ {print $2; exit}'
二、动态提取新主节点连接信息
避免硬编码IP和端口，需从集群元数据中实时解析：
- 对每个分片（slot range），用CLUSTER SLOTS获取负责该区间的主节点地址（格式：127.0.0.1:7000）
- 若应用使用单点接入（如通过Twemproxy或Codis），则重点更新Proxy后端配置，并重载其进程；若直连，则需按分片生成应用可读的映射文件（如JSON或env格式）
- 建议将结果写入统一配置中心（如Consul KV）或本地临时文件（如/etc/redis/current_master.conf），供后续步骤读取
三、安全更新应用配置并触发重载
重载方式取决于应用架构，Shell需适配不同场景：
- Java应用（Spring Boot）：通过Actuator的/actuator/refresh接口触发配置刷新（需提前暴露端点），用curl -X POST http://localhost:8080/actuator/refresh
- Python应用（Flask/FastAPI）：监听配置文件变更（如watchdog + reload），或提供SIGUSR2信号接口，Shell中执行kill -USR2 $(pidof myapp)
- NGINX / HAProxy代理层：更新upstream后，执行nginx -t && nginx -s reload或haproxy -f /etc/haproxy/haproxy.cfg -c校验后重载
- 所有操作前建议加锁（如flock）防止并发冲突，重载失败时保留上一版配置并告警
四、验证与回滚机制
自动化不等于盲目执行，必须闭环验证：
- 重载后立即用redis-cli -h $new_master PING测试连通性，再发一条SET test_key "auto-reload-$(date +%s)"确认可写
- 检查应用日志关键词（如“Connected to Redis at”、“Refreshed configuration”），超时未出现则判定失败
- 预置回滚脚本：若验证失败，自动恢复旧配置文件、重启应用，并发送企业微信/邮件告警（可用curl调用Webhook）
