Twitch是一個(gè)面向視頻游戲的實(shí)時(shí)流媒體視頻平臺，由Justin Kan和Emmett Shear聯(lián)合創(chuàng)立，它是Justin.tv旗下專注于游戲相關(guān)內(nèi)容的獨(dú)立運(yùn)營站點(diǎn)。根據(jù)其內(nèi)部分析師透露，Twitch每月的訪問量超過3800萬，有超過2000萬個(gè)游戲玩家匯聚到這個(gè)平臺，每個(gè)訪問用戶在網(wǎng)站的日平均停留時(shí)間為1.5小時(shí)。網(wǎng)站支持28個(gè)國家和地區(qū)的語言，包括中文簡體和繁體。
Twitch的直播模式完全不同于YouTube等點(diǎn)播批處理方式，直播對技術(shù)要求更高更難，這也是目前國內(nèi)電視直播還依賴有線網(wǎng)絡(luò)的原因，而互聯(lián)網(wǎng)上的電視直播業(yè)務(wù)在直播效果上要大打折扣，而Twitch則是在利用互聯(lián)網(wǎng)技術(shù)實(shí)現(xiàn)流暢不間斷直播上探索了一條成功道路。
Twitch直播視頻和是YouTube的批處理視頻不同是：后者將所有視頻存儲在磁盤上，稍后根據(jù)要求進(jìn)行重播，而直播視對頻視頻存儲寫和視頻讀播放是同時(shí)進(jìn)行的，因此需要一個(gè)完全不同的體系架構(gòu)。下面是其技術(shù)堆棧：

Usher - 這是其核心系統(tǒng)，用來實(shí)現(xiàn)對視頻流播放的業(yè)務(wù)邏輯服務(wù)器
Twice - 可定制的web緩存系統(tǒng)(http://code.google.com/p/twicecache/)
XFS - 文件系統(tǒng) 將視頻以秒為單位存儲該系統(tǒng)中，
HAProxy - 軟件負(fù)載平衡.
LVS stack 和 ldirectord - 保證高可用性.
Ruby on Rails - 應(yīng)用服務(wù)器
Nginx - web 服務(wù)器
PostgreSQL - 存儲用戶和其他元數(shù)據(jù)
MongoDB - 用于存儲用戶操作事件實(shí)現(xiàn)內(nèi)部分析
MemcachedDB - 用于處理高密集寫操作如瀏覽數(shù)量
Syslog-ng - 日志服務(wù)
RabitMQ - 用于 job 系統(tǒng).
Puppet - 用于構(gòu)建服務(wù)器.
Git - 源碼控制.
Wowza - Flash/H.264 視頻服務(wù)器, 許多定制的模塊使用Java編寫
S3 - small image storage.

跟著 YouTube 等一眾廠商的腳步，現(xiàn)在連游戲直播服務(wù) Twitch 也"開始"棄用 Flash 改用 HTML5 了。根據(jù)官網(wǎng)的消息，Twitch 目前已經(jīng)完成了第一步驟，先將舊的 Flash 模塊改成了 HTML5 + Javascript 的組合，重新設(shè)計(jì)了播放控制界面。既然說到這是第一步，這代表了其實(shí) Twitch 的視頻本身還是以 Flash 為基礎(chǔ)的架構(gòu)，所以接下來才是要漸漸地將播放器完全置換為從里到外都是 HTML5 基礎(chǔ)。新的界面已經(jīng)可以在 Channel 頁面上看到，并且已經(jīng)逐步地向使用者開始推送，所以看到界面變得比較不同可別以為走錯(cuò)網(wǎng)站了喔。

有一個(gè)問題就是：為什么視頻直播那么困難？好像只需要大量的帶寬，讓這一切在內(nèi)存中，圍繞流進(jìn)行視頻組合就可以了，其實(shí)沒那么簡單。是什么讓視頻直播有如此這樣的挑戰(zhàn)力？

1. 視頻不能像打嗝一樣存在中斷, 如果視頻超過網(wǎng)絡(luò)容量哪怕幾分之一秒，每一個(gè)觀眾在同一時(shí)刻將看到屏幕上顯示“正在緩沖...“。擁有網(wǎng)絡(luò)容量是非常重要的。

2.需要CDN實(shí)現(xiàn)溢流overflow Usher會處理這個(gè)邏輯，一旦用戶量超過最大容量，新的播放者將被發(fā)往CDN服務(wù)器。

3.當(dāng)觀眾快速發(fā)現(xiàn)任何問題就會立即交談聊天。用戶期望能夠優(yōu)雅地處理這些問題。他們必須等到一臺服務(wù)器上的每個(gè)人觀眾完成瀏覽后才能讓這臺服務(wù)器維護(hù)模式。這是一個(gè)非常緩慢的維護(hù)過程。會話必須從未中斷。通常的網(wǎng)站可以有許多錯(cuò)誤只是很少人會注意到，而直播系統(tǒng)則不同。

下面看看Twitch如何應(yīng)對這些挑戰(zhàn)？
他們最大的問題是控制快閃的人群，所謂快閃人群，就是當(dāng)很多人在同一時(shí)間想看同樣的事情。這是一個(gè)龐大的傳入流量。因此，他們需要創(chuàng)建一個(gè)方法來在所有的視頻服務(wù)器和數(shù)據(jù)中心之間實(shí)現(xiàn)實(shí)時(shí)適應(yīng)性負(fù)載。該機(jī)制是Usher。

Usher是一個(gè)他們開發(fā)的軟件，用來管理負(fù)載平衡 授權(quán)和播放等其他業(yè)務(wù)邏輯。Usher對每個(gè)流視頻都要計(jì)算出有多少服務(wù)器在發(fā)送它們，這樣確保最佳負(fù)載。 它實(shí)時(shí)決定如何在這些服務(wù)器之間復(fù)制流，復(fù)制依據(jù)的規(guī)則有：
所有服務(wù)器的單獨(dú)負(fù)載
優(yōu)化的延遲
一個(gè)流在哪些服務(wù)器上
用戶的IP地址，這樣能夠分辨用戶來自哪個(gè)國家
根據(jù)路由route數(shù)據(jù)庫尋找離用戶IP最近的ISP.
根據(jù)請求來自的數(shù)據(jù)中心，試圖將這個(gè)請求發(fā)往同一個(gè)數(shù)據(jù)中心的視頻服務(wù)器。

使用這些優(yōu)化指標(biāo)可以引導(dǎo)優(yōu)化每個(gè)發(fā)往服務(wù)器的請求，以保證更好的延遲和性能優(yōu)化。他們還有很多的監(jiān)控調(diào)校表盤和非常細(xì)粒度的控制。

每個(gè)服務(wù)器可以充當(dāng)一個(gè)邊緣服務(wù)器（該服務(wù)器的視頻直接發(fā)送到觀眾）和源服務(wù)器（視頻從一個(gè)廣播流進(jìn)該服務(wù)器）。基于一個(gè)流可適用一臺服務(wù)器或網(wǎng)絡(luò)中的每臺服務(wù)器上的負(fù)載策略，不斷進(jìn)行動態(tài)的調(diào)整。

服務(wù)器之間復(fù)制流的連接如同樹形結(jié)構(gòu)，流的數(shù)量不斷被取樣，如果某個(gè)流的新增瀏覽有快速增加，這個(gè)流就會被復(fù)制到其他服務(wù)器，這個(gè)過程不斷重復(fù)，構(gòu)建出一個(gè)樹形(banq注：根據(jù)構(gòu)造定律樹形是最有效生命系統(tǒng)特征)，最終可能涵蓋了某個(gè)網(wǎng)絡(luò)中所有服務(wù)器，這個(gè)過程每三秒執(zhí)行一次。

整個(gè)視頻流從其源服務(wù)器到拷貝到其他服務(wù)器直至復(fù)制到用戶都時(shí)刻在內(nèi)存中，其中沒有任何磁盤存儲。

使用 RTMP協(xié)議（視頻流播放協(xié)議），每個(gè)流都需要一個(gè)獨(dú)立的會話，這會帶來昂貴的開銷，但是廣播多播和P2P技術(shù)沒有使用， 很多下游的ISP不支持多播，只是利用多播在內(nèi)部服務(wù)器進(jìn)行視頻復(fù)制，內(nèi)部帶寬相當(dāng)廉價(jià)，但是也沒有太多好處，因?yàn)闊o法細(xì)粒度控制在服務(wù)器間復(fù)制。

Usher根據(jù)HTTP請求，決定哪個(gè)服務(wù)器來處理請求的視頻，而視頻服務(wù)器一般是被動的，Usher在其之前控制整個(gè)服務(wù)器的拓?fù)浣Y(jié)構(gòu)。

視頻流不是來自磁盤，視頻是歸檔存儲在磁盤，源服務(wù)器會被挑選出來處理一個(gè)上傳進(jìn)來的新的視頻流，記錄這個(gè)流在本地磁盤，每一秒視頻被保存和歸檔，歸檔存儲服務(wù)器是使用XFS文件系統(tǒng)。架構(gòu)能夠處理數(shù)千個(gè)并發(fā)流視頻傳入寫。每個(gè)視頻流缺省保存7天，視頻文件可能跨磁盤分區(qū)保存。

從其他重量協(xié)議遷移到HTTP流協(xié)議是快樂的，能夠使用現(xiàn)有技術(shù)進(jìn)行很好地?cái)U(kuò)展，但是有一個(gè)問題必須積極面對，就是延遲和實(shí)時(shí)性問題，通常人們認(rèn)為不超過5-30秒就是實(shí)時(shí)的了，但是這個(gè)不適用成千上萬人實(shí)時(shí)通訊交互，不能有1/4秒的延遲。

以上是介紹了視頻廣播復(fù)制系統(tǒng)，他們還有一套Web架構(gòu)，兩個(gè)架構(gòu)圖如下：

最新評論