分布式存储系统设计的若干原则

原文载于：http://blog.csdn.net/liuaigui/article/details/6196290  作者：刘爱贵

1、CAP理论
2000年Eric Brewer教授提出了著名的CAP理论，即：一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。2002年MIT的Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。因此系统架构师不要把精力浪费在如何设计才能同时满足CAP三者的完美分布式系统，而是应该研究如何进行取舍，满足实际的业务需求。

C: Consistency(一致性)，任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的；
A: Availability(可用性)，每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的；
P: Tolerance of network Partition(分区容忍性)，在出现网络分区（比如断网）的情况下，分离的系统也能正常运行；
对于分布式存储系统而言，分区容错性(P)是基本需求，因此只有CP和AP两种选择。CP模式保证分布在网络上不同节点数据的一致性，但对可用性支持不足，这类系统主要有BigTable, HBASE, MongoDB, Redis, MemcacheDB, Berkeley DB等。AP模式主要以实现"最终一致性（Eventual Consistency）"来确保可用性和分区容忍性，但弱化了数据一致性要求，典型系统包括Dynamo, Tokyo Cabinet, Cassandra, CouchDB, SimpleDB等。

2、Eventual Consistency(最终一致性)
简而言之：过程松，结果紧，最终结果必须保持一致性。

从客户端考虑数据一致性模型，假设如下场景：
存储系统：它在本质上是大规模且高度分布的系统，其创建目的是为了保证耐用性和可用性。
进程A：对存储系统进行读写。
进程B和C：这两个进程完全独立于进程A，也读写存储系统。客户端一致性必须处理一个观察者（在此即进程A、B或C）如何以及何时看到存储系统中的一个数据对象被更新。

根据以上场景可以得到如下三种一致性模型：
强一致性：在更新完成后，（A、B或C进行的）任何后续访问都将返回更新过的值。
弱一致性：系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。
最终一致性：这是弱一致性的一种特殊形式；存储系统保证如果对象没有新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，不一致窗口的最大值可以根据下列因素确定，比如通信延迟、系统负载、复制方案涉及的副本数量。

客户端一致性模型的变体有：
因果一致性(Causal consistency)：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
“读己之所写”一致性(Read-your-writes consistency)：这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
会话一致性(Session consistency)：这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性，系统保证也不会延续到新的会话。
单调读一致性(Monotonic read consistency)：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
单调写一致性(Monotonic write consistency)：系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

3、BASE理论
BASE，即Basically Availble（基本可用）、Soft-state （软状态）、Eventual Consistency （最终一致性）。BASE的英文意义是碱，而ACID是酸，有点水火不容的意思。
关系数据库的ACID模型拥有高一致性和可靠性，丧失可用性。ACID，即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。其中的一致性强调事务完成时，数据库处于一致的状态。对于很多应用来说，一致性要求可以降低，而可用性(Availability)的要求则更为明显。从而产生了弱一致性的理论BASE。 BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性。它仅需要保证系统基本可用，支持分区失败，允许状态在一定时间内不同步，保证数据达到最终一致性即可。BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

4、I/O五分钟法则
1987年，Jim Gray 与 Gianfranco Putzolu 发表了"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持1KB的数据成本相当于硬盘中存储400秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。
根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

5、Amdahl定律和Gustafson定律
这里我们以S(n)表示n核系统对具体程序的加速比，K表示串行部分计算时间比例。
Amdahl 定律的加速比：S(n) ＝ 使用1个处理器的串行计算时间 / 使用n个处理器的并行计算时间，S(n) = 1/(K+(1-K)/n) = n/(1+(n-1)K)
Gustafson定律的加速比：S(n) ＝ 使用n个处理器的并行计算量 / 使用1个处理器的串行计算量，S(n) = K+(1-K)n
通俗的讲，Amdahl定律将工作量看作1，有n核也只能分担1-K的工作量；而Gustafson定律则将单核工作量看作1，有n核就可以增加n(1-K)的工作量。这里没有考虑引进分布式带来的开销，如网络和加锁。从性能价格比的角度看，并不是越分布越好。

6、摩尔定律
摩尔定律是由英特尔（Intel）创始人之一戈登・摩尔（Gordon Moore）提出来的。其内容为：集成电路上可容纳的晶体管数目，约每隔18个月便会增加一倍，性能也将提升一倍，当价格不变时；或者说，每一美元所能买到的电脑性能，将每隔18个月翻两倍以上。这一定律揭示了信息技术进步的速度。"Tape is dead, disk is tape, flash is disk, RAM locality is king." Jim Gray - 2006. 从系统Scale-up的角度看，花费大量的时间和精力来提高系统性能，如Cache，数据预测与预取，数据局部性，并发性等，可能还不如扩充内存量、使用SSD替换传统磁盘来得直接和划算。计算机硬件的更新速度越来越快，成本也越为越低。作为一名系统架构师，应该充分考虑摩尔定律的影响，使用更经济、合理和简单的方法来实现系统性能目标。

7、推荐阅读
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services:　http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
Brewer's CAP Theorem: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Brewers CAP theorem on distributed systems: http://www.royans.net/arch/brewers-cap-theorem-on-distributed-systems
Towards Robust　Distributed Systems：http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
NoSQL数据库笔谈：http://sebug.net/paper/databases/nosql/Nosql.html#CAP_7730791447684169_231516710
Visual Guide to NoSQL Systems：http://blog.nahurst.com/visual-guide-to-nosql-systems/?c=1