# Justin.tv 的實時視頻廣播架構 > 原文： [http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html)  未來是活的。 未來是實時的。 未來是現在。 無論如何，這是炒作。 由于它有做事的習慣，因此炒作正逐漸成為現實。 我們正在看到實時搜索，實時推文，實時位置，實時現實增強，實時螃蟹（新鮮和本地）以及實時事件發布。 所有直播技術中最具挑戰性的一項是直播視頻廣播。 想象一下一個世界，每個人都是實時的廣播人和視頻流的使用者（< 250 毫秒延遲），所有這些使您可以直接進行對話和交互，而不會感到自己處于時移之中 戰爭。 實現這一目標所需的資源和工程必須足夠。 你是怎樣做的？ 為了找到答案，我與 Justin.tv 創始人兼工程副總裁 Kyle Vogt 進行了交談。 Justin.tv 當然有這個數字。 據報道，他們每月有 3000 萬獨立訪問者在視頻上傳游戲中的表現甚至超過了 YouTube，據報道每分鐘上傳視頻的時間比 You??Tube 的 23 小時多了近 30 小時。我在聽了另一位 Justin Kan 的[采訪后要求接受采訪 同名](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) [Justin.tv](http://www.justin.tv) 的創始人。 賈斯汀（Justin）談到實況視頻與 YouTube 的批處理視頻方法有本質的區別，后者將所有視頻存儲在磁盤上，然后按需播放。 實時視頻無法通過更快地推送視頻來制作，它采用了完全不同的架構。 由于 [YouTube 體系結構](http://highscalability.com/youtube-architecture)文章是該網站上最受歡迎的文章，因此我認為人們也可能會喜歡學習視頻世界的現場知識。 凱爾（Kyle）投入大量時間和洞察力，對賈斯汀（Justin.tv）如何使所有實時視頻魔術發生的事情產生了極大的興趣，遠遠超出了通話范圍，提供了大量多汁的細節。 任何構建系統的人都可以從他們的業務運作中學習到一些東西。 我非常感謝 Kyle 忍受著我永無止境的努力。 隨著重點從批處理轉移到實時，Justin.tv 正在采取的步驟在整個行業中也正在發生。 我們基本上已經學習了如何創建可伸縮的批處理系統。 實時性需要不同的架構。 例如，LinkedIn 已花費大量精力來構建[實時搜索](http://thenoisychannel.com/2010/01/31/linkedin-search-a-look-beneath-the-hood/)，即使對于復雜的查詢，該查詢也幾乎是即時更新的。 他們通過在內存中對數據進行分區并編寫自己的高度專業化的系統來使其工作來實現此目的。 Google 也許是實時更改的完美典范。 當 Google 有點笨拙時，他們每個月都會懶惰地更新搜索索引。 這是一個批處理模型，這意味著需要設計用于存儲大量數據的基礎結構，這需要高吞吐量而不是低延遲。 時代變了。 現在，谷歌大肆宣傳[咖啡因](http://www.theregister.co.uk/2009/08/14/google_caffeine_truth)和[不斷更新](http://cacm.acm.org/magazines/2010/3/76283-gfs-evolution-on-fast-forward/fulltext)。 他們必須進行許多架構更改，并徹底改革其堆棧，以支持延遲至關重要的面向客戶的應用程序（例如 Gmail）。 而且，谷歌將不是唯一必須學習如何處理新實時技術的公司。 ## 信息來源 1. Justin.tv 創始人兼工程副總裁 Kyle Vogt 訪談。 2. [賈斯汀·坎（Justin Kan）著作加布里埃爾·溫伯格（Gabriel Weinberg）的著作](http://www.gabrielweinberg.com/blog/2010/03/justin-kan-on-getting-traction.html) 3. [AWS Kyle Vogt 的啟動項目](http://www.slideshare.net/tracylaxdal/justintv-aws-the-startup-project)。 這是 3 年前的 Justin.tv 的體系結構。 4. [內部實時視頻服務 Justin.tv](http://www.building43.com/videos/2010/01/12/inside-live-video-service-justin-tv) 。 Robert Scoble 對 Justin.tv 市場營銷副總裁 Evan Solomon 的采訪。 ## 平臺 1. 兩次-自定義 Web 緩存系統。 （http://code.google.com/p/twicecache/） 2. XFS-文件系統。 3. HAProxy-軟件負載平衡。 4. LVS 堆棧和 ldirectord-高可用性。 5. Ruby on Rails-應用程序服務器 6. Nginx-Web 服務器。 7. PostgreSQL-用于用戶和其他元數據的數據庫。 8. MongoDB-用于其內部分析工具。 9. MemcachedDB-用于處理高寫入數據，例如視圖計數器。 10. Syslog-ng-日志記錄服務。 11. RabitMQ-用于作業系統。 12. 木偶-用于構建服務器。 13. Git-用于源代碼控制。 14. Wowza-Flash / H.264 視頻服務器，以及許多用 Java 編寫的定制模塊。 15. Usher-用于播放視頻流的自定義業務邏輯服務器。 16. S3-小圖像存儲。 ## 統計資料 1. 4 個數據中心遍布全國。 2. 在任何給定時間，都會有近 2,000 個傳入流。 3. 每天每分鐘增加 30 個小時的視頻。 4. 每月有 3000 萬獨立訪問者。 5. 平均實時帶寬約為每秒 45 吉比特。 每日峰值帶寬約為 110 Gbps。 最大峰值是 500 Gbps。 6. 基于商用硬件的大約 200 臺視頻服務器，每個服務器都可以發送 1Gbps 的視頻。 比大多數 CDN 小，但比大多數視頻網站大。 7. 每周可節省約 100TB 的檔案存儲空間。 8. 觀看者開始失去實時交談和交互功能之前，完整的視頻路徑的延遲不得超過 250 毫秒。 ## 實時視頻架構  1. 為什么直播視頻很難？ 似乎您只需要很多帶寬，將其全部保留在內存中，將流重新排序，就可以完成了。 簡單。 沒那么簡單。 如果您不能僅通過 YouTube 更快地處理實時視頻，是什么使實時視頻成為挑戰？ 1. 實時視頻不會打 h，這意味著您無法超額訂閱帶寬。 當 YouTube 從訂閱帶寬開始時。 他們在 8 個演出管道中有 10 個演出的流量。 那行得通，因為玩家只需要緩沖即可。 使用實時視頻，即使您超出網絡容量一秒鐘，也可以讓每個觀眾同時觀看所有視頻。 如果您的需求超出容量，它將無法正常工作，每個人都會不斷看到緩沖。 擁有網絡容量非常重要，他們必須做正確的事情。 因此，他們提出了他們的對等架構。 如果需要，它們還具有比所需可用容量更多的容量。 2. 當 CDN 溢出時，它們會優雅地溢出到 CDN。 有時它們確實會用完容量，并且努力地努力使 CDN 溢出。 Usher 處理此邏輯。 一旦容量不足，新的觀看者將被發送到 CDN。 3. 建筑系統似乎具有 100％的正常運行時間，但能夠將機器緩慢地逐步停產以進行維護。 當觀眾可以迅速注意到任何問題并立即通過聊天與每個人談論時，這是非常困難的。 使用聊天功能，沒有隱藏問題。 用戶對服務的期望很高，因此必須妥善處理問題。 他們必須等到每個人都使用完服務器后才能進入維護模式。 旋轉速度非常慢。 會話永不中斷。 您通常的網站可能會有一些錯誤，很少有人會注意到。 2. 當許多人想同時觀看同一件事時，他們最大的問題就是控制閃光燈人群。 這是巨大的傳入流量。 因此，他們需要創建一種在所有視頻服務器和數據中心之間實時調整負載的方法。 該機制就是 Usher。 3. Usher 是他們創建的自定義軟件，用于管理負載均衡，身份驗證和其他播放流的業務邏輯。 Usher 會計算要發送每個流的服務器數量，以確保始終保持最佳負載。 這是他們的特殊調味料，也是使他們的系統與眾不同的地方。 它基于以下因素實時決定如何將流復制到服務器： 1. 特定數據中心的負載量。 2. 所有服務器的單獨負載。 3. 延遲優化。 4. 流可用的服務器列表。 5. 您的 IP 地址，以了解您來自哪個國家。 6. 您在其路由數據庫中的 IP 地址，以查看他們是否與您的 ISP 對等。 7. 請求來自哪個數據中心，他們嘗試將您發送到同一數據中心中的視頻服務器。 4. 使用這些指標，Usher 可以優化純成本，以將您發送到免費的服務器，或者將您發送到最接近要優化其延遲和性能的服務器。 他們有很多撥盤可以轉動，并且具有非常精細的控制。 5. 每個服務器都可以充當邊緣服務器（視頻在其中流傳輸到查看器）和原始服務器（視頻在其中從廣播公司流式傳輸）。 根據負載，流可能在網絡中的一臺服務器或每臺服務器上可用。 這是一個動態且不斷變化的過程。 6. 服務器之間如何復制流的連接看起來像一棵加權樹。 流的數量不斷采樣。 如果某個流具有很高的新傳入查看器速度，則該流將被復制到其他幾個服務器。 然后重復該過程，建立樹形結構，可能包括網絡中的所有服務器。 此過程僅需三秒鐘即可執行。 7. 從命中原始服務器到將其復制到其他服務器以及將其復制到觀眾時，整個視頻流都保留在內存中。 不涉及磁盤路徑。 8. 過去，Flash 盡可能使用 RTMP 協議進行訪問。 每個流都有一個獨立的會話。 由于該協議，它相當昂貴。 不使用多播或 P2P 技術。 下游 ISP 不支持多播。 他們確實考慮過在內部使用多播在服務器之間復制流，但是由于他們可以控制網絡并在內部擁有大量廉價的帶寬，因此沒有太多好處。 由于它們的算法已經過優化，可以在每臺服務器上放置最少數量的流，因此在精細級別上也很難做到。 這比獲得的收益要復雜得多。 9. 通過 HTTP 請求，使用 Usher 來決定使用哪個視頻服務器來處理流。 視頻服務器相當笨，控制服務拓撲的疊加邏輯由 Usher 管理。 10. 最初始于 AWS，然后移至 Akamai，然后移至其自己的數據中心。 1. 之所以離開 AWS 是因為：1）成本； 2）網絡太慢，無法滿足他們的需求。 實時視頻占用大量帶寬，因此擁有快速，可靠，一致，低延遲的網絡至關重要。 使用 AWS，您無法控制這些因素。 您的服務器運行在一個共享的網絡上，該網絡被過度訂閱，它們的速度不能超過 300 Mbps。 他們非常喜歡動態擴展和云 API 的功能，但無法解決性能和成本問題。 2. 三年前，他們使用以下各種解決方案計算的每位客戶成本：CDN $ .135，AWS $ .0074 數據中心$ .0017。 CDN 成本有所下降，但其數據中心成本卻大致相同。 11. 具有多個數據中心的目的不是為了冗余，而應盡可能與所有[主要對等交換](http://en.wikipedia.org/wiki/Peering)（“管理上獨立的 Internet 網絡的自愿互連，目的是為了在每個客戶之間交換流量” 網絡”）。 他們選擇了該國最好的地理位置，因此可以接觸到最多的同行。 1. 節約成本。 這意味著它們的大部分流量不會花任何錢，因為它們直接連接到其他網絡。 2. 性能提升。 它們直接連接到所謂的“眼球”網絡。 眼球網絡是指網絡中有許多有線/ DSL 用戶的網絡。 與 Justing.tv 主要為最終用戶提供流量相比，與“內容”網絡（如 CDN，其他網站等）進行對等互連更有意義。 它們距網絡僅一跳之遙，這對于性能非常有用。 在大多數情況下，這些安排都是免費的，沒有人支付任何錢，您只需掛上電話即可。 12. 他們有一個骨干網絡來獲取數據中心之間的視頻流。 13. 查找對等方的選擇過程是選擇愿意與之對等的人。 很難找到合作伙伴。 14. 批量購買時，帶寬計費非常復雜且不規范。 他們按 90％和 95％的百分比計費，而不是實際使用率。 15. 雖然沒有從磁盤流式傳輸視頻流，但視頻已存檔到磁盤。 原始服務器是為處理傳入流而選擇的服務器，它將流記錄在本地磁盤上，然后將該記錄上載到長期存儲中。 1. 視頻的每一秒都會被記錄和存檔。 2. 存檔存儲看起來就像 YouTube，只是一堆磁盤。 XFS 用作文件系統。 3. 這種體系結構將廣播的寫入傳播到整個服務器。 同時編寫數千個流需要大量的工作。 4. 默認情況下，流將保留 7 天。 用戶可以手動指定可以永久存儲的剪輯。 5. 視頻文件可以輕松地跨磁盤分區。 16. 他們的操作系統已經過優化，可以應付大量的閃存，因為閃存給系統帶來了很大壓力。 網絡堆棧已調整為每秒處理大量傳入連接。 由于它們沒有大量的磁盤活動，因此不需要進行其他調整。 17. 客戶端參與負載平衡邏輯，這是他們要求使用自己的播放器的原因之一。 TCP 非常擅長處理幾百 kbps 的典型數據速率，因此無需對 TCP 設置進行特殊處理。 18. 視頻服務器的數量似乎很少，因為使用 Usher 可以將每個視頻服務器運行到最大容量。 負載平衡確保它們永遠不會超出其限制。 負載主要在內存中，因此它們可以以最大容量驅動網絡。 19. 一次從 Rackable 購買整個機架的服務器。 他們只是在所有預接線中滾動它們。 20. 添加了實時轉碼功能，可以采用任何格式的流，更改傳輸層和編解碼器，然后以新格式將其流式傳輸。 有一個代碼轉換集群可以處理代碼轉換。 轉碼會話是通過作業系統安排的，該作業系統在集群中產生轉碼會話。 如果需求超過其轉碼服務器場，則它們的所有服務器都可以是轉碼服務器。 21. 對于從繁重的協議轉向使用 HTTP 流的趨勢感到滿意，HTTP 流在現有技術的基礎上可以很好地擴展。 一個問題是沒有重點關注延遲和實時性。 人們忽悠了一下，說它是實時的，如果晚 5 到 30 秒，但是對于成千上萬試圖實時交談和互動的人來說，這是不能正常工作的。 延遲不能超過 1/4 秒。 ## 網絡架構  1. 高峰請求量是其穩態流量的 10 倍。 他們必須能夠處理重大事件。 2. Ruby on Rails 被用作前端。 3. 系統中的每個頁面都使用其自定義的稱為 Twice 的緩存系統進行緩存。 兩次充當輕量級反向代理和模板系統的組合。 想法是緩存每個頁面，然后使合并每個用戶的內容變得容易。 4. 使用兩次，每個進程每秒可以處理 150 個請求，而后端每秒可以處理 10-20 個請求，它們可以服務的網頁數量增加了 7 倍至 10 倍。 超過 95％的頁面超出了緩存的速度。 5. 由于所需的處理量很少，因此大多數動態網頁瀏覽均在 5 毫秒內呈現。 6. Twice 具有插件架構，因此可以支持特定于應用程序的功能，例如： 1. 添加地理信息。 2. 查找兩次高速緩存密鑰或 MemcacheDB 密鑰。 3. 自動緩存用戶名等數據，而無需觸摸應用程序服務器。 7. 兩次量身定制，以適應他們的需求和環境。 如果啟動一個新的 Rails 應用程序，一位工程師認為使用 Varnish 可能是一個更好的主意。 8. Web 流量由一個數據中心提供。 其他數據中心在那里提供視頻。 9. 他們已經添加了對所有內容的監視。 每次點擊，頁面瀏覽和操作都會得到衡量，以幫助改善服務。 來自前端，Web 調用或來自應用程序服務器的日志消息將轉換為 syslog 消息，并通過 syslog-ng 轉發到單個日志主機。 他們掃描數據，將其加載到 MongoDB 中，然后在 MongoDB 上運行查詢。 10. 他們的 API 由與網站相同的應用服務器提供。 它使用相同的緩存引擎，因此可以通過擴展網站來擴展 API。 11. PostegreSQL 是他們的主要數據庫。 具有主控器和一組讀取從屬器的結構很簡單。 12. 對于他們的網站類型，他們沒有太多的寫作。 緩存系統處理讀取。 13. 他們發現 PostgreSQL 不能很好地處理大量的少量寫入，這確實使它陷入困境。 因此，MemcachedDB 用于處理高寫入數據，例如視圖計數器。 14. 他們有一個聊天集群來處理其聊天功能。 如果您轉到某個頻道，則會被發送到五個不同的聊天服務器。 縮放聊天比縮放視頻更容易，因為它是文本并且可以很好地分區。 人們可以分成不同的房間，可以在不同的服務器上使用。 他們也沒有與 10 萬觀看頻道的人聊天。 他們所做的是將人員分配到每個 200 人的房間中，以便您可以在較小的組中進行有意義的互動。 這也有助于縮放。 我認為這是一個非常聰明的策略。 15. AWS 用于存儲配置文件圖像。 他們沒有建立任何可以存儲很多小圖像的東西，因此使用 S3 更容易。 它非常方便，而且成本也不高，因此沒有理由花時間在上面。 如果確實有問題，他們會處理。 它們的圖像經常使用，因此非常易于緩存，沒有長尾巴問題要處理。 ## 網絡拓撲與設計 1. 網絡拓撲非常簡單且平坦。 每個服務器在機架頂部都有兩個 1 gig 卡。 每個機架有多個 10 gig 接口連接到核心路由器。 對于交換機，他們發現了 Dell Power Edge 交換機，它對 L3（TCP / IP）并不是很好，但是對 L2（以太網）則很好。 一整天它將推動每個交換機 20 個演出，而且非常便宜。 核心路由器是 Cisco 6500 系列。 把事情簡單化。 他們希望最小化跳數以最小化等待時間，并且還最小化每個數據包的處理量。 Usher 處理所有訪問控制和其他邏輯，而不是網絡硬件。 2. 使用多個數據中心來利用對等關系，并能夠將流量盡可能移近用戶。 3. 大量的對等和與其他網絡的互連。 多個提供程序的供應商，因此他們可以選擇最佳路徑。 如果他們發現某個網絡出現擁塞，則可以選擇其他路由。 他們可以查看 IP 地址，查看時間并找出 ISP。 ## 開發與部署 1. Puppet 用于從裸機構建服務器。 他們有大約 20 種不同類型的服務器。 從數據庫從站到內存緩存框的任何內容。 有了 Puppet，他們可以將盒子變成想要的東西。 2. 他們有兩個軟件團隊。 一個是產品團隊，另一個是基礎架構團隊。 團隊非常平坦，每個團隊大約有七八個人。 每個團隊都有一名產品經理。 3. 他們通常聘請通才，但確實有網絡架構和數據庫專家。 4. 使用基于 Web 的部署系統，可以在幾分鐘之內將任何分支機構推入階段或生產。 5. 質量檢查必須先簽字才能投入生產。 通常需要 5 到 10 分鐘。 6. Git 用于源代碼控制。 他們喜歡您可以編寫一個分支（20 或 30 行功能），并將其與當前正在生產的其他所有分支合并。 事情是非常獨立和模塊化的。 您可以輕松地撤回與 Subversion 相適應的某些功能，在該版本中，您必須撤回整個提交，而提交某些非違規代碼的任何人都不走運。 7. 每隔幾天，每個人都會嘗試合并到 master 分支中，以消除沖突。 8. 他們發布了許多小功能：每天生產 5 到 15 個部署！ 范圍表格 1 行錯誤修復可用于更大的實驗。 9. 數據庫模式升級是手工完成的。 ActiveRecord 遷移的功能強大的版本可在其復制的數據庫中工作。 在將變更部署到生產中之前，有許多不同的登臺環境在其中進行測試。 10. 配置文件更改由 Puppet 處理。 11. 每個功能基本上都是實驗。 他們正在跟蹤病毒性和對所做的每項重大更改的保留。 這是一個實驗，因為他們試圖找出哪些更改實際上可以改善他們關注的指標。 ## 未來 他們的目標是增長一個數量級。 為此，他們計劃進行以下更改： 1. 分割他們的視頻元數據系統。 元數據負載隨流的數量和服務器的數量呈指數增長，因此隨著分片的增長，需要擴展以擴展。 正在考慮卡桑德拉。 2. 分割其 Web 數據庫。 3. 為災難恢復目的而構建其主數據中心的副本。 ## 得到教訓 1. **建立與購買**。 過去，他們在構建自己的產品或購買現成的東西時做出了許多錯誤的決定。 例如，當他們確實應該購買時，他們首先構建了視頻服務器。 軟件工程師喜歡構建定制的軟件，但是使用開源社區維護的軟件有很多好處。 因此，他們提出了一個更好的決策流程： 1. 這個項目活躍嗎？ 保持？ 打補丁？ 2. 有人在用嗎？ 你能問別人如何修改嗎？ 3. 可擴展性很重要。 他們通常需要進行更改。 4. 如果我們可以自己構建，可以更快地構建它，獲得更好的性能，還是獲得我們需要的某些功能？ 這是一個滑坡，因為可以隨時使用 feature 參數自行構建它。 現在，與 Usher 一樣，他們考慮是否可以在另一個系統的外部和頂部構建功能。 在相對笨拙的視頻服務器之上構建 Usher 作為其視頻可伸縮性的核心主干，是該策略的一個很好的例子。 2. **擔心您所??做的事情，而不是別人在做什么**。 他們的目標是擁有最好的系統，最多的運行時間和完善的可伸縮性。 開發該技術以處理數百萬個同時廣播需要花費 3 年的時間。 3. **不要外包**。 您學到的東西的價值在于經驗。 不在代碼或硬件中。 4. **將所有內容視為實驗**。 衡量一切。 拆分測試。 跟蹤。 測量。 這很值得。 從頭開始。 做好儀器。 例如，他們將＃標簽附加到復制的 URL 上，以便告訴您是否共享鏈接。 他們從沒有測量到過度測量的時期。 通過改寫廣播過程，他們將轉換率提高了 700％。 他們希望網站能夠快速響應，以使頁面加載速度更快，從而更好地提供視頻。 從系統中擠出的每毫秒延遲都會帶來更多廣播公司。 他們希望進行 40 個實驗，以使用戶成為廣播公司。 對于每個實驗，他們希望隨后查看廣播公司的保留率，廣播公司的病毒性，轉換率，然后做出明智的決定以進行更改。 5. **最重要的是要了解如何共享您的站點并對其進行優化**。 通過減少共享鏈接所需的菜單深度，他們能夠將共享增加 500％。 6. **峰的增長速度不及其他峰**快。 提供 10 倍的總視頻觀看次數，只需要將系統縮放 3 到 4 倍即可。 7. **使用本地可互換零件**。 使用通用的構建基塊和基礎結構意味著可以響應動態負載立即重新利用系統。 8. **確定重要內容并執行**。 網絡容量非常重要，從一開始他們就必須做些事情。 9. **運行系統熱**。 利用系統的全部容量。 為什么要把錢放在桌子上？ 構建可以通過適當分配負載來響應負載的系統。 10. **不要將時間花在無關緊要的**上。 如果它非常方便且成本不高，則沒有理由花時間在上面。 對配置文件圖像使用 S3 是此策略的一個示例。 11. **支持用戶他們想做的事情，而不是您認為他們應該做的事情**。 Justin.tv 的最終目標似乎是使每個人都成為廣播公司。 他們正在嘗試通過在用戶進行實驗時盡可能多地擺脫用戶的方式來盡可能簡化該過程。 在此過程中，他們發現游戲是一個巨大的用例。 用戶喜歡捕獲 Xbox 輸出并直播并談論它。 您可能不會想到要納入業務計劃的內容。 12. **峰值負載**的設計。 如果您只是為穩定狀態而設計，那么在出現峰值負載時，您的站點將被壓碎。 在現場視頻中，這通常是一件大事，如果您搞砸了，很多人都會散布關于您的壞話。 為峰值負載進行設計需要其他技術水平以及在架構上做正確的事情的意愿。 工程問題。 13. **使網絡架構保持簡單**。 使用多個數據中心。 使用繁重的對等和網絡互連。 14. **不要害怕將事情分成更多可擴展的塊**。 例如，與其在聊天頻道上擁有 100,000 個人，不如將他們分成更具社交性和可擴展性的組。 15. **實時系統無法向用戶隱藏任何內容，這可能很難說服用戶您的站點可靠**。 用戶由于與實時系統保持不斷的互動，因此他們會注意到每個問題和每個故障。 你不能躲藏 大家注意。 每個人都可以實時就發生的事情相互交流。 當用戶經常遇到問題時，用戶很快就會發現您的網站存在問題。 很難說服人們您的站點可靠。 在這種情況下，與用戶進行交流變得更加重要。 從頭開始建立可靠性，質量，可伸縮性和性能； 并設計盡可能簡單且無痛苦的用戶體驗。 ## 相關文章 1. [YouTube 體系結構](http://highscalability.com/youtube-architecture)。 2. [熱門新趨勢：通過廉價的 IP VPN 而非私有線路鏈接云](http://highscalability.com/blog/2009/6/30/hot-new-trend-linking-clouds-through-cheap-ip-vpns-instead-o.html) 3. [凝視數據中心知識](http://www.datacenterknowledge.com/archives/category/peering/) 4. [Internet 對等知識中心](http://drpeering.net/a/Home.html) -關于對等的非常酷的圖表和論文。 5. [創業時的生活](http://abstractnonsense.com/life-at-a-startup/)，作者 Bill Moorier。 托德，很棒的文章。 感謝您的信息。 史詩般的帖子。 有了對最重要（對我而言）網站之一的驚人見解，您就使這個書呆子感到非常高興，我很高興:-)他們提供了出色的服務，其背后的技術令人 jaw 目結舌，但仍然證實了 KISS 的設計 原理。 榮譽！ 此頁面（http://blog.justin.tv/about/）顯示了他們的媒體服務器是用 python 編寫的，并且他們正在使用 Twisted 聊天服務器。 這仍然準確嗎？ 很棒的帖子！ 很棒的文章。 謝謝！ 很棒的文章，謝謝分享。 出色的寫作。 我很好奇誰管理他們的“ Usher”系統？ 誰可以轉動它支持的所有旋鈕？ 知道有關基于 Web 的源部署系統的更多詳細信息將很有趣。 它是定制的還是一些現有的產品？ 他們有多少個系統管理員？ 他們使用哪種 Linux（？）發行版？ nginex 是用作反向代理還是常規的直接 http Web 服務器？ 他們對 flash / h264 / html5 視頻標簽/ ogg theora 有何想法？ 哦，還有，他們說他們使用 Amazon S3 托管小型圖像，是僅使用 S3 還是 S3 + CloudFront？ 您提到 Jtv 成功的“數字”大多被夸大了，因為大量的“觀看者”從未直接訪問該站點，而是通過諸如 ATDHE.net 之類的站點進入。 所有這些所謂的查看器永遠不會看到任何 Jtv 廣告，也不屬于 Jtv 聊天的一部分。 相反，他們是虛假的觀眾，似乎 Jtv 迫切希望增加其數字... 謝謝你的好帖子.. 這可能是我讀過的有關可擴展性的最佳文章。 賈斯汀真的成了流媒體的圣地。 有趣的寫...有時有點沉重！ 我最基本的觀察是廣播是關于傳輸/路由的，而本文在這方面有點過分……似乎主要集中在服務器端的考慮因素和負載平衡上。 當然這些很重要，但是當廣播（實時或回放內容）是關鍵考慮因素時，它們并不是最重要的。 只有 200 臺服務器如何處理如此龐大的客戶群和極端的流媒體？ 關于哪種硬件有任何詳細信息嗎？ 本文只討論對等和帶寬，沒有具體介紹 Usher 和如何平衡 200 臺服務器上的多個流。