Twitch(Justin.tv)的技術架構

banq發表於2014-08-30
架構


Twitch的直播模式完全不同於YouTube等點播批處理方式，直播對技術要求更高更難，這也是目前國內電視直播還依賴有線網路的原因，而網際網路上的電視直播業務在直播效果上要大打折扣，而Twitch則是在利用網際網路技術實現流暢不間斷直播上探索了一條成功道路。

8月25日，亞馬遜宣佈，公司將以9.7億美元 (約合人民幣59.7億元)的價格收購全球最大的遊戲影片直播商TwitchInteractive(以下簡稱Twitch)。此前谷歌還一度準備收購Twitch。

Twitch的前身是Justin.tv，於2011年正式推出，主營業務是做線上的影片遊戲直播和數字影片直播。精選遊戲包括《DOTA2》、《星際爭霸2》和《魔獸世界：潘達利亞的迷霧》等。截至2014年4月7日，Qwilt統計美國線上流媒體影片流量中有43.6%都來自Twitch。今年2月，Twitch的峰值網際網路流量在全美排名第四，僅僅次於影片點播巨頭Netflix 谷歌和蘋果，比Hulu、亞馬遜、Facebook都高。

Twitch直播影片和是YouTube的批處理影片不同是：後者將所有影片儲存在磁碟上，稍後根據要求進行重播，而直播視對頻影片儲存寫和影片讀播放是同時進行的，因此需要一個完全不同的體系架構。下面是其技術堆疊：

Usher - 這是其核心繫統，用來實現對影片流播放的業務邏輯伺服器
Twice - 可定製的web快取系統(http://code.google.com/p/twicecache/)
XFS - 檔案系統 將影片以秒為單位儲存該系統中，
HAProxy - 軟體負載平衡.
LVS stack 和 ldirectord - 保證高可用性.
Ruby on Rails - 應用伺服器
Nginx - web 伺服器
PostgreSQL - 儲存使用者和其他後設資料
MongoDB - 用於儲存使用者操作事件實現內部分析
MemcachedDB - 用於處理高密集寫操作如瀏覽數量
Syslog-ng - 日誌服務
RabitMQ - 用於 job 系統.
Puppet - 用於構建伺服器.
Git - 原始碼控制.
Wowza - Flash/H.264 影片伺服器, 許多定製的模組使用Java編寫
S3 - small image storage.

為什麼影片直播那麼困難？好像只需要大量的頻寬，讓這一切在記憶體中，圍繞流進行影片組合就可以了，其實沒那麼簡單。是什麼讓影片直播有如此這樣的挑戰力？

1. 影片不能像打嗝一樣存在中斷, 如果影片超過網路容量哪怕幾分之一秒，每一個觀眾在同一時刻將看到螢幕上顯示“正在緩衝...“。擁有網路容量是非常重要的。

2.需要CDN實現溢流overflow Usher會處理這個邏輯，一旦使用者量超過最大容量，新的播放者將被髮往CDN伺服器。

3.當觀眾快速發現任何問題就會立即交談聊天。使用者期望能夠優雅地處理這些問題。他們必須等到一臺伺服器上的每個人觀眾完成瀏覽後才能讓這臺伺服器維護模式。這是一個非常緩慢的維護過程。會話必須從未中斷。通常的網站可以有許多錯誤只是很少人會注意到，而直播系統則不同。

下面看看Twitch如何應對這些挑戰？
他們最大的問題是控制快閃的人群，所謂快閃人群，就是當很多人在同一時間想看同樣的事情。這是一個龐大的傳入流量。因此，他們需要建立一個方法來在所有的影片伺服器和資料中心之間實現實時適應性負載。該機制是Usher。

Usher是一個他們開發的軟體，用來管理負載平衡 授權和播放等其他業務邏輯。Usher對每個流影片都要計算出有多少伺服器在傳送它們，這樣確保最佳負載。 它實時決定如何在這些伺服器之間複製流，複製依據的規則有：
所有伺服器的單獨負載
最佳化的延遲
一個流在哪些伺服器上
使用者的IP地址，這樣能夠分辨使用者來自哪個國家
根據路由route資料庫尋找離使用者IP最近的ISP.
根據請求來自的資料中心，試圖將這個請求發往同一個資料中心的影片伺服器。

使用這些最佳化指標可以引導最佳化每個發往伺服器的請求，以保證更好的延遲和效能最佳化。他們還有很多的監控調校錶盤和非常細粒度的控制。

每個伺服器可以充當一個邊緣伺服器（該伺服器的影片直接傳送到觀眾）和源伺服器（影片從一個廣播流進該伺服器）。基於一個流可適用一臺伺服器或網路中的每臺伺服器上的負載策略，不斷進行動態的調整。

伺服器之間複製流的連線如同樹形結構，流的數量不斷被取樣，如果某個流的新增瀏覽有快速增加，這個流就會被複制到其他伺服器，這個過程不斷重複，構建出一個樹形(banq注：根據構造定律樹形是最有效生命系統特徵)，最終可能涵蓋了某個網路中所有伺服器，這個過程每三秒執行一次。

整個影片流從其源伺服器到複製到其他伺服器直至複製到使用者都時刻在記憶體中，其中沒有任何磁碟儲存。

使用 RTMP協議（影片流播放協議），每個流都需要一個獨立的會話，這會帶來昂貴的開銷，但是廣播多播和P2P技術沒有使用， 很多下游的ISP不支援多播，只是利用多播在內部伺服器進行影片複製，內部頻寬相當廉價，但是也沒有太多好處，因為無法細粒度控制在伺服器間複製。

Usher根據HTTP請求，決定哪個伺服器來處理請求的影片，而影片伺服器一般是被動的，Usher在其之前控制整個伺服器的拓撲結構。

影片流不是來自磁碟，影片是歸檔儲存在磁碟，源伺服器會被挑選出來處理一個上傳進來的新的影片流，記錄這個流在本地磁碟，每一秒影片被儲存和歸檔，歸檔儲存伺服器是使用XFS檔案系統。架構能夠處理數千個併發流影片傳入寫。每個影片流預設儲存7天，影片檔案可能跨磁碟分割槽儲存。

從其他重量協議遷移到HTTP流協議是快樂的，能夠使用現有技術進行很好地擴充套件，但是有一個問題必須積極面對，就是延遲和實時性問題，通常人們認為不超過5-30秒就是實時的了，但是這個不適用成千上萬人實時通訊互動，不能有1/4秒的延遲。

以上是介紹了影片廣播複製系統，他們還有一套Web架構(細節點選標題看英文)，兩個架構圖如下：

相關文章