RTSP 媒体协议流的录制方案及其覆盖策略详解（下）
RTSP 媒体协议流的录制方案及其覆盖策略详解（下）
【自我介绍】大家好，我是 Data-Mining，别名 liuzhen007，中国邦德，一个敲代码的邦德，前后就职于传统广电巨头和音视频互联网公司，具有丰富的音视频直播和点播相关经验，对WebRTC、FFmpeg和Electron有非常深入的了解。
（承接上篇）
3. 异常处理
录制过程中会遇到各种各样的问题，接下会分别介绍。有一点是相同的，所有的异常状况都会通知到录制调度服务，由调度服务进行统一分析和管理，同时支持热备机制，我们通过 Nacos 的服务发现机制监测录制调度服务的运行状态，具体关系可以参考下图：
3.1 CPU、磁盘
CPU 负载过高和磁盘空间不足是最为常见的两种录制时的异常状况，大致的处理逻辑也是较为相似的。
CPU 过高的处理逻辑，可以参考下图：
当前机器接收到任务后，进行自检操作，发现 CPU 负载过高会停止当前录制任务的执行，同时上报调度服务，重新分配别的机器执行该录制任务。
当前机器正在执行录制任务，突然发现 CPU 负载超过阈值，会持续观察一段时间，假定观察周期为 10 秒，如果 CPU 负载连续 10 秒钟超高，那么会停止当前录制任务，同时上报调度服务，请求别的机器继续执行该录制任务，最后将两台机器上的录制文件进行逻辑关联保存到数据库中。如果 CPU 负载在 10 秒内恢复到正常值，我们将继续执行当前录制任务。
磁盘空间不足的处理逻辑和 CPU 负载过高有类似的处理逻辑，具体可以参考下图：
通过流程图，我们也可以知道磁盘空间不足的处理逻辑和 CPU 负载过高时类似，上图已经展示的非常明确了，这里就不过多赘述了。
3.2 异常处理
一些其他的异常处理情况，比如崩溃，整体流程可以参考下图：
异常发生时，如果是一般异常，我们只需要将状态通知调度服务即可，调度服务记录相关日志，综合分析整个录制服务的状态。如果 60%的录制机器触发了相同的异常，调度服务就要采取相应的策略。如果是崩溃等重大异常，就需要重启机器或者调度新的机器继续执行录制任务。
3.3 录制超时
如果发生了录制超时，比如我们想录制 24 个小时的视频，现在时长已经录够了，接下来应该怎么做呢？一般有两种处理方法，第一种是直接停止当前录制，上报通知调度服务即可，这种处理方式比较简单粗暴，但是在安防和监控领域是不合适的。第二种是执行特定规则的覆盖策略，实现循环覆盖，始终保留最近 24 小时之内的视频画面内容。
对比上述两种处理方式，当发生录制超时时，第二种方式是最符合安防和监控领域的通用做法。那么覆盖策略又是怎么实现的呢，这就引出了下面的内容——覆盖策略。
4. 覆盖策略
覆盖策略在原理上理解起来很简单，但是具体执行时，就不那么简单了。首先，我们也先通过一个流程图对覆盖策略的处理逻辑有一个整体上的认识。
4.1 一级定时器
当录制任务启动时，我们同时启动一个定时器（一级定时器），定时器的时长就是录制任务的目标时长，这个非常好理解。但是，这个定时器只生效一次或者一次都不生效。只有一级定时器生效后，才会启动二级定时器。如果一级定时器没有启动，那么二级定时器也不会启动。
我们可以这样理解，只有一级定时器触发，录制服务才会执行对应的覆盖策略。当覆盖策略启动后，一级定时器销毁，二级定时器生效。
4.2 二级定时器
当文件时长达到了预设的最大时长时，我们将启动二级定时器。其实，二级定时器控制的是覆盖策略的删除频率，每次时间到了，就删除早些时候到录制文件分片。
4.3 执行覆盖
具体覆盖的执行逻辑是，根据 ts 分片的时长和二级定时器的时间周期，计算需要删除的 ts 分片个数，同时更新 m3u8 中的索引列表，然后循环执行该策略，最终实现动态循环的录制覆盖策略。
覆盖策略的执行过程如上图所示，相信通过上文的解释，大家理解起来还是非常容易的。需要特别说明的是，由于二级定时器执行周期 t 的限制，录制文件的实际时长在最大录制时长 T 和（T+t）之间。
结尾
好了，现在关于 RTSP 媒体流的录制方案和覆盖策略就介绍完了，相信大家对云端录制方案也有了一定认识，有自己想法和感兴趣的小伙伴，欢迎评论留言。关注我，分享更多音视频和流媒体服务器内容。