業務緩存：元數據服務如何實現？
當你打開微博或一個新聞網站時，眼前會呈現出豐富的媒體文件：圖片、文本、音頻、視頻等應有盡有。有時，一個頁面甚至由成百上千個文件組合而成。那么，這些文件究竟存放在哪里呢？
通常來說，對于小于 1KB 的少量文本數據，我們會將其存儲在數據庫中。然而，對于較大的文本或多媒體文件（例如 MP4、TS、MP3、JPG、JS、CSS 等），我們則會存放在硬盤上。這類文件的管理并不復雜，但當文件數量達到數百萬時，單靠硬盤管理就顯得吃力了。
在這種情況下，當用戶請求服務器時，幾十臺服務器需要在上百塊硬盤中定位文件的具體存儲位置。此外，定期備份、統計訪問記錄等維護工作也隨之增加，大大增加了研發負擔。
而對象存儲技術的出現幫助我們屏蔽了這些復雜細節，顯著提升了研發效率。本節課，我們將探討存儲技術的演變過程，幫助你更深入地理解服務器存儲和對象存儲的原理與實踐。
分布式文件存儲服務
在介紹對象存儲之前，我們先來了解支撐它的基礎技術——分布式文件存儲服務。這類服務是互聯網媒體資源的數據存儲基礎。我們先具體分析一下，分布式文件存儲具備哪些功能，以及數據庫在管理文件時需要完成的任務。
通常情況下，數據庫中保存的只是文件路徑。于是，在文件遷移、歸檔和備份副本時，數據庫就需要同步更新這些路徑記錄。當文件數量達到百萬級別，為了能高效響應文件查找請求，系統需要為文件索引信息進行分庫分表。此外，還需提供文件檢索、管理、訪問統計，以及根據文件熱度調整存儲位置等功能。
那么，這些文件索引和存儲究竟是如何協同工作的呢？請看下圖：
圖片
從上圖中可以看出，光是管理文件索引這一任務，研發團隊已經面臨極大的壓力，更不用說涉及到文件存儲、傳輸和副本備份的分布式存儲服務，這些工作更加復雜。
在未使用分布式存儲前，靜態文件服務通常依賴于 Nginx 和 NFS 掛載 NAS 的方式。然而，這種方法存在明顯缺陷：文件只有一份，且需要人工定期備份。為了確保數據完整性，提高文件服務的可用性，并減少研發團隊的重復勞動，業界普遍選擇使用分布式存儲系統來統一管理文件的分發和存儲。
通過分布式存儲，系統能夠自動實現動態擴容、負載均衡、文件分片與合并、文件歸檔以及冷熱點文件管理等服務。這使得管理大量文件的過程變得更加高效和便捷。
為了幫助你理解常見的分布式存儲服務的工作原理，我們將以 FastDFS 分布式存儲為例進行分析，請看下圖：
圖片
其實，分布式文件存儲的方案也并不是十全十美的。就拿 FastDFS 來說，它有很多強制規范，比如新保存文件的訪問路徑是由分布式存儲服務生成的，研發需要維護文件和實際存儲的映射。這樣每次獲取要展示的圖片時，都需要查找數據庫，或者為前端提供一個沒有規律的 hash 路徑，這樣一來，如果文件丟失的話前端都不知道這個文件到底是什么。FastDFS 生成的文件名很難懂，演示路徑如下所示：
# 在網上找的FastDFS生成的演示路徑
/group1/M00/03/AF/wKi0d1QGA0qANZk5AABawNvHeF0411.png相信你一定也發現了，這個地址很長很難懂，這讓我們管理文件的時候很不方便，因為我們習慣通過路徑層級歸類管理各種圖片素材信息。如果這個路徑是 /active/img/banner1.jpg，相對就會更好管理。雖然我只是舉了一種分布式存儲系統，但其他分布式存儲系統也會有這樣那樣的小問題。
這里我想提醒你注意的是，即便用了分布式存儲服務，我們的運維和研發工作也不輕松。為什么這么說呢？根據我的實踐經驗，我們還需要關注以下五個方面的問題：
- 磁盤監控：
監控磁盤的壽命、容量、inode 剩余。
進行故障監控警告及日常維護。
- 文件管理：
使用分布式存儲控制器對文件做定期、冷熱轉換、定期清理以及文件歸檔等工作。
確保服務穩定：
關注分布式存儲副本同步狀態及服務帶寬。
如果服務流量過大，運維和研發還需要處理好熱點訪問文件緩存的問題。
業務定制化：
一些稍微個性點的需求，比如在文件中附加業務類型的標簽、增加自動 TTL 清理，現有的分布式存儲服務可能無法直接支持，還需要我們閱讀相關源碼，進一步改進代碼才能實現功能。
硬件更新：
服務器用的硬盤壽命普遍不長，特別是用于存儲服務的硬盤，需要定期更換（比如三年一換）。
對象存儲
自從采用分布式存儲后，回想過去的經歷，我意識到樹形磁盤存儲結構給研發帶來了很多額外的工作。比如，在數百臺服務器和磁盤上提供相對路徑和絕對路徑的掛載服務，需要具備文件檢索、遍歷功能，并設置文件的訪問權限。這些管理功能并非我們對外業務所需的高頻使用功能，這種設計導致研發投入過高，超出了本應關注的范圍。
而使用對象存儲服務后，這些問題得到了顯著改善。對象存儲優雅地屏蔽了底層實現細節，將業務和運維工作隔離，使路徑變得簡單明了，讓研發團隊可以更專注于業務發展。
對象存儲的優勢主要體現在以下三個方面：
首先，從文件索引的角度來看，對象存儲弱化了樹形目錄結構，甚至可以說是省略了。盡管如此，樹形目錄結構仍然可以保留。當需要進行運維操作時，可以通過前綴檢索對 Key 進行查找，從而實現目錄管理。這種方式使用方便，無需擔心數據量大導致索引查找緩慢的問題。值得強調的是，對象存儲并不是按照指定路徑進行存儲，實際上，文件路徑僅是一個 Key。當查詢文件對象時，實際上是進行了一次哈希查詢，這比在數據庫中進行字符串前綴匹配查詢要快得多。此外，由于不需要維護整體樹索引，鍵值（KV）方式在查詢和存儲上都大幅提升了效率，同時更容易進行維護。
其次，讀寫管理方式也從原先通過磁盤文件管理，轉變為通過 API 管理文件對象。這種簡化后的接口方式使得數據讀寫變得更加靈活和方便，無需過多考慮磁盤相關的知識。
最后，對象存儲還提供了文件的索引管理與映射，增加了數據和媒體文件的管理可能性。以往，我們的文件主要是圖片、音頻和視頻，這些文件通常在業務系統中是獨立存在的。而結合對象存儲后，我們可以將一些數據作為小文件來管理。然而，這也帶來了大量小文件的管理挑戰。這些小文件往往很零碎，需要更多的管理策略和工具。接下來，我們將探討在對象存儲的思路下，如何有效管理小文件。
對象存儲如何管理小文件
之前曾提到過，在對象存儲當中，實際的存儲路徑已經轉變為通過 hash 方式來進行存儲了。
對此，我們能夠借鑒類似 RESTful 的思路去規劃設計我們的對象存儲路徑，示例如下：
- “user\info\9527.json”，該路徑下保存的是用戶的公共信息。
- “user\info\head\9527.jpg”，這里存放的是與之對應的用戶頭像。
- “product\detail\4527.json”，通過此路徑可直接獲取商品信息。
從上述設計能夠看出，如此一來，我們無需在每次發起請求時都去訪問數據庫，便能夠獲取到特定對象的相關信息。前端只需簡單地對路徑進行拼接操作，就可以拿到所有所需的文件。采用這樣的方式，能夠幫助我們大幅削減緩存的維護成本。
也許看到這里，你心里會存在疑問：既然這個技巧這么好用，那為什么在此之前它沒有得到廣泛普及呢？
這是因為在以往的實現過程中，請求所訪問的路徑就是文件實際的物理存儲路徑。而對于 Linux 系統而言，在同一個目錄下是無法存放過多文件的，要是存放的文件數量過多，就會導致管理起來極為困難。
就拿上面所舉的例子來說，如果我們擁有 300 萬個用戶，將這 300 萬個頭像文件全部放置在同一個目錄下，那么即便是執行一個簡單的 ls 命令，都有可能致使服務器卡頓長達十分鐘之久。
為了避免出現類似這樣的問題，很多服務器在存儲這些小文件的時候，會先對文件名進行 hash 計算，然后取 hash 結果的最后四位作為雙層子目錄名，通過這種方式來確保在一個目錄下不會存在過多的文件。
然而，這樣做就需要進行 hash 計算，這會使得前端在使用時極為不方便，而且我們在平時對磁盤數據進行查找、管理等操作時，也會感覺十分痛苦，所以這種方式遭到了很多人的排斥。
不過，即便切換到了分布式存儲服務，小文件存儲方面的問題依舊會給我們帶來困擾。因為在進行副本同步以及存儲操作時，都是以文件作為基本單位來開展的。倘若文件很小，每秒能夠上傳上千個文件，那么在進行副本同步時，就會由于存在大量的分配調度請求，進而出現延遲現象，這樣一來，要對副本同步的流量進行管理也就變得十分困難了。
針對上述這些問題，對象存儲和分布式存儲服務針對這方面做出了優化，不再將小文件獨立地進行保存，而是采用文件塊的方式對多個文件進行壓縮存儲。
圖片
比如把 100 個文件壓縮存儲到一個 10M 大小的文件塊里統一管理，比直接管理文件簡單很多。不過可以預見這樣數據更新會麻煩，為此我們通常會在小文件更新數據時，直接新建一個文件來更新內容。定期整理數據的時候，才會把新老數據合并寫到新的塊里，清理掉老數據。這里順便提示一句，大文件你也可以使用同樣的方式，切成多個小文件塊來管理，這樣更方便。
對象存儲如何管理大文本
在前面討論了對象存儲在管理小文件方面的優勢后，接下來我們來看看對象存儲如何管理大文本。這種管理方式可以抽象地概括為用對象存儲取代緩存。
那么，什么情況下會有大文本的管理需求呢？比較典型的場景就是新聞資訊網站，尤其是資訊量特別豐富的那些網站，它們常常直接使用對象存儲提供文本服務。這種設計的主要原因是，1KB 以上的大文本并不適合放在數據庫或緩存中。接下來，我們通過后面的示意圖進行分析。
首先，大文本通常具有較大的體積和不規則的訪問模式，這使得將其存儲在數據庫中不僅增加了存儲成本，還可能導致數據庫性能下降。數據庫的設計初衷是高效管理小規模、頻繁更新的數據，而大文本的讀寫操作相對較少，因此將其存儲在數據庫中并不高效。
其次，緩存雖然能加速數據的訪問，但它的內存資源有限。大量大文本的緩存會迅速消耗可用內存，導致緩存命中率降低，從而影響整體性能。因此，對于大文本的管理，直接使用對象存儲會更加合適。
對象存儲提供了高效、靈活的存儲解決方案，能夠處理大文本的存取需求，同時避免了數據庫和緩存中的瓶頸。這使得在需要頻繁更新和訪問的大文本場景中，使用對象存儲成為一種理想的選擇。通過這種方式，我們可以更高效地管理和提供服務，同時確保系統的整體性能。
圖片
如上圖所示，左邊展示了通過緩存提供數據查詢服務的常見方式，而右邊則展示了使用對象存儲的方式。從結構上來看，對象存儲在使用和維護上顯得更為方便和簡單。接下來，我們來估算一下成本。
假設我們的請求訪問量為 1W QPS，那么對于 1KB 的數據緩存服務，帶寬需求可以計算為：
為了留出一些余地，我們大概需要 100MB/s 的帶寬。此外，還需要多臺高性能服務器和一個大容量的緩存集群，以支撐我們的服務。這么一算，成本確實不低。對于資訊類網站這種讀多寫少的系統，如果無法降低維護成本，必然需要更多資源投入。
一種常見的解決方法是將資訊內容直接生成靜態文件，雖然這樣可以控制流量成本，但運維和開發的成本卻會隨之增加。有沒有更好的方法呢？
相較之下，使用對象存儲維護資源的具體頁面則更為高效。具體過程如下：所有流量都會請求云廠商的對象存儲服務，同時通過 CDN 實現緩存和加速。當 CDN 找不到待查文件時，會回源到對象存儲進行查找；如果對象存儲也未找到，則會回源到服務端生成。這種方式大大降低了網絡流量壓力，若配合版本控制功能，還能實現文件的歷史版本回退，提高服務的可用性。
此外，值得補充的是，如果資訊內容存在閱讀權限限制（例如僅限會員閱讀），我們可以對特定對象設置權限，使得只有使用短期有效的 token 才能讀取文件內容。這種做法不僅保護了內容的安全性，也提高了系統的靈活性。
文件的云中轉
圖片
除了通過服務端提供數據供用戶下載之外，還有一種更為普遍的數據交換方式，即用戶之間的文件傳輸。例如，當用戶 A 想傳遞一個文件給用戶 B，通常的做法是通過 TCP 連接兩端客戶端或通過服務端中轉，但這種方式傳輸效率較低。而使用對象存儲則能顯著提升文件傳輸和交換的效率。
主要過程如下：文件傳輸服務為發送方生成一個臨時授權 token，文件上傳至對象存儲后，接收方即可通過該地址和授權 token 進行多線程下載。當臨時文件過期后，系統會自動清除文件。
實際上，這種方式不僅適用于用戶之間的數據交換，業務系統也可利用對象存儲實現跨機房的數據交換和數據備份。許多對象存儲服務提供商的客戶端 SDK 已內置了多線程分片上傳下載和 GSLB（全局服務器負載均衡）就近 CDN 路線優化的上傳加速功能，使用這些服務可大大提高數據傳輸速度。
此外，關于容災，大部分對象存儲服務商都提供容災支持。我們可以為所有數據開啟同城雙活備份、全球加速、災難調度以及主備切換等功能。這種完善的容災機制確保數據在各種情況下都能安全、快速地訪問。
