【文章內(nèi)容簡(jiǎn)介】 otocol）來(lái)完成。同時(shí)，完成存儲(chǔ)任務(wù)的各個(gè)Server也獨(dú)立的運(yùn)行于每一個(gè)Zone之中環(huán)（Ring），保存設(shè)備上實(shí)體名稱和物理位置間的映射。系統(tǒng)中不同的存儲(chǔ)對(duì)象，如帳號(hào)、容器、對(duì)象都有相應(yīng)的環(huán)。當(dāng)Swift的其它組件(比如復(fù)制)要對(duì)帳號(hào)、容器或?qū)ο蟛僮鲿r(shí)，需要查詢相應(yīng)的環(huán)來(lái)確定它在集群上的位置。同時(shí)，當(dāng)設(shè)備發(fā)生變更時(shí)也需要重新建立環(huán)。代理服務(wù)器（Proxy Server），負(fù)責(zé)Swift架構(gòu)的其余組件間的相互通信。對(duì)于每個(gè)客戶端的請(qǐng)求，它將在自身保存的Ring中查詢帳號(hào)、容器或者對(duì)象的位置并且相應(yīng)地轉(zhuǎn)發(fā)請(qǐng)求。也可以使用公共API向代理服務(wù)器發(fā)送請(qǐng)求。賬號(hào)服務(wù)器（Account Server），帳號(hào)服務(wù)器的首要工作是處理容器的列表。服務(wù)器并不知道容器的具體位置，只知道指定賬號(hào)對(duì)應(yīng)的容器。 這些信息以sqlite數(shù)據(jù)庫(kù)文件的形式存儲(chǔ)，和對(duì)象一樣在集群上做類似的備份。帳號(hào)服務(wù)器也對(duì)帳號(hào)以及賬號(hào)下面的容易進(jìn)行監(jiān)控和統(tǒng)計(jì)。容器服務(wù)器（Container Server），與賬號(hào)服務(wù)器功能類似，不過(guò)里面保存的是容器內(nèi)所存儲(chǔ)的對(duì)象的數(shù)據(jù)。對(duì)象服務(wù)器（Object Server），對(duì)象服務(wù)器是一個(gè)簡(jiǎn)單的二進(jìn)制大對(duì)象存儲(chǔ)服務(wù)器，可以提供存儲(chǔ)、檢索和刪除本地設(shè)備上對(duì)象的功能。在文件系統(tǒng)上，對(duì)象以二進(jìn)制文件的形式存儲(chǔ)，它的元數(shù)據(jù)存儲(chǔ)在文件系統(tǒng)的擴(kuò)展屬性(Xattrs)中。所以，用于實(shí)現(xiàn)Swift的文件系統(tǒng)本身必須能夠支持?jǐn)U展屬性。在實(shí)際的存儲(chǔ)中，帳號(hào)、容器和對(duì)象的處理方式基本一致，而且在整個(gè)系統(tǒng)中至少有3份副本，以保證滿足簡(jiǎn)單多數(shù)的最低要求。以新浪的采用Swift部署的存儲(chǔ)系統(tǒng)為例，每一個(gè)Zone由包含12塊2T的硬盤的服務(wù)器構(gòu)成，總共有5個(gè)這樣的Zone構(gòu)成了整體的存儲(chǔ)系統(tǒng)。在生產(chǎn)環(huán)境中，也可以在Zone的上層增加一個(gè)負(fù)載均衡的控制來(lái)更好的維護(hù)訪問(wèn)的均衡性。通過(guò)這樣一個(gè)簡(jiǎn)潔的存儲(chǔ)結(jié)構(gòu)，當(dāng)系統(tǒng)的存儲(chǔ)設(shè)備發(fā)生變化時(shí)，只需要重新建立Ring并遷移少量的數(shù)據(jù)就可以正常的運(yùn)行，大大的降低了系統(tǒng)擴(kuò)展的消耗和維護(hù)的代價(jià)。 Swift存儲(chǔ)訪問(wèn)過(guò)程以新浪應(yīng)用的存儲(chǔ)系統(tǒng)為例，當(dāng)用戶存儲(chǔ)一份文件時(shí)，可以在任何一個(gè)Zone上面進(jìn)行映射的計(jì)算，從而得到實(shí)際應(yīng)該存儲(chǔ)的虛擬目錄位置。Proxy Server將文件發(fā)送到對(duì)應(yīng)的對(duì)象服務(wù)器中，僅當(dāng)存儲(chǔ)系統(tǒng)返回的成功滿足簡(jiǎn)單多數(shù)協(xié)議時(shí)，Proxy Server返回保存成功。如果用戶需要獲取某一個(gè)存儲(chǔ)對(duì)象，同樣可以向任何一個(gè)Zone發(fā)送對(duì)象OID，Proxy Server通過(guò)計(jì)算命中對(duì)象所在的虛擬目錄，對(duì)象服務(wù)器返回的成功數(shù)滿足簡(jiǎn)單多數(shù)時(shí)，Proxy Server選擇對(duì)象服務(wù)器并將所要求的存儲(chǔ)對(duì)像發(fā)送給客戶。同時(shí)，系統(tǒng)內(nèi)部的更新器按照預(yù)設(shè)的時(shí)間規(guī)律的查找失敗的存儲(chǔ)記錄，在系統(tǒng)允許的情況下完成內(nèi)部的一致性維護(hù)工作，保證存儲(chǔ)系統(tǒng)的正確運(yùn)行。圖 新浪Swift存儲(chǔ)系統(tǒng)從上面的系統(tǒng)我們也可以看到，當(dāng)訪問(wèn)數(shù)據(jù)的用戶增加，每一個(gè)用戶可以通過(guò)不同的Zone獲得數(shù)據(jù)，也就是說(shuō)，文件的冗余存儲(chǔ)帶來(lái)了IO性能的提升。那么，當(dāng)我們繼續(xù)增加存儲(chǔ)設(shè)備的數(shù)量，就可以通過(guò)增加文件的副本數(shù)量的方式來(lái)提高系統(tǒng)的訪問(wèn)性能。例如，對(duì)于一些擁有大規(guī)模訪問(wèn)量的文件共享服務(wù)器，通過(guò)將副本數(shù)量從默認(rèn)的3份提高到更多的份數(shù)無(wú)疑可以提供更高的吞吐能力，并且這種增長(zhǎng)與投入的設(shè)備數(shù)量是直接相關(guān)的，這種模式可以廉價(jià)的獲得高彈性的存儲(chǔ)性能。在現(xiàn)實(shí)的應(yīng)用中，對(duì)于同一個(gè)存儲(chǔ)系統(tǒng)，不同的應(yīng)用環(huán)境下，對(duì)存儲(chǔ)訪問(wèn)性能的要求是不相同的。如果直接采用最高性能的配置方案，會(huì)帶來(lái)一定的資源浪費(fèi)。而且，在多租戶系統(tǒng)中，單一的性能配置方案也是不能夠滿足多樣的用戶需求的。那么，在現(xiàn)有的系統(tǒng)上找到一種可以充分利用云存儲(chǔ)的高可伸縮性的設(shè)計(jì)方案是具有很強(qiáng)的現(xiàn)實(shí)意義的[20]。通過(guò)了解Swift的存儲(chǔ)過(guò)程我們可以看出，要想提升系統(tǒng)的可配置性，最直接的方法就是讓系統(tǒng)中副本的冗余度是可配置的。通過(guò)提供更靈活的副本數(shù)量來(lái)提供靈活的吞吐性能選擇。 Swift中對(duì)象的存儲(chǔ)結(jié)構(gòu)在Swift中，主要存在三種類型的對(duì)象，即賬號(hào)、容器和存儲(chǔ)對(duì)象。其中，帳號(hào)和容器的數(shù)據(jù)都以sqlite的形式存儲(chǔ)在相應(yīng)的目錄中。在每一個(gè)具體的存儲(chǔ)設(shè)備下，掛載的目錄內(nèi)會(huì)存在以下子目錄，它們是accounts、containers、objects，對(duì)應(yīng)賬號(hào)、容器、對(duì)象的存儲(chǔ)目錄；async_pending是異步待更新目錄；quarantined是隔離目錄；tmp是臨時(shí)目錄。下面分別分析帳號(hào)、容器和對(duì)象的存儲(chǔ)結(jié)構(gòu)。其中容器與帳號(hào)的存儲(chǔ)結(jié)構(gòu)類似。 帳號(hào)存儲(chǔ)結(jié)構(gòu)在accounts目錄下存放的是各個(gè)partition，而每個(gè)partition目錄是由若干個(gè)suffix_path目錄組成，suffix_path目錄下是由account的hash名構(gòu)成的目錄，在hash目錄下存放了關(guān)于account的sqlite db。圖 帳號(hào)存儲(chǔ)結(jié)構(gòu)，展示了測(cè)試系統(tǒng)中的帳號(hào)存儲(chǔ)結(jié)構(gòu)。圖 賬號(hào)存儲(chǔ)展示如圖所示，在存儲(chǔ)設(shè)備下存在帳號(hào)、容器、對(duì)象存儲(chǔ)目錄和臨時(shí)目錄。，對(duì)上面的結(jié)構(gòu)進(jìn)行了分析。PathDeviceAccountPartitionSuffix_pathHash pathHash+extensionsdb1/2/node/sdb2/accounts160771c839d00c…c839d00c…圖 帳號(hào)信息的db文件主要保存了關(guān)于account的信息，如名稱、創(chuàng)建時(shí)間、容器數(shù)統(tǒng)計(jì)等。共包含了account_stat、container、ining_sync 、outgoing_sync等4張表，其中最基礎(chǔ)的是account_stat表，：表 31 accountstat表結(jié)構(gòu)account_stat (account TEXT, created_at TEXT,put_timestamp TEXTDEFAULT39。039。, delete_timestamp TEXTDEFAULT39。039。, container_count INTEGER, object_count INTEGERDEFAULT0, bytes_used INTEGERDEFAULT0, hash TEXTdefault39。0000000000000000000000000000000039。, id TEXT, status TEXTDEFAULT39。39。, status_changed_at TEXTDEFAULT39。039。, metadata TEXTDEFAULT39。39。 )。可以看出來(lái)，Account主要管理了其包含的容器計(jì)數(shù)、對(duì)象計(jì)數(shù)，并記錄空間的使用情況。 容器存儲(chǔ)結(jié)構(gòu)容器存儲(chǔ)結(jié)構(gòu)在文件系統(tǒng)中的目錄與帳號(hào)存儲(chǔ)結(jié)構(gòu)類似，只是其中的賬號(hào)目錄換成了對(duì)應(yīng)的容器目錄。容器在Swift系統(tǒng)中有著重要的作用，對(duì)象可以通過(guò)容器直接列舉出來(lái)，同時(shí)也可以按照容器來(lái)直接的下載容器內(nèi)全部對(duì)象。所以，容器是與對(duì)象存儲(chǔ)直接相關(guān)的一個(gè)邏輯結(jié)構(gòu)。通過(guò)對(duì)容器的理解和操作，可以完成很多一般的文件系統(tǒng)所做不到或者低效的工作。但是，由于容器是與對(duì)象直接相關(guān)的結(jié)構(gòu)，它的結(jié)構(gòu)和管理要比帳號(hào)數(shù)據(jù)復(fù)雜。db文件中包含了container_stat、object、sqlite_sequence、ining_sync 、outgoing_sync5張表，object表保存了其下屬的存儲(chǔ)對(duì)象的名稱、etag等基本信息。：表 32 Container_stat結(jié)構(gòu)container_stat ( account TEXT, container TEXT, created_at TEXT, put_timestamp TEXTDEFAULT39。039。, delete_timestamp TEXTDEFAULT39。039。, object_count INTEGER, bytes_used INTEGER, reported_put_timestamp TEXTDEFAULT39。039。, reported_delete_timestamp TEXTDEFAULT39。039。, reported_object_count INTEGERDEFAULT0, reported_bytes_used INTEGERDEFAULT0, hash TEXTdefault39。0000000000000000000000000000000039。, id TEXT, status TEXTDEFAULT39。39。, status_changed_at TEXTDEFAULT39。039。, metadata TEXTDEFAULT39。39。, x_container_sync_point1 INTEGERDEFAULT1, x_container_sync_point2 INTEGERDEFAULT1 )。其中account字段表示container所屬的account，container字段表示container名稱，created_at表示創(chuàng)建時(shí)間，put_timestamp表示put request的時(shí)間戳，delete_timestamp表示delete request的時(shí)間戳，object_count表示object計(jì)數(shù)，bytes_used表示使用空間，hash表示db文件的哈希值, reported_put_timestamp, reported_delete_timestamp, reported_object_count, reported_bytes_used表示reported的狀態(tài)信息，id表示統(tǒng)一標(biāo)識(shí)符，status表示container狀態(tài)，status_changed_at表示更改時(shí)間，metadata表示container的元數(shù)據(jù)，x_container_sync_point1表示同步點(diǎn)1，x_container_sync_point2表示同步點(diǎn)2。通過(guò)Container，我們可以直接獲得其下屬對(duì)象的信息，從而可以很容易的按照Container整體的復(fù)制或遷移數(shù)據(jù)。這也是Swift存儲(chǔ)的一個(gè)優(yōu)點(diǎn)。由于Swift中的sqlite數(shù)據(jù)庫(kù)在運(yùn)行中會(huì)完全載入內(nèi)存，所以當(dāng)Contianer中對(duì)象的數(shù)量過(guò)多的時(shí)候，可能會(huì)造成性能的急劇下降，一般建議系統(tǒng)保持在每個(gè)容器中的對(duì)象不超過(guò)百萬(wàn)級(jí)別。對(duì)于實(shí)際的需求，可以通過(guò)客戶端內(nèi)部自動(dòng)建立新的容器來(lái)解決。 對(duì)象存儲(chǔ)結(jié)構(gòu)對(duì)象的存儲(chǔ)在文件系統(tǒng)的目錄結(jié)構(gòu)上也和帳號(hào)以及容器類似，但是其中存儲(chǔ)的文件卻并不相同。在objects目錄下存放的是各個(gè)partition目錄，suffix_path目錄下是由object的hash_path名構(gòu)成的目錄，在hash_path目錄下存放了關(guān)于object的數(shù)據(jù)和元數(shù)據(jù)。：圖 object存儲(chǔ)目錄結(jié)構(gòu)其中的pkl文件保存了partition下面對(duì)象的時(shí)間戳等信息，用于數(shù)據(jù)同步時(shí)作為對(duì)比。，；當(dāng)對(duì)象被刪除后，這個(gè)文件會(huì)在定期的檢查過(guò)后清理掉。在對(duì)象存儲(chǔ)中，重要的一項(xiàng)就是生成對(duì)象保存路徑，這個(gè)路徑的生成過(guò)程如下：、container和object名稱產(chǎn)生39。/account/container/object39。格式的字符串，和HASH_PATH_SUFFI