# Wistia 如何每小時處理數百萬個請求并處理豐富的視頻分析 > 原文： [http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html](http://highscalability.com/blog/2015/11/23/how-wistia-handles-millions-of-requests-per-hour-and-process.html) <iframe align="RIGHT" height="188" src="https://www.youtube.com/embed/bAEjtLy6G4I?rel=0" style="padding:2px" width="205"></iframe>*這是來自 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的來賓[轉貼](https://scaleyourcode.com/interviews/interview/18)，他在接受 [Max Schnur](https://twitter.com/maxschnur) 采訪時，在 [Wistia [](http://wistia.com/) 。* Wistia 是企業視頻托管。 他們提供像熱圖一樣的視頻分析，并且使您能夠添加號召性用語。 我真的很想了解所有不同組件的工作方式以及它們如何流式傳輸大量視頻內容，因此這是本集重點介紹的內容。 ## Wistia 的堆棧是什么樣的？ 正如您將看到的，Wistia 由不同的部分組成。 以下是支持這些不同部分的一些技術： * [HAProxy](http://www.haproxy.org/) * [Nginx](http://nginx.org/) * [MySQL](https://www.mysql.com/) （共享） * [Ruby on Rails](http://rubyonrails.org/) * [獨角獸](http://unicorn.bogomips.org/)和某些服務在 [Puma](http://puma.io/) 上運行 * [nsq](https://github.com/wistia/nsq-ruby) （他們編寫了 Ruby 庫） * [Redis](http://redis.io/) （正在緩存） * [Sidekiq](http://sidekiq.org/) 用于異步作業 ## 您的規模是多少？ [Wistia](http://wistia.com/) 包含三個主要部分： 1. Wistia 應用程序（用戶登錄并與該應用程序互動的“樞紐”） 2. 酒廠（統計處理） 3. 面包店（轉碼和投放） 以下是一些統計信息： * **每小時加載 150 萬個播放器**（加載一個播放器的頁面計為一個。兩個播放器計為兩個，依此類推……） * **每小時向其 Fastly CDN 發出 1880 萬個高峰請求** * **每小時 740,000 個應用程序請求** * **每小時轉碼 12,500 個視頻** * **每小時 150,000 播放** * **每小時統計 ping 達 800 萬次** 它們在 [Rackspace](http://www.rackspace.com/) 上運行。 ## 接收視頻，對其進行處理然后為它們提供服務會帶來什么挑戰？ 1. **They want to balance quality and deliverability**, which has two sides to it: 1. 原始視頻的編碼派生 2. 知道何時玩哪個衍生品 在這種情況下，衍生產品是視頻的不同版本。 具有不同質量的版本很重要，因為它使您可以減小文件的大小。 這些較小的視頻文件可以以較少的帶寬提供給用戶。 否則，他們將不得不不斷緩沖。 有足夠的帶寬？ 大！ 您可以享受更高質量（更大）的文件。 擁有這些不同的版本并知道何時播放哪個版本對于良好的用戶體驗至關重要。 2. **很多 I / O。** 當用戶同時上傳視頻時，最終將不得不在群集之間移動許多繁重的文件。 這里很多事情都會出錯。 3. **波動率。** 請求數量和要處理的視頻數量均存在波動。 他們需要能夠承受這些變化。 4. **當然，提供視頻也是一個主要挑戰。** 幸運的是，CDN 具有不同類型的配置來幫助實現這一目標。 5. **在客戶端，有很多不同的瀏覽器，設備大小等...** 如果您曾經不得不處理使網站具有響應能力或在較舊的 IE 版本上工作，那么您確切地知道我們 在這里談論。 ## 您如何處理視頻上傳數量的重大變化？ 他們有被稱為 *Primes* 的盒子。 這些 Prime 盒子負責接收用戶上傳的文件。 如果上載開始占用所有可用磁盤空間，則它們可以使用 Chef 食譜啟動新的 Prime。 目前，這是一項手動工作，但通常情況下，他們無法達到極限。 他們有很多空間。  ## 您使用哪種轉碼系統？ 轉碼部分是他們所謂的*面包店*。 面包房由我們剛剛看過的 Prime 組成，可以接收和提供文件。 他們也有一群工人。 工作者處理任務并從上傳的視頻創建派生文件。 這部分需要強壯的系統，因為它非常消耗資源。 多強壯 我們說的是數百名工人。 每個工人通常一次執行兩項任務。 它們都具有 8 GB 的 RAM 和相當強大的 CPU。 工人要進行什么樣的任務和處理？ 他們主要使用 x264 編碼視頻，這是一種快速編碼方案。 通常可以將視頻編碼為視頻長度的一半或三分之一。 視頻還必須調整[的大小](http://www.movavi.com/support/how-to/resizing-video.html)，并且它們需要不同的[比特率](http://help.encoding.com/knowledge-base/article/understanding-bitrates-in-video-files/)版本。 此外，針對不同設備的編碼配置文件也不同，例如 iPhone 的 [HLS](http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Encode-Video-for-HLS-Delivery-95251.aspx) 。 對于同樣也是 x264 編碼的 Flash 派生，這些編碼需要加倍。 ## 上傳視頻并對其進行轉碼的整個過程是什么樣的？ 用戶上傳視頻后，該視頻將排隊并發送給工作人員進行轉碼，然后緩慢地轉移到 S3。 無需立即將視頻發送到 S3，而是將其推送到群集中的 Prime，以便客戶可以立即提供視頻。 然后，在幾個小時內，文件被推到 S3 進行永久存儲，并從 Prime 清除以騰出空間。 ## 處理完視頻后如何將其提供給客戶？ 當您播放 Wistia 上托管的視頻時，您需要請求 embed.wistia.com/video-url，該請求實際上是在播放 CDN（他們使用了幾種不同的 CDN。我只是嘗試了一下，而我通過了 [Akamai](https://www.akamai.com/) ）。 CDN 可以追溯到 Origin，這就是我們剛剛談到的 Prime。 Primes 通過稱為“面包路線”的特殊平衡器運行 HAProxy。 面包路由是位于 Prime 前面并平衡流量的路由層。 Wistia 可能將文件本地存儲在群集中（這將更快地提供服務），而 Breadroute 足夠聰明，可以知道這一點。 如果真是這樣，那么 Nginx 將直接從文件系統提供文件。 否則，它們代理 S3。 ## 您如何分辨要加載的視頻質量？ 這主要是在客戶端決定的。 Wistia 將在用戶點擊播放后立即接收有關用戶帶寬的數據。 在用戶甚至沒有點擊播放之前，Wistia 都會接收有關設備，嵌入視頻的大小以及其他啟發式方法的數據，以確定該特定請求的最佳資產。 僅當用戶進入全屏狀態時才辯論是否要高清。 當用戶第一次單擊播放時，這使 Wistia 有機會不中斷播放。 ## 您怎么知道什么時候不加載視頻？ 您如何監控呢？ 他們擁有稱為 *pipedream* 的服務，他們在應用程序和嵌入代碼中使用該服務來不斷地將數據發送回去。 如果用戶單擊播放，則會獲得有關其窗口大小，窗口所在位置以及是否緩沖的信息（如果它處于播放狀態，但幾秒鐘后時間沒有改變）。 視頻的一個已知問題是加載時間慢。 Wistia 想知道視頻何時加載緩慢，因此他們嘗試為此跟蹤指標。 不幸的是，他們只知道如果用戶實際上在等待負載完成才慢。 如果用戶的連接速度確實很慢，他們可能會在此之前離開。 這個問題的答案？ 心跳。 如果他們收到心跳，卻再也沒有收到游戲，那么用戶可能會保釋。 ## 您還收集其他哪些分析？ 他們還為客戶收集分析數據。 諸如播放，暫停，搜尋，轉化（輸入電子郵件或點擊號召性用語）之類的分析。 其中一些顯示在熱圖中。 他們還將這些熱圖匯總到顯示參與度的圖表中，例如人們觀看和重看的區域。  ## 您如何獲得如此詳細的數據？ 播放視頻時，他們使用視頻跟蹤器，該跟蹤器是綁定到播放，暫停和搜索的對象。 該跟蹤器將事件收集到數據結構中。 每 10 到 20 秒一次，它會回傳至 Distillery，該酒廠又找出如何將數據轉換為熱圖。 為什么每個人都不這樣做？ 我問他，因為我什至沒有從 YouTube 獲得此類數據。 馬克斯說，原因是因為它非常密集。 釀酒廠處理大量的東西，并擁有一個龐大的數據庫。  （ *http://www.cotswoldsdistillery.com/First-Cotswolds-Distillery-Opens* ） ## 什么是擴展易用性？ Wistia 擁有約 60 名員工。 一旦開始擴大客戶群，就很難確保繼續保持良好的客戶支持。 它們的最高接觸點是播放和嵌入。 這些因素有很多無法控制的因素，因此必須做出選擇： 1. 不要幫助客戶 2. 幫助客戶，但需要很多時間 這些選擇還不夠好。 取而代之的是，他們追究導致客戶支持問題最多的來源-嵌入式。 嵌入經歷了多次迭代。 為什么？ 因為他們經常破產。 不管是 WordPress 做一些奇怪的嵌入，還是 Markdown 破壞嵌入，隨著時間的推移，Wistia 都遇到了很多問題。 為了解決這個問題，他們最終大大簡化了嵌入代碼。 這些更簡單的嵌入代碼在客戶端遇到的問題更少。 盡管確實在后臺增加了更多的復雜性，但是卻導致了更少的支持請求。 這就是 Max 通過擴展易用性的含義。 使客戶更輕松，這樣他們就不必經常與客戶支持聯系。 即使這意味著更多的工程挑戰，對他們來說也是值得的。 縮放易用性的另一個示例是回放。 Max 確實對實現一種客戶端 CDN 負載均衡器感興趣，該負載均衡器確定了從中提供內容的最低延遲服務器（類似于 Netflix 所做的事情）。 ## 您現在正在從事哪些項目？ Max 計劃很快啟動的就是他們所說的上載服務器。 這個上載服務器將使他們能夠對上載做很多很酷的事情。 正如我們所討論的那樣，對于大多數上載服務，您必須等待文件到達服務器，然后才能開始轉碼并對其進行處理。 上傳服務器將使上傳時可以進行轉碼。 這意味著客戶可以在視頻完全上傳到系統之前就開始播放他們的視頻。 他們還可以獲取靜止圖像并幾乎立即嵌入 ## 結論 我必須嘗試在此摘要中盡可能多地添加信息，而又不要太長。 這意味著我刪去了一些可以真正幫助您的信息。 如果您發現這很有趣，我強烈建議您查看[完整訪談](https://scaleyourcode.com/interviews/interview/18)，因為還有更多隱藏的寶石。 您可以觀看，閱讀甚至收聽。 還有一個下載 MP3 的選項，因此您可以聆聽自己的工作方式。 當然，該節目也在 [iTunes](https://itunes.apple.com/tt/podcast/scale-your-code-podcast/id987253051?mt=2) 和 [Stitcher](http://www.stitcher.com/podcast/scaleyourcode?refid=stpr) 上進行。 Thanks for reading, and please let me know if you have any feedback!- Christophe Limpalair (@ScaleYourCode) 您好，HS 讀者們，我希望您從本集中找到有趣且有用的信息。 在很多（當之無愧的）關注焦點集中在 Netflix 和 YouTube 上的時代，Wistia 感覺就像是一顆隱藏的寶石。 我一直在努力改善演出，因此，我敞開雙臂歡迎任何反饋。 受訪者的建議和一般問題也是如此。 謝謝，享受！ 很棒的帖子... 這些天，每個人都在后端使用 s3，但是為什么他們不使用彈性代碼轉換器？ 您好，感謝您的閱讀/觀看！ RE：為什么我們不使用彈性代碼轉換器。 好吧，如果我們今天要創辦一家視頻托管公司，我們可能最終會使用諸如彈性代碼轉換器或 zencoder 之類的服務。 這是因為要獲得像大規模構建的那樣健壯的系統非常困難，而且這些服務非常好。 但是面包店（我們的轉碼服務）是在彈性轉碼器或 zencoder 出現之前建立的。 而現在，由于這些年來我們投入了大量工作并實施了自動縮放功能，因此它為我們帶來了競爭優勢。 也就是說，我們能夠快速輕松地實施新的編碼方案，并將轉碼與我們的應用程序體驗更加緊密地集成在一起。 例如，我不提一提的服務器允許在仍上傳的同時進行轉碼和回放，這是面包店的特色。 使用任何現有服務都很難做到這一點，但是會極大地改善用戶體驗。 再說一次，我們總是在評估我們的選項，因此，如果有必要將部分或全部轉碼卸載到另一個服務，我們一定會考慮的。 目前，面包店是秘密武器。 :) 嗨，好帖子 看起來您正在 Rackspace 上運行，并且存儲在 S3 上。 為什么不只在 AWS 和 S3 上運行？ 謝謝！