Twitch是一個(gè)面向視頻游戲的實(shí)時(shí)流媒體視頻平臺(tái)，由Justin Kan和Emmett Shear聯(lián)合創(chuàng)立，它是Justin.tv旗下專(zhuān)注于游戲相關(guān)內(nèi)容的獨(dú)立運(yùn)營(yíng)站點(diǎn)。根據(jù)其內(nèi)部分析師透露，Twitch每月的訪(fǎng)問(wèn)量超過(guò)3800萬(wàn)，有超過(guò)2000萬(wàn)個(gè)游戲玩家匯聚到這個(gè)平臺(tái)，每個(gè)訪(fǎng)問(wèn)用戶(hù)在網(wǎng)站的日平均停留時(shí)間為1.5小時(shí)。網(wǎng)站支持28個(gè)國(guó)家和地區(qū)的語(yǔ)言，包括中文簡(jiǎn)體和繁體。
Twitch的直播模式完全不同于YouTube等點(diǎn)播批處理方式，直播對(duì)技術(shù)要求更高更難，這也是目前國(guó)內(nèi)電視直播還依賴(lài)有線(xiàn)網(wǎng)絡(luò)的原因，而互聯(lián)網(wǎng)上的電視直播業(yè)務(wù)在直播效果上要大打折扣，而Twitch則是在利用互聯(lián)網(wǎng)技術(shù)實(shí)現(xiàn)流暢不間斷直播上探索了一條成功道路。
Twitch直播視頻和是YouTube的批處理視頻不同是：后者將所有視頻存儲(chǔ)在磁盤(pán)上，稍后根據(jù)要求進(jìn)行重播，而直播視對(duì)頻視頻存儲(chǔ)寫(xiě)和視頻讀播放是同時(shí)進(jìn)行的，因此需要一個(gè)完全不同的體系架構(gòu)。下面是其技術(shù)堆棧：
Usher - 這是其核心系統(tǒng)，用來(lái)實(shí)現(xiàn)對(duì)視頻流播放的業(yè)務(wù)邏輯服務(wù)器
Twice - 可定制的web緩存系統(tǒng)(http://code.google.com/p/twicecache/)
XFS - 文件系統(tǒng) 將視頻以秒為單位存儲(chǔ)該系統(tǒng)中，
HAProxy - 軟件負(fù)載平衡.
LVS stack 和 ldirectord - 保證高可用性.
Ruby on Rails - 應(yīng)用服務(wù)器
Nginx - web 服務(wù)器
PostgreSQL - 存儲(chǔ)用戶(hù)和其他元數(shù)據(jù)
MongoDB - 用于存儲(chǔ)用戶(hù)操作事件實(shí)現(xiàn)內(nèi)部分析
MemcachedDB - 用于處理高密集寫(xiě)操作如瀏覽數(shù)量
Syslog-ng - 日志服務(wù)
RabitMQ - 用于 job 系統(tǒng).
Puppet - 用于構(gòu)建服務(wù)器.
Git - 源碼控制.
Wowza - Flash/H.264 視頻服務(wù)器, 許多定制的模塊使用Java編寫(xiě)
S3 - small image storage.
跟著 YouTube 等一眾廠(chǎng)商的腳步，現(xiàn)在連游戲直播服務(wù) Twitch 也"開(kāi)始"棄用 Flash 改用 HTML5 了。根據(jù)官網(wǎng)的消息，Twitch 目前已經(jīng)完成了第一步驟，先將舊的 Flash 模塊改成了 HTML5 + Javascript 的組合，重新設(shè)計(jì)了播放控制界面。既然說(shuō)到這是第一步，這代表了其實(shí) Twitch 的視頻本身還是以 Flash 為基礎(chǔ)的架構(gòu)，所以接下來(lái)才是要漸漸地將播放器完全置換為從里到外都是 HTML5 基礎(chǔ)。新的界面已經(jīng)可以在 Channel 頁(yè)面上看到，并且已經(jīng)逐步地向使用者開(kāi)始推送，所以看到界面變得比較不同可別以為走錯(cuò)網(wǎng)站了喔。
有一個(gè)問(wèn)題就是：為什么視頻直播那么困難？好像只需要大量的帶寬，讓這一切在內(nèi)存中，圍繞流進(jìn)行視頻組合就可以了，其實(shí)沒(méi)那么簡(jiǎn)單。是什么讓視頻直播有如此這樣的挑戰(zhàn)力？
1. 視頻不能像打嗝一樣存在中斷, 如果視頻超過(guò)網(wǎng)絡(luò)容量哪怕幾分之一秒，每一個(gè)觀眾在同一時(shí)刻將看到屏幕上顯示“正在緩沖...“。擁有網(wǎng)絡(luò)容量是非常重要的。
2.需要CDN實(shí)現(xiàn)溢流overflow Usher會(huì)處理這個(gè)邏輯，一旦用戶(hù)量超過(guò)最大容量，新的播放者將被發(fā)往CDN服務(wù)器。
3.當(dāng)觀眾快速發(fā)現(xiàn)任何問(wèn)題就會(huì)立即交談聊天。用戶(hù)期望能夠優(yōu)雅地處理這些問(wèn)題。他們必須等到一臺(tái)服務(wù)器上的每個(gè)人觀眾完成瀏覽后才能讓這臺(tái)服務(wù)器維護(hù)模式。這是一個(gè)非常緩慢的維護(hù)過(guò)程。會(huì)話(huà)必須從未中斷。通常的網(wǎng)站可以有許多錯(cuò)誤只是很少人會(huì)注意到，而直播系統(tǒng)則不同。
下面看看Twitch如何應(yīng)對(duì)這些挑戰(zhàn)？
他們最大的問(wèn)題是控制快閃的人群，所謂快閃人群，就是當(dāng)很多人在同一時(shí)間想看同樣的事情。這是一個(gè)龐大的傳入流量。因此，他們需要?jiǎng)?chuàng)建一個(gè)方法來(lái)在所有的視頻服務(wù)器和數(shù)據(jù)中心之間實(shí)現(xiàn)實(shí)時(shí)適應(yīng)性負(fù)載。該機(jī)制是Usher。
Usher是一個(gè)他們開(kāi)發(fā)的軟件，用來(lái)管理負(fù)載平衡 授權(quán)和播放等其他業(yè)務(wù)邏輯。Usher對(duì)每個(gè)流視頻都要計(jì)算出有多少服務(wù)器在發(fā)送它們，這樣確保最佳負(fù)載。 它實(shí)時(shí)決定如何在這些服務(wù)器之間復(fù)制流，復(fù)制依據(jù)的規(guī)則有：
所有服務(wù)器的單獨(dú)負(fù)載
優(yōu)化的延遲
一個(gè)流在哪些服務(wù)器上
用戶(hù)的IP地址，這樣能夠分辨用戶(hù)來(lái)自哪個(gè)國(guó)家
根據(jù)路由route數(shù)據(jù)庫(kù)尋找離用戶(hù)IP最近的ISP.
根據(jù)請(qǐng)求來(lái)自的數(shù)據(jù)中心，試圖將這個(gè)請(qǐng)求發(fā)往同一個(gè)數(shù)據(jù)中心的視頻服務(wù)器。
使用這些優(yōu)化指標(biāo)可以引導(dǎo)優(yōu)化每個(gè)發(fā)往服務(wù)器的請(qǐng)求，以保證更好的延遲和性能優(yōu)化。他們還有很多的監(jiān)控調(diào)校表盤(pán)和非常細(xì)粒度的控制。
每個(gè)服務(wù)器可以充當(dāng)一個(gè)邊緣服務(wù)器（該服務(wù)器的視頻直接發(fā)送到觀眾）和源服務(wù)器（視頻從一個(gè)廣播流進(jìn)該服務(wù)器）。基于一個(gè)流可適用一臺(tái)服務(wù)器或網(wǎng)絡(luò)中的每臺(tái)服務(wù)器上的負(fù)載策略，不斷進(jìn)行動(dòng)態(tài)的調(diào)整。
服務(wù)器之間復(fù)制流的連接如同樹(shù)形結(jié)構(gòu)，流的數(shù)量不斷被取樣，如果某個(gè)流的新增瀏覽有快速增加，這個(gè)流就會(huì)被復(fù)制到其他服務(wù)器，這個(gè)過(guò)程不斷重復(fù)，構(gòu)建出一個(gè)樹(shù)形(banq注：根據(jù)構(gòu)造定律樹(shù)形是最有效生命系統(tǒng)特征)，最終可能涵蓋了某個(gè)網(wǎng)絡(luò)中所有服務(wù)器，這個(gè)過(guò)程每三秒執(zhí)行一次。
整個(gè)視頻流從其源服務(wù)器到拷貝到其他服務(wù)器直至復(fù)制到用戶(hù)都時(shí)刻在內(nèi)存中，其中沒(méi)有任何磁盤(pán)存儲(chǔ)。
使用 RTMP協(xié)議（視頻流播放協(xié)議），每個(gè)流都需要一個(gè)獨(dú)立的會(huì)話(huà)，這會(huì)帶來(lái)昂貴的開(kāi)銷(xiāo)，但是廣播多播和P2P技術(shù)沒(méi)有使用， 很多下游的ISP不支持多播，只是利用多播在內(nèi)部服務(wù)器進(jìn)行視頻復(fù)制，內(nèi)部帶寬相當(dāng)廉價(jià)，但是也沒(méi)有太多好處，因?yàn)闊o(wú)法細(xì)粒度控制在服務(wù)器間復(fù)制。
Usher根據(jù)HTTP請(qǐng)求，決定哪個(gè)服務(wù)器來(lái)處理請(qǐng)求的視頻，而視頻服務(wù)器一般是被動(dòng)的，Usher在其之前控制整個(gè)服務(wù)器的拓?fù)浣Y(jié)構(gòu)。
視頻流不是來(lái)自磁盤(pán)，視頻是歸檔存儲(chǔ)在磁盤(pán)，源服務(wù)器會(huì)被挑選出來(lái)處理一個(gè)上傳進(jìn)來(lái)的新的視頻流，記錄這個(gè)流在本地磁盤(pán)，每一秒視頻被保存和歸檔，歸檔存儲(chǔ)服務(wù)器是使用XFS文件系統(tǒng)。架構(gòu)能夠處理數(shù)千個(gè)并發(fā)流視頻傳入寫(xiě)。每個(gè)視頻流缺省保存7天，視頻文件可能跨磁盤(pán)分區(qū)保存。
從其他重量協(xié)議遷移到HTTP流協(xié)議是快樂(lè)的，能夠使用現(xiàn)有技術(shù)進(jìn)行很好地?cái)U(kuò)展，但是有一個(gè)問(wèn)題必須積極面對(duì)，就是延遲和實(shí)時(shí)性問(wèn)題，通常人們認(rèn)為不超過(guò)5-30秒就是實(shí)時(shí)的了，但是這個(gè)不適用成千上萬(wàn)人實(shí)時(shí)通訊交互，不能有1/4秒的延遲。
以上是介紹了視頻廣播復(fù)制系統(tǒng)，他們還有一套Web架構(gòu)，兩個(gè)架構(gòu)圖如下：
