# Twitter 如何每秒處理 3,000 張圖像 > 原文： [http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html)  今天，Twitter 正在每秒創建并永久保存 3,000 張（200 GB）圖像。 更好的是，由于媒體存儲政策的改進，2015 年 Twitter 節省了 600 萬美元。 并非總是如此。 2012 年的 Twitter 主要基于文本。 霍格沃茨沒有在墻上掛滿所有酷炫的動態圖像。 現在是 2016 年，Twitter 已經進入了一個擁有豐富媒體的未來。 Twitter 已通過開發新的*媒體平臺*進行了過渡，該平臺可支持帶有預覽的照片，多張照片，gif，藤蔓和嵌入式視頻。 Twitter 的軟件開發工程師 [Henna Kermani](https://www.linkedin.com/in/henna-kermani-27701146) 在 [Mobile @上進行了有趣的演講，講述了媒體平臺的故事 倫敦規模](https://www.atscalelondon.co.uk/) ： [每秒 3,000 張圖像](https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/) 。 演講主要集中在圖像管道上，但她說大多數細節也適用于其他形式的媒體。 這次演講中一些最有趣的教訓： * **做可能可行的最簡單的事情確實會使您陷入困境**。 上載帶有圖像的 tweet 的簡單方法是“全有或全無”操作，是一種鎖定形式。 它的伸縮性不好，尤其是在網絡較差的情況下，這使得 Twitter 很難添加新功能。 * **解耦**。 通過將媒體上傳與推文脫鉤，Twitter 能夠獨立地優化每種途徑，并獲得了極大的運營靈活性。 * **移動不處理斑點**。 請勿在系統中傳輸大量數據。 它占用了帶寬，并為每個必須處理數據的服務帶來了性能問題。 而是存儲數據并使用句柄引用它。 * 移至**分段可恢復上傳**導致媒體上傳失敗率大大降低。 * **實驗和研究**。 Twitter 通過研究發現，圖像變體（縮略圖，小圖，大圖等）的 20 天 TTL（生存時間）是一個最佳選擇，在存儲和計算之間取得了很好的平衡。 映像在 20 天后被訪問的可能性很小，因此可以將其刪除，**每天節省近 4TB 的數據存儲量**，**幾乎減少了一半** **所需的計算服務器數量** ，每年可節省數百萬美元。 * **按需**。 可以刪除舊的圖像變體，因為它們可以即時重新創建而不是預先計算。 按需執行服務可提高靈活性，使您對執行任務的方式更加了解，并提供集中控制點。 * **漸進 JPEG** 作為標準圖像格式是真正的贏家。 它具有強大的前端和后端支持，并且在速度較慢的網絡上表現非常出色。 Twitter 走向富媒體的未來之旅中發生了很多美好的事情，讓我們了解一下他們是如何做到的... ## 舊方法-2012 年的 Twitter ### 寫入路徑 * 用戶在應用程序中撰寫推文，并可能在其中附加圖像。 * 客戶端將推文發布到整體端點。 該圖像將與所有其他推特元數據捆綁在一起上傳，并傳遞到流程中涉及的每個服務。 * 此端點是舊設計中很多問題的根源。 * **問題＃1** ：大量浪費的網絡帶寬 * 發推文的創建和媒體上載緊密地結合到一個操作中。 * 正在上傳，上傳完全成功或完全失敗。 由于任何原因導致的故障，網絡故障，瞬時錯誤等，都要求整個上傳過程從頭開始重新啟動，包括媒體上傳。 上傳可以完成 95％，如果失敗，則必須重新上傳所有內容。 * **問題 2** ：對于新的較大尺寸的介質，無法很好地擴展 * 這種方法無法擴展到視頻等大型媒體。 較大的文件會增加失敗的可能性，尤其是在巴西，印度，印度尼西亞等新興市場中，網絡緩慢且不可靠的地方，他們確實希望提高推文上傳成功率。 * **問題 3** ：內部帶寬使用效率低下 * 連接到 TFE 的終結點，即 Twitter 前端，用于處理用戶身份驗證和路由。 用戶被路由到圖像服務。 * 圖像服務與 Variant Generator 對話，后者生成不同大小（例如小，中，大，縮略圖）的圖像實例。 這些變體存儲在 BlobStore 中，BlobStore 是為大型有效負載（如圖像和視頻）優化的鍵值存儲。 這些圖像永遠存在。 * 創建和保留推文的過程中還涉及許多其他服務。 因為端點是整體的，將媒體與推文元數據結合在一起，所以該捆綁包也流經所有服務。 如此大的有效負載被傳遞給了不直接負責處理圖像的服務，它們不是媒體管道的一部分，但仍被迫對其進行優化以處理大型有效負載。 這種方法在內部帶寬方面效率很低。 * **問題 4** ：膨脹的存儲空間 * 來自不再需要幾個月和幾年的推文中的圖像將永遠存在于 BlobStore 中，從而占用了空間。 即使有時刪除推文時，圖像也會保留在 BlobStore 中。 沒有垃圾收集。 ### 讀取路徑 * 用戶看到一條推文以及與之相關的圖像。 圖片從何而來？ * 客戶端從 CDN 請求圖像的變體。 CDN 可能需要詢問圖像的來源 TFE。 這最終將導致在 BlobStore 中直接查找特定大小的 URL 的圖像。 * **問題 5** ：不可能引入新的變體 * 設計不是很靈活。 添加新的變體，即大小不同的圖像，將需要為 BlobStore 中的每個圖像回填新的圖像大小。 沒有隨需應變的設施。 * 缺乏靈活性使 Twitter 很難在客戶端上添加新功能。 ## 新方法-2016 年的 Twitter ### The Write Path #### 將媒體上傳與發帖分離。 * 上傳的內容為頭等公民。 創建了一個上傳端點，唯一的責任是將原始媒體放入 BlobStore * 這在處理上傳方式方面提供了很大的靈活性。 * 客戶端與 TFE 對話，TFE 與 Image Service 對話，后者將圖像放入 BlobStore 中并將數據添加到元數據存儲中。 而已。 沒有涉及其他隱藏服務。 沒有人在處理媒體，沒有人在傳遞媒體。 * 從圖像服務返回 mediaId（媒體的唯一標識符）。 當客戶想要創建推文，DM 或更新其個人資料照片時，mediaId 將用作引用媒體的句柄，而不是提供媒體。 * 假設我們要使用剛剛上傳的媒體創建一條推文。 流程如下： * 客戶端點擊更新端點，并在發布中傳遞 mediaId； 它將到達 Twitter 前端； TFE 將路由到適合于所創建實體的服務。 對于推文，它是 TweetyPie。 DM 和配置文件有不同的服務； 所有服務將與圖像服務對話； 圖像服務器具有處理諸如人臉檢測和兒童色情檢測之類的功能的后處理隊列。 完成此操作后，Image Service 會與 ImageBird 取得圖像或與 VideoBird 取得視頻； ImageBird 將生成變體； VideoBird 將進行一些轉碼； 生成的任何媒體都將放入 BlobStore。 * 沒有媒體通過。 節省了大量浪費的帶寬。 #### 分段的可恢復上傳。 * 走進地鐵，在 10 分鐘后出來，上傳過程將從停止的地方恢復。 對用戶而言是完全無縫的。 * 客戶端使用上載 API 初始化上載會話。 后端將為它提供一個 mediaId，該 ID 是整個上傳會話中要使用的標識符。 * 圖像分為多個部分，例如三個部分。 使用 API??附加細分，每個附加調用給出細分索引，所有附加都針對相同的 mediaId。 上載完成后，上載完成，可以使用媒體了。 * 這種方法對于網絡故障更具彈性。 每個細分都可以重試。 如果網絡由于任何原因而掉線，您可以暫停并取回網絡恢復時停在的網段。 * 具有巨大收獲的簡單方法。 對于> 50KB 的文件，巴西的圖像上傳失敗率下降了 33％，印度為 30％，印度尼西亞為 19％。 ### The Read Path #### 推出了名為 MinaBird 的 CDN 原始服務器。 * MinaBird 可以與 ImageBird 和 VideoBird 對話，因此，如果不存在圖像大小變體和視頻格式變體，則可以即時生成它們。 * MinaBird 在處理客戶端請求方面更流暢，更動態。 例如，如果有《數字千年版權法案》下架，則很容易阻止訪問或重新啟用對特定媒體的訪問。 * Twitter 能夠即時生成變體和代碼轉換，因此 Twitter 在存儲方面更加聰明。 * 按需變量生成意味著不需要將所有變量存儲在 BlobStore 中。 巨大的勝利。 * 原始圖像將保留直到刪除。 變體僅保留 20 天。 Media Platform 團隊針對最佳有效期限進行了大量研究。 所有請求的圖像中大約有 50％的時間最多為 15 天左右。 保留比這更舊的圖像會導致收益遞減。 沒人會要求使用較舊的媒體。 15 天后尾巴很長。 * 由于沒有 TTL（生存時間），沒有過期，因此媒體存儲每天的存儲量每天增長 6TB。 這種按需生成所有變體的惰性方法導致每日存儲增長 1.5TB。 20 天的 TTL 使用的存儲空間不多于惰性方法，因此在存儲空間上并不需要花費太多，但是在計算方面卻是一個巨大的勝利。 使用懶惰的方法來計算讀取的所有變體將需要每個數據中心使用 150 臺 ImageBird 機器，而使用 20 天 TTL 則需要 75 臺左右。 因此 20 天的 TTL 是最佳選擇，可以在存儲和計算之間取得良好的平衡。 * 由于節省存儲空間和計算就是節省資金，2015 年 Twitter 通過引入 20 天 TTL 節省了 600 萬美元。 #### 客戶端改進（Android） * 使用 Google 創建的圖像格式 [WebP](https://en.wikipedia.org/wiki/WebP) 進行了為期 6 個月的實驗。 * 圖像平均比相應的 PNG 或 JPEG 圖像小 25％。 * 鋸增加了用戶的參與度，尤其是在新興市場中，在新興市場中，較小的圖像尺寸會減輕網絡壓力。 * iOS 不支持。 * 僅在 Android 4.0+上受支持。 * 缺乏平臺支持使 WebP 的支持成本很高。 * 漸進 JPEG 是 Twitter 嘗試的另一種選擇。 它在連續掃描中呈現。 第一次掃描可能是塊狀的，但是它將通過連續掃描進行完善。 * 更好的性能。 * 易于在后端支持。 * 的編碼速度比傳統 JPEG 慢 60％。 由于編碼只會發生一次，而投放會發生多次，因此這不是一個大問題。 * 不支持透明，因此保留了透明的 PNG，但是其他所有內容都在漸進 JPEG 上收斂。 * 在客戶端， [Facebook 的 Fresco](https://github.com/facebook/fresco) 庫提供了支持。 關于壁畫有很多很好的話要說。 2G 連接的結果令人印象深刻。 首次掃描 PJPEG 僅需要大約 10kb，因此加載時間不會很長。 本機管道仍在等待加載，什么也沒有顯示，而 PJPEG 正在顯示可識別的圖像。 * 正在 tweet 詳細信息視圖中進行負載實驗的結果。 p50 加載時間減少了 9％。 p95 加載時間減少了 27％。 故障率降低了 74％。 連接速度較慢的用戶確實會獲得巨大的成功。 ## 相關文章 * [關于 HackerNews](https://news.ycombinator.com/item?id=11535418) * [Twitter 用來處理 1.5 億活躍用戶，300K QPS，22 MB / S Firehose 的架構，并在 5 秒內發送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) * [Twitter 如何使用 Redis 進行擴展-105TB RAM，39MM QPS，10,000 多個實例](http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html) * [DataSift 架構：每秒 120,000 條推特的實時數據挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) “今天，Twitter 正在每秒創建并保留 3,000（200 GB）圖像。” 與...不同 “ Twitter 可以創建大約 3,000 張獨特的圖像，并每秒傳輸大約 200 GB 的圖像。” 請不要更改其含義。 我并不是要批評/挑剔這是什么引人入勝的文章，但是在開始的段落中 200GB 的數字不是很清楚–它顯示為 200GB /秒：“每秒可保留 3,000（200 GB）圖像” 。 除非我缺少任何東西，否則這似乎是不正確的。 對于 3000 張圖像，相當于 200GB，它們將需要很大的文件（每個?68mb），而且每天 6TB 的存儲量（無 TTL）將不可用（在 200GB /秒的情況下，它們需要更多 16PB /天，沒有 TTL）。 我已經嘗試過數學運算，我能得到的最合邏輯的是：200GB /分鐘，這將使我們平均獲得 1.3MB /圖像，這看起來更準確，但是仍然是 281TB /天。 如果有人可以弄清楚我是不是愚蠢還是真正的價值應該是很棒的。 我認為 200GB 包含必要的復制。 因此，200GB 可能至少是圖像原始大小的 3 倍。 另外，Twitter 可能需要每個圖像有多個版本，例如 縮略圖，原始圖片等。每個都有不同的分辨率。 這就增加了很多存儲空間。 無論 Twitter 進行多少復制，仍然很難相信一張圖像可能會占用約 66 MB。 數字/單位在這里肯定是錯誤的。 哦，這應該是“ Twitter 可以創建約 3,000 個唯一圖像，每秒傳輸約 200 GB 圖像。” 正如第一個評論試圖指出的那樣。 原始來源：https://code.facebook.com/posts/1566627733629653/mobile-scale-london-recap/ 沒有狗屎夏洛克，這些都是眾所周知的技術，對不起，沒什么有趣的。 你好 好吧，我記得自 2011 年該版本于 2011 年發布以來，我認為客戶端改進版并沒有在 Android 4.0+上受支持的任何問題。 因此，可能每個人都擁有較年輕的版本。 這句話的意思很清楚：“ Twitter 可以創建大約 3,000 個唯一的圖像，并每秒傳輸大約 200 GB 的圖像。” “創建大約 3,000 張獨特的圖像”：如果以 3 種不同的尺寸保存圖像，則用戶將上傳 1,000 張圖像。 “每秒傳輸大約 200 GB 的圖像”：并不是說它們存儲 200 GB 的圖像。 但是他們傳輸 200 GB。 這意味著它們每秒可交付 200 GB 的圖像。 他們是否將圖像存儲兩次？ 圖片服務將圖片上傳到 Blob 存儲并返回 mediaId。 mageBird 將生成變體； VideoBird 將進行一些轉碼； 生成的任何媒體都將放入 BlobStore。