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

下面從Justin.TV的實時視頻系統(tǒng)使用到的平臺，他們的架構(gòu)細節(jié)，從他們身上應(yīng)該學到的東西等幾個方面逐一展開。

使用到的平臺

Twice —— 代理服務(wù)系統(tǒng)，主要用緩沖優(yōu)化應(yīng)用服務(wù)器負載

XFS —— 文件系統(tǒng)

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

LVS stack and Idirectord —— 高可靠性

Ruby on Rails —— 應(yīng)用服務(wù)器系統(tǒng)

Nginx —— web服務(wù)器系統(tǒng)

PostgreSQL —— 數(shù)據(jù)庫，用于用戶和meta數(shù)據(jù)

MongoDB —— 數(shù)據(jù)庫，用于內(nèi)部分析

MemcachedDB —— 數(shù)據(jù)庫，用于存放經(jīng)常要修改的數(shù)據(jù)

Syslog-ng —— 日志服務(wù)系統(tǒng)

RabitMQ —— job系統(tǒng)

Puppet —— 創(chuàng)建服務(wù)

Git —— 源代碼管理

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

Usher —— 播放視頻流的邏輯控制服務(wù)器

S3 —— 用于存儲小型鏡像

Justin.TV的一些統(tǒng)計數(shù)據(jù)

有覆蓋全美的4個數(shù)據(jù)中心

在任何時候都有2000多個同時流入的數(shù)據(jù)流

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

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

每秒實時的網(wǎng)絡(luò)流量在45G左右 #p# 

實時視頻結(jié)構(gòu)詳述

實時視頻結(jié)構(gòu)

1.使用了P2P和CDN

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

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

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

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

3.Usher與負載均衡

Justin.TV遇到的最大的麻煩是即時擁塞，當大量的用戶同時看同一個欄目的時候，便會突然產(chǎn)生突發(fā)網(wǎng)絡(luò)擁塞。他們開發(fā)了一個實時的服務(wù)器和數(shù)據(jù)中心調(diào)度系統(tǒng)，它就是Usher。

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

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

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

每個數(shù)據(jù)中心的負載是多少

每個服務(wù)器的負載是多少

延遲優(yōu)化的角度

當前這個流可用的服務(wù)器列表

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

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

請求來自于哪個數(shù)據(jù)中心

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

Justin.TV系統(tǒng)的每個服務(wù)器都可以做邊緣服務(wù)器，直接為用戶輸出視頻流，同時每個服務(wù)器也可以做源服務(wù)器，為其他服務(wù)器傳遞視頻流。這個特性，使得視頻流的負載結(jié)構(gòu)成了動態(tài)的，經(jīng)常改變的一個過程。

4.服務(wù)器形成了加權(quán)樹

服務(wù)器之間由視頻流的拷貝而產(chǎn)生的聯(lián)系和加權(quán)樹非常相似。數(shù)據(jù)流的數(shù)量經(jīng)常被系統(tǒng)取樣、統(tǒng)計，如果觀看某個視頻流的用戶數(shù)量飛速上漲，系統(tǒng)便將其拷貝很多份到一些其他的服務(wù)器上去。這個過程反復(fù)執(zhí)行，最終就形成了一個樹狀的結(jié)構(gòu)，最終會將網(wǎng)絡(luò)中所有的服務(wù)器都畫在里面。Justin.TV的視頻流從源服務(wù)器出發(fā)，被拷貝到其他服務(wù)器，或者拷貝到用戶的整個過程中，都處于內(nèi)存中，沒有硬盤路徑的概念。

5.RTMP和HTTP

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

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

6.從AWS到自己的數(shù)據(jù)中心

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

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

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

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

7.存儲

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

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

8.實時轉(zhuǎn)碼

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

Web結(jié)構(gòu)

Web 結(jié)構(gòu)

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

2.用Twice做緩存

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

不用觸及應(yīng)用服務(wù)器，便能自動緩存像用戶名一樣的數(shù)據(jù)。

Twice是一個為Justin.TV的需求和環(huán)境而定制化開發(fā)的。如果開發(fā)一個新的Rails應(yīng)用，使用Varnish或許是一個更好的主意。

3.網(wǎng)絡(luò)流量由一個數(shù)據(jù)中心服務(wù)，其他的數(shù)據(jù)中心為視頻服務(wù)。

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

5.Justin.TV的API來自網(wǎng)站的應(yīng)用服務(wù)器。它使用相同緩沖引擎，通過擴展網(wǎng)站來擴展他們的API.

6.PostegreSQL是他們最主要的數(shù)據(jù)庫。結(jié)構(gòu)式是簡單的主從結(jié)構(gòu)，由一個主機和多個從屬讀數(shù)據(jù)庫組成。

由于他們網(wǎng)站的類型，他們不需要許多寫數(shù)據(jù)庫。緩沖系統(tǒng)控制著這些讀數(shù)據(jù)庫。他們發(fā)現(xiàn)PostgreSQL并不擅長處理寫操作。因此Justin.TV就是用MemcachedDB去處理那些經(jīng)常要寫的數(shù)據(jù)，例如計數(shù)器。

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

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

網(wǎng)絡(luò)拓撲結(jié)構(gòu)設(shè)計

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

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

開發(fā)和部署

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

他們有兩個軟件隊伍。一個是產(chǎn)品隊伍，另一個是硬件基礎(chǔ)設(shè)施隊伍。他們的隊伍非常小，大概每個隊伍只有7-8個人。每個隊伍都有一個產(chǎn)品經(jīng)理。他們雇傭一般的技術(shù)員，但卻雇傭了網(wǎng)絡(luò)結(jié)構(gòu)和數(shù)據(jù)庫相關(guān)的專家。

他們使用了基于網(wǎng)絡(luò)的開發(fā)系統(tǒng)，所以每個新的改動都會在幾分鐘內(nèi)完成。QA必須在變成產(chǎn)品之前完成，在這里通常需要5-10分鐘。

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

數(shù)據(jù)庫模式通過手動更新完成。將他們復(fù)制的數(shù)據(jù)庫副本遷移到一起就會形成一個最新的動態(tài)記錄的版本。在把改動最終應(yīng)用到產(chǎn)品之前會在許多不同的環(huán)境下對其進行測試。

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

Justin.TV的未來

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

學到的東西

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

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

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

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

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

使用公共的構(gòu)建模塊和基礎(chǔ)設(shè)施意味著系統(tǒng)將立刻識別什么是重要的，然后執(zhí)行。具有網(wǎng)絡(luò)能力很重要，這也是他們應(yīng)該從開始就關(guān)注的地方。

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

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

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

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

讓網(wǎng)絡(luò)結(jié)構(gòu)保持簡單。使用多數(shù)據(jù)中心。使用點對點網(wǎng)絡(luò)連接結(jié)構(gòu)。

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

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