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

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

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

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

分布式文件存儲服務

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

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

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

圖片

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

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

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

為了幫助你理解常見的分布式存儲服務的工作原理，我們將以 FastDFS 分布式存儲為例進行分析，請看下圖：

圖片

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

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

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

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

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

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

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

2. 文件管理：

使用分布式存儲控制器對文件做定期、冷熱轉換、定期清理以及文件歸檔等工作。

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

關注分布式存儲副本同步狀態(tài)及服務帶寬。

如果服務流量過大，運維和研發(fā)還需要處理好熱點訪問文件緩存的問題。

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

一些稍微個性點的需求，比如在文件中附加業(yè)務類型的標簽、增加自動 TTL 清理，現(xiàn)有的分布式存儲服務可能無法直接支持，還需要我們閱讀相關源碼，進一步改進代碼才能實現(xiàn)功能。

5. 硬件更新：

服務器用的硬盤壽命普遍不長，特別是用于存儲服務的硬盤，需要定期更換（比如三年一換）。

對象存儲

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

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

對象存儲的優(yōu)勢主要體現(xiàn)在以下三個方面：

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

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

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

對象存儲如何管理小文件

之前曾提到過，在對象存儲當中，實際的存儲路徑已經(jīng)轉變?yōu)橥ㄟ^ hash 方式來進行存儲了。

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

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

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

也許看到這里，你心里會存在疑問：既然這個技巧這么好用，那為什么在此之前它沒有得到廣泛普及呢？

這是因為在以往的實現(xiàn)過程中，請求所訪問的路徑就是文件實際的物理存儲路徑。而對于 Linux 系統(tǒng)而言，在同一個目錄下是無法存放過多文件的，要是存放的文件數(shù)量過多，就會導致管理起來極為困難。

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

為了避免出現(xiàn)類似這樣的問題，很多服務器在存儲這些小文件的時候，會先對文件名進行 hash 計算，然后取 hash 結果的最后四位作為雙層子目錄名，通過這種方式來確保在一個目錄下不會存在過多的文件。

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

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

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

圖片

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

對象存儲如何管理大文本

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

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

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

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

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

圖片

如上圖所示，左邊展示了通過緩存提供數(shù)據(jù)查詢服務的常見方式，而右邊則展示了使用對象存儲的方式。從結構上來看，對象存儲在使用和維護上顯得更為方便和簡單。接下來，我們來估算一下成本。

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

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

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

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

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

文件的云中轉

圖片

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

主要過程如下：文件傳輸服務為發(fā)送方生成一個臨時授權 token，文件上傳至對象存儲后，接收方即可通過該地址和授權 token 進行多線程下載。當臨時文件過期后，系統(tǒng)會自動清除文件。

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

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