为了不在直播中看到少儿不宜的景象，阿里做了这些

为了平衡管控的时效性和计算资源之间的矛盾冲突，在实际操作中，我们对直播流每5秒截帧一次，图片保存在OSS上，同时推送消息给安全部接口。接口层将消息传递到规则层，在这里配置规则，决定截图需要调用的算法，以及对算法返回的结果进行判断，向审核系统发送消息。

直播管控整体系统框图

我们面临的问题是5400路并发视频需要在5秒之内给出反馈，延时过长会错造成风险外露。图片算法服务本身相消耗计算资源多，是系统中的瓶颈，为此我们采取了以下应对手段。

1、通过消息接入解耦应用

同步接入算法服务是最简单的也最容易维护的，但会面临三个主要问题，1）同步接入给接入方带来了更多资源消耗；2）一旦算法服务不正常，会影响主流程。3）图片量已远远超过审核人力的极限，运营只能覆盖一些潜在重点风险视频，非重点风险视频流不需要流入审核。因此，虽然异步接入也会带来维护成本，但最终决定还是采用异步接入。

2、通过异步回调减少接入的成本

收到异步消息后，节点会调用算法服务，如果采用同步调用，会导致很多线程IO阻塞，需要大量的task,从而需要很多节点；采用异步回调服务，task线程可以立即回收，能减少很多task线程，从而节省节点。本项目中节省了约70%的节点。

3、通过批处理增加吞吐

在直播防控中单张截图会调用2个算法，之前的模式是每张图发2个消息。由于内部是可以并行且非阻塞过多个算法的，单张图一个算法和多个算法成本一样，所以我们将单张图调用多个算法的多条消息合并成一条。吞吐翻倍，按qps评估的机器成本也减半。

4、削峰和异常保护

虽然直播的峰值是5400路并发，考虑到截帧是每5秒进行一次，所以不必要按峰值准备容量。我们按照4s来平滑峰值，机器数也可以减少75%。除了常规的限流措施之外，考虑到审核页面每5秒刷新，如果超过4s没处理的消息选择丢弃，可以避免突发的消息堆积造成雪崩。所有的出错消息都会回写入SLS并同步到ODPS，以便之后的排查、分析和恢复。同时，我们将应用部署在两个机房来实现容灾。

算法服务系统架构图

（编辑：PHP编程网 - 金华站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!