海量小文件導(dǎo)致高并發(fā)、大流量問題的探討
在互聯(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)過(guò)我們大量研究，實(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ì)超過(guò)200T，單臺(tái)squid只是杯水車薪，頻繁的Cache置換更是加劇了Cache效率低下，再加上現(xiàn)有的存儲(chǔ)系統(tǒng)無(wú)法有效管理海量小文件，并且在單個(gè)目錄下存放文件的數(shù)量有一定的限制，一旦文件數(shù)到達(dá)了一定規(guī)模之后，文件的檢索速度就急劇下降。我們只能通過(guò)多級(jí)目錄來(lái)組織存放大量的小文件，隨著目錄深度的增加，文件的檢索開銷進(jìn)一步增大，檢索效率隨之下降。
3、大量的cache導(dǎo)致的磁盤IO問題。
由于目前單臺(tái)Cache容量已經(jīng)達(dá)到上百G，文件系統(tǒng)瓶頸、磁盤IO問題也很快凸顯。
4、壓力過(guò)大導(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做反向代理。部分代碼如下：
- upstream img{
- server squid1:81;
- server squid2:81;
- hash $request_uri;
- hash_again 0; # default 0
- hash_method crc32; # default “simple”
- }
- server {
- listen 80;
- server_name images.gx.com;
- location / {
- proxy_pass http://img;
(3)負(fù)載均衡軟件，我們選擇了LVS+HA，用DR模式。目前我們運(yùn)行環(huán)境中的LVS（2.6的內(nèi)核），普通很穩(wěn)定。我們主要用Heartbeat+ldirectord。
(4) 適合處理小文件的文件系統(tǒng)XFS。XFS最佳表現(xiàn)之一在于：象ReiserFS一樣，它不產(chǎn)生不必要的磁盤活動(dòng)。XFS設(shè)法在內(nèi)存中緩存盡可能多的數(shù)據(jù)，并且，通常僅當(dāng)內(nèi)存不足時(shí)，才會(huì)命令將數(shù)據(jù)寫到磁盤時(shí)。當(dāng)它將數(shù)據(jù)清倉(cāng)（flushing）到磁盤時(shí)，其它IO操作在很大程度上似乎不受影響。
(5)其它優(yōu)化
在客戶端和服務(wù)器做大量有效的緩存策略;用更小的并且可緩存的圖片（單張圖片盡量不要超過(guò)200K）;盡量減少http請(qǐng)求;開起 keepalive減少tcp連接開銷;優(yōu)化tcp參數(shù);起用多域名分域名策略;減少cookie影響等。
(6)關(guān)于優(yōu)化題外：大配置和架構(gòu)沒有問題的前提下，有money的話應(yīng)該首選硬件優(yōu)化方案而不是軟件細(xì)節(jié)優(yōu)化。
整個(gè)架構(gòu)如圖
后端存儲(chǔ)垂直分割的規(guī)則如下(按00-ff散列)：
- location ~ ^/[0-1][0-f]/ {
- proxy_pass http://192.168.3.12;
- }
- location ~ ^/[2-3][0-f]/ {
- proxy_pass http://192.168.3.11;
- }
- ……..
以上這個(gè)架構(gòu)的優(yōu)化在于：
◆實(shí)現(xiàn)了高可用性，最大程度上防止單點(diǎn)，又保證架構(gòu)的伸縮性。
◆在后端服務(wù)器中模擬url hash的算法來(lái)找到內(nèi)容所在的squid，提高了命中率。
◆充分發(fā)揮機(jī)器的性能，架構(gòu)可擴(kuò)展性，層次分明。
最后，很重要的二點(diǎn)：
1）要通過(guò)性能分析和監(jiān)控，來(lái)找到系統(tǒng)瓶頸的臨界點(diǎn)和薄弱點(diǎn)。監(jiān)控分析是一切優(yōu)化的重點(diǎn)，要以數(shù)據(jù)事實(shí)來(lái)調(diào)整策略。
2）架構(gòu)的負(fù)荷如果已經(jīng)超過(guò)設(shè)計(jì)負(fù)荷的5~10倍，就要考慮重新設(shè)計(jì)系統(tǒng)的架構(gòu)，我們這里僅僅討論某一階段的架構(gòu)設(shè)計(jì)。
【編輯推薦】
