本篇文章主要介绍了" Dropbox的神奇口袋：Dropbox架构详析第二篇"，主要涉及到方面的内容，对于产品设计感兴趣的同学可以参考一下：
自从内部使用、扩展至EB级别的存储系统“Magic Pocket”发布之后，我们收到了很多正面反馈。我们会继续跟进Magic Po...
自从内部使用、扩展至EB级别的存储系统“Magic Pocket”发布之后，我们收到了很多正面反馈。我们会继续跟进Magic Pocket，陆续发布一系列技术博文，从各种有趣的角度来观察这个系统，包括我们的保护机制、操作工具以及软件与硬件之间的方法创新。不过首先，我们需要了解一些背景：在本文中，我们会从宏观角度对Magic Pocket的架构以及设计标准做以概览。
在之前的序篇中我们解释过(注：上篇的翻译请点击这里查看)，Dropbox存储两类数据：文件内容与文件/用户的元数据。Magic Pocket是我们用来存储文件内容的系统，这些文件被分成块状存储，并存有副本以保证持久化，它们分布在整个系统中的多个物理位置上。
虽然Magic Pocket的基础是相当简单的核心协议组，但它本身仍是庞大而复杂的系统，因此我们需要略过一些细节。欢迎反馈，我们会在后续文章中尽量深入探究。
注：在Dropbox内部，这个系统也被称为“MP”，这样我们就不用因为老提起“神奇(Magic)”这个词而感觉傻乎乎的了，本文中我们也会用MP来代指这个系统。
需求
不可变的数据块存储
MP是一个具有不变性的数据块存储系统，其中存储了多达4MB的加密块区文件，某个数据块一旦写入系统就不会再发生变化。不变性让一切简单得多。
当用户在Dropbox上对文件作出变更时，我们会在另一个单独的系统中(FileJournal)记录下所有的变更。这样一来，通过将支持易变性的逻辑转移到堆栈的更高层级，就能简单地存储不变的数据块了。许多大规模的存储系统都对可变数据块提供内部支持，但在较低层级中一般都是基于不可变的存储基元。
工作负载
Dropbox有很多数据，并具有高度的时间局部性(temporal locality)。许多数据在上传后一个小时之内会有频繁的访问量，而随着时间流逝，访问频率也会越来越低。这种模式合乎情理：Dropbox的用户有大量的协作任务，因此文件上传后很可能需要同步到其它设备上。但我们仍需要可靠的快速访问：也许从1997年开始你就没怎么看过税务记录了，但在需要的时候，你会想要立即看到。我们有一个相当“冷”的存储系统，但需要以低延迟快速访问所有数据区域。
为了处理这种工作负载，我们在构建系统时用到了硬盘驱动，由于硬盘具有持久、价廉、存储密集、延迟较低等优势，我们使用了SSD盘来保存数据库以及缓存内容。对于新近上传的内容，我们使用了高度的初始复制与缓存技术;而对于其余的数据，我们使用了更为高效的存储编码技术。
持久性
在MP中，持久性是必备的。理论上，我们要求系统的持久性能保持到地老天荒，除非小行星导致天灾——我们有更重要的事情要操心，不能因为随机的磁盘故障就出现数据损毁的问题。这些数据以效率更高的纠删码(erasure-coded)形式存储，同时还使用了跨区(地理位置)高度复制以保障在灾难或自然灾害发生时数据的安全性。
规模
对工程师来说，这个部分非常有趣，MP必须在差不多半年的时间里，从初始数十PB的原型成长到EB级别的庞然大物，这可真是空前的转变。因此，我们需要花费大量时间来思考、设计、构建原型，以克服能预见到的瓶颈问题。在这个过程中，我们也确认了这个架构完全可以扩展，因此在出现不可预知的需求时，也能进行相应的修改。
关于不可预知的需求，其实有很多例子：比如流量突然增长，网络集群间的路由器工作负载逐渐饱和。因此，我们需要修改数据存放的算法以及路径请求，以便更好地反映集群间的关联(以及可用存储量、集群成长计划等)，并最终为集群间的网络架构带来改变。
简单性
