摘要：年月日，社區(qū)聯(lián)合又拍云，舉辦全國巡回沙龍北京站，京東云技術(shù)專家羅玉杰在活動上做了在直播場景中的應(yīng)用的分享。項目功能基于協(xié)議將文件上傳至云存儲。

2019 年 3 月 23 日，OpenResty 社區(qū)聯(lián)合又拍云，舉辦 OpenResty × Open Talk 全國巡回沙龍·北京站，京東云技術(shù)專家羅玉杰在活動上做了《 OpenResty 在直播場景中的應(yīng)用 》的分享。

OpenResty x Open Talk 全國巡回沙龍是由 OpenResty 社區(qū)、又拍云發(fā)起，邀請業(yè)內(nèi)資深的 OpenResty 技術(shù)專家，分享 OpenResty 實戰(zhàn)經(jīng)驗，增進 OpenResty 使用者的交流與學(xué)習(xí)，推動 OpenResty 開源項目的發(fā)展?；顒右呀?jīng)在深圳、北京兩地舉辦，未來將陸續(xù)在武漢、上海、杭州、成都等城市巡回舉辦。

羅玉杰，京東云技術(shù)專家，10 余年 CDN、流媒體行業(yè)從業(yè)經(jīng)驗，熱衷于開源軟件的開發(fā)與研究，對 OpenResty、Nginx 模塊開發(fā)有較深入的研究，熟悉 CDN 架構(gòu)和主流流媒體協(xié)議。

以下是分享全文：

大家下午好，我是來自京東云的羅玉杰，今天給大家分享的主題是 《OpenResty 在直播場景中的應(yīng)用》。

京東云前期的服務(wù)是基于 Nginx 二次開發(fā)的，之后因為要對接上云的需求，于是新做了兩個服務(wù)，一個是對接云存儲的上傳服務(wù)，另一個是偏業(yè)務(wù)層的直播時移回看服務(wù)。項目的需求是做視頻數(shù)據(jù)上云，主要是視頻的相關(guān)數(shù)據(jù)對接云存儲，需求的開發(fā)周期很緊，基本上是以周為單位。

我們之前的服務(wù)用 C 、C++ 開發(fā)，但 C 和 C++ 的開發(fā)周期很長。我們發(fā)現(xiàn)這個項目基于 OpenResty 開發(fā)是非常適合的，可以極大地縮短開發(fā)周期，同時提高運行效率，并且 OpenResty 對運維非常友好，能提供很多的配置項，讓運維根據(jù)線上動態(tài)修改一些配置，甚至運維都可以看懂代碼的主流程。

上圖是一個直播服務(wù)的主流體系結(jié)構(gòu)，先是主播基于 RTMP 協(xié)議推到 CDN 邊緣，接著到視頻源站接入層，然后把 RTMP 流推送到切片上傳服務(wù)器，上面有兩個服務(wù)：一個是切片服務(wù)，把流式的視頻流進行切片存儲到本地，生成 TS 視頻文件和 M3U8 文本文件，每形成一個小切片都會通知上傳服務(wù)，后者將這些 TS 文件和 M3U8 文件基于 AWS S3 協(xié)議上傳到云存儲服務(wù)，我們的云存儲兼容 AWS S3 協(xié)議。在此基礎(chǔ)上，我們用 OpenResty 做了一個直播時移回看服務(wù)，用戶基于 HLS 協(xié)議看視頻，請求參數(shù)里帶上時間段信息，比如幾天之前或者幾個小時之前的信息，此服務(wù)從云存儲上下載 M3U8 信息進行裁剪，再返回給用戶，用戶就可以看到視頻了。HLS 協(xié)議的應(yīng)用面、支持面很廣，各大廠商、終端支持得都非常好，而且對 HTTP 和 CDN 原有的技術(shù)棧、體系非常友好，可以充分地利用原來的一些積累。有的播放是基于 RTMP，HDL（HTTP + FLV）協(xié)議的，需要播放器的支持。

1、基于 s3 PUT 協(xié)議將 TS 文件上傳至云存儲。
2、S3 multi 分片上傳大文件，支持斷點續(xù)傳。這個服務(wù)重度依賴于 Redis，用 Redis 實現(xiàn)任務(wù)隊列、存儲任務(wù)元數(shù)據(jù)、點播 M3U8。
3、基于 Redis 實現(xiàn)任務(wù)隊列的同時做了 Nginx Worker 的負載調(diào)度。在此基礎(chǔ)上做了對于后端服務(wù)的保護，連接和請求量控制，防止被短時間內(nèi)特別大的突發(fā)流量把后端的云服務(wù)直接打垮。實現(xiàn)任務(wù)隊列之后，對后端的鏈接數(shù)是固定的，而且請求處理看的是后端服務(wù)的能力，簡單地說，它處理得多快就請求得多快。
4、為了保證云和服務(wù)的高可靠性，我們做了失敗重試和異常處理、降低策略。其中，任務(wù)失敗是不可避免的，現(xiàn)在也遇到了大量的任務(wù)失敗，包括鏈接失敗、后端服務(wù)異常等，需要把失敗的任務(wù)進行重試，降級。把它在失敗隊列里面，進行一些指數(shù)退避。還有一些降級策略，我這個服務(wù)依賴于后面的 Redis 服務(wù)，和后端的云存儲服務(wù)，如果它們失敗之后，我們需要做一些功能的降級，保證我們的服務(wù)高可用。在后端 Redis 服務(wù)恢復(fù)的時候再把數(shù)據(jù)同步過去，保證數(shù)據(jù)不會丟失。
5、還有就是生成直播、點播 M38，為后續(xù)的服務(wù)提供一些基礎(chǔ)數(shù)據(jù)。如直播時移回看服務(wù)。
AWS S3 協(xié)議
AWS S3 比較復(fù)雜的就是鑒權(quán)，主要用它的兩個協(xié)議，一個是 PUT，一個是 MULTI PART。

AWS S3 的鑒權(quán)和 Nginx 中的 Secure Link 模塊比較相似，將請求相關(guān)信息用私鑰做一個散列，這個散列的內(nèi)容會放到 HTTP 頭 authorization 里面，服務(wù)端收到請求后，會有同樣的方式和同樣的私鑰來計算這個內(nèi)容，計算出的內(nèi)容是相同的就會通過，不相同的話會認為是一個非法請求。


它主要分三步驟，第一步是創(chuàng)建任務(wù)，創(chuàng)建任務(wù)之后會返回一個 ID 當(dāng)做任務(wù)的 Session ID，用 POST 和 REST 規(guī)范實現(xiàn)的協(xié)議。初始化任務(wù)之后，可以傳各種分片了，然后還是用 PUT 傳小片，加上 Session ID，每一片都是這樣。

上傳任務(wù)成功之后，會發(fā)一個 Complete 消息，然后文件就認為是成功了，成功之后就會合并成一個新的文件，對外生成一個可用的大文件。
HLS 協(xié)議
HLS 協(xié)議，全稱是 HTTP LIVE STREAMING 協(xié)議，是由蘋果推出的，可讀性很強。里面的每一個片都是一個 HTTP 請求，整個文本協(xié)議就是一個索引。

上圖是每一個視頻段的時長，這個是 8 秒是視頻的最大長度。直播的應(yīng)用中會有一個 Sequence 從零開始遞增的，如果有一個新片，就會把舊片去掉，把新的加上去，并增加 Sequence。
任務(wù)隊列、均衡、流控
下面再介紹一下具體的功能實現(xiàn)，任務(wù)收到請求之后不是直接處理，而是異步處理的。先把請求分發(fā)到各個 Worker 的私有隊列，分發(fā)算法是用的 crc32，因為 crc32 足夠快、足夠輕量，基于一個 key 視頻流會有域名、App、stream，再加上 TS 的文件名稱。這樣分發(fā)可以很好地做一次負載均衡?；谶@個任務(wù)隊列，可以處理大量的突發(fā)請求，如果突然有了數(shù)倍的請求，可以把這些消息發(fā)到 Redis 里，由 Redis 存儲這些請求。每個 Worker 會同步進行處理，把 TS 片上傳，上傳完之后再生成 M3U8 文件。我們現(xiàn)在對后端固定了連接數(shù)，一個 woker 一個鏈接，因為存儲集群的連接數(shù)量是有限的，現(xiàn)在采取一個簡單策略，后端能處理請求多快，就發(fā)送多快，處理完之后可以馬上發(fā)送下一個。因任務(wù)隊列是同步處理，是同步非阻塞的，不會發(fā)送超過后端的處理能力。
我們未來準備進行優(yōu)化的方向就是把任務(wù)隊列分成多個優(yōu)先級，高優(yōu)先級的先處理，低優(yōu)先級的降級處理。比如我們線上遇到的一些視頻流，它不太正常會大量的切小，比如正常視頻 10 秒一片，而它 10 毫秒就一片，這樣我們會把它的優(yōu)先級降低，防止異常任務(wù)導(dǎo)致正常任務(wù)不能合理地處理。以后就是要實現(xiàn)可以動態(tài)調(diào)解鏈接數(shù)、請求速率和流量。如果后端的處理能力很強，可以動態(tài)增長一些鏈接數(shù)和請求速率，一旦遇到瓶頸后可以動態(tài)收縮。

任務(wù)分發(fā)比較簡單，主要就是上面的三行代碼，每一個 Worker 拿到一個任務(wù)后，把任務(wù)分發(fā)給相應(yīng)的 Worker ，它的算法是拿到總 Worker 數(shù)然后基于 crc32 和 key ，得到正確的 Worker ID，把它加到任務(wù)隊列里。這樣的做法好處是每個任務(wù)分發(fā)是非單點的，每一個 Worker 都在做分發(fā)，把請求的任務(wù)發(fā)到任務(wù)隊列里，請求的元信息放入 Redis 里面，還有一個就是任務(wù)拉取消費的協(xié)程，拉取任務(wù)并執(zhí)行。
失敗重試、降級、高可靠
如果數(shù)據(jù)量大會有很多失敗的任務(wù)，失敗任務(wù)需要放入失敗隊列，進行指數(shù)退避重試。重試成功后再進行后續(xù)處理，比如添加進點播 m3u8、分片 complete。分片 complete 是如果原來有 100 個任務(wù)會同時執(zhí)行，但是現(xiàn)在有 3 個失敗了，我們可以判斷一下它是不是最后一個，如果是最后一個的分片就要調(diào)一下 complete，然后完成這個分片，完成整個事務(wù)。
同時我們做了一個 Redis 失敗時的方案，Redis 失敗后需要把 Redis 的數(shù)據(jù)降級存到本地，一部分存到 share dict，另一部分用 LRU cache，TS 對應(yīng) m3u8 的索引信息會用 share dict 做緩存。LRU 主要是存一些 m3u8 的 key，存儲哪些信息和流做了降級，Redis 恢復(fù)后會把這些信息同步到 Redis。因為存在于各個 Worker 里面數(shù)據(jù)量會比較大，有些任務(wù)會重復(fù)執(zhí)行，我們下一步工作就想基于 share dict，加一個按照指定值來排序的功能，這樣就可以優(yōu)先處理最近的任務(wù)，將歷史任務(wù)推后處理。
我們還有一些 M3U8 的列表數(shù)據(jù)存儲在 Redis，因為線上的第一版本是單實例的，存儲空間比較有限，但是現(xiàn)在對接的流量越來越多，單實例內(nèi)存空間不足，于是我們做了支持 Redis 集群的工作，實現(xiàn) Reids 高可用，突破內(nèi)存限制。
還有一個比較兜底的策略：定期磁盤巡檢，重新處理失敗任務(wù)。事務(wù)可能是在任何的時點失敗的，但是只要我們能夠重做整個任務(wù)，業(yè)務(wù)流程就是完整的。

第一版的時候是全局的單一任務(wù)隊列，基于 resty lock 的鎖取保護這個隊列，每一個 woker 爭用鎖，獲取任務(wù)，鎖沖突比較嚴重，CPU 消耗也高，因為那個鎖是輪詢鎖，優(yōu)化后我們?nèi)サ袅艘粋€鎖實現(xiàn)了無鎖，每一個 Worker一個任務(wù)隊列， 每個 Worker 基于 CRC_32 分發(fā)任務(wù)。
舊版一個 TS 更新一次 M3U8，一次生成一個哈希表，數(shù)量較多的情況下 CPU 開銷比較大。我們進行了優(yōu)化，做了一些定時觸發(fā)的機制，進行定期更新，因為點播 M3U8 對時間是不敏感的，可以定期地更新，減少開銷。當(dāng)然直播的 還是實時生產(chǎn)的，因為要保證直播的實時性。
直播方面如果異常切片太多，用戶也不能很好觀看，會進行主動丟片，主要是基于 Redis 鎖去實現(xiàn)；對于 Redis 內(nèi)存消耗高的問題我們搭建了 Redis 集群。

我們開發(fā)了一個直播時移回看服務(wù)，根據(jù)用戶請求的時間去后臺下載相應(yīng)的 M3U8 的數(shù)據(jù)進行裁剪拼接返回給用戶。這一塊的 M3U8 信息不是很大，非常適合用 MLCACHE 保存，它是一個開源的兩級緩存，Worker 一級的和共享內(nèi)存一級，因為共享內(nèi)存緩存有鎖沖突，MLCACHE 會把一些熱點數(shù)據(jù)緩存到 Worker 級別，這樣是無鎖的，使用后效果非常好，雖然文件不大，但是運行時間建連，網(wǎng)絡(luò)IO耗時很大，經(jīng)過緩存之后可以大大提高處理效率，節(jié)省時間。時移的時候每一個用戶會也一個 Session 記錄上次返回的 M3U8 位置，因為直播流會有中斷，不是 24 小時都有流的，用戶遇到了一個斷洞，可以跳過看后面的視頻，時移不需要等待，并且用戶網(wǎng)絡(luò)短暫異常時不會跳片。

點擊觀看演講視頻和 PPT～
OpenResty 在直播場景中的應(yīng)用