文：?How Twitter Handles 3,000 Images Per Second?
編譯：?孫薇?
責編：?錢曙光，關注架構和算法領域，尋求報道或者投稿請發郵件qianshg@csdn.net，另有「CSDN 高級架構師群」，內有諸多知名互聯網公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備注姓名+公司+職位。

如今，Twitter每秒可以創建并保存3000張（20GB）的圖片。2015年，Twitter甚至從對媒體存儲策略的優化中節省出了600萬美元。

但并非一開始就是這樣的，2012年Twitter還主要是基于文本的，就像《哈利波特》中的霍格沃茨魔法學校沒有了那些懸掛在墻上的炫酷活動照片一樣。如今已經是2016年，Twitter已進入了富媒體未來時代。在新媒體平臺發展的過程中，Twitter可以支持照片預覽、多張照片、gif圖、Vine短片以及在線視頻。

Twitter的軟件開發工程師Henna Kermani在Mobile @Scale London的談話中提及，這個媒體平臺每秒能夠處理3000張圖片。雖然這次談話的主要話題是討論圖片管道，但她表示其中的大多細節也適用于其他的媒體類型。

這次談話所總結的心得中，一些最有趣的內容摘錄如下：

• 按照可能奏效的最簡單方式來執行，結果真的會讓你大吃一驚：?發送一條帶圖片的推特是一個要么全有要么全無的操作，最簡單的方式就是鎖定。由于無法很好地擴展，尤其是網絡狀況不佳的情況下，Twitter很難再增加新功能。

• 分離處理：?將發推與發送媒體分離，通過解耦的方式來處理，Twitter便可分別優化各個途徑，同時還能大幅增進操作靈活性。

• 移動handle（句柄），而不要移動blob（二進制大對象）：?不要在系統中執行大塊的數據移動，這樣會消耗掉帶寬，并導致接觸到數據的各個服務有性能上的問題。請存儲數據，并使用handle來引用。

• 改用分段的、可恢復的上傳操作能夠大幅降低媒體上傳的失敗率。

• 實驗與研究：?Twitter在研究中發現：將各類圖片變體（縮略圖、小圖、大圖等）的TTL（存活時間）設為20天可以讓存儲與計算達到最有效、最優秀的平衡。圖片在20天之后的訪問概率很低，刪除后每天能節省下來的存儲空間幾乎有4TB——達到計算服務器需要數值的近乎一半，這樣做之后每年能節省數百萬美元。

• 按需操作：?我們可以刪除舊圖片的變體，是因為它們能在瞬間完成重建，而無需預計算。根據需求來執行服務能夠增加靈活性，并在任務執行的方式上更為智能，控制時也更集中化。

• 漸進式JPEG（Progressive JPEG）是標準圖片格式的真正優勝者：不但前端和后端對其支持都很優秀，在速度較慢的網絡中，這類圖片的效果也很好。?
  在Twitter發展為富媒體未來的過程中，有許許多多好事發生，讓我們來一一解讀。

過去——2012年的Twitter

寫入方式

• 用戶在應用中編輯一條推文，或許再附上一張圖片。

  • 客戶端將這條帶圖推文發送給單一整體式端點。上傳時，推文中的圖片和其他元數據是捆綁在一起，發送給過程中所涉及的單體服務的。

  • 在舊式設計中，端點就是諸多問題產生的根源。

• 問題一：?浪費大量帶寬

  • 創建一條推文與上傳媒體，兩者在一個操作中緊密耦合。

  • 上傳的動作是一個整體，要么全部成功，要么全部失敗。無論失敗的原因是什么——網絡臨時中斷、暫時出錯等等，都需要將整個過程從頭來過，包括要重新上傳媒體。如果在上傳到95%的時候出現故障而導致失敗，就必須重新再次上傳。

• 問題二：?對較大的新型媒體來說，缺乏良好的擴展

  • 這種辦法缺乏針對大型媒體，比如視頻的擴展性。媒體越大，失敗的可能性也越大，特別是在IT業的新興市場，比如巴西、印度、印尼等地，由于網速慢、網絡可靠性差，這個問題更加嚴重，確實很需要增加上傳的成功率。

• 問題三：?內部帶寬的使用效率低下

  • 終端與TFE（Twitter前端）相連，而TFE則負責用戶身份驗證，并將用戶分配到不同圖片服務器（Image Service）。

  • 圖片服務器與圖片變體生成器（Variant Generator ）會話，并生成不同大小的圖片實例（比如小圖、中圖、大圖、縮略圖）。圖片變體存儲在BlobStore中，這是一個針對類似圖片和視頻等大型有效載荷而優化的key-value存儲系統，存儲在其中的圖片是永久性的。

  • 創建及保存推文的過程中，還涉及了許多其他服務。由于終端是單一整體式的，媒體與推文的元數據結合在一起，也會流經所有的服務。這個大型有效載荷被發送給直接負責圖片的服務，這些服務并不屬于媒體管道，但仍被強制執行大型有效載荷的優化。這種辦法在內部帶寬中效率非常低。

• 問題四：?臃腫的存儲空間

  • 推文中的圖片在數月或數年后已經不再會被調用了，但仍存于BloStore中占用空間。有時甚至在推文被刪除后，圖片仍存在于BlobStore中，缺乏垃圾回收機制。

讀取方式

• 用戶查看推文以及相關聯的圖片。圖片的來源是哪里？

• 客戶端從CDN請求圖片的變體，這個CDN可能需要向原點與Twitter前端請求圖片，最終導致在BlobStore中直接查找特定大小、特定URL上的圖片。

• 問題五：?不可能引入新的變體

  • 設計上不夠靈活，增加新的變體也就是不同尺寸的圖片的話，需要在BlobStore中為每張圖片回填新的圖片大小，缺乏按需增加變體的機制。

  • 由于缺乏靈活性，Twitter很難在客戶端新增功能。

現在——2016年的Twitter

寫入方式

將上傳與發推解耦。

• 上傳被設置為首要的，上傳終端建立后，唯一的職責就是將原始媒體放在BlobStore中。

• 給上傳方式增加了許多靈活性。

• 客戶端與TFE會話，TFE與圖片服務器會話，圖片服務器將圖片放置在BlobStore中，并向元數據存儲添加數據，就是這樣，沒有其它相關的隱藏服務。

• 媒體ID（mediaId）是媒體唯一的標識符，由圖片服務器返回。如果用戶在客戶端想要創建推文、DM或者上傳個人資料照片時，系統會使用mediaID作為媒體的引用句柄，而不是直接使用媒體本身。

• 假設我們想要用剛剛上傳的媒體來創建推文，流程如下：

  • 客戶端找到更新端點，在推文中加入mediaId；這些內容會被發送到Twitter前端；Twitter前端會將其引入合適的服務中，來執行創建。對于推文來說，使用的服務是TweetyPie，而DM和個人資料會使用其它服務；所有服務都會與圖片服務器對話；圖片服務器上有推文處理隊列機制，可以執行類似人臉檢測與兒童色情檢測之類的功能；檢測完成后，圖片服務器與負責圖片的ImageBird或者負責視頻的VideoBird會話；ImageBird會生成圖片變體；VideoBird會執行一些轉碼工作；無論如何，生成的媒體都會被放在BlobStore上。

  • 不會直接發送媒體本身，從而節省了大量之前被浪費的帶寬。

分段可恢復的上傳：

• 用戶走進地鐵，沒有信號；10分鐘后出來，信號恢復，這時上傳過程會從斷開的地方自動恢復。對于用戶來說整個過程是無縫的。

• 客戶端通過上傳API來初始化上傳進程，后端會發給它一個mediaId，在整個上傳進程中，這個mediaId都會被用作標識符。

• 一張圖片被分為幾部分，比如三個部分。通過API來append每個部分，每個append調用都會有段索引，所有append的mediaId都是相同的。上傳完成后，意味著上傳過程終結，媒體可供使用。

• 這個辦法更能適應網絡故障的情況，每個單獨的部分都可以重試，如果網絡由于某種原因而產生中斷，那么暫停上傳，等待網絡恢復后繼續該部分的上傳。

• 簡單的方法帶來了巨大的收益。對大于50KB的文件，圖片上傳的故障率在巴西高達33%，在印度高達30%，在印尼則為19%。

讀取方式

引入了名為MinaBird的CDN源服務器（Origin Server ）。

• MinaBird可以與ImageBird、VideoBird對話，因此如果沒有的話，可以立即生成相應大小的圖片及視頻格式。

• MinaBird在執行客戶端請求時，更為動態也更為流暢。比如因為版權問題而需要將某個內容屏蔽，使用MinaBird可以很容易地對特定某條媒體執行屏蔽及恢復的操作。

• 能夠實時生成需求大小的圖片與視頻格式轉碼，Twitter在存儲上的智能性也更高了。

  • 按需生成要求的媒體變體意味著無需在BlobStore中存儲所有的變體。這是一個巨大的勝利。

  • 原始媒體直到刪除前都存儲在BlobStore中，而變體只保存20天。媒體平臺團隊做了很多關于最佳保存時限的研究，所有請求的圖片中，大約50%只保存15天，按收益率遞減結果，刪除較早的圖片。很舊的媒體很可能沒有人會發起相應的請求，在15天后會有很長的長尾期。

  • 如果不設定TTL（存活時間）和過期時間，每天增加的媒體存儲量有6TB。懶辦法就是按需生成所有媒體變體，導致媒體存儲增長為1.5TB。20天TTL所使用的存儲空間比懶辦法多不了多少，因此不會占用太大的存儲空間，但在計算上這是一個巨大的勝利。使用懶辦法來計算，讀取所有變體需要在每個數據中心設置150個ImageBird，而使用20天TTL的話，只需要75個ImageBird。因此20天TTL是令計算和存儲達到最有效、最平衡的時間點。

  • 由于節省存儲空間和計算資源就是節省金錢，引入20天TTL之后，在2015年Twitter節省下了600萬美元。

客戶端優化（安卓）

• 在使用WebP（谷歌創建的一種圖片格式）進行了6個月的實驗之后，

  • 這種圖片比相應的PNG或JPEG圖片要小25%。

  • 這樣一來，特別是在新興市場，由于較小的圖片對網絡壓力也較小，因而用戶參與度也更高。

  • 由于不支持iOS系統，并且只支持安卓4.0以上的系統，缺少平臺的支持使得WebP格式花費巨大。

• 于是Twitter嘗試了另一個選項，漸進式JPEG格式。由于通過連續掃描的形式來渲染，首次掃描可能是塊狀的，但在連續掃描的過程中會逐漸自我完善。

  • 這種格式的性能更佳。

  • 后端很容易支持。

  • 這種格式比傳統JPEG格式的編碼速度慢了60%，由于一次編碼，多次服務，因此這不算大問題。

  • 漸進式JPEG圖片不支持透明圖片，因此保留了透明的PNG圖片，除此之外其它都使用了漸進式JPEG。

  • 客戶端由Facebook的Fresco庫提供支持，Fresco的優點很多。在2G網絡下，效果令人印象深刻。第一次掃描PJPEG圖片只用了10kb流量，因此加載時間不長，在本地管道還等待加載，什么都沒顯示的時候，PJPEG已經顯示出了可識別的圖像。

  • 有正在進行的實現結果顯示，負載細節如下：減少了9%的P50加載時間，減少了27%的P95加載時間，減少了74%的失敗率，慢速連接的用戶確實能獲得極大改善。

2016年5月13日-15日，由CSDN重磅打造的2016中國云計算技術大會（CCTC 2016）將于5月13日-15日在北京舉辦，今年大會特設“中國Spark技術峰會”、“Container技術峰會”、“OpenStack技術峰會”、“大數據核心技術與應用實戰峰會”四大技術主題峰會，以及“云計算核心技術架構”、“云計算平臺構建與實踐”等專場技術論壇。大會講師陣容囊括Intel、微軟、IBM、AWS、Hortonworks、Databricks、Elastic、百度、阿里、騰訊、華為、樂視、京東、小米、微博、迅雷、國家電網、中國移動、長安汽車、廣發證券、民生銀行、國家超級計算廣州中心等60+頂級技術講師，CCTC必將是中國云計算技術開發者的頂級盛會。目前會議門票限時7折（截止至4月29日24點），詳情訪問CCTC 2016官網。

總結

以上是生活随笔為你收集整理的Twitter是如何做到每秒处理3000张图片的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。