當(dāng)你打開微博或一個(gè)新聞網(wǎng)站時(shí)，眼前會(huì)呈現(xiàn)出豐富的媒體文件：圖片、文本、音頻、視頻等應(yīng)有盡有。有時(shí)，一個(gè)頁(yè)面甚至由成百上千個(gè)文件組合而成。那么，這些文件究竟存放在哪里呢？

通常來(lái)說(shuō)，對(duì)于小于 1KB 的少量文本數(shù)據(jù)，我們會(huì)將其存儲(chǔ)在數(shù)據(jù)庫(kù)中。然而，對(duì)于較大的文本或多媒體文件（例如 MP4、TS、MP3、JPG、JS、CSS 等），我們則會(huì)存放在硬盤上。這類文件的管理并不復(fù)雜，但當(dāng)文件數(shù)量達(dá)到數(shù)百萬(wàn)時(shí)，單靠硬盤管理就顯得吃力了。

在這種情況下，當(dāng)用戶請(qǐng)求服務(wù)器時(shí)，幾十臺(tái)服務(wù)器需要在上百塊硬盤中定位文件的具體存儲(chǔ)位置。此外，定期備份、統(tǒng)計(jì)訪問(wèn)記錄等維護(hù)工作也隨之增加，大大增加了研發(fā)負(fù)擔(dān)。

而對(duì)象存儲(chǔ)技術(shù)的出現(xiàn)幫助我們屏蔽了這些復(fù)雜細(xì)節(jié)，顯著提升了研發(fā)效率。本節(jié)課，我們將探討存儲(chǔ)技術(shù)的演變過(guò)程，幫助你更深入地理解服務(wù)器存儲(chǔ)和對(duì)象存儲(chǔ)的原理與實(shí)踐。

分布式文件存儲(chǔ)服務(wù)

在介紹對(duì)象存儲(chǔ)之前，我們先來(lái)了解支撐它的基礎(chǔ)技術(shù)——分布式文件存儲(chǔ)服務(wù)。這類服務(wù)是互聯(lián)網(wǎng)媒體資源的數(shù)據(jù)存儲(chǔ)基礎(chǔ)。我們先具體分析一下，分布式文件存儲(chǔ)具備哪些功能，以及數(shù)據(jù)庫(kù)在管理文件時(shí)需要完成的任務(wù)。

通常情況下，數(shù)據(jù)庫(kù)中保存的只是文件路徑。于是，在文件遷移、歸檔和備份副本時(shí)，數(shù)據(jù)庫(kù)就需要同步更新這些路徑記錄。當(dāng)文件數(shù)量達(dá)到百萬(wàn)級(jí)別，為了能高效響應(yīng)文件查找請(qǐng)求，系統(tǒng)需要為文件索引信息進(jìn)行分庫(kù)分表。此外，還需提供文件檢索、管理、訪問(wèn)統(tǒng)計(jì)，以及根據(jù)文件熱度調(diào)整存儲(chǔ)位置等功能。

那么，這些文件索引和存儲(chǔ)究竟是如何協(xié)同工作的呢？請(qǐng)看下圖：

圖片

從上圖中可以看出，光是管理文件索引這一任務(wù)，研發(fā)團(tuán)隊(duì)已經(jīng)面臨極大的壓力，更不用說(shuō)涉及到文件存儲(chǔ)、傳輸和副本備份的分布式存儲(chǔ)服務(wù)，這些工作更加復(fù)雜。

在未使用分布式存儲(chǔ)前，靜態(tài)文件服務(wù)通常依賴于 Nginx 和 NFS 掛載 NAS 的方式。然而，這種方法存在明顯缺陷：文件只有一份，且需要人工定期備份。為了確保數(shù)據(jù)完整性，提高文件服務(wù)的可用性，并減少研發(fā)團(tuán)隊(duì)的重復(fù)勞動(dòng)，業(yè)界普遍選擇使用分布式存儲(chǔ)系統(tǒng)來(lái)統(tǒng)一管理文件的分發(fā)和存儲(chǔ)。

通過(guò)分布式存儲(chǔ)，系統(tǒng)能夠自動(dòng)實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容、負(fù)載均衡、文件分片與合并、文件歸檔以及冷熱點(diǎn)文件管理等服務(wù)。這使得管理大量文件的過(guò)程變得更加高效和便捷。

為了幫助你理解常見的分布式存儲(chǔ)服務(wù)的工作原理，我們將以 FastDFS 分布式存儲(chǔ)為例進(jìn)行分析，請(qǐng)看下圖：

圖片

其實(shí)，分布式文件存儲(chǔ)的方案也并不是十全十美的。就拿 FastDFS 來(lái)說(shuō)，它有很多強(qiáng)制規(guī)范，比如新保存文件的訪問(wèn)路徑是由分布式存儲(chǔ)服務(wù)生成的，研發(fā)需要維護(hù)文件和實(shí)際存儲(chǔ)的映射。這樣每次獲取要展示的圖片時(shí)，都需要查找數(shù)據(jù)庫(kù)，或者為前端提供一個(gè)沒(méi)有規(guī)律的 hash 路徑，這樣一來(lái)，如果文件丟失的話前端都不知道這個(gè)文件到底是什么。FastDFS 生成的文件名很難懂，演示路徑如下所示：

# 在網(wǎng)上找的FastDFS生成的演示路徑
/group1/M00/03/AF/wKi0d1QGA0qANZk5AABawNvHeF0411.png

相信你一定也發(fā)現(xiàn)了，這個(gè)地址很長(zhǎng)很難懂，這讓我們管理文件的時(shí)候很不方便，因?yàn)槲覀兞?xí)慣通過(guò)路徑層級(jí)歸類管理各種圖片素材信息。如果這個(gè)路徑是 /active/img/banner1.jpg，相對(duì)就會(huì)更好管理。雖然我只是舉了一種分布式存儲(chǔ)系統(tǒng)，但其他分布式存儲(chǔ)系統(tǒng)也會(huì)有這樣那樣的小問(wèn)題。

這里我想提醒你注意的是，即便用了分布式存儲(chǔ)服務(wù)，我們的運(yùn)維和研發(fā)工作也不輕松。為什么這么說(shuō)呢？根據(jù)我的實(shí)踐經(jīng)驗(yàn)，我們還需要關(guān)注以下五個(gè)方面的問(wèn)題：

1. 磁盤監(jiān)控：

監(jiān)控磁盤的壽命、容量、inode 剩余。

進(jìn)行故障監(jiān)控警告及日常維護(hù)。

2. 文件管理：

使用分布式存儲(chǔ)控制器對(duì)文件做定期、冷熱轉(zhuǎn)換、定期清理以及文件歸檔等工作。

3. 確保服務(wù)穩(wěn)定：

關(guān)注分布式存儲(chǔ)副本同步狀態(tài)及服務(wù)帶寬。

如果服務(wù)流量過(guò)大，運(yùn)維和研發(fā)還需要處理好熱點(diǎn)訪問(wèn)文件緩存的問(wèn)題。

4. 業(yè)務(wù)定制化：

一些稍微個(gè)性點(diǎn)的需求，比如在文件中附加業(yè)務(wù)類型的標(biāo)簽、增加自動(dòng) TTL 清理，現(xiàn)有的分布式存儲(chǔ)服務(wù)可能無(wú)法直接支持，還需要我們閱讀相關(guān)源碼，進(jìn)一步改進(jìn)代碼才能實(shí)現(xiàn)功能。

5. 硬件更新：

服務(wù)器用的硬盤壽命普遍不長(zhǎng)，特別是用于存儲(chǔ)服務(wù)的硬盤，需要定期更換（比如三年一換）。

對(duì)象存儲(chǔ)

自從采用分布式存儲(chǔ)后，回想過(guò)去的經(jīng)歷，我意識(shí)到樹形磁盤存儲(chǔ)結(jié)構(gòu)給研發(fā)帶來(lái)了很多額外的工作。比如，在數(shù)百臺(tái)服務(wù)器和磁盤上提供相對(duì)路徑和絕對(duì)路徑的掛載服務(wù)，需要具備文件檢索、遍歷功能，并設(shè)置文件的訪問(wèn)權(quán)限。這些管理功能并非我們對(duì)外業(yè)務(wù)所需的高頻使用功能，這種設(shè)計(jì)導(dǎo)致研發(fā)投入過(guò)高，超出了本應(yīng)關(guān)注的范圍。

而使用對(duì)象存儲(chǔ)服務(wù)后，這些問(wèn)題得到了顯著改善。對(duì)象存儲(chǔ)優(yōu)雅地屏蔽了底層實(shí)現(xiàn)細(xì)節(jié)，將業(yè)務(wù)和運(yùn)維工作隔離，使路徑變得簡(jiǎn)單明了，讓研發(fā)團(tuán)隊(duì)可以更專注于業(yè)務(wù)發(fā)展。

對(duì)象存儲(chǔ)的優(yōu)勢(shì)主要體現(xiàn)在以下三個(gè)方面：

首先，從文件索引的角度來(lái)看，對(duì)象存儲(chǔ)弱化了樹形目錄結(jié)構(gòu)，甚至可以說(shuō)是省略了。盡管如此，樹形目錄結(jié)構(gòu)仍然可以保留。當(dāng)需要進(jìn)行運(yùn)維操作時(shí)，可以通過(guò)前綴檢索對(duì) Key 進(jìn)行查找，從而實(shí)現(xiàn)目錄管理。這種方式使用方便，無(wú)需擔(dān)心數(shù)據(jù)量大導(dǎo)致索引查找緩慢的問(wèn)題。值得強(qiáng)調(diào)的是，對(duì)象存儲(chǔ)并不是按照指定路徑進(jìn)行存儲(chǔ)，實(shí)際上，文件路徑僅是一個(gè) Key。當(dāng)查詢文件對(duì)象時(shí)，實(shí)際上是進(jìn)行了一次哈希查詢，這比在數(shù)據(jù)庫(kù)中進(jìn)行字符串前綴匹配查詢要快得多。此外，由于不需要維護(hù)整體樹索引，鍵值（KV）方式在查詢和存儲(chǔ)上都大幅提升了效率，同時(shí)更容易進(jìn)行維護(hù)。

其次，讀寫管理方式也從原先通過(guò)磁盤文件管理，轉(zhuǎn)變?yōu)橥ㄟ^(guò) API 管理文件對(duì)象。這種簡(jiǎn)化后的接口方式使得數(shù)據(jù)讀寫變得更加靈活和方便，無(wú)需過(guò)多考慮磁盤相關(guān)的知識(shí)。

最后，對(duì)象存儲(chǔ)還提供了文件的索引管理與映射，增加了數(shù)據(jù)和媒體文件的管理可能性。以往，我們的文件主要是圖片、音頻和視頻，這些文件通常在業(yè)務(wù)系統(tǒng)中是獨(dú)立存在的。而結(jié)合對(duì)象存儲(chǔ)后，我們可以將一些數(shù)據(jù)作為小文件來(lái)管理。然而，這也帶來(lái)了大量小文件的管理挑戰(zhàn)。這些小文件往往很零碎，需要更多的管理策略和工具。接下來(lái)，我們將探討在對(duì)象存儲(chǔ)的思路下，如何有效管理小文件。

對(duì)象存儲(chǔ)如何管理小文件

之前曾提到過(guò)，在對(duì)象存儲(chǔ)當(dāng)中，實(shí)際的存儲(chǔ)路徑已經(jīng)轉(zhuǎn)變?yōu)橥ㄟ^(guò) hash 方式來(lái)進(jìn)行存儲(chǔ)了。

對(duì)此，我們能夠借鑒類似 RESTful 的思路去規(guī)劃設(shè)計(jì)我們的對(duì)象存儲(chǔ)路徑，示例如下：

• “user\info\9527.json”，該路徑下保存的是用戶的公共信息。
• “user\info\head\9527.jpg”，這里存放的是與之對(duì)應(yīng)的用戶頭像。
• “product\detail\4527.json”，通過(guò)此路徑可直接獲取商品信息。

從上述設(shè)計(jì)能夠看出，如此一來(lái)，我們無(wú)需在每次發(fā)起請(qǐng)求時(shí)都去訪問(wèn)數(shù)據(jù)庫(kù)，便能夠獲取到特定對(duì)象的相關(guān)信息。前端只需簡(jiǎn)單地對(duì)路徑進(jìn)行拼接操作，就可以拿到所有所需的文件。采用這樣的方式，能夠幫助我們大幅削減緩存的維護(hù)成本。

也許看到這里，你心里會(huì)存在疑問(wèn)：既然這個(gè)技巧這么好用，那為什么在此之前它沒(méi)有得到廣泛普及呢？

這是因?yàn)樵谝酝膶?shí)現(xiàn)過(guò)程中，請(qǐng)求所訪問(wèn)的路徑就是文件實(shí)際的物理存儲(chǔ)路徑。而對(duì)于 Linux 系統(tǒng)而言，在同一個(gè)目錄下是無(wú)法存放過(guò)多文件的，要是存放的文件數(shù)量過(guò)多，就會(huì)導(dǎo)致管理起來(lái)極為困難。

就拿上面所舉的例子來(lái)說(shuō)，如果我們擁有 300 萬(wàn)個(gè)用戶，將這 300 萬(wàn)個(gè)頭像文件全部放置在同一個(gè)目錄下，那么即便是執(zhí)行一個(gè)簡(jiǎn)單的 ls 命令，都有可能致使服務(wù)器卡頓長(zhǎng)達(dá)十分鐘之久。

為了避免出現(xiàn)類似這樣的問(wèn)題，很多服務(wù)器在存儲(chǔ)這些小文件的時(shí)候，會(huì)先對(duì)文件名進(jìn)行 hash 計(jì)算，然后取 hash 結(jié)果的最后四位作為雙層子目錄名，通過(guò)這種方式來(lái)確保在一個(gè)目錄下不會(huì)存在過(guò)多的文件。

然而，這樣做就需要進(jìn)行 hash 計(jì)算，這會(huì)使得前端在使用時(shí)極為不方便，而且我們?cè)谄綍r(shí)對(duì)磁盤數(shù)據(jù)進(jìn)行查找、管理等操作時(shí)，也會(huì)感覺(jué)十分痛苦，所以這種方式遭到了很多人的排斥。

不過(guò)，即便切換到了分布式存儲(chǔ)服務(wù)，小文件存儲(chǔ)方面的問(wèn)題依舊會(huì)給我們帶來(lái)困擾。因?yàn)樵谶M(jìn)行副本同步以及存儲(chǔ)操作時(shí)，都是以文件作為基本單位來(lái)開展的。倘若文件很小，每秒能夠上傳上千個(gè)文件，那么在進(jìn)行副本同步時(shí)，就會(huì)由于存在大量的分配調(diào)度請(qǐng)求，進(jìn)而出現(xiàn)延遲現(xiàn)象，這樣一來(lái)，要對(duì)副本同步的流量進(jìn)行管理也就變得十分困難了。

針對(duì)上述這些問(wèn)題，對(duì)象存儲(chǔ)和分布式存儲(chǔ)服務(wù)針對(duì)這方面做出了優(yōu)化，不再將小文件獨(dú)立地進(jìn)行保存，而是采用文件塊的方式對(duì)多個(gè)文件進(jìn)行壓縮存儲(chǔ)。

圖片

比如把 100 個(gè)文件壓縮存儲(chǔ)到一個(gè) 10M 大小的文件塊里統(tǒng)一管理，比直接管理文件簡(jiǎn)單很多。不過(guò)可以預(yù)見這樣數(shù)據(jù)更新會(huì)麻煩，為此我們通常會(huì)在小文件更新數(shù)據(jù)時(shí)，直接新建一個(gè)文件來(lái)更新內(nèi)容。定期整理數(shù)據(jù)的時(shí)候，才會(huì)把新老數(shù)據(jù)合并寫到新的塊里，清理掉老數(shù)據(jù)。這里順便提示一句，大文件你也可以使用同樣的方式，切成多個(gè)小文件塊來(lái)管理，這樣更方便。

對(duì)象存儲(chǔ)如何管理大文本

在前面討論了對(duì)象存儲(chǔ)在管理小文件方面的優(yōu)勢(shì)后，接下來(lái)我們來(lái)看看對(duì)象存儲(chǔ)如何管理大文本。這種管理方式可以抽象地概括為用對(duì)象存儲(chǔ)取代緩存。

那么，什么情況下會(huì)有大文本的管理需求呢？比較典型的場(chǎng)景就是新聞資訊網(wǎng)站，尤其是資訊量特別豐富的那些網(wǎng)站，它們常常直接使用對(duì)象存儲(chǔ)提供文本服務(wù)。這種設(shè)計(jì)的主要原因是，1KB 以上的大文本并不適合放在數(shù)據(jù)庫(kù)或緩存中。接下來(lái)，我們通過(guò)后面的示意圖進(jìn)行分析。

首先，大文本通常具有較大的體積和不規(guī)則的訪問(wèn)模式，這使得將其存儲(chǔ)在數(shù)據(jù)庫(kù)中不僅增加了存儲(chǔ)成本，還可能導(dǎo)致數(shù)據(jù)庫(kù)性能下降。數(shù)據(jù)庫(kù)的設(shè)計(jì)初衷是高效管理小規(guī)模、頻繁更新的數(shù)據(jù)，而大文本的讀寫操作相對(duì)較少，因此將其存儲(chǔ)在數(shù)據(jù)庫(kù)中并不高效。

其次，緩存雖然能加速數(shù)據(jù)的訪問(wèn)，但它的內(nèi)存資源有限。大量大文本的緩存會(huì)迅速消耗可用內(nèi)存，導(dǎo)致緩存命中率降低，從而影響整體性能。因此，對(duì)于大文本的管理，直接使用對(duì)象存儲(chǔ)會(huì)更加合適。

對(duì)象存儲(chǔ)提供了高效、靈活的存儲(chǔ)解決方案，能夠處理大文本的存取需求，同時(shí)避免了數(shù)據(jù)庫(kù)和緩存中的瓶頸。這使得在需要頻繁更新和訪問(wèn)的大文本場(chǎng)景中，使用對(duì)象存儲(chǔ)成為一種理想的選擇。通過(guò)這種方式，我們可以更高效地管理和提供服務(wù)，同時(shí)確保系統(tǒng)的整體性能。

圖片

如上圖所示，左邊展示了通過(guò)緩存提供數(shù)據(jù)查詢服務(wù)的常見方式，而右邊則展示了使用對(duì)象存儲(chǔ)的方式。從結(jié)構(gòu)上來(lái)看，對(duì)象存儲(chǔ)在使用和維護(hù)上顯得更為方便和簡(jiǎn)單。接下來(lái)，我們來(lái)估算一下成本。

假設(shè)我們的請(qǐng)求訪問(wèn)量為 1W QPS，那么對(duì)于 1KB 的數(shù)據(jù)緩存服務(wù)，帶寬需求可以計(jì)算為：

為了留出一些余地，我們大概需要 100MB/s 的帶寬。此外，還需要多臺(tái)高性能服務(wù)器和一個(gè)大容量的緩存集群，以支撐我們的服務(wù)。這么一算，成本確實(shí)不低。對(duì)于資訊類網(wǎng)站這種讀多寫少的系統(tǒng)，如果無(wú)法降低維護(hù)成本，必然需要更多資源投入。

一種常見的解決方法是將資訊內(nèi)容直接生成靜態(tài)文件，雖然這樣可以控制流量成本，但運(yùn)維和開發(fā)的成本卻會(huì)隨之增加。有沒(méi)有更好的方法呢？

相較之下，使用對(duì)象存儲(chǔ)維護(hù)資源的具體頁(yè)面則更為高效。具體過(guò)程如下：所有流量都會(huì)請(qǐng)求云廠商的對(duì)象存儲(chǔ)服務(wù)，同時(shí)通過(guò) CDN 實(shí)現(xiàn)緩存和加速。當(dāng) CDN 找不到待查文件時(shí)，會(huì)回源到對(duì)象存儲(chǔ)進(jìn)行查找；如果對(duì)象存儲(chǔ)也未找到，則會(huì)回源到服務(wù)端生成。這種方式大大降低了網(wǎng)絡(luò)流量壓力，若配合版本控制功能，還能實(shí)現(xiàn)文件的歷史版本回退，提高服務(wù)的可用性。

此外，值得補(bǔ)充的是，如果資訊內(nèi)容存在閱讀權(quán)限限制（例如僅限會(huì)員閱讀），我們可以對(duì)特定對(duì)象設(shè)置權(quán)限，使得只有使用短期有效的 token 才能讀取文件內(nèi)容。這種做法不僅保護(hù)了內(nèi)容的安全性，也提高了系統(tǒng)的靈活性。

文件的云中轉(zhuǎn)

圖片

除了通過(guò)服務(wù)端提供數(shù)據(jù)供用戶下載之外，還有一種更為普遍的數(shù)據(jù)交換方式，即用戶之間的文件傳輸。例如，當(dāng)用戶 A 想傳遞一個(gè)文件給用戶 B，通常的做法是通過(guò) TCP 連接兩端客戶端或通過(guò)服務(wù)端中轉(zhuǎn)，但這種方式傳輸效率較低。而使用對(duì)象存儲(chǔ)則能顯著提升文件傳輸和交換的效率。

主要過(guò)程如下：文件傳輸服務(wù)為發(fā)送方生成一個(gè)臨時(shí)授權(quán) token，文件上傳至對(duì)象存儲(chǔ)后，接收方即可通過(guò)該地址和授權(quán) token 進(jìn)行多線程下載。當(dāng)臨時(shí)文件過(guò)期后，系統(tǒng)會(huì)自動(dòng)清除文件。

實(shí)際上，這種方式不僅適用于用戶之間的數(shù)據(jù)交換，業(yè)務(wù)系統(tǒng)也可利用對(duì)象存儲(chǔ)實(shí)現(xiàn)跨機(jī)房的數(shù)據(jù)交換和數(shù)據(jù)備份。許多對(duì)象存儲(chǔ)服務(wù)提供商的客戶端 SDK 已內(nèi)置了多線程分片上傳下載和 GSLB（全局服務(wù)器負(fù)載均衡）就近 CDN 路線優(yōu)化的上傳加速功能，使用這些服務(wù)可大大提高數(shù)據(jù)傳輸速度。

此外，關(guān)于容災(zāi)，大部分對(duì)象存儲(chǔ)服務(wù)商都提供容災(zāi)支持。我們可以為所有數(shù)據(jù)開啟同城雙活備份、全球加速、災(zāi)難調(diào)度以及主備切換等功能。這種完善的容災(zāi)機(jī)制確保數(shù)據(jù)在各種情況下都能安全、快速地訪問(wèn)。