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