根本原因是K8s缩容时Redis Pod被强制终止前未主动关闭pub/sub连接或通知客户端下线，且客户端未及时感知拓扑变更；需preStop+SIGTERM协同处理退订，并配合客户端拓扑刷新与连接重建。
Redis 订阅连接在 K8s 扩缩容时中断，根本原因不是客户端没重连，而是服务端（Redis Pod）被强制终止前，pub/sub 连接未被主动关闭、未通知客户端“即将下线”，导致 TCP 连接突然断开，客户端收到 ECONNRESET 或超时；更关键的是，若用的是 Redis Cluster 或 Sentinel 架构，扩缩容还可能触发拓扑变更，而客户端未及时刷新节点列表。
为什么滚动更新/缩容会导致 Redis 订阅断连
滚动更新或 cluster-autoscaler 缩容时，K8s 会向旧 Pod 发送 SIGTERM，然后等待 terminationGracePeriodSeconds（默认 30 秒），超时即 SIGKILL。但 Redis 服务进程（尤其是 redis-server 自身）默认不响应 SIGTERM 做优雅退订 —— 它不会主动向所有 pub/sub 客户端发送 FIN 包，也不会广播“本节点将退出集群”。订阅连接靠 TCP 心跳维持，一旦 Pod 网络栈被 kubelet 清理（如 netns 销毁），连接就静默失效。
- StatefulSet 滚动更新时，旧 Pod 被删，但客户端仍往其 IP 发送
SUBSCRIBE请求，直到 DNS/Service 更新或连接超时 - Redis Cluster 扩容后，槽位（slot）重新分配，但客户端缓存的旧拓扑未刷新，
PUB可能打到错误节点，SUB则因目标节点无对应 channel 而静默失败 - Headless Service +
publishNotReadyAddresses: true能暴露 Pod IP，但不解决连接生命周期管理问题
必须同时配置 preStop + SIGTERM 捕获 + 主动退订逻辑
单靠 preStop 或单靠信号捕获都不够：前者是容器层面钩子，后者是进程层面响应。二者需协同触发“通知客户端下线 → 关闭监听 → 等待订阅连接自然断开或强制清理”的完整链路。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
preStop钩子中调用脚本，向注册中心（如 Nacos/Eureka）标记实例为下线，并通过 Redis 的PUBLISH机制广播“maintenance:start”事件，让客户端主动退订并切换节点 - Redis 服务进程本身需支持
SIGTERM：若使用自研代理层（如基于 Go 的 redis-proxy），应在main()中注册signal.Notify(ch, syscall.SIGTERM)，收到后执行redis.Client.Close()并调用UNSUBSCRIBE清理本地 channel - 若直接跑官方
redis-server，无法改源码，则必须用 wrapper 启动：例如用sh -c 'trap "redis-cli shutdown save" TERM; exec redis-server /etc/redis.conf'，但注意这仅停服务，不处理已有pub/sub连接 —— 所以 wrapper 必须额外加一步：redis-cli --scan --pattern '__keyspace@*:*' | xargs -I{} redis-cli PUBLISH maintenance "going-down"
客户端侧必须实现拓扑感知与连接重建
服务端再优雅，客户端不配合也白搭。很多 SDK（如 Jedis、Lettuce、redis-py）默认不自动刷新 Redis Cluster 拓扑或重试 SUBSCRIBE。
- Lettuce 必须启用
DynamicNodeResolver并设置refreshTriggersReconnectEnabled = true，否则扩容后新主节点上线，客户端仍连旧地址 - redis-py 的
PubSub对象不自动重连，需手动捕获ConnectionError后重建pubsub实例并重新SUBSCRIBE - 所有客户端都应配置合理的
socket_timeout和health_check_interval，避免长时间卡在已断开的 fd 上 - 避免在单个连接上混用
PUB/SUB和普通命令 —— Redis 不允许在pub/sub连接上发GET，否则连接会被服务端关闭
Operator 模式是生产环境最稳的选择
手动维护 StatefulSet + ConfigMap + preStop 的组合极易遗漏环节（比如忘记调大 terminationGracePeriodSeconds，或 preStop 脚本超时）。Redis Operator（如 redis-operator 或 spotahome/redis-operator）把“集群初始化、故障转移、扩缩容时的槽迁移、节点退订广播”全封装成控制器逻辑。
- Operator 在缩容前，会先调用
redis-cli cluster forget清理旧节点元数据，并触发redis-cli cluster check确保槽分布一致 - 它通过自定义资源（CR）声明期望状态，例如
spec.cluster.nodes: 6，控制器自动完成分片重平衡，期间持续提供CLUSTER NODES查询接口供客户端拉取最新拓扑 - 配套的 Helm Chart 通常内置了带健康检查的
livenessProbe和readinessProbe，确保只有真正可服务的 Pod 才进入 Endpoints
真正容易被忽略的点是：即使用了 Operator，客户端仍要自己做连接池隔离 —— 订阅连接和命令连接不能共用一个 ConnectionPool，否则一个连接断开可能触发整个池重建，放大抖动影响。
