聯(lián)通系統(tǒng)集成有限公司 北京 100032

1 分布式存儲技術(shù)概述

1.1 分布式存儲概念

運(yùn)用分布式計算技術(shù)把大量標(biāo)準(zhǔn)X86服務(wù)器的本地存儲介質(zhì)進(jìn)行聚合，將這些存儲資源通過網(wǎng)絡(luò)整合為一個既具備傳統(tǒng)SAN/NAS的企業(yè)級功能和特性又具有良好擴(kuò)展性、低成本、高可靠、易用的存儲系統(tǒng)，形成全新的產(chǎn)品類型。目前，市場上絕大部分分布式存儲產(chǎn)品都是由上述形態(tài)構(gòu)成，我們將這一類產(chǎn)品稱為Server SAN。

1.2 分布式存儲的特點

1)良好的擴(kuò)展性。它可以擴(kuò)展到幾百臺甚至幾千臺的集群規(guī)模，容量達(dá)PB級，而且，其擴(kuò)展的方式是漸進(jìn)式的，隨著規(guī)模的增長，系統(tǒng)整體性能表現(xiàn)為線性增長。

2)低成本。由成本低廉的PC服務(wù)器組成的集群在性能方面能夠達(dá)到或超越中高端存儲的性能，在成本上遠(yuǎn)低于中高端存儲。這也是分布式存儲最吸引人之處。但成本低廉的PC服務(wù)器在硬件可靠性方面與大型機(jī)相比相去甚遠(yuǎn)，于是分布式系統(tǒng)由軟件來對硬件進(jìn)行容錯，通過軟件來保證整體系統(tǒng)的高可靠性。

3)高可靠性。通過把數(shù)據(jù)分成2-3個副本負(fù)載分散到眾多的機(jī)器上，單個節(jié)點故障最多只會使一個副本丟失，而其它副本不會受任何影響。理想條件下，某一時刻如果有1/3的節(jié)點出現(xiàn)故障，存儲仍能繼續(xù)工作，只不過損失1/3的性能。另外，線性擴(kuò)展能力也使得增加、減少機(jī)器非常方便，可以實現(xiàn)自動運(yùn)維。

4)易用性。分布式存儲需要能夠提供易用的對外接口，另外，也要求具備完善的監(jiān)控、運(yùn)維工具，并能夠方便地與其他系統(tǒng)集成[1]。

1.3 分布式存儲的關(guān)鍵技術(shù)

對于大多數(shù)分布式文件系統(tǒng)，通常將元數(shù)據(jù)(inode)與數(shù)據(jù)(block)兩者獨立開來，即將控制流與數(shù)據(jù)流進(jìn)行分離，從而獲得更高的系統(tǒng)擴(kuò)展性和I/O并發(fā)性。因而，元數(shù)據(jù)管理架構(gòu)顯得至關(guān)重要，直接影響到系統(tǒng)的擴(kuò)展性、性能、可靠性和穩(wěn)定性等。存儲系統(tǒng)要具有很高的Scale-Out(橫向擴(kuò)展)特性，最大的挑戰(zhàn)之一就是記錄數(shù)據(jù)邏輯與物理位置的映像關(guān)系即數(shù)據(jù)元數(shù)據(jù)，還包括諸如屬性和訪問權(quán)限等信息。特別是對于海量小文件的應(yīng)用，元數(shù)據(jù)問題是個非常大的挑戰(zhàn)?？傮w來說，分布式文件系統(tǒng)的元數(shù)據(jù)管理大致可以分為三種架構(gòu)，即集中式元數(shù)據(jù)架構(gòu)(如Lustre、PVFS、StorNext、GFS等)、分布式元數(shù)據(jù)架構(gòu)(如PanFS、GPFS、Ceph等)和無元數(shù)據(jù)架構(gòu)(最典型的就是GlusterFS)。這三種架構(gòu)各有優(yōu)勢和不足之處，實際系統(tǒng)實現(xiàn)中也難分優(yōu)劣，三種元數(shù)據(jù)架構(gòu)都有各自存在的理由。[2]

1.4 分布式存儲的主流產(chǎn)品

目前，市場上絕大部分Server SAN類型的分布式存儲產(chǎn)品都是由開源的或自研的分布式文件系統(tǒng)+標(biāo)準(zhǔn)X86服務(wù)器+存儲管理軟件來實現(xiàn)的。其中，分布式文件系統(tǒng)包括Ceph、GlusterFS、HDFS、GFS、OpenStack swift、MogileFS、FastDFS、MooseFS以及NFS等，根據(jù)不同應(yīng)用場景，選擇不同分布式文件系統(tǒng)；標(biāo)準(zhǔn)X86服務(wù)器一般會選用硬盤槽位較多的服務(wù)器；存儲管理軟件主要有兩個作用，一是封裝多種協(xié)議供前端設(shè)備訪問，例如iSCSI(塊設(shè)備)、NFS(文件服務(wù))、Amazon S3(對象存儲)等，第二是根據(jù)每個廠商的自身技術(shù)實力，開發(fā)企業(yè)級的存儲功能，例如提升性能的SSD加速、存儲自動分層，數(shù)據(jù)負(fù)載均衡功能，增強(qiáng)可靠性的多副本、糾刪碼、自動修復(fù)功能，提高利用率的去重、壓縮、精簡配置等功能。

2 海量小文件問題

通常我們稱小于1MB的文件為小文件，百萬級數(shù)量及以上稱為海量，由此量化定義海量小文件問題[3]。海量小文件在目前實際中越來越常見，如社交網(wǎng)站、電子商務(wù)、廣電、網(wǎng)絡(luò)視頻、高性能計算，例如以下幾個場景。

1)社交網(wǎng)站Facebook存儲了600億張以上的圖片，推出專門針對海量小圖片定制優(yōu)化的Haystack進(jìn)行存儲。

2)淘寶作為最大的C2C電子商務(wù)網(wǎng)站，存儲超過200億張圖片，平均大小僅為15KB，也推出了針對小文件優(yōu)化的TFS文件系統(tǒng)存儲這些圖片。

3)歌華有線可以進(jìn)行圖書和視頻的在線點播，圖書每頁會掃描成一個幾十KB大小的圖片，總圖片數(shù)量能夠超過20億。

從上述數(shù)據(jù)和近幾年的統(tǒng)計結(jié)果來看，非結(jié)構(gòu)化數(shù)據(jù)的增長趨勢明顯已經(jīng)超過了結(jié)構(gòu)化數(shù)據(jù)。未來，企業(yè)勢必要選擇一種更適合的存儲非結(jié)構(gòu)化數(shù)據(jù)的存儲設(shè)備，這種存儲設(shè)備必須具備良好的橫向擴(kuò)展能力、高可靠性，還要支持大數(shù)據(jù)類的應(yīng)用，并能夠構(gòu)建云計算基礎(chǔ)，同時，它還必須得在合理的成本之內(nèi)。分布式存儲正迅速成為一種可行的方案，因為其擴(kuò)展的上限比集中存儲要高，而且成本更低。

2.1 聯(lián)通集團(tuán)應(yīng)用系統(tǒng)現(xiàn)狀

目前，聯(lián)通集團(tuán)內(nèi)部眾多系統(tǒng)也面臨著海量小文件的問題，以電子商城系統(tǒng)為例，電子商城系統(tǒng)屬于核心系統(tǒng)，其中存儲了眾多用戶信息的圖片文件，文件大小在100k～200k之間，數(shù)量為億級，整體容量約20TB左右。商城系統(tǒng)架構(gòu)如圖1所示。

圖1 聯(lián)通集團(tuán)電子商城架構(gòu)圖

電子商城系統(tǒng)目前分為商城前置機(jī)和商城主存儲兩個部分，商城前置機(jī)部分共有31臺PC服務(wù)器作為前置機(jī)，分別存儲不同營業(yè)廳上傳的近半年的文件，圖片主存儲部分由2臺PC服務(wù)器和1臺終端存儲構(gòu)成，存儲的是過期半年的圖片文件。商城系統(tǒng)的文件上傳和調(diào)閱過程如下。

1)上傳過程。營業(yè)廳的客戶端在上傳時，需要輸入唯一的身份證號，核心系統(tǒng)的應(yīng)用程序會以身份證號碼作為唯一標(biāo)識并根據(jù)上傳文件的營業(yè)廳編碼、日期信息生成一個目錄索引，然后核心系統(tǒng)應(yīng)用程序會將目錄索引寫入到核心系統(tǒng)數(shù)據(jù)庫中。之后核心系統(tǒng)應(yīng)用程序會將圖片按照目錄索引寫入到對應(yīng)的前置機(jī)中存儲起來。由于前置機(jī)的存儲容量有限，6個月之后，前置機(jī)會將6個月以前的數(shù)據(jù)遷移至圖片主存儲中，并通過核心系統(tǒng)應(yīng)用程序修改數(shù)據(jù)中的目錄索引。

2)調(diào)閱過程。營業(yè)廳的客戶端在查閱某一圖片文件時，首先，根據(jù)唯一的身份證號標(biāo)識將向核心系統(tǒng)應(yīng)用程序發(fā)起請求，應(yīng)用程序會在核心系統(tǒng)數(shù)據(jù)庫中查詢圖片的目錄索引。之后，核心系統(tǒng)應(yīng)用程序會根據(jù)索引讀取存在前置機(jī)上或圖片主存儲上的用戶信息文件，并緩存在自己的內(nèi)容緩存中，供客戶端查看。

目前，聯(lián)通電子商城系統(tǒng)主要存在的問題是系統(tǒng)主存儲調(diào)閱時性能不高，主存儲使用的是一臺中低端HDS存儲，本身性能不強(qiáng)，并且還存儲了上億的圖片小文件，而傳統(tǒng)存儲對于海量小文件的支持并不好，因此在查閱主存儲上的文件時性能不是很好，由于文件數(shù)量巨大，從查詢請求發(fā)起到接收到最終結(jié)果，會有3～5秒左右的延遲，這對前端業(yè)務(wù)人員的耐心是一種考驗。

2.2 傳統(tǒng)存儲無法解決海量小文件問題

傳統(tǒng)存儲解決不好海量小文件問題主要有兩方面原因。第一，作為傳統(tǒng)存儲主要使用的存儲介質(zhì)，機(jī)械硬盤本身就不適合隨機(jī)小文件I/O讀寫，機(jī)械硬盤最適合的是順序的大文件I/O讀寫，這是由存儲介質(zhì)自身特性決定的，也是傳統(tǒng)存儲在海量小文件場景下性能表現(xiàn)不佳的最根本原因。第二，傳統(tǒng)存儲大都使用本地文件系統(tǒng)，比如XFS/EXT4、EXT3、EXT2、JFS2、ZFS，這些文件系統(tǒng)是針對機(jī)械硬盤適合大文件I/O特性而設(shè)計的，在I/O訪問流程、空間利用率和元數(shù)據(jù)管理方面都側(cè)重大文件，而在應(yīng)對海量小文件時，由于文件數(shù)量多，傳統(tǒng)文件系統(tǒng)中無法緩存所有inode信息，因此，系統(tǒng)將進(jìn)行頻繁的I/O，這會使讀寫數(shù)據(jù)的速率降低。

2.3 分布式存儲如何解決海量小文件問題

海量小文件由于數(shù)量巨大，又通常需要進(jìn)行共享和并發(fā)訪問，目前主流的解決方案是采用分布式存儲技術(shù)，包括分布式文件系統(tǒng)和分布式對象存儲系統(tǒng)，每個存儲節(jié)點底層采用本地文件系統(tǒng)進(jìn)行管理。

對于分布式存儲而言，通常將元數(shù)據(jù)與數(shù)據(jù)兩者獨立開來，即控制流與數(shù)據(jù)流進(jìn)行分離。元數(shù)據(jù)節(jié)點處理控制流，通常稱為MDC。通過擴(kuò)展元數(shù)據(jù)節(jié)點，可以擴(kuò)展元數(shù)據(jù)的存儲容量、提高元數(shù)據(jù)的并發(fā)訪問能力，從而提升整個系統(tǒng)的I/O并發(fā)能力。數(shù)據(jù)節(jié)點處理數(shù)據(jù)流，通過擴(kuò)展數(shù)據(jù)節(jié)點，可以將數(shù)據(jù)I/O訪問分散到多個數(shù)據(jù)節(jié)點，從而實現(xiàn)容量和性能的整體提升。

相比傳統(tǒng)存儲，分布式存儲可以靈活地調(diào)整元數(shù)據(jù)節(jié)點和數(shù)據(jù)節(jié)點的配比，從而提高空間利用率；對于海量小文件的情況，還可以將元數(shù)據(jù)緩存在多個節(jié)點的SSD或內(nèi)存中，從而提高元數(shù)據(jù)的訪問效率；同時，分布式存儲還可以進(jìn)一步優(yōu)化I/O訪問流程，提升I/O效率。總體上來說，分布式存儲與傳統(tǒng)存儲相比，對海量小文件的優(yōu)化可以更加靈活，有更多可優(yōu)化的手段去適配海量小文件的場景。

分布式存儲邏輯架構(gòu)如圖2所示。

3 如何提高分布式存儲的性能

根據(jù)上述內(nèi)容中對海量小文件問題根源的剖析，結(jié)合Facebook Haystack、淘寶TFS等分布式存儲在海量小文件應(yīng)用方面的優(yōu)化實踐，我們認(rèn)為硬件優(yōu)化、Cache管理優(yōu)化、小文件合并存儲、元數(shù)據(jù)管理優(yōu)化等是幾種行之有效的優(yōu)化方法。

圖2 分布式存儲邏輯架構(gòu)圖

3.1 提高硬件配置

分布式存儲雖然在擴(kuò)展性和靈活性方面比傳統(tǒng)存儲要好，但其由于各個節(jié)點之間必須通過網(wǎng)絡(luò)通信，因此，增加了數(shù)據(jù)訪問的開銷。例如，分布式存儲系統(tǒng)的客戶端與元數(shù)據(jù)服務(wù)器和I/O服務(wù)器之間的網(wǎng)絡(luò)通常為TCP/IP網(wǎng)絡(luò)，網(wǎng)絡(luò)開銷較大，增大了文件訪問的延時。其他方面，服務(wù)器的CPU、內(nèi)存、硬盤等硬件配置也或多或少地會對分布式存儲系統(tǒng)產(chǎn)生影響。

如果不考慮成本問題，硬件優(yōu)化是最為直接有效的優(yōu)化方法，可以采用更高性能的硬件來提高分布式存儲系統(tǒng)的性能。1)使用速度更快的SSD作為全部或部分存儲介質(zhì)，部署時采用數(shù)據(jù)分層存儲或Cache加速，可以顯著提高隨機(jī)讀寫場景下的IOPS性能；2)采用處理能力更強(qiáng)或更多的CPU，可以提高系統(tǒng)的I/O處理速度和并發(fā)性；3)配置更大容量的內(nèi)存，有效提高數(shù)據(jù)緩存命中率；4)采用延遲更小、帶寬更高的網(wǎng)絡(luò)設(shè)備優(yōu)化網(wǎng)絡(luò)傳輸效率，比如萬兆網(wǎng)絡(luò)或Inf i niBand網(wǎng)絡(luò)。

擴(kuò)展硬件設(shè)備時需要注意，硬件設(shè)備在性能上要做到匹配，尤其是磁盤速率和網(wǎng)絡(luò)速率要匹配，例如萬兆網(wǎng)絡(luò)中理論帶寬為1.28GB，SATA3理論速率為600MB左右，如果采用萬兆網(wǎng)絡(luò)+SATA盤，此時系統(tǒng)瓶頸在硬盤處，如果換成SSD盤，就可以消除硬盤的瓶頸。必要時需要調(diào)節(jié)操作系統(tǒng)內(nèi)核參數(shù)，以優(yōu)化通過網(wǎng)絡(luò)接收和發(fā)送數(shù)據(jù)的效率，如表1所示(各參數(shù)的具體數(shù)值需要按照實際項目需求來定)。

表1 操作系統(tǒng)優(yōu)化參數(shù)

3.2 提高元數(shù)據(jù)管理效率

分布式存儲系統(tǒng)架構(gòu)大致分兩種，即有中心架構(gòu)和無中心架構(gòu)。在有中心架構(gòu)的分布式存儲系統(tǒng)中，通常有一個元數(shù)據(jù)服務(wù)器來統(tǒng)一管理元數(shù)據(jù)。而在無中心的架構(gòu)中，元數(shù)據(jù)會分散存儲于各個存儲節(jié)點上，通過哈希算法進(jìn)行管理和定位?？蛻舳嗽谧x寫小文件數(shù)據(jù)前，需要通過與元數(shù)據(jù)服務(wù)器(有中心架構(gòu))或存儲節(jié)點(無中心架構(gòu))進(jìn)行通信，以獲取位置信息，這一過程相當(dāng)于額外增加一次網(wǎng)絡(luò)傳輸開銷和元數(shù)據(jù)服務(wù)訪問開銷。對小文件I/O來說，開銷影響非常大；因此，對于有中心架構(gòu)，元數(shù)據(jù)管理主要從減少元數(shù)據(jù)量、減少元數(shù)據(jù)訪問次數(shù)、提高元數(shù)據(jù)檢索效率幾個方面著手。

在分布式存儲系統(tǒng)中，可以根據(jù)實際應(yīng)用需求，對元數(shù)據(jù)進(jìn)行適當(dāng)精簡，只保留需要的元數(shù)據(jù)信息即可，從而達(dá)到減少元數(shù)據(jù)的目的。例如，在文件命名時，可以加入位置信息；對象存儲系統(tǒng)可以不設(shè)置訪問日期、訪問權(quán)限等元數(shù)據(jù)信息，這樣可以減少元數(shù)據(jù)的存儲量。需要注意的是，精簡元數(shù)據(jù)信息雖然可以帶來性能上的提升，但也會帶來管理上的不便，需要應(yīng)用系統(tǒng)在開發(fā)時統(tǒng)一格式，并且開發(fā)人員要嚴(yán)格遵守制度，從管理上杜絕可能造成的混亂。

另外，元數(shù)據(jù)操作在小文件整個I/O過程中占了大部分時間，可以對多個RPC請求進(jìn)行合并，從而大幅減少對元數(shù)據(jù)訪問次數(shù)。還可以在客戶端對元數(shù)據(jù)進(jìn)行緩存，利用Cache機(jī)制顯著減少元數(shù)據(jù)訪問次數(shù)。

在元數(shù)據(jù)服務(wù)器上或存儲節(jié)點上，元數(shù)據(jù)最終持久化存儲在數(shù)據(jù)庫上或磁盤文件系統(tǒng)目錄上，甚至是單個文件中。為達(dá)到高效的元數(shù)據(jù)檢索，需要使用大容量內(nèi)存和更快速度的磁盤(例如SSD磁盤)，同時，還可以通過多級索引、BloomFilter等減少元數(shù)據(jù)操作過程的I/O訪問次數(shù)，進(jìn)一步加快元數(shù)據(jù)訪問速度。

3.3 優(yōu)化數(shù)據(jù)布局和I/O訪問模式

對于大文件的處理：分布式文件系統(tǒng)往往采用條帶化技術(shù)對大文件進(jìn)行切片，并在多個數(shù)據(jù)服務(wù)器上進(jìn)行存儲，從而提高用戶對文件訪問的并發(fā)性。

對于小文件的處理：由于小文件不利于條帶化，一般采用將單個文件存儲在單個數(shù)據(jù)服務(wù)器上的策略。但當(dāng)小文件數(shù)量達(dá)到一定程度后，對小文件的大量重復(fù)訪問將會給數(shù)據(jù)服務(wù)器帶來性能上的負(fù)擔(dān)。分布式存儲采用將小文件合并存儲的方式來優(yōu)化海量小文件訪問的問題。該策略通過多個邏輯文件共享同一個物理文件，將多個小文件合并存儲到一個大文件中，實現(xiàn)高效的小文件存儲。這種方式將大量的小文件存儲到一個大文件中，把大量的小文件數(shù)據(jù)變成大文件數(shù)據(jù)，減少了文件數(shù)量，從而減少元數(shù)據(jù)數(shù)量，提高了元數(shù)據(jù)的檢索和查詢效率，性能得以顯著提升。小文件的元數(shù)據(jù)和數(shù)據(jù)會一并存儲在大文件中，并形成索引文件，訪問時通過索引進(jìn)行定位。索引文件采用預(yù)加載到Cache的策略，可以實現(xiàn)隨機(jī)讀寫小文件只需要一次I/O。

眾多小文件合并存儲后實際上相當(dāng)于一個微型文件系統(tǒng)，這種機(jī)制對于“一次寫，多次讀”模式的分布式存儲系統(tǒng)非常合適，但不適合“多次寫”的存儲系統(tǒng)。因為文件改寫和刪除操作會使大文件內(nèi)部產(chǎn)生碎片，如何進(jìn)行空間管理并在合適的時候執(zhí)行碎片整理，實現(xiàn)起來比較復(fù)雜，并會產(chǎn)生額外開銷。如果不對碎片進(jìn)行處理，則會導(dǎo)致數(shù)據(jù)分布的不連續(xù)，訪問數(shù)據(jù)時會增加I/O的次數(shù)，導(dǎo)致性能下降。

3.4 提高Cache管理效率

Cache技術(shù)主要通過空間換時間的策略，利用數(shù)據(jù)訪問的時間和空間局部性，盡量提高數(shù)據(jù)訪問的緩存命中率，從而提高系統(tǒng)的性能。

分布式存儲系統(tǒng)中，多個存儲節(jié)點、元數(shù)據(jù)服務(wù)以及客戶端都通過物理網(wǎng)絡(luò)互聯(lián)，客戶端和服務(wù)器端都會進(jìn)行數(shù)據(jù)緩存。根據(jù)節(jié)點上Cache資源工作方式的不同，分布式存儲系統(tǒng)中的Cache分為分布獨立式Cache和協(xié)作式Cache。

分布獨立式Cache中，每個存儲節(jié)點上的文件系統(tǒng)Cache只負(fù)責(zé)緩存本節(jié)點上的I/O數(shù)據(jù)，Cache中數(shù)據(jù)的一致性和Cache資源分配等工作由本節(jié)點上的Cache管理器負(fù)責(zé)。這種Cache管理簡單，不影響系統(tǒng)的整體結(jié)構(gòu)。增刪存儲節(jié)點后，也不需要做額外的Cache配置和管理工作。

協(xié)作式Cache中，每個存儲節(jié)點上的Cache不僅負(fù)責(zé)緩存本節(jié)點上的I/O數(shù)據(jù)，還負(fù)責(zé)緩存其他節(jié)點上的Cache數(shù)據(jù)。協(xié)作式Cache需要各節(jié)點之間能夠快速的通信，因此，存儲節(jié)點之間的網(wǎng)絡(luò)帶寬必須足夠大。協(xié)作式Cache能夠充分利用Cache資源，構(gòu)造全局的“Cache Fusion”，以實現(xiàn)更高的Cache命中率。

兩種Cache方式相比較，分布獨立式Cache簡單、擴(kuò)展性高，協(xié)作式Cache管理復(fù)雜、對網(wǎng)絡(luò)要求高，但是Cache命中率能夠大幅提高，對分布式存儲系統(tǒng)整體性能提高更加明顯。

通過以上幾方面的分析我們可以看出，分布式文件系統(tǒng)的海量小文件問題主要包括元數(shù)據(jù)管理、數(shù)據(jù)布局、Cache管理、I/O訪問流程、網(wǎng)絡(luò)開銷等幾個方面；因此，想要用好分布式文件系統(tǒng)，必須要針對問題的根源進(jìn)行特定的優(yōu)化措施。優(yōu)化思路大體分為兩種：一是減少數(shù)據(jù)訪問次數(shù)，二是減少數(shù)據(jù)訪問時間。具體來講，可以從合并小文件、增大Cache命中率、優(yōu)化元數(shù)據(jù)管理等方面提高訪問效率，進(jìn)而達(dá)到優(yōu)化海量小文件存儲的效果。同時，可以結(jié)合硬件和應(yīng)用優(yōu)化，進(jìn)一步增強(qiáng)優(yōu)化效果。

4 聯(lián)通集團(tuán)應(yīng)用系統(tǒng)問題的解決

4.1 成功案例

Facebook和淘寶都面臨著百億級的小文件存儲，兩家公司都根據(jù)自身應(yīng)用特點設(shè)計相應(yīng)解決方案。Facebook采用的是Haystack[4]，淘寶采用TFS，而它們都不約而同地采用分布式存儲的設(shè)計思想，并對分布式存儲的不足進(jìn)行了改進(jìn)。

Facebook設(shè)計的Haystack與淘寶設(shè)計的TFS思路相仿：將元數(shù)據(jù)與文件實際內(nèi)容分開處理，元數(shù)據(jù)保存在主控節(jié)點的內(nèi)存中，文件實際內(nèi)容合并成大文件再保存在存儲集群的磁盤中，存儲節(jié)點通過內(nèi)存索引檢索文件實際內(nèi)容。Facebook使用Haystack來應(yīng)付海量圖片的讀取更新，如圖3所示。

圖3 Haystack架構(gòu)圖

該系統(tǒng)由三個核心部分組成：存儲節(jié)點、目錄節(jié)點和緩存系統(tǒng)。當(dāng)用戶訪問某個頁面時，目錄節(jié)點會為其中的每個圖片構(gòu)造一個URL，根據(jù)該URL，瀏覽器會先訪問對應(yīng)的CDN，如無命中則訪問高速緩存，再無命中則訪問存儲節(jié)點。Haystack適配海量小文件的秘密在存儲節(jié)點上：存儲節(jié)點的磁盤空間被劃分為幾個100GB左右的大文件，圖片依次寫入這些大文件，存儲節(jié)點在內(nèi)存為每個圖片建立索引，并實時備份到磁盤，機(jī)器宕機(jī)后仍能根據(jù)磁盤上的備份迅速恢復(fù)該內(nèi)存索引表。Haystack使用專門的目錄服務(wù)節(jié)點處理圖片的元數(shù)據(jù)。

淘寶也開發(fā)了類似Haystack的系統(tǒng)TFS來存儲非結(jié)構(gòu)化數(shù)據(jù)[5]，主要是針對海量的小圖片文件。TFS能有效處理淘寶“雙十一購物狂歡節(jié)”的驚人并發(fā)量。TFS的整體架構(gòu)如圖4所示，是由一個NameServer(名稱服務(wù)器)與眾多數(shù)據(jù)節(jié)點組成的主從結(jié)構(gòu)。為防止單點問題，NameServer使用了HA結(jié)構(gòu)(High Availability)：兩臺NameServer互為熱備，實現(xiàn)主從復(fù)制，從機(jī)器只提供讀功能；從機(jī)器可以在需要時迅速切換為主機(jī)器，以便持續(xù)工作；心跳代理負(fù)責(zé)監(jiān)控這一切換過程。

4.2 問題的解決

之前聯(lián)通集團(tuán)電子商城系統(tǒng)的瓶頸主要集中在圖片存儲服務(wù)器和圖片主存儲這里，圖片索引、核心應(yīng)用集群、前置機(jī)等部分沒有性能瓶頸，因此，主要針對圖片服務(wù)器和圖片主存儲部分進(jìn)行改進(jìn)。改進(jìn)后的效果如圖5所示。

針對之前提到的聯(lián)通電子商城系統(tǒng)中存在的主要問題，參考淘寶和Facebook解決方案案例，我們來對聯(lián)通集團(tuán)電子商城系統(tǒng)架構(gòu)進(jìn)行改進(jìn)。

我們采用有元數(shù)據(jù)的架構(gòu)，首先將兩臺圖片存儲服務(wù)器利舊，作為分布式存儲的名稱節(jié)點，配置為HA結(jié)構(gòu)，使兩臺服務(wù)器互為熱備，并且實現(xiàn)主從復(fù)制；從設(shè)備提供讀功能；心跳代理監(jiān)控主從之間的狀態(tài)。之后，采購多臺大容量硬盤服務(wù)器作為圖片存儲節(jié)點，所有服務(wù)器之間采用萬兆以太網(wǎng)方式連接。

圖4 TFS整體架構(gòu)圖

圖5 改進(jìn)后效果圖

架構(gòu)確定以后，我們針對分布式存儲系統(tǒng)進(jìn)行了優(yōu)化，包括：Cache管理優(yōu)化、小文件合并存儲、元數(shù)據(jù)管理優(yōu)化等。另外，對于圖片存儲服務(wù)器和圖片存儲節(jié)點，我們還要對操作系統(tǒng)進(jìn)行優(yōu)化，例如修改I/O調(diào)度算法為DeadLine方式；修改BDP(Bandwidth Delay Product，帶寬和延遲的乘積)大小，以擴(kuò)大TCP Socket緩沖區(qū)大??；調(diào)大TCP滑動窗口；調(diào)整TCP Socket創(chuàng)建和保持參數(shù)等。

經(jīng)過這些改進(jìn)，聯(lián)通集團(tuán)電子商城系統(tǒng)性能有了大幅提升。傳統(tǒng)存儲系統(tǒng)中從查詢請求發(fā)起到接收到最終結(jié)果，會有3～5秒左右的延遲，在我們的分布式存儲系統(tǒng)中，這一時間被控制在了1秒以內(nèi)，業(yè)務(wù)人員實際體驗較好。

5 結(jié)束語

中國聯(lián)通分布式存儲系統(tǒng)的建設(shè)，對集團(tuán)內(nèi)部海量小文件應(yīng)用系統(tǒng)建設(shè)起到了指導(dǎo)作用，在數(shù)據(jù)存儲、數(shù)據(jù)處理、數(shù)據(jù)傳輸?shù)确矫嫣岣吡诵?。為?lián)通邁向大數(shù)據(jù)時代奠定了基礎(chǔ)。

參考文獻(xiàn)

[1]楊傳輝.大規(guī)模分布式存儲系統(tǒng)：原理解析與架構(gòu)實戰(zhàn)[M].北京：機(jī)械工業(yè)出版社,2013

[2]劉愛貴.GlusterFS分布式文件系統(tǒng)[EB/OL].(2014-12-27)[2016-07-15]. http：//vdisk.weibo.com/s/HPecIjqX8sc

[3]李其力.適配海量小文件的分布式文件系統(tǒng)關(guān)鍵技術(shù)研究及系統(tǒng)實現(xiàn)[EB/OL].[2016-07-15].http：//cdmd.cnki.com.cn/Article/CDMD-10561-1015987694.htm

[4]王鈴惠,李小勇,張軼彬.海量小文件存儲系統(tǒng)研究綜述[J].計算機(jī)應(yīng)用及軟件,2012,29(8)：106-109

[5]阿里云Code[EB/OL].(2011-09-29)[2016-07-15].http：//code.tobao.org/p/tfs/wiki/intro/