直播伴侣服务器升级中推流中断如何解决？

Question

在直播伴侣服务器升级过程中，推流中断的常见问题之一是：**升级期间服务实例未实现无缝切换，导致推流连接被强制断开**。 该问题通常发生在灰度发布或容器编排调度不当的场景下，旧Pod或虚拟机实例被直接终止，未完成正在传输的RTMP流的优雅关闭。同时，DNS解析延迟或负载均衡权重更新滞后，使推流端无法及时连接新实例。如何在升级时保持推流链路的高可用性，成为保障主播体验的关键挑战。需结合连接保持、会话同步与健康检查机制进行优化。

Answer 1

1. 问题背景与现象分析

在直播伴侣服务器的升级过程中，推流中断是一个影响用户体验的关键问题。特别是在灰度发布或容器化部署场景下，当旧的服务实例（如Kubernetes中的Pod）被强制终止时，正在传输的RTMP流连接往往无法完成优雅关闭，导致主播端出现“推流失败”或“连接断开”的提示。

该问题的根本原因在于：服务编排系统未充分考虑长连接的生命周期管理。RTMP协议基于TCP，属于典型的长连接应用，其会话持续时间可长达数小时。若在升级过程中直接删除运行中的Pod，内核将发送RST包强制关闭连接，而非FIN包进行有序释放。

• 现象一：升级期间部分主播突然掉线，重连耗时3~10秒
• 现象二：DNS缓存未及时更新，客户端仍尝试连接已下线节点
• 现象三：负载均衡器未感知后端实例状态变化，继续转发流量

2. 核心技术挑战拆解

挑战维度	具体表现	影响范围
连接保持	RTMP连接未优雅关闭	主播推流中断
会话同步	新实例缺乏上下文信息	重连后需重新鉴权
健康检查	Liveness探针误判活跃连接	提前终止有效Pod
DNS传播延迟	客户端解析到旧IP	连接路由错误
LB权重更新滞后	流量未切换至新实例	性能瓶颈加剧
滚动更新策略不当	并发终止多个Pod	区域性服务雪崩

3. 深层机制剖析：从协议层到调度层

RTMP作为实时音视频推流的核心协议，依赖稳定的TCP连接维持数据帧连续性。一旦底层传输中断，即使上层应用快速重连，也会造成GOP丢失和观众卡顿。

Kubernetes默认的滚动更新策略（RollingUpdate）在处理无状态服务时表现良好，但对于长连接服务则存在明显缺陷：

1. PreStop Hook未合理配置，导致SIGTERM信号来不及处理现有连接
2. Readiness Probe过早标记为不可用，但仍在处理请求
3. Service Endpoint更新延迟于Pod销毁，引发“黑洞流量”
4. Ingress Controller未支持连接 draining 机制
5. 全局会话存储缺失，新实例无法继承推流状态

4. 解决方案设计：多层级协同优化

  client → DNS → LB → Ingress → Service → Pod
                   ↑         ↑        ↑
             [健康检查]  [会话同步] [连接保持]
  

实现无缝切换需构建一个覆盖网络全链路的高可用体系：

• 连接保持：通过设置PreStop Hook延迟终止，并启用TCP keep-alive与SO_LINGER选项
• 会话同步：引入Redis集群存储推流Session元数据（streamKey, startTime, encoderInfo）
• 健康检查优化：分离Liveness与Readiness探针，Readiness在drain完成后才返回失败
• DNS TTL调优：将A记录TTL降至30秒以内，配合EDNS Client Subnet提升精度
• 负载均衡智能切换：使用gRPC health probe或WebSocket ping机制检测真实可用性

5. 典型实施代码示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: live-ingress-gateway
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
      - name: rtmp-proxy
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30 && nginx -s quit"]
        readinessProbe:
          exec:
            command: ["/check-ready.sh"] 
          initialDelaySeconds: 10
          periodSeconds: 5

6. 架构演进路径与流程图

graph TD A[客户端发起RTMP推流] --> B{DNS解析} B --> C[负载均衡接入层] C --> D[Ingress Controller] D --> E[Service Cluster IP] E --> F[旧Pod接收连接] F --> G[升级触发滚动更新] G --> H[新Pod启动并注册] H --> I[旧Pod进入Drain模式] I --> J[继续处理存量连接] J --> K[连接自然结束或超时] K --> L[Pod最终终止] L --> M[流量完全切至新实例]