流媒体系统主要向外提供的是离线转码，切片和缩略图服务，这些服务的特点是极度耗费资源的，所以平台的考量并不是在并发性，而是在资源的分配上，和流媒体本身的特性。
该文章后续仍在不断的更新修改中， 请移步到原文地址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 等等。