Twitter是如何做到每秒处理3000张图片的?
文:?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张图片的?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 深度卷积网络CNN与图像语义分割
- 下一篇: 深度学习系列:深度学习在腾讯的平台化和应