sidecar 本身不处理 redis pub/sub 长连接，需自行实现代理逻辑：建立独立 redis.client 订阅、本地转发消息、断线自动重连（指数退避）、单实例限订，并配合 headless service、acl 授权与 client-output-buffer-limit 调优。
Sidecar 本身不处理 Redis Pub/Sub 长连接，代理逻辑必须自己实现
Kubernetes 的 Sidecar 模式只是把一个辅助容器和业务 Pod 绑在同一个 Pod 里、共享网络命名空间，并不会自动帮你接管 Redis 的 PUBSUB 或 SUBSCRIBE 连接。你看到的“Sidecar 管理 Pub/Sub”，实际是自己写的代理程序（比如用 Go 启一个 redis.Client 长连池）跑在 Sidecar 容器里，由它来收发消息、做重连、限流、鉴权——Redis 6.x 自身完全不参与这个过程。
常见错误现象包括：业务容器直连 Redis 做 SUBSCRIBE，但 Pod 重启后连接丢失、无重试；或多个副本同时订阅同一 channel 导致消息重复消费；又或者没做连接保活，被 Redis 的 timeout 或中间网络设备踢掉连接却无感知。
- 不要依赖 Kubernetes 的
LivenessProbe或ReadinessProbe来保活 Pub/Sub 连接——它们只管 HTTP/TCPSocket，不感知 Redis 协议层状态 - Sidecar 容器不能只靠
envoy或istio-proxy转发 Pub/Sub 流量——Envoy 默认不支持 RESP 协议解析，无法识别SUBSCRIBE命令并做连接复用或路由 - 若用 Istio 注入的默认 Sidecar，它根本不会转发非 HTTP/gRPC 流量，除非显式配置
TrafficPolicy和ServiceEntry，但这仍不解决长连接管理问题
必须手动实现的 Pub/Sub Sidecar 核心逻辑
一个真正能管住 Redis Pub/Sub 长连接的 Sidecar，至少要覆盖这四件事。用 Go + github.com/go-redis/redis/v8 是最简可行路径：
- 启动时建立独立于业务容器的
redis.Client，调用Subscribe(ctx, "channel")并持续监听ch := pubsub.Channel()，不是让业务代码自己去conn.Read() - 收到消息后，通过本地 Unix socket / HTTP endpoint / shared memory（如
/dev/shm）转发给主容器，避免跨网络带来延迟和失败点 - 监听
pubsub.Ping()和pubsub.Close()错误，检测到连接断开立即重建Subscribe，且带 backoff 重试（例如指数退避 100ms → 200ms → 400ms） - 限制单个 Sidecar 最多维持 1 个
PubSub实例（不是多个 goroutine 各自SUBSCRIBE），防止同一 Pod 内多个消费者重复订阅
示例关键片段（非完整代码）：
ps := client.Subscribe(ctx, "order.created")
defer ps.Close()
for {
msg, err := ps.ReceiveMessage(ctx)
if err != nil {
if errors.Is(err, redis.Nil) || strings.Contains(err.Error(), "connection refused") {
time.Sleep(backoff())
ps = client.Subscribe(ctx, "order.created") // 重建
continue
}
log.Printf("pubsub error: %v", err)
break
}
// 通过 localhost:9091/post 推给主容器
http.Post("http://localhost:9091/post", "application/json", bytes.NewReader([]byte(msg.Payload)))
}
Kubernetes Service 配置必须用 Headless，否则 DNS 不稳定
Redis Pub/Sub 对连接稳定性极度敏感，而 Kubernetes 默认 Service 的 ClusterIP 会做负载均衡和连接复用，导致 SUBSCRIBE 请求可能被调度到不同实例，或因 endpoint 变更触发连接中断。必须用 Headless Service，让 Sidecar 直连具体 Pod IP。
- 确保 Redis StatefulSet 使用稳定的网络标识，比如
redis-0.redis-headless.default.svc.cluster.local - Sidecar 容器里的代理代码应解析 SRV 记录或直接拼接 DNS 名，而不是写死
redis:6379（后者走 ClusterIP，不可靠） - 在
redis-headlessService 中启用publishNotReadyAddresses: true，避免 Pod 启动中就被 DNS 缓存剔除，造成首次订阅失败 - 禁用
externalTrafficPolicy: Local等干扰东西向流量的设置——Pub/Sub 是纯集群内通信，不该绕行节点路由
Sidecar 与 Redis 6.x 的 ACL 和超时参数需对齐
Redis 6.x 的 ACL 功能可限制 Sidecar 容器只能执行必要命令，但若配置不当，会导致 SUBSCRIBE 失败或连接被静默关闭：
- ACL 规则必须显式允许
subscribe、psubscribe、ping、quit，仅允许get/set是不够的 - Redis 配置中的
timeout 0（禁用空闲超时）是必须项；若设为非零值（如timeout 300），即使 Sidecar 在 ping，也可能因 RESP 协议未定义 ping payload 被误判为空闲 -
tcp-keepalive 60推荐开启，配合 Linux kernel 的net.ipv4.tcp_keepalive_time，防止 NAT 设备或云厂商 SLB 主动断连 - Sidecar 容器的 readiness probe 应检查本地代理是否已成功
SUBSCRIBE并收到一次PING响应，而非只检查 Redis 端口连通性
最容易被忽略的是：Pub/Sub 连接一旦建立，就不再走 Redis 的 maxclients 限制，但会占用 client-output-buffer-limit pubsub 配额。若 Sidecar 订阅了大量 channel 且下游消费慢，缓冲区溢出会导致连接被强制断开——必须按实际吞吐调大该值，比如 client-output-buffer-limit pubsub 32mb 8mb 60。
