??
　　自從內(nèi)部使用、擴(kuò)展至EB級別的存儲系統(tǒng)“Magic Pocket”發(fā)布之后，我們收到了很多正面反饋。我們會繼續(xù)跟進(jìn)Magic Pocket，陸續(xù)發(fā)布一系列技術(shù)博文，從各種有趣的角度來觀察這個系統(tǒng)，包括我們的保護(hù)機(jī)制、操作工具以及軟件與硬件之間的方法創(chuàng)新。不過首先，我們需要了解一些背景：在本文中，我們會從宏觀角度對Magic Pocket的架構(gòu)以及設(shè)計標(biāo)準(zhǔn)做以概覽。
　　在之前的序篇中我們解釋過（注：上篇的翻譯請點擊這里查看），Dropbox存儲兩類數(shù)據(jù)：文件內(nèi)容與文件/用戶的元數(shù)據(jù)。Magic Pocket是我們用來存儲文件內(nèi)容的系統(tǒng)，這些文件被分成塊狀存儲，并存有副本以保證持久化，它們分布在整個系統(tǒng)中的多個物理位置上。
　　雖然Magic Pocket的基礎(chǔ)是相當(dāng)簡單的核心協(xié)議組，但它本身仍是龐大而復(fù)雜的系統(tǒng)，因此我們需要略過一些細(xì)節(jié)。歡迎反饋，我們會在后續(xù)文章中盡量深入探究。
　　注：在Dropbox內(nèi)部，這個系統(tǒng)也被稱為“MP”，這樣我們就不用因為老提起“神奇（Magic）”這個詞而感覺傻乎乎的了，本文中我們也會用MP來代指這個系統(tǒng)。
　　需求
　　不可變的數(shù)據(jù)塊存儲
　　MP是一個具有不變性的數(shù)據(jù)塊存儲系統(tǒng)，其中存儲了多達(dá)4MB的加密塊區(qū)文件，某個數(shù)據(jù)塊一旦寫入系統(tǒng)就不會再發(fā)生變化。不變性讓一切簡單得多。
　　當(dāng)用戶在Dropbox上對文件作出變更時，我們會在另一個單獨的系統(tǒng)中（FileJournal）記錄下所有的變更。這樣一來，通過將支持易變性的邏輯轉(zhuǎn)移到堆棧的更高層級，就能簡單地存儲不變的數(shù)據(jù)塊了。許多大規(guī)模的存儲系統(tǒng)都對可變數(shù)據(jù)塊提供內(nèi)部支持，但在較低層級中一般都是基于不可變的存儲基元。
　　工作負(fù)載
　　Dropbox有很多數(shù)據(jù)，并具有高度的時間局部性（temporal locality）。許多數(shù)據(jù)在上傳后一個小時之內(nèi)會有頻繁的訪問量，而隨著時間流逝，訪問頻率也會越來越低。這種模式合乎情理：Dropbox的用戶有大量的協(xié)作任務(wù)，因此文件上傳后很可能需要同步到其它設(shè)備上。但我們?nèi)孕枰煽康目焖僭L問：也許從1997年開始你就沒怎么看過稅務(wù)記錄了，但在需要的時候，你會想要立即看到。我們有一個相當(dāng)“冷”的存儲系統(tǒng)，但需要以低延遲快速訪問所有數(shù)據(jù)區(qū)域。
　　為了處理這種工作負(fù)載，我們在構(gòu)建系統(tǒng)時用到了硬盤驅(qū)動，由于硬盤具有持久、價廉、存儲密集、延遲較低等優(yōu)勢，我們使用了SSD盤來保存數(shù)據(jù)庫以及緩存內(nèi)容。對于新近上傳的內(nèi)容，我們使用了高度的初始復(fù)制與緩存技術(shù)；而對于其余的數(shù)據(jù)，我們使用了更為高效的存儲編碼技術(shù)。
　　持久性
　　在MP中，持久性是必備的。理論上，我們要求系統(tǒng)的持久性能保持到地老天荒，除非小行星導(dǎo)致天災(zāi)——我們有更重要的事情要操心，不能因為隨機(jī)的磁盤故障就出現(xiàn)數(shù)據(jù)損毀的問題。這些數(shù)據(jù)以效率更高的糾刪碼（erasure-coded）形式存儲，同時還使用了跨區(qū)（地理位置）高度復(fù)制以保障在災(zāi)難或自然災(zāi)害發(fā)生時數(shù)據(jù)的安全性。
　　規(guī)模
　　對工程師來說，這個部分非常有趣，MP必須在差不多半年的時間里，從初始數(shù)十PB的原型成長到EB級別的龐然大物，這可真是空前的轉(zhuǎn)變。因此，我們需要花費大量時間來思考、設(shè)計、構(gòu)建原型，以克服能預(yù)見到的瓶頸問題。在這個過程中，我們也確認(rèn)了這個架構(gòu)完全可以擴(kuò)展，因此在出現(xiàn)不可預(yù)知的需求時，也能進(jìn)行相應(yīng)的修改。
　　關(guān)于不可預(yù)知的需求，其實有很多例子：比如流量突然增長，網(wǎng)絡(luò)集群間的路由器工作負(fù)載逐漸飽和。因此，我們需要修改數(shù)據(jù)存放的算法以及路徑請求，以便更好地反映集群間的關(guān)聯(lián)（以及可用存儲量、集群成長計劃等），并最終為集群間的網(wǎng)絡(luò)架構(gòu)帶來改變。
　　簡單性
　　是個工程師都知道，復(fù)雜性通常會導(dǎo)致不可靠性。有很多人在花費大量時間編寫復(fù)雜的一致性協(xié)議后發(fā)現(xiàn)：在Paxos算法的重實現(xiàn)上浪費一整天可不是什么好主意。MP盡可能避免了quorum一致或分布式協(xié)作的情況，并在使用容錯及可伸縮方式時大量利用集中的協(xié)作點。有時在數(shù)據(jù)塊索引（Block Index）中，我們可以選擇分布式哈希表或trie樹，而不僅是巨大的分片MySQL集群。這一決策在簡化開發(fā)與減少未知因素方面表現(xiàn)非常優(yōu)秀。
　　數(shù)據(jù)模型
　　在討論架構(gòu)自身之前，我們先來研究一下所存儲的內(nèi)容。
　　在Dropbox的MP系統(tǒng)中，存儲的是最大4MB的文件數(shù)據(jù)塊：
　　
　　經(jīng)過壓縮加密后，這些數(shù)據(jù)塊（block）被發(fā)送到MP中進(jìn)行存儲，每個數(shù)據(jù)塊都需要一個鍵值或者名稱，大多情況下我們會使用SHA-256哈希。
　　然而在EB級別的存儲系統(tǒng)中，4MB的數(shù)據(jù)量猶如滄海一粟，如果需要替換磁盤或者對某些數(shù)據(jù)使用糾刪碼技術(shù)，這個大小就顯得太小了。為了簡化這個問題，我們將這些數(shù)據(jù)塊整合成1GB大小的邏輯存儲容器，稱為bucket。指定bucket中的數(shù)據(jù)塊無需有什么相同的特性，只是上傳的時間差不多相同。
　　為了保證可靠性，我們需要將這些bucket復(fù)制到多臺物理機(jī)器上，新近上傳的數(shù)據(jù)塊可直接復(fù)制到多臺機(jī)器上。最終系統(tǒng)會將包含數(shù)據(jù)塊的bucket整合到一起，再通過糾刪碼技術(shù)提高存儲的效率。我們使用volume來指代復(fù)制到一系列物理存儲節(jié)點的一個或多個bucket。