流媒體平臺建設

    流媒體系統主要向外提供的是離線轉碼，切片和縮略圖服務，這些服務的特色是極度耗費資源的，因此平臺的考量並非在併發性，而是在資源的分配上，和流媒體自己的特性。

該文章後續仍在不斷的更新修改中， 請移步到原文地址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 等等。