文：?How Twitter Handles 3,000 Images Per Second?
編譯：?孫薇?
責(zé)編：?錢曙光，關(guān)注架構(gòu)和算法領(lǐng)域，尋求報(bào)道或者投稿請(qǐng)發(fā)郵件qianshg@csdn.net，另有「CSDN 高級(jí)架構(gòu)師群」，內(nèi)有諸多知名互聯(lián)網(wǎng)公司的大牛架構(gòu)師，歡迎架構(gòu)師加微信qshuguang2008申請(qǐng)入群，備注姓名+公司+職位。

如今，Twitter每秒可以創(chuàng)建并保存3000張（20GB）的圖片。2015年，Twitter甚至從對(duì)媒體存儲(chǔ)策略的優(yōu)化中節(jié)省出了600萬(wàn)美元。

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

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

這次談話所總結(jié)的心得中，一些最有趣的內(nèi)容摘錄如下：

• 按照可能奏效的最簡(jiǎn)單方式來(lái)執(zhí)行，結(jié)果真的會(huì)讓你大吃一驚：?發(fā)送一條帶圖片的推特是一個(gè)要么全有要么全無(wú)的操作，最簡(jiǎn)單的方式就是鎖定。由于無(wú)法很好地?cái)U(kuò)展，尤其是網(wǎng)絡(luò)狀況不佳的情況下，Twitter很難再增加新功能。

• 分離處理：?將發(fā)推與發(fā)送媒體分離，通過(guò)解耦的方式來(lái)處理，Twitter便可分別優(yōu)化各個(gè)途徑，同時(shí)還能大幅增進(jìn)操作靈活性。

• 移動(dòng)handle（句柄），而不要移動(dòng)blob（二進(jìn)制大對(duì)象）：?不要在系統(tǒng)中執(zhí)行大塊的數(shù)據(jù)移動(dòng)，這樣會(huì)消耗掉帶寬，并導(dǎo)致接觸到數(shù)據(jù)的各個(gè)服務(wù)有性能上的問(wèn)題。請(qǐng)存儲(chǔ)數(shù)據(jù)，并使用handle來(lái)引用。

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

• 實(shí)驗(yàn)與研究：?Twitter在研究中發(fā)現(xiàn)：將各類圖片變體（縮略圖、小圖、大圖等）的TTL（存活時(shí)間）設(shè)為20天可以讓存儲(chǔ)與計(jì)算達(dá)到最有效、最優(yōu)秀的平衡。圖片在20天之后的訪問(wèn)概率很低，刪除后每天能節(jié)省下來(lái)的存儲(chǔ)空間幾乎有4TB——達(dá)到計(jì)算服務(wù)器需要數(shù)值的近乎一半，這樣做之后每年能節(jié)省數(shù)百萬(wàn)美元。

• 按需操作：?我們可以刪除舊圖片的變體，是因?yàn)樗鼈兡茉谒查g完成重建，而無(wú)需預(yù)計(jì)算。根據(jù)需求來(lái)執(zhí)行服務(wù)能夠增加靈活性，并在任務(wù)執(zhí)行的方式上更為智能，控制時(shí)也更集中化。

• 漸進(jìn)式JPEG（Progressive JPEG）是標(biāo)準(zhǔn)圖片格式的真正優(yōu)勝者：不但前端和后端對(duì)其支持都很優(yōu)秀，在速度較慢的網(wǎng)絡(luò)中，這類圖片的效果也很好。?
  在Twitter發(fā)展為富媒體未來(lái)的過(guò)程中，有許許多多好事發(fā)生，讓我們來(lái)一一解讀。

過(guò)去——2012年的Twitter

寫入方式

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

  • 客戶端將這條帶圖推文發(fā)送給單一整體式端點(diǎn)。上傳時(shí)，推文中的圖片和其他元數(shù)據(jù)是捆綁在一起，發(fā)送給過(guò)程中所涉及的單體服務(wù)的。

  • 在舊式設(shè)計(jì)中，端點(diǎn)就是諸多問(wèn)題產(chǎn)生的根源。

• 問(wèn)題一：?浪費(fèi)大量帶寬

  • 創(chuàng)建一條推文與上傳媒體，兩者在一個(gè)操作中緊密耦合。

  • 上傳的動(dòng)作是一個(gè)整體，要么全部成功，要么全部失敗。無(wú)論失敗的原因是什么——網(wǎng)絡(luò)臨時(shí)中斷、暫時(shí)出錯(cuò)等等，都需要將整個(gè)過(guò)程從頭來(lái)過(guò)，包括要重新上傳媒體。如果在上傳到95%的時(shí)候出現(xiàn)故障而導(dǎo)致失敗，就必須重新再次上傳。

• 問(wèn)題二：?對(duì)較大的新型媒體來(lái)說(shuō)，缺乏良好的擴(kuò)展

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

• 問(wèn)題三：?內(nèi)部帶寬的使用效率低下

  • 終端與TFE（Twitter前端）相連，而TFE則負(fù)責(zé)用戶身份驗(yàn)證，并將用戶分配到不同圖片服務(wù)器（Image Service）。

  • 圖片服務(wù)器與圖片變體生成器（Variant Generator ）會(huì)話，并生成不同大小的圖片實(shí)例（比如小圖、中圖、大圖、縮略圖）。圖片變體存儲(chǔ)在BlobStore中，這是一個(gè)針對(duì)類似圖片和視頻等大型有效載荷而優(yōu)化的key-value存儲(chǔ)系統(tǒng)，存儲(chǔ)在其中的圖片是永久性的。

  • 創(chuàng)建及保存推文的過(guò)程中，還涉及了許多其他服務(wù)。由于終端是單一整體式的，媒體與推文的元數(shù)據(jù)結(jié)合在一起，也會(huì)流經(jīng)所有的服務(wù)。這個(gè)大型有效載荷被發(fā)送給直接負(fù)責(zé)圖片的服務(wù)，這些服務(wù)并不屬于媒體管道，但仍被強(qiáng)制執(zhí)行大型有效載荷的優(yōu)化。這種辦法在內(nèi)部帶寬中效率非常低。

• 問(wèn)題四：?臃腫的存儲(chǔ)空間

  • 推文中的圖片在數(shù)月或數(shù)年后已經(jīng)不再會(huì)被調(diào)用了，但仍存于BloStore中占用空間。有時(shí)甚至在推文被刪除后，圖片仍存在于BlobStore中，缺乏垃圾回收機(jī)制。

讀取方式

• 用戶查看推文以及相關(guān)聯(lián)的圖片。圖片的來(lái)源是哪里？

• 客戶端從CDN請(qǐng)求圖片的變體，這個(gè)CDN可能需要向原點(diǎn)與Twitter前端請(qǐng)求圖片，最終導(dǎo)致在BlobStore中直接查找特定大小、特定URL上的圖片。

• 問(wèn)題五：?不可能引入新的變體

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

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

現(xiàn)在——2016年的Twitter

寫入方式

將上傳與發(fā)推解耦。

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

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

• 客戶端與TFE會(huì)話，TFE與圖片服務(wù)器會(huì)話，圖片服務(wù)器將圖片放置在BlobStore中，并向元數(shù)據(jù)存儲(chǔ)添加數(shù)據(jù)，就是這樣，沒(méi)有其它相關(guān)的隱藏服務(wù)。

• 媒體ID（mediaId）是媒體唯一的標(biāo)識(shí)符，由圖片服務(wù)器返回。如果用戶在客戶端想要?jiǎng)?chuàng)建推文、DM或者上傳個(gè)人資料照片時(shí)，系統(tǒng)會(huì)使用mediaID作為媒體的引用句柄，而不是直接使用媒體本身。

• 假設(shè)我們想要用剛剛上傳的媒體來(lái)創(chuàng)建推文，流程如下：

  • 客戶端找到更新端點(diǎn)，在推文中加入mediaId；這些內(nèi)容會(huì)被發(fā)送到Twitter前端；Twitter前端會(huì)將其引入合適的服務(wù)中，來(lái)執(zhí)行創(chuàng)建。對(duì)于推文來(lái)說(shuō)，使用的服務(wù)是TweetyPie，而DM和個(gè)人資料會(huì)使用其它服務(wù)；所有服務(wù)都會(huì)與圖片服務(wù)器對(duì)話；圖片服務(wù)器上有推文處理隊(duì)列機(jī)制，可以執(zhí)行類似人臉檢測(cè)與兒童色情檢測(cè)之類的功能；檢測(cè)完成后，圖片服務(wù)器與負(fù)責(zé)圖片的ImageBird或者負(fù)責(zé)視頻的VideoBird會(huì)話；ImageBird會(huì)生成圖片變體；VideoBird會(huì)執(zhí)行一些轉(zhuǎn)碼工作；無(wú)論如何，生成的媒體都會(huì)被放在BlobStore上。

  • 不會(huì)直接發(fā)送媒體本身，從而節(jié)省了大量之前被浪費(fèi)的帶寬。

分段可恢復(fù)的上傳：

• 用戶走進(jìn)地鐵，沒(méi)有信號(hào)；10分鐘后出來(lái)，信號(hào)恢復(fù)，這時(shí)上傳過(guò)程會(huì)從斷開的地方自動(dòng)恢復(fù)。對(duì)于用戶來(lái)說(shuō)整個(gè)過(guò)程是無(wú)縫的。

• 客戶端通過(guò)上傳API來(lái)初始化上傳進(jìn)程，后端會(huì)發(fā)給它一個(gè)mediaId，在整個(gè)上傳進(jìn)程中，這個(gè)mediaId都會(huì)被用作標(biāo)識(shí)符。

• 一張圖片被分為幾部分，比如三個(gè)部分。通過(guò)API來(lái)append每個(gè)部分，每個(gè)append調(diào)用都會(huì)有段索引，所有append的mediaId都是相同的。上傳完成后，意味著上傳過(guò)程終結(jié)，媒體可供使用。

• 這個(gè)辦法更能適應(yīng)網(wǎng)絡(luò)故障的情況，每個(gè)單獨(dú)的部分都可以重試，如果網(wǎng)絡(luò)由于某種原因而產(chǎn)生中斷，那么暫停上傳，等待網(wǎng)絡(luò)恢復(fù)后繼續(xù)該部分的上傳。

• 簡(jiǎn)單的方法帶來(lái)了巨大的收益。對(duì)大于50KB的文件，圖片上傳的故障率在巴西高達(dá)33%，在印度高達(dá)30%，在印尼則為19%。

讀取方式

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

• MinaBird可以與ImageBird、VideoBird對(duì)話，因此如果沒(méi)有的話，可以立即生成相應(yīng)大小的圖片及視頻格式。

• MinaBird在執(zhí)行客戶端請(qǐng)求時(shí)，更為動(dòng)態(tài)也更為流暢。比如因?yàn)榘鏅?quán)問(wèn)題而需要將某個(gè)內(nèi)容屏蔽，使用MinaBird可以很容易地對(duì)特定某條媒體執(zhí)行屏蔽及恢復(fù)的操作。

• 能夠?qū)崟r(shí)生成需求大小的圖片與視頻格式轉(zhuǎn)碼，Twitter在存儲(chǔ)上的智能性也更高了。

  • 按需生成要求的媒體變體意味著無(wú)需在BlobStore中存儲(chǔ)所有的變體。這是一個(gè)巨大的勝利。

  • 原始媒體直到刪除前都存儲(chǔ)在BlobStore中，而變體只保存20天。媒體平臺(tái)團(tuán)隊(duì)做了很多關(guān)于最佳保存時(shí)限的研究，所有請(qǐng)求的圖片中，大約50%只保存15天，按收益率遞減結(jié)果，刪除較早的圖片。很舊的媒體很可能沒(méi)有人會(huì)發(fā)起相應(yīng)的請(qǐng)求，在15天后會(huì)有很長(zhǎng)的長(zhǎng)尾期。

  • 如果不設(shè)定TTL（存活時(shí)間）和過(guò)期時(shí)間，每天增加的媒體存儲(chǔ)量有6TB。懶辦法就是按需生成所有媒體變體，導(dǎo)致媒體存儲(chǔ)增長(zhǎng)為1.5TB。20天TTL所使用的存儲(chǔ)空間比懶辦法多不了多少，因此不會(huì)占用太大的存儲(chǔ)空間，但在計(jì)算上這是一個(gè)巨大的勝利。使用懶辦法來(lái)計(jì)算，讀取所有變體需要在每個(gè)數(shù)據(jù)中心設(shè)置150個(gè)ImageBird，而使用20天TTL的話，只需要75個(gè)ImageBird。因此20天TTL是令計(jì)算和存儲(chǔ)達(dá)到最有效、最平衡的時(shí)間點(diǎn)。

  • 由于節(jié)省存儲(chǔ)空間和計(jì)算資源就是節(jié)省金錢，引入20天TTL之后，在2015年Twitter節(jié)省下了600萬(wàn)美元。

客戶端優(yōu)化（安卓）

• 在使用WebP（谷歌創(chuàng)建的一種圖片格式）進(jìn)行了6個(gè)月的實(shí)驗(yàn)之后，

  • 這種圖片比相應(yīng)的PNG或JPEG圖片要小25%。

  • 這樣一來(lái)，特別是在新興市場(chǎng)，由于較小的圖片對(duì)網(wǎng)絡(luò)壓力也較小，因而用戶參與度也更高。

  • 由于不支持iOS系統(tǒng)，并且只支持安卓4.0以上的系統(tǒng)，缺少平臺(tái)的支持使得WebP格式花費(fèi)巨大。

• 于是Twitter嘗試了另一個(gè)選項(xiàng)，漸進(jìn)式JPEG格式。由于通過(guò)連續(xù)掃描的形式來(lái)渲染，首次掃描可能是塊狀的，但在連續(xù)掃描的過(guò)程中會(huì)逐漸自我完善。

  • 這種格式的性能更佳。

  • 后端很容易支持。

  • 這種格式比傳統(tǒng)JPEG格式的編碼速度慢了60%，由于一次編碼，多次服務(wù)，因此這不算大問(wèn)題。

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

  • 客戶端由Facebook的Fresco庫(kù)提供支持，Fresco的優(yōu)點(diǎn)很多。在2G網(wǎng)絡(luò)下，效果令人印象深刻。第一次掃描PJPEG圖片只用了10kb流量，因此加載時(shí)間不長(zhǎng)，在本地管道還等待加載，什么都沒(méi)顯示的時(shí)候，PJPEG已經(jīng)顯示出了可識(shí)別的圖像。

  • 有正在進(jìn)行的實(shí)現(xiàn)結(jié)果顯示，負(fù)載細(xì)節(jié)如下：減少了9%的P50加載時(shí)間，減少了27%的P95加載時(shí)間，減少了74%的失敗率，慢速連接的用戶確實(shí)能獲得極大改善。

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。