UCloud元數(shù)據(jù)設(shè)計(jì)

US3FS通過(guò)實(shí)現(xiàn)FUSE的接口，將US3中bucket的對(duì)象映射為文件，和分布式文件系統(tǒng)不同，沒(méi)有mds(metadata server)維護(hù)文件元數(shù)據(jù)，需要通過(guò)HTTP向us3獲取。當(dāng)文件較多時(shí)，大量的請(qǐng)求會(huì)瞬間發(fā)出，性能很差。為了解決這一點(diǎn)，US3FS在內(nèi)存中維護(hù)了bucket的目錄樹(shù)，并設(shè)置文件元數(shù)據(jù)的有效時(shí)間，避免頻繁和US3交互。

這也帶來(lái)了一致性的問(wèn)題，當(dāng)多個(gè)client修改同一bucket中的文件，其中的緩存一致性無(wú)法保證，需要用戶(hù)自己取舍。為了提升檢索的性能，文件并沒(méi)有像對(duì)象存儲(chǔ)以平鋪的方式放在整個(gè)目錄中，而是采用了傳統(tǒng)文件系統(tǒng)類(lèi)似的方式，為每一個(gè)目錄構(gòu)建相關(guān)數(shù)據(jù)結(jié)構(gòu)來(lái)保存其中的文件，同時(shí)inode的設(shè)計(jì)也盡量簡(jiǎn)潔，只保存必要字段，減少內(nèi)存的占用。

目前Inode中保存的字段有uid，gid，size，mtime等，通過(guò)US3的元數(shù)據(jù)功能在對(duì)象中持久化。例如下圖所示，在US3的bucket中有一個(gè)名為”a/b/c/f1″的對(duì)象，在文件系統(tǒng)中，會(huì)將每一個(gè)“/”劃分的前綴映射為目錄，從而實(shí)現(xiàn)左邊的目錄樹(shù)。

UCloud IO流程設(shè)計(jì)

對(duì)于數(shù)據(jù)的寫(xiě)入，US3支持大文件的分片上傳。利用這一特性，US3FS通過(guò)將數(shù)據(jù)寫(xiě)入cache，在后臺(tái)將數(shù)據(jù)以分片上傳的方式，將數(shù)據(jù)以4MB的chunk寫(xiě)入到后端存儲(chǔ)中。分片上傳的流程如下圖所示，通過(guò)令牌桶限制整個(gè)系統(tǒng)的寫(xiě)入并發(fā)數(shù)。每個(gè)分片寫(xiě)入的線(xiàn)程都會(huì)獲取令牌后寫(xiě)入，通過(guò)當(dāng)文件close時(shí)寫(xiě)入最后一個(gè)分片，完成整個(gè)上傳流程。

文件的讀取通過(guò)在US3FS的cache實(shí)現(xiàn)預(yù)讀來(lái)提升性能。kernel-fuse自身對(duì)數(shù)據(jù)的讀寫(xiě)進(jìn)行了分片，在不修改內(nèi)核的情況下，IO最大為128K。而大文件的讀取場(chǎng)景一般為連續(xù)的大IO，這種場(chǎng)景下IO會(huì)被切成128K的片，不做預(yù)讀的話(huà)，無(wú)法很好的利用網(wǎng)絡(luò)帶寬。US3FS的預(yù)讀算法如下所示：

如圖所示，第一次同步讀取完成后，會(huì)往后進(jìn)行當(dāng)前長(zhǎng)度的預(yù)讀，并將預(yù)讀的中點(diǎn)設(shè)置為下次觸發(fā)預(yù)讀的trigger。之后的讀取如果不連續(xù)，則清空之前的狀態(tài)，進(jìn)行新的預(yù)讀，如果連續(xù)，則判斷當(dāng)前讀取的結(jié)束位置是否不小于觸發(fā)預(yù)讀的偏移，如果觸發(fā)預(yù)讀，則將預(yù)讀窗口的大小擴(kuò)大為2倍，直到達(dá)到設(shè)定的閾值。之后以新的窗口進(jìn)行預(yù)讀。如果未觸發(fā)，則不進(jìn)行預(yù)讀。預(yù)讀對(duì)順序讀的性能有很大提升。鑒于US3FS使用場(chǎng)景多為大文件的場(chǎng)景，US3FS本身不對(duì)數(shù)據(jù)進(jìn)行任何緩存。在US3FS之上有內(nèi)核的pagecache，當(dāng)用戶(hù)重復(fù)讀取同一文件時(shí)pagecache能夠很好的起作用。

UCloud數(shù)據(jù)一致性

由于對(duì)象存儲(chǔ)的實(shí)現(xiàn)機(jī)制原因，當(dāng)前大文件的寫(xiě)入，在完成所有的分片上傳之前，數(shù)據(jù)是不可見(jiàn)的，所以對(duì)于US3FS的寫(xiě)入，在close之前，寫(xiě)入的數(shù)據(jù)都是不可讀的，當(dāng)close后，US3FS會(huì)發(fā)送結(jié)束分片的請(qǐng)求，結(jié)束整個(gè)寫(xiě)入流程，此時(shí)數(shù)據(jù)對(duì)用戶(hù)可見(jiàn)。

對(duì)比測(cè)試

在并發(fā)度為64，IO大小為4M測(cè)試模型下，40G文件的順序?qū)懞晚樞蜃x進(jìn)行多次測(cè)試，平均結(jié)果如下:

測(cè)試過(guò)程中,goofys的內(nèi)存占用比較高，峰值約3.3G，而US3FS比較平穩(wěn)，峰值約305M，節(jié)省了90%內(nèi)存空間。s3fs表現(xiàn)相對(duì)較好，因?yàn)槭褂帽镜嘏R時(shí)文件做緩存，所以?xún)?nèi)存占用比較少，但是寫(xiě)入文件比較大，硬盤(pán)空間不足時(shí)，性能會(huì)下降到表格中的數(shù)據(jù)。

在順序讀的測(cè)試中，測(cè)試結(jié)果可以驗(yàn)證我們的分析，goofys由于本身設(shè)計(jì)的原因，在這種場(chǎng)景下性能無(wú)法滿(mǎn)足我們的要求。另外在測(cè)試移動(dòng)1G文件的場(chǎng)景中，對(duì)比結(jié)果如下:

可見(jiàn)在移動(dòng)需求場(chǎng)景下，特別是大文件居多的場(chǎng)景，通過(guò)US3FS能提升上百倍的性能。

總結(jié)

總而言之，s3fs和goofys在大文件的讀寫(xiě)場(chǎng)景下各有優(yōu)劣，相比之下，UCloud優(yōu)刻得US3自研的 US3FS 無(wú)論是讀還是寫(xiě)都有更好的性能，而且和UCloud優(yōu)刻得US3的適配性更強(qiáng)，更易于拓展。

zhangnn