WVP-GB28181-Pro项目中的RTP端口管理问题分析与解决方案

问题背景

在视频监控系统的国标级联场景中，WVP-GB28181-Pro项目作为重要的视频管理平台，负责处理视频流的传输和管理。其中，RTP(实时传输协议)端口的管理是确保视频流正常传输的关键环节。近期发现项目中存在一个可能导致系统崩溃的严重问题——当RTP发送端口被异常占用时，系统会因递归调用过深而抛出StackOverflowError错误。

问题现象

在特定场景下，当平台尝试播放一个无法正常播放的摄像头视频时，系统会持续尝试建立RTP传输通道。这一过程中，Redis数据库中会积累大量未释放的RTP端口记录。随着时间推移，配置的所有RTP发送端口(如30000-30200范围内的200个端口)都会被这些异常记录占用。当所有端口都被占用后，系统在尝试获取新端口时会进入无限递归状态，最终导致StackOverflowError，使整个服务崩溃。

技术原理分析

RTP端口管理机制

WVP-GB28181-Pro项目中，RTP端口的分配和管理通过SendRtpPortManager类实现。当有视频点播请求时，系统会从配置的端口范围内分配一个可用端口用于RTP流传输。正常情况下，当视频流停止或异常终止时，这些端口应该被及时释放回资源池。

Redis存储结构

系统使用Redis存储端口分配信息，键名格式为VMP_PLATFORM_SEND_RTP_INFO_{serverId}_{platformGbId}_{channelId}_{streamId}_{callId}。每个键对应一个RTP会话的端口信息，包含本地端口号等关键参数。

递归获取端口的问题

在SendRtpPortManager.getSendPort()方法中，当所有配置端口都被占用时，代码会递归调用自身尝试获取端口。由于端口资源已被耗尽，递归调用无法终止，最终导致调用栈溢出。

问题根源

1. 端口泄漏：当视频点播失败时，系统没有正确清理Redis中的端口占用记录，导致这些端口无法被回收利用。

2. 缺乏异常处理：在端口资源耗尽的情况下，系统没有合理的错误处理机制，而是采用递归方式不断尝试，这是程序设计上的缺陷。

3. 资源竞争：在多级平台级联场景下，对同一不可用设备的重复点播请求会加速端口资源的耗尽。

解决方案

短期修复方案

1. 增加端口检查机制：在递归获取端口前，先检查是否已超过最大递归深度，避免栈溢出。

2. 完善异常处理：当端口资源耗尽时，应抛出明确的异常信息，而不是无限递归。

3. 定期清理机制：实现定时任务，定期扫描并清理Redis中过期的端口占用记录。

长期优化方案

1. 引入端口租约机制：为每个端口分配设置有效期，超时后自动释放。

2. 实现端口健康检查：定期检查端口实际使用情况，回收未被实际使用的端口。

3. 优化资源分配策略：采用更智能的端口分配算法，减少资源碎片。

4. 增强日志监控：对端口分配和释放操作进行详细日志记录，便于问题排查。

实施建议

1. 紧急修复：首先应修复递归调用导致的栈溢出问题，这是系统稳定性的关键。

2. 监控部署：在生产环境部署端口使用情况的监控，及时发现资源紧张情况。

3. 逐步优化：按照业务优先级，逐步实现长期优化方案中的各项改进。

总结

RTP端口管理是视频监控系统中的关键环节，WVP-GB28181-Pro项目中发现的这一问题揭示了在资源管理和异常处理方面需要加强。通过本次问题的分析和解决，不仅修复了系统稳定性问题，也为后续的系统优化提供了方向。在视频监控这类对稳定性要求极高的系统中，资源管理的鲁棒性和异常处理的完备性都是需要持续关注和改进的重点。