ZLMediaKit RTMP推流假死问题分析与解决方案

问题现象

在使用ZLMediaKit进行RTMP推流时，部分用户遇到了服务假死的情况。具体表现为：

• 服务进程显示为运行状态（UP），但实际上已无法正常工作
• 推流和拉流功能失效
• HTTP API接口无法响应请求
• 服务日志停止打印新内容
• 需要手动重启服务才能恢复正常

问题分析

从日志中可以观察到几个关键现象：

1. 服务异常终止：日志中出现了"SIGTERM:exit"记录，表明服务收到了终止信号。但用户确认这是手动重启时的操作，并非问题的根本原因。

2. RTMP会话错误：大量出现"mediakit::RtmpSession on err: 6(Already publishing:)"错误，表明存在流重复发布的情况。

3. 服务无响应期：在假死期间，服务完全停止响应，日志记录中断，这表明服务可能进入了某种阻塞状态。

技术背景

ZLMediaKit是一个高性能的流媒体服务器，支持RTMP、RTSP、HLS等多种协议。在RTMP协议处理中：

1. 流管理机制：每个流(stream)在服务器中是唯一的，同一时刻只能有一个发布者(publisher)。

2. 会话保持：配置中的continue_push_ms参数允许推流中断后在指定时间内重新连接继续推流。

3. 线程模型：采用多线程事件循环(event poller)处理网络IO和媒体流转发。

问题根源

经过技术团队分析，这个问题可能由以下几个因素共同导致：

1. 流状态不一致：当推流异常中断时，流的发布状态可能没有正确清理，导致后续推流请求被拒绝。

2. 资源竞争：在多线程环境下，流状态管理可能出现竞争条件，导致某些关键线程阻塞。

3. 内存管理：长时间运行后可能出现内存泄漏或资源耗尽，影响服务稳定性。

解决方案

针对这一问题，ZLMediaKit团队已经确认这是一个bug并提供了修复方案：

1. 代码更新：建议升级到最新版本，该版本包含了针对此问题的修复。

2. 配置调整：

   • 可以尝试关闭continue_push_ms功能（设置为0）
   • 调整RTMP的keepAliveSecond参数
   • 检查流超时设置(streamNoneReaderDelayMS)

3. 监控措施：

   • 实现服务健康检查机制
   • 定期重启服务作为临时解决方案
   • 监控内存和线程状态

最佳实践建议

1. 版本管理：定期更新ZLMediaKit到稳定版本，获取最新的bug修复和性能优化。

2. 日志监控：建立完善的日志监控系统，及时发现服务异常。

3. 压力测试：在生产环境部署前进行充分的压力测试，验证服务稳定性。

4. 资源隔离：为ZLMediaKit分配专用服务器资源，避免与其他服务竞争。

5. 容灾方案：考虑使用集群部署，单节点故障时自动切换。

总结

ZLMediaKit作为高性能流媒体服务器，在大多数场景下表现稳定可靠。本次遇到的RTMP推流假死问题已经得到官方确认并修复。建议用户关注版本更新，同时建立完善的监控体系，确保流媒体服务的稳定运行。对于关键业务场景，可以考虑实现自动恢复机制或采用高可用架构部署。