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

Usher - 這是其核心系統(tǒng)，用來實現(xiàn)對視頻流播放的業(yè)務(wù)邏輯服務(wù)器
Twice - 可定制的web緩存系統(tǒng)(http://code.google.com/p/twicecache/)
XFS - 文件系統(tǒng) 將視頻以秒為單位存儲該系統(tǒng)中，
HAProxy - 軟件負載平衡.
LVS stack 和 ldirectord - 保證高可用性.
Ruby on Rails - 應(yīng)用服務(wù)器
Nginx - web 服務(wù)器
PostgreSQL - 存儲用戶和其他元數(shù)據(jù)
MongoDB - 用于存儲用戶操作事件實現(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è)計了播放控制界面。既然說到這是第一步，這代表了其實 Twitch 的視頻本身還是以 Flash 為基礎(chǔ)的架構(gòu)，所以接下來才是要漸漸地將播放器完全置換為從里到外都是 HTML5 基礎(chǔ)。新的界面已經(jīng)可以在 Channel 頁面上看到，并且已經(jīng)逐步地向使用者開始推送，所以看到界面變得比較不同可別以為走錯網(wǎng)站了喔。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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