流媒体平台建设

    流媒体系统主要向外提供的是离线转码，切片和缩略图服务，这些服务的特色是极度耗费资源的，因此平台的考量并非在并发性，而是在资源的分配上，和流媒体自己的特性。

该文章后续仍在不断的更新修改中， 请移步到原文地址http://dmwan.cc

    系统架构：

 

如下是须要考虑的问题：

主控部分：

    1，入口负载均衡，支持多主，高可用，保证某节点挂了的状况下，不会出问题。

    2， 失败任务定时回扫，须要分布式选主。

    这里常见的方案，redis /zk/etcd?几种方案，基本都差很少，这里选的是redis，直接用redis最主要的缘由，是便宜，机器能够复用，并且redis 很稳定，基本没遇到过奔溃的状况。

    3，是否须要分库分表？

    这里数据量，天天有几万个请求，须要频繁对任务表insert and update 操做，是否须要分库分表？其实不须要，只须要按期缩表就ok，这种数据特色是通常会回扫近几个月的数据，随机性不强，这种数据，单表上亿都不会有问题。

    4，控制状态一致性，最终一致性

    这种消息投递系统，这里如何保证状态一致性，咱们采起的是保证消息最终一致性的方式： 解决方式：发送端保证（update + 必定通知到！） ，消费端保证 （必定消费，不重复消费！）
    4.1， 发送端，两张表，或者添加个字段，消息字段，标识消息状态码！保证状态！
    4.2， 发送端保证重发，不断scan，
    能保证任务 update db + notify 必定成功
    消费端：去重 ，保证只执行一次便可 ，已经执行过，就只notify！（这里）
最糟糕的状况，不断 scan，始终这条消息不执行成功。而后，人工干预

    5，数据库与多级缓存的一致性

    什么状况会出现数据库和多级缓存不一致的问题？就是当失败任务回扫的时候，任务被推到redis 中两份，前一份是由于还没来的及执行。在单机，咱们加了list+set 作redis去重，在客户端，咱们作了幂等保证。

    6，客户鉴权，access/secret key 管理

    不一样客户不一样的access/secret key 鉴权操做，这是很常规作法。

    7，模板管理

    流媒体任务参数比较复杂，咱们采用和模板的方式控制，每次传任务，只需事先创建模板，传递模板id 便可。

    8，优先级队列

    不一样级别客户是须要作优先级均衡的，这个在从buffer 取到任务队列中，这步中操做，咱们会为每一个客户id设置动态优先级。

    9，限频

    咱们有些客户会从源站拉取视频文件，这里须要对整个任务分布式限频，这里在buffer 向任务队列中吐数据的时候能够控制。

    10，监控/报警

    失败数据计数报警，至关因而业务层面的。

 

agent 部分：

   1， 交互是推拉？

    这里系统瓶颈是再agent ，并非在master，拉任务比较合适

    2，如何控制资源

    流媒体任务，比较核心的资源是cpu，这里须要作的是控制cpu 占比，当cpu 占比高的时候，再也不取任务。比较合适的方式是令牌桶的方式抢cpu，将cpu数量当成临界资源，用完即还。控制好一场处理便可。

    3，如何查看实时任务状态

    ffmpeg 输出流的实时解析回传

    4，提升转码能力，gpu / 边缘节点？

    这里能够支持gpu 或者边缘节点闲时转码。前者成本高，后者实现还算简单，控制cpu 核心的竞争便可。

    5，部署问题

    docker 安装ffmpeg，一键部署

    6，控制倍数

    有些客户要求一批资源要尽量快的转码，这里能够在令牌桶作文章，按阶梯取任务便可。

 

    其余优化，其实仍是有不少能够作的，主要集中在资源的利用上，怎么尽量快的实现单资源的优先转码，可否一次decodec 后，屡次encodec 等等。