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

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

使用到的平臺

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

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

HAProxy —— 用于TCP/HTTP負(fù)載平衡

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)計(jì)數(shù)據(jù)

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

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

每天每分鐘新增30個(gè)小時(shí)的視頻

每月有3000萬個(gè)獨(dú)立訪問量(不計(jì)同一用戶多次訪問)

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

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

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

1.使用了P2P和CDN

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

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

2.100%可用時(shí)間和維護(hù)的矛盾

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

3.Usher與負(fù)載均衡

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

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

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

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

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

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

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

當(dāng)前這個(gè)流可用的服務(wù)器列表

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

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

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

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

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

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

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

5.RTMP和HTTP

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

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

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

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

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

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

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

7.存儲

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

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

8.實(shí)時(shí)轉(zhuǎn)碼

增加了實(shí)時(shí)的轉(zhuǎn)碼功能，可以將任何一種流式數(shù)據(jù)轉(zhuǎn)化為傳輸層數(shù)據(jù)或者是代碼，并且可以用新的格式將它重新編為流媒體。有一個(gè)轉(zhuǎn)碼集群，用來處理轉(zhuǎn)換工作。轉(zhuǎn)換的會(huì)話使用job系統(tǒng)進(jìn)行管理。如果需要的轉(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)個(gè)每個(gè)頁面都使用了他們自己定制的Twice緩存系統(tǒng)。Twice扮演的角色是輕量級反向代理服務(wù)器和模板系統(tǒng)的合并角色。思路是對每一個(gè)用戶，緩存每一個(gè)頁面，然后將每個(gè)頁面的更新再并入其中。使用Twice以后，每個(gè)進(jìn)程每秒可以處理150條請求，同時(shí)可以在后臺處理10-20個(gè)請求，這就擴(kuò)展了7-10倍之前的服務(wù)器可以處理的網(wǎng)頁的數(shù)量。大部分動(dòng)態(tài)網(wǎng)頁訪問都在5ms以內(nèi)。Twice有一個(gè)插件結(jié)構(gòu)，所以它可以支持應(yīng)用程序的一個(gè)特點(diǎn)，例如添加地理信息。

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

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

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

4.Justin.TV 對所有的操作都做了監(jiān)控.每一個(gè)點(diǎn)擊，查看頁面和每一個(gè)動(dòng)作都被記錄下來，這樣就可以不斷提高服務(wù)。前端，網(wǎng)絡(luò)呼叫或者一個(gè)應(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ù)器。它使用相同緩沖引擎，通過擴(kuò)展網(wǎng)站來擴(kuò)展他們的API.

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

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

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

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

網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)設(shè)計(jì)

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

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

開發(fā)和部署

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

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

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

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

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

Puppet管理配置文件。每個(gè)小的改動(dòng)基本上就是一個(gè)實(shí)驗(yàn)。他們會(huì)追蹤每個(gè)對核心文件的改動(dòng)的影響和之前的版本。這些測試很重要，因?yàn)橥ㄟ^它他們可以找出哪些改動(dòng)是真正提高他們關(guān)心的指標(biāo)。 #p# 

Justin.TV的未來

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

學(xué)到的東西

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

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

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

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

最重要的一件事是理解你的網(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)進(jìn)行合理的分配的系統(tǒng)。

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

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

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

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

不要擔(dān)心將東西劃分到更多的可擴(kuò)展塊中去。例如，與其使用一個(gè)100,000人的頻道，不如將他們劃分到更多的社會(huì)和可擴(kuò)展的頻道去。

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