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

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

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

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

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

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

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

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

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

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

· 漸進(jìn)式JPEG（Progressive JPEG）是標(biāo)準(zhǔn)圖片格式的真正優(yōu)勝者：不但前端和后端對其支持都很優(yōu)秀，在速度較慢的網(wǎng)絡(luò)中，這類圖片的效果也很好。

· 在Twitter發(fā)展為富媒體未來的過程中，有許許多多好事發(fā)生，讓我們來一一解讀。

過去——2012年的Twitter

寫入方式

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

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

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

問題一： 浪費(fèi)大量帶寬

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

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

問題二： 對較大的新型媒體來說，缺乏良好的擴(kuò)展

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

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

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

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

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

問題四： 臃腫的存儲空間

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

讀取方式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這種格式的性能更佳。

后端很容易支持。

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

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

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

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