[轉(zhuǎn)]架構(gòu)高性能海量圖片服務(wù)器的技術(shù)要素

在筆者的另一篇文章《nginx性能改進一例》有講到,在圖片規(guī)模比大的情況,nginx處理能力受制于文件系統(tǒng)的io幅疼,意味著,在大規(guī)模圖片的場景昼接,如果運維還依舊采用傳統(tǒng)文件系統(tǒng)的方式爽篷,無論是備份成本,還是前端成本慢睡,將是無法去衡量逐工,不要去指望調(diào)優(yōu)一點文件系統(tǒng)的一些參數(shù),能帶來多大的性能收益一睁,也不要去目錄hash+rewrite的方式钻弄,改進不大,因為新版的文件系統(tǒng)默認開啟了dir_index者吁,解決了同一個目錄下文件過多而過慢的問題窘俺。不過還有一種方案就是采購SSD盤、fusion-io卡之類高性能的硬件去解決隨機io复凳,當然你得容忍備份的痛苦瘤泪。先看一下架構(gòu)圖邏輯圖,這也是現(xiàn)在各大公司采用的方式育八。

這個是一個大致邏輯圖对途,具體布署是根據(jù)模塊的性能消耗類型去混合部署。
第一點髓棋,分布存儲的必要性:存儲原始圖片实檀,用分布式存儲有幾個好處,分布式能自動提供冗余按声,不需要我們?nèi)浞萆庞蹋瑩臄?shù)據(jù)安全,在文件數(shù)量特別大的情況下签则,備份是一件很痛苦的事情须床,rsync掃一次可能是就是好幾個小時。還有一點就是分布式存儲動態(tài)擴容方便渐裂。不過唯一遺憾的是目前適合于存小文件系統(tǒng)比較少豺旬,我了解的只有fastdfs,以及淘寶的tfs柒凉,還有mongodb這幾個族阅,tfs經(jīng)歷過淘寶那種規(guī)模的考驗,文檔和工具都太少扛拨,如果能駕馭tfs耘分,我覺得值得嘗試一下。。

第二點求泰,上傳和下載分開處理:通常圖片服務(wù)器上傳的壓力與下載的壓力相差很大央渣,大多數(shù)的公司都是下載的壓力是上傳壓力的n倍。業(yè)務(wù)邏輯的處理也區(qū)別明顯渴频,上傳服務(wù)器對圖片重命名芽丹,記錄入庫信息,下載服務(wù)器對圖片添加水印卜朗、修改尺寸之類的動態(tài)處理拔第。從數(shù)據(jù)的角度,我們能容忍部分圖片下載失敗场钉,但絕不能有圖片上傳失敗蚊俺,因為上傳失敗,意味著數(shù)據(jù)的丟失逛万。上傳與下載分開泳猬,能保證不會因下載的壓力影響圖片的上傳,而且還有一點宇植,下載入口和上傳入口的負載均衡策略也不同得封,下面有說明。

第三點指郁,使用cache做緩層:分布式存儲解決了存儲安全問題忙上,但性能問題還需要用cache去解決,直接從分布式存儲取文件給用戶提供服務(wù)闲坎,每秒的request高不到哪里去疫粥,像淘寶之類的網(wǎng)站,都做了二層cache腰懂。對于cache的開源軟件選型要考慮二點手形,1,緩存的量級大悯恍,盡可能讓熱點圖片緩存在cache中,像varnish之類的伙狐,純內(nèi)存的cache涮毫,雖然性能很好,但能cache的量級很限于內(nèi)存贷屎,用來做圖片的緩存不太適合罢防;2,避免文件系統(tǒng)式的緩存唉侄,在我的另一篇文章中有測過咒吐,在文件量非常的情況下,文件系統(tǒng)的型能很差,像squid,nginx的proxy_store,proxy_cache之類的方式緩存恬叹,當緩存的量級上來后候生,性能將不能滿足要求。開源的traffic server直接用裸盤緩存绽昼,是一個不錯的選擇唯鸭,當然使用leveldb之類的做緩存,我估計也能達到很好的效果硅确。這里說明一下cache緩存最好不要去依賴第三方CDN目溉,現(xiàn)在很多第三的CDN業(yè)務(wù),不僅提供內(nèi)容分發(fā)外菱农,還額外提供第一個二級緩存之類的服務(wù)缭付,但這里面就一個最大的風險就是如果第三調(diào)整帶來的回源壓力暴增,此時你的架構(gòu)能否支撐循未,需要認真評估一下陷猫,如果成本允許,服務(wù)控制在自己手中最靠譜只厘。

第四點烙丛,使用一致性哈希(consistent hashing)做下載負載均衡:雖公司的業(yè)務(wù)的增加帶來流量的增加,一個階段后羔味,一個cache通常不能解決問題河咽,這時擴容cache就是常做的一件事,傳統(tǒng)的哈希不足就是每擴容一次赋元,哈希策略將重新分配忘蟹,大部分cache將失效,帶來的問題是后端壓力暴增搁凸。對uri進行一性能哈希負載均衡媚值,能避免增加或者減少cache引起哈希策略變化,目前大多開源的負載均衡軟件都有這個功能护糖,像haproxy都有褥芒,至于一致性哈希的最優(yōu)化,可以參考一下下圖(摘自網(wǎng)上的一張圖嫡良,表示的是怎樣的物理節(jié)點和虛擬節(jié)點數(shù)量關(guān)系锰扶,哈希最均勻)。

20150302171929860.png

第五點寝受,利用CDN分發(fā)和多域名訪問入口:想要獲得好的用戶體驗坷牛,利用CDN的快速分發(fā)是有必要的,從成本上考慮可以購買使用第三方的CDN平臺很澄。多域名訪問方式京闰,大多的瀏覽器都對單個域名進行了線程并發(fā)限制颜及,采用多域名能夠加快圖片展示的速度。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末蹂楣,一起剝皮案震驚了整個濱河市俏站,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌捐迫,老刑警劉巖乾翔,帶你破解...
    沈念sama閱讀 212,383評論 6 493
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異施戴,居然都是意外死亡反浓,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,522評論 3 385
  • 文/潘曉璐 我一進店門赞哗,熙熙樓的掌柜王于貴愁眉苦臉地迎上來雷则,“玉大人,你說我怎么就攤上這事肪笋≡屡” “怎么了?”我有些...
    開封第一講書人閱讀 157,852評論 0 348
  • 文/不壞的土叔 我叫張陵藤乙,是天一觀的道長猜揪。 經(jīng)常有香客問我,道長坛梁,這世上最難降的妖魔是什么而姐? 我笑而不...
    開封第一講書人閱讀 56,621評論 1 284
  • 正文 為了忘掉前任,我火速辦了婚禮划咐,結(jié)果婚禮上拴念,老公的妹妹穿的比我還像新娘。我一直安慰自己褐缠,他們只是感情好政鼠,可當我...
    茶點故事閱讀 65,741評論 6 386
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著队魏,像睡著了一般公般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上胡桨,一...
    開封第一講書人閱讀 49,929評論 1 290
  • 那天俐载,我揣著相機與錄音,去河邊找鬼登失。 笑死,一個胖子當著我的面吹牛挖炬,可吹牛的內(nèi)容都是我干的揽浙。 我是一名探鬼主播,決...
    沈念sama閱讀 39,076評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼馅巷!你這毒婦竟也來了膛虫?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,803評論 0 268
  • 序言:老撾萬榮一對情侶失蹤钓猬,失蹤者是張志新(化名)和其女友劉穎稍刀,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體敞曹,經(jīng)...
    沈念sama閱讀 44,265評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡账月,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,582評論 2 327
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了澳迫。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片局齿。...
    茶點故事閱讀 38,716評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖橄登,靈堂內(nèi)的尸體忽然破棺而出抓歼,到底是詐尸還是另有隱情,我是刑警寧澤拢锹,帶...
    沈念sama閱讀 34,395評論 4 333
  • 正文 年R本政府宣布谣妻,位于F島的核電站,受9級特大地震影響卒稳,放射性物質(zhì)發(fā)生泄漏蹋半。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 40,039評論 3 316
  • 文/蒙蒙 一展哭、第九天 我趴在偏房一處隱蔽的房頂上張望湃窍。 院中可真熱鬧,春花似錦匪傍、人聲如沸您市。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,798評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽茵休。三九已至,卻和暖如春手蝎,著一層夾襖步出監(jiān)牢的瞬間榕莺,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,027評論 1 266
  • 我被黑心中介騙來泰國打工棵介, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留钉鸯,地道東北人。 一個月前我還...
    沈念sama閱讀 46,488評論 2 361
  • 正文 我出身青樓邮辽,卻偏偏與公主長得像唠雕,于是被迫代替她去往敵國和親贸营。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 43,612評論 2 350

推薦閱讀更多精彩內(nèi)容