在互聯(lián)網(wǎng)快速發(fā)展的背景下，特別是Web 2.0，網(wǎng)絡(luò)上的數(shù)據(jù)內(nèi)容呈幾何級(jí)的增長(zhǎng)，而其中增長(zhǎng)最快并且最容易給技術(shù)架構(gòu)帶來(lái)挑戰(zhàn)的就是數(shù)目龐大的小文件，如何來(lái)解決這種高并發(fā)，大流量，小文件，熱點(diǎn)不集中的問題，經(jīng)過我們大量研究，實(shí)踐之后，總結(jié)出這種海量小文件，高并發(fā)所存在的關(guān)鍵問題和解決方案。

　　我們先對(duì)比一下在Web 1.0的解決方案和Web 2.0的我們碰到的困難。

　　Web 1.0解決方案：

　　1、源數(shù)據(jù)量小，單臺(tái)squid即可達(dá)到很高的命中率。

　　2、請(qǐng)求量大，用lvs+squid或者dns輪詢即可解決問題。

　　3、squid服務(wù)器磁盤IO壓力大，用超大內(nèi)存做Cache。

　　Web 2.0目前的瓶頸：

　　1、源數(shù)據(jù)數(shù)量很大，導(dǎo)致squid hash table索引效率不高，Cache命中率低。

　　為了提高對(duì)文件的訪問效率，往往會(huì)在前端配置一個(gè)稍大容量的緩存。但由于小文件的數(shù)量極其龐大，應(yīng)用對(duì)這些文件訪問的隨機(jī)性非常高，使得Cache命中率極低，緩存失去了應(yīng)有的作用，導(dǎo)致應(yīng)用需要直接到后端存儲(chǔ)系統(tǒng)上讀取數(shù)據(jù)，給存儲(chǔ)系統(tǒng)帶來(lái)了極大的壓力。剛開始就是我們也采用了昂貴的高端存儲(chǔ)系統(tǒng)NETApp，但是在用戶高并發(fā)訪問的情況下，存儲(chǔ)系統(tǒng)經(jīng)常出現(xiàn)長(zhǎng)時(shí)間無(wú)響應(yīng)的嚴(yán)重故障。

　　2、源數(shù)據(jù)容量巨大，海量文件檢索效率低，從而也導(dǎo)致單臺(tái)squid命中率很低。

　　有些頻道數(shù)據(jù)容量會(huì)超過200T，單臺(tái)squid只是杯水車薪，頻繁的Cache置換更是加劇了Cache效率低下，再加上現(xiàn)有的存儲(chǔ)系統(tǒng)無(wú)法有效管理海量小文件，并且在單個(gè)目錄下存放文件的數(shù)量有一定的限制，一旦文件數(shù)到達(dá)了一定規(guī)模之后，文件的檢索速度就急劇下降。我們只能通過多級(jí)目錄來(lái)組織存放大量的小文件，隨著目錄深度的增加，文件的檢索開銷進(jìn)一步增大，檢索效率隨之下降。

　　3、大量的cache導(dǎo)致的磁盤IO問題。

　　由于目前單臺(tái)Cache容量已經(jīng)達(dá)到上百G，文件系統(tǒng)瓶頸、磁盤IO問題也很快凸顯。

　　4、壓力過大導(dǎo)致的hit ratio抖動(dòng)。

　　Cache刪除，寫操作達(dá)到一定的比例,同時(shí)如果壓力較高，會(huì)導(dǎo)致hit ratio呈線性下降。即使Cache沒down，但也因?yàn)槊新实南陆刀?yīng)有的作用。

　　5、特殊集群下的單臺(tái)失效問題。

　　在類url hash的集群下，單臺(tái)cache失效會(huì)導(dǎo)致hash rehash，那么整個(gè)集群的squid命中率都會(huì)被沖擊。

　　如何來(lái)解決這些問題，思路如下：

　　1、優(yōu)化squid hash table索引算法，需要修改源squid代碼。

　　2、Cache集群，用類url hash的方法，以增加Cache容量。

　　◆wccp: cisco的路由器均有此功能

　　◆carp: ISA,squid自身的7層調(diào)度協(xié)議

　　◆url hash: nginx haproxy等7層代理

　　3、選擇合適的文件系統(tǒng)

　　XFS使用更多的內(nèi)存來(lái)作為自己的高速緩存，以盡可能的延遲零散的寫操作，盡可能的執(zhí)行批量寫操作。

　　4、選擇更合理的磁盤搭配策略，比如Raid策略或者單盤策略等

　　Raid 5，10帶來(lái)了不錯(cuò)的安全性，但是會(huì)導(dǎo)致磁盤IO效率低下，不做Raid的單盤性能最高，更適合單臺(tái)服務(wù)器多squid進(jìn)程模式。

　　5、集群下的單臺(tái)Cache失效的接管，以免單點(diǎn)故障，提高可用性。

　　針對(duì)以上分析，我們大量嘗試了開源的一些產(chǎn)品，像LVS，Nginx，Squid，XFS等。具體的軟件組合和架構(gòu)如下：

　　(1)Web服務(wù)器的選擇，目前，大多數(shù)Web服務(wù)器的處理能力有限，互聯(lián)網(wǎng)廣泛上使用的Web服務(wù)器如Apache，其并發(fā)能力往往在2000以下，這是由Web服務(wù)器自身的設(shè)計(jì)模式（如多進(jìn)程，無(wú)IO緩存等）決定的。因此，在較大規(guī)模的訪問情況下，通常會(huì)表現(xiàn)出用戶訪問網(wǎng)站慢，Web服務(wù)器負(fù)載高。為什么選擇Nginx?use linux epoll, sendfile and aio to improve the performanc，我們主要利用的是Nginx的第三方模塊ngx_http_upstream_hash_module做反向代理。部分代碼如下：

   1. upstream img{  
   2. server squid1:81;  
   3. server squid2:81;  
   4. hash $request_uri;  
   5. hash_again 0; # default 0  
   6. hash_method crc32; # default “simple”  
   7. }  
   8.  
   9. server {  
  10. listen 80;  
  11. server_name images.gx.com;  
  12. location / {  
  13. proxy_pass http://img;         

        

        
        
      
        
it知識(shí)庫(kù)：海量小文件導(dǎo)致高并發(fā)、大流量問題的探討，轉(zhuǎn)載需保留來(lái)源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。