Twitch是一個面向視頻游戲的實時流媒體視頻平臺，由Justin Kan和Emmett Shear聯合創立，它是Justin.tv旗下專注于游戲相關內容的獨立運營站點。根據其內部分析師透露，Twitch每月的訪問量超過3800萬，有超過2000萬個游戲玩家匯聚到這個平臺，每個訪問用戶在網站的日平均停留時間為1.5小時。網站支持28個國家和地區的語言，包括中文簡體和繁體。
Twitch的直播模式完全不同于YouTube等點播批處理方式，直播對技術要求更高更難，這也是目前國內電視直播還依賴有線網絡的原因，而互聯網上的電視直播業務在直播效果上要大打折扣，而Twitch則是在利用互聯網技術實現流暢不間斷直播上探索了一條成功道路。
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.
跟著 YouTube 等一眾廠商的腳步，現在連游戲直播服務 Twitch 也"開始"棄用 Flash 改用 HTML5 了。根據官網的消息，Twitch 目前已經完成了第一步驟，先將舊的 Flash 模塊改成了 HTML5 + Javascript 的組合，重新設計了播放控制界面。既然說到這是第一步，這代表了其實 Twitch 的視頻本身還是以 Flash 為基礎的架構，所以接下來才是要漸漸地將播放器完全置換為從里到外都是 HTML5 基礎。新的界面已經可以在 Channel 頁面上看到，并且已經逐步地向使用者開始推送，所以看到界面變得比較不同可別以為走錯網站了喔。
有一個問題就是：為什么視頻直播那么困難？好像只需要大量的帶寬，讓這一切在內存中，圍繞流進行視頻組合就可以了，其實沒那么簡單。是什么讓視頻直播有如此這樣的挑戰力？
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架構，兩個架構圖如下：
