Justin.TV每月有3000萬個獨立訪問量，在游戲視頻上傳領域打敗了YouTube ，他們每天每分鐘新增30個小時的視頻，而YouTube只有23。

下面從Justin.TV的實時視頻系統使用到的平臺，他們的架構細節，從他們身上應該學到的東西等幾個方面逐一展開。

使用到的平臺

Twice —— 代理服務系統，主要用緩沖優化應用服務器負載

XFS —— 文件系統

HAProxy —— 用于TCP/HTTP負載平衡

LVS stack and Idirectord —— 高可靠性

Ruby on Rails —— 應用服務器系統

Nginx —— web服務器系統

PostgreSQL —— 數據庫，用于用戶和meta數據

MongoDB —— 數據庫，用于內部分析

MemcachedDB —— 數據庫，用于存放經常要修改的數據

Syslog-ng —— 日志服務系統

RabitMQ —— job系統

Puppet —— 創建服務

Git —— 源代碼管理

Wowza —— Flash/H.264視頻服務器和許多Java寫的custome modules

Usher —— 播放視頻流的邏輯控制服務器

S3 —— 用于存儲小型鏡像

Justin.TV的一些統計數據

有覆蓋全美的4個數據中心

在任何時候都有2000多個同時流入的數據流

每天每分鐘新增30個小時的視頻

每月有3000萬個獨立訪問量(不計同一用戶多次訪問)

每秒實時的網絡流量在45G左右 #p# 

實時視頻結構詳述

 

 

實時視頻結構

1.使用了P2P和CDN

一般人認為，只需要不斷提高帶寬，把傳來的數據都放入內存，不斷的接收數據流就可以了，事實并非如此。實時視頻要求不能打斷，這就意味著你不可以超負荷的使用帶寬。YouTube只需要讓播放器緩沖一下，就可以用8G的帶寬解決10G通道的需求，但在實時視頻里，你不能緩沖，如果在信道上的流量超過了它的傳輸能力，哪怕只是一瞬間，那么所有的正在看的用戶在那一刻都會卡。如果你在它的極限能力上再加入了一點兒負載，所有人立刻就會進入緩沖狀態。

Justin.TV使用了點對點的結構來解決這個問題，當然他們也有更好的解決辦法，CDN(內容分發網絡)便是之一。當用戶的流量負載超過Justin.TV的負載能力時，Justin.TV便很巧妙的將超標流量引入到一個CDN中去。Usher控制著這個處理邏輯。一旦接到了超標用戶的負載請求，Usher便立刻將這些新用戶轉發到CDN中去。

2.100%可用時間和維護的矛盾

實時視頻構建的系統既要保證100%的可用時間，又要保證機器可以進行維護。與一般網站不同，一般網站維護時出現的問題只有少數人會發現、關注，而實時視頻網站不同，用戶很快就會發現維護時帶來的任何問題，并且互相傳播的非常快，這就使得沒有什么問題可以隱瞞用戶，面對現在用戶的挑剔，你必須避免維護時出問題。對一個服務器維護時，你不能主動結束用戶的進程，必須等待所有在這個服務器上的用戶自己結束服務才能開始，而這個過程往往非常緩慢。

3.Usher與負載均衡

Justin.TV遇到的最大的麻煩是即時擁塞，當大量的用戶同時看同一個欄目的時候，便會突然產生突發網絡擁塞。他們開發了一個實時的服務器和數據中心調度系統，它就是Usher。

Justin.TV的系統在突發的高峰擁塞上做了很多。他們的網絡每秒可以處理大量的鏈入連接。用戶也參與了負載均衡，這也是Justin.TV需要用戶使用Justin.TV自己的播放器的原因之一。至于TCP，由于它的典型處理速度就是百kbps級的，所以也不用對TCP協議做什么修改。

相對于他們的流量，他們的視頻服務器看來來有些少，原因是他們可以使用Usher把每個視頻服務器的性能發揮到最好。負載均衡可以確保流量從不會超過他們的負載極限。負載大部分是在內存中，因此這個系統可以讓網絡的速度發揮到極限。服務器他們是一次從Rackable(SGI服務器的一個系列)買了一整套。他們做的僅僅是從所有預置的里面做了下挑選。

Usher是Justin.TV開發的一款定制化軟件，用來管理負載平衡，用戶認證和其他一些流播放的處理邏輯。Usher通過計算出每個流需要多少臺服務器提供支持，從而分配資源，保證系統處于最優狀態。這是他們的系統和別家不同之處。Usher通常會從下面幾個指標計算、衡量某個流媒體所需要的服務器：

每個數據中心的負載是多少

每個服務器的負載是多少

延遲優化的角度

當前這個流可用的服務器列表

用戶的國家(通過IP地址獲得)

用戶是否有可用的對等網(通過在路由數據庫中查詢IP地址獲得)

請求來自于哪個數據中心

Usher使用這些指標便可以在服務凈成本上來優化，把服務放在比較空閑的服務器上，或者把服務放在離用戶較近的服務器上，從而給用戶帶來更低的延遲和更好的表現。Usher有很多個可以選擇的模式從而達到很細的控制粒度。

Justin.TV系統的每個服務器都可以做邊緣服務器，直接為用戶輸出視頻流，同時每個服務器也可以做源服務器，為其他服務器傳遞視頻流。這個特性，使得視頻流的負載結構成了動態的，經常改變的一個過程。

4.服務器形成了加權樹

服務器之間由視頻流的拷貝而產生的聯系和加權樹非常相似。數據流的數量經常被系統取樣、統計，如果觀看某個視頻流的用戶數量飛速上漲，系統便將其拷貝很多份到一些其他的服務器上去。這個過程反復執行，最終就形成了一個樹狀的結構，最終會將網絡中所有的服務器都畫在里面。Justin.TV的視頻流從源服務器出發，被拷貝到其他服務器，或者拷貝到用戶的整個過程中，都處于內存中，沒有硬盤路徑的概念。

5.RTMP和HTTP

Justin.TV盡可能的使用了Flash，因為它使用RTMP協議，對每個視頻流，系統都有一個獨立的Session去維護它。由于使用這個協議，成本就相當高。由于下載流的ISP不支持，因而無法使用多路廣播和P2P技術。Justin.TV確實想過用多路廣播在內部服務器之間拷貝數據流，然而由于他們的系統控制覆蓋整個網絡，而且內部有大量的很便宜的帶寬可以使用，這樣使用多路廣播的技術就并沒有產生多少效益。同時，由于他們的優化算法是將每個服務器上的流數都最小化，這就使得在很細的力度上做些事情會非常麻煩，甚至超過了他們能得到收益。

Justin.TV的Usher使用HTTP請求去控制某個服務器負載哪個視頻流，從而控制了服務的拓撲結構。Justin.TV在流數據上使用HTTP，但存在的一個問題是它沒有延遲和實時方面的性能。有些人說實時的定義就是5-30秒，然而，面對數千人做實時視頻的時候這顯然不行，因為他們還需要實時的討論，交流。這意味著延遲不能高于1/4秒。

6.從AWS到自己的數據中心

起初Justin.TV使用AWS，后來遷移到Akamai(云服務供應商)，最后到了自己的數據中心。

離開AWS到Akamai的原因有：1，成本;2，網速不能滿足他們的需求。視頻直播對帶寬非常敏感，因此有一個快速的，可靠的，穩定的和低延遲的網絡非常關鍵。使用AWS時，你不能控制這些。它是一個共享的網絡，常常超負載，AWS的網速不會比300Mbps更快。他們對動態范圍改動和云API很重視，然而在性能和成本問題上沒有做什么。

3年前，Justin.TV計算他們每個用戶的成本，CDN是$0.135，AWS是0.0074，Datacenter是$0.001如今，他們的CDN成本降低了，但他們的數據中心的成本卻仍然一樣。

擁有多個數據中心的關鍵是為了能夠接近所有的主要交換節點。他們選擇國內最好的位置從而使得他們為國內最多的節點提供了入口。而且節約了成本。構建了這些數據中心后，他們就直接連入了這些其他的網絡，從而就省去了之前處理這些中轉流量的費用。還提高了性能。他們直接連入了他們所謂的"eyeball"網絡。這個網絡中包含了大量的cable/DSL用戶。和"content"網絡連接有些類似，Justin.TV的"eyeball"連接的流量主要來自終端用戶。在大多數情況下，這些都是免費的，不用任何花一分錢，要做的就是連進來就行。Justin.TV有一個主干網，用于在不同的數據中心傳輸視頻流。因為要到一個可用節點的選拔過程是去找愿意和你做對等節點的過程，這通常是很困難的。

7.存儲

視頻流不是從磁盤形成，而是要存到磁盤上去。源服務器將一個傳入的視頻流在本地磁盤上復制一份，之后便將這個文件上傳到長期存儲器上。視頻的每一秒都被錄下來并且存檔了。

存儲設備和YouTube類似，就是一個磁盤庫。使用XFS文件系統。這個結構用于記錄通過服務器傳播的廣播。默認的視頻流是保存7天。用戶可以手動的設置，甚至你可以保存到永遠(如果公司沒有倒閉的話)。

8.實時轉碼

增加了實時的轉碼功能，可以將任何一種流式數據轉化為傳輸層數據或者是代碼，并且可以用新的格式將它重新編為流媒體。有一個轉碼集群，用來處理轉換工作。轉換的會話使用job系統進行管理。如果需要的轉碼服務超過了集群的處理能力，那所有的服務器都可以用作轉碼服務器。 #p# 

Web結構

 

 

Web 結構

1.Justin.TV前端使用Ruby on Rails。

2.用Twice做緩存

系統個每個頁面都使用了他們自己定制的Twice緩存系統。Twice扮演的角色是輕量級反向代理服務器和模板系統的合并角色。思路是對每一個用戶，緩存每一個頁面，然后將每個頁面的更新再并入其中。使用Twice以后，每個進程每秒可以處理150條請求，同時可以在后臺處理10-20個請求，這就擴展了7-10倍之前的服務器可以處理的網頁的數量。大部分動態網頁訪問都在5ms以內。Twice有一個插件結構，所以它可以支持應用程序的一個特點，例如添加地理信息。

不用觸及應用服務器，便能自動緩存像用戶名一樣的數據。

Twice是一個為Justin.TV的需求和環境而定制化開發的。如果開發一個新的Rails應用，使用Varnish或許是一個更好的主意。

3.網絡流量由一個數據中心服務，其他的數據中心為視頻服務。

4.Justin.TV 對所有的操作都做了監控.每一個點擊，查看頁面和每一個動作都被記錄下來，這樣就可以不斷提高服務。前端，網絡呼叫或者一個應用服務器的日志消息都被轉換成系統日志消息，通過syslog-ngto轉發。他們掃描所有的數據，將它裝入MongoDB，使用Mongo執行查詢。

5.Justin.TV的API來自網站的應用服務器。它使用相同緩沖引擎，通過擴展網站來擴展他們的API.

6.PostegreSQL是他們最主要的數據庫。結構式是簡單的主從結構，由一個主機和多個從屬讀數據庫組成。

由于他們網站的類型，他們不需要許多寫數據庫。緩沖系統控制著這些讀數據庫。他們發現PostgreSQL并不擅長處理寫操作。因此Justin.TV就是用MemcachedDB去處理那些經常要寫的數據，例如計數器。

7.他們有一個聊天服務器集群，專門用來為聊天功能服務。如果用戶進入了一個頻道，用戶就會有5個不同的聊天服務器為他服務。擴展聊天功能要比擴展視頻功能簡單的多。用戶可以被劃分到不同的房間，這些房間又由不同的服務器負載。他們也不會讓100,000個人同時在一起聊天。他們限制每個房間200人，這樣就可以在一個小組里進行更有意義的交談。這同時對擴展也很有幫助，這真的是一個很聰明的策略。

8.AWS用于存儲文檔鏡像。他們沒有為存儲許多小鏡像而開發專門的系統，他們使用了S3。它非常方便，而且很便宜，這就不用在他們上面花更多的時間了。他們的鏡像使用頻率很高，所有他們是可緩沖的，也沒有留下什么后續問題。 #p# 

網絡拓撲結構設計

網絡拓撲結構非常簡單。每個服務器機架頂都有一對1G的卡。每個機架都有多個10G的接口，接口連接到外部的核心路由器。他們使用Dell Power Edge交換機，這些交換機對L3(TCP/IP)并不是完全支持，但是比L2(ethernet)要好的多。每個交換機每天要傳輸20G的數據，而且很便宜。核心路由器是思科的6500的系列。Justin.TV想要將節點最小化，從而讓延遲降低，并且降低每個packet的處理時間。Usher管理著所有的接入控制和其他的邏輯，而不僅僅限于網絡硬件。

使用多個數據中心可以充分利用對等網的優勢，把流量轉移到離用戶最近的地方。和其他的網絡和節點的連接非常多。這樣就有多個可選的傳輸途徑，所以可以使用最好的那個路徑。如果他們遇到了網絡的擁塞，就可以選擇一條別的路。他們可以通過IP地址和時間，找到對應的ISP。

開發和部署

他們使用Puppet服務器主機，有20中不同種類的服務器。從數據庫中出來的任何東西都要經過緩存器。使用Puppet他們可以把這個緩存器變成他們想要的任何東西。

他們有兩個軟件隊伍。一個是產品隊伍，另一個是硬件基礎設施隊伍。他們的隊伍非常小，大概每個隊伍只有7-8個人。每個隊伍都有一個產品經理。他們雇傭一般的技術員，但卻雇傭了網絡結構和數據庫相關的專家。

他們使用了基于網絡的開發系統，所以每個新的改動都會在幾分鐘內完成。QA必須在變成產品之前完成，在這里通常需要5-10分鐘。

Justin.TV使用Git管理源代碼。Justin.TV喜歡Git的這個功能，你可以寫一個程序副本，20-30行，然后它可以融合到其他人手里正在修改的副本。這個工作是獨立的，模塊化的。在你不得不撤銷你提交的副本時，你可以很容易就修改或者撤銷你的代碼。每過幾天每個人都會試著將自己的代碼副本融入到主代碼中去消除沖突。他們每天對軟件做5-15個修改。范圍從1行代碼中的bug到大范圍的測試都有。

數據庫模式通過手動更新完成。將他們復制的數據庫副本遷移到一起就會形成一個最新的動態記錄的版本。在把改動最終應用到產品之前會在許多不同的環境下對其進行測試。

Puppet管理配置文件。每個小的改動基本上就是一個實驗。他們會追蹤每個對核心文件的改動的影響和之前的版本。這些測試很重要，因為通過它他們可以找出哪些改動是真正提高他們關心的指標。 #p# 

Justin.TV的未來

他們的目標是增加一個數量級。首先要切分他們的視頻元數據系統。由于流數據和服務器的大幅增長，他們的元數據負載也指數級的爆發增長，因此，他們需要將其大范圍進行切分。對于網絡數據庫，將使用Cassandra對其進行拆分。其次，為了災后恢復，要對核心數據中心進行備份。

學到的東西

自己開發還是購買。他們在這個問題上已經做了很多錯誤的決策。例如，他們起初應該買一臺視頻服務器而不是自己去做了一臺。軟件工程師喜歡將軟件做的個性化，然后使用開源社區維護的東西卻有很多益處。因此他們提出了一個更好的流程去做這個決定：1.這個項目是活動?還是維護?還是修補漏洞?2.有其他的人要用它么?你能向別人請教下該如何定義它?3.擴展性的問題。他們必須去做改變。4.如果我們自己開發，我們可以做到更快，更好，還是我們可以獲得更多我們需要的特性呢? 就像使用Usher，他們考慮他們可否創造一個新的外部特性，并且和另外一個系統交互。把Usher做為視頻擴展性的核心針對相對笨拙的視頻服務器來說是一個非常好的決策的例子。

關注自己做的事情，不要在意別人怎么干。他們的目標是有用最好的系統，最多的服務時間和最完美的擴展性。他們用了3年去開發能管理百萬個廣播并發的技術。

不要外包。你學到的核心價值在于經驗，而不是代碼或者硬件。

把一切都當做實驗來做。對所有的東西都進行測量。局部測試，追蹤，測量。這很劃算。從一開始就做。使用優秀的測量工具。例如，他們在復制的URL上附加一個標簽，然后就可以知道你是否分享了這個鏈接。他們從不測量的一段時間走到了如今高度測量。通過重寫廣播進程，使得他們的會話數量增長了700%。他們想要網站運行更快，響應更快，網頁裝載更快，視頻服務更好。系統擠出的每一毫秒的延遲都帶來了更多的廣播者。他們有40個實驗，如果他們希望讓一個用戶變成一個廣播者。對每個實驗他們都想要看一下廣播后的留存率，廣播的可用性，會話率，然后對每個改動都做一個明智的決策。

最重要的一件事是理解你的網站如何共享服務，怎么優化它。他們通過減少共享的鏈接在菜單中的深度，成功的提高了500%的分享率。

使用公共的構建模塊和基礎設施意味著系統將立刻識別什么是重要的，然后執行。具有網絡能力很重要，這也是他們應該從開始就關注的地方。

讓系統忙起來。使用系統的所有能力。為什么要把錢放在桌子上呢?構建可以通過應答對系統進行合理的分配的系統。

對不重要的事情不要浪費時間。如果它非常方便并且不用花費多少，就沒有必要在它上面花費時間。使用S3去存儲鏡像就是一個很典型的例子。

試著為用戶想做的事情提供支持，而不是做你認為用戶該這樣使用的東西。Justin.TV的終極目標似乎是把所有人都變成一個廣播點。在用戶實驗時，通過盡可能的走出用戶的使用方式，他們試著讓這個過程變得盡可能簡單。在這過程中，他們發現，游戲是一個巨大的用力。用戶喜歡將Xbox截圖出來，并且與大家分享，討論它。很有可能有些東西是你沒想過要放在商務計劃里的。

為負載峰值做設計。如果你只為了靜態的狀態做了設計，之后你的網站將會在峰值來臨時垮掉。在直播時，這通常是一個大事，如果你陷入了這個麻煩，很快人們就開始傳播對你不利的話。為峰值負載進行設計需要使用一個所有層次的技術。

讓網絡結構保持簡單。使用多數據中心。使用點對點網絡連接結構。

不要擔心將東西劃分到更多的可擴展塊中去。例如，與其使用一個100,000人的頻道，不如將他們劃分到更多的社會和可擴展的頻道去。

實時系統不能隱藏來自用戶的任何問題，這就是的說服用戶你的網站很可靠變的很困難。由于他們和實時系統之間的聯系是固定的，這會使的系統的每個問題和故障都讓大家知道。你藏不住。每個人都會發現。并且每個人都會通過交流傳播發生了什么。很快，用戶就會有一個你的網站有很多問題的感覺。在這種情況下，和你的用戶交流就變得很重要，從一開始就構建一個可信賴的，高質量的，可擴展的，高性能的系統，設計一個用戶用起來盡可能簡單和舒服的系統。