分布式云存储系统的基础 CAP理论.docVIP

分布式云存储系统的基础 CAP理论 2000年7月19号，周三，对主流文化来说并不（象前者一样）具有同样的重要性，但这个日子对互联网公司来说，和25年Sex Pistols对音乐所做的一样，具有同样的影响。这就是Eric Brewer在ACM研讨会上关于分布式计算的原则（Principles of Distributed Computing）所做的开题演讲 （keynote speech）。 Sex Pistols向同时代的人展示了几乎无限制的狂躁远比学院派的结构主义重要的多，给任何人3根弦以及一些许可就可以组建一支乐队。Eric Brewer，在那时被称为Brewer猜想，认为当应用系统变得越来越web化，应当放弃对数据一致性（data consistency）的担忧，因为要想获得这种新的分布式系统的高可用性（high availability），确保数据一致性是我们无法做到的，这样给予任何人3台服务器和一双关注客户体验的眼睛就可以建立一家互联网公司。Brewer的信徒（当天就有的和后来皈依的）包括像Amazon, EBay和Twitter这类公司 2年后，2002年，麻省理工（MIT）的Seth Gilbert和Nancy Lynch，理论上证明了Brewer猜想是正确的，就此Brewer定理（Theorem）诞生了。 Brewer（CAP）定理 那么到底Brewer的定理是什么，为何它足以和1976年Manchester的punk演出媲美？ Brewer 在2000年的演讲是基于他在UC Berkley的理论工作以及主持Inktomi（期间）的观察，是通过数年前Brewer和其他人，在如何构建高伸缩性系统（highly scalable system）时所做出的各种折衷方案的讨论（例如：SOSP（Symposium on Operating System Principles）的1997年的Cluster-Based Scalable Network Service和1999年的Harvest, yield, and scalable tolerant system）就像其他的许多思想，因此这个演讲的内容并不是全新的，它是许多聪明人的共同成果（我确信Brewer会很快说明这一点）。 Brewer认为在分布式的环境下设计和部署系统时，有3个核心的系统需求（systemic requirements），以一种特殊的关系存在。（他主要是谈论Web类的应用，但如今非常多的公司业务是多站点／多国家的，因此该理论同样适用于你的数据中心/LAN/WAN的设计） 这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 － CAP。 要想将该理论和现实的联系起来，让我们举一个简单的例子：你想购买一套托尔斯泰的《战争与和平》，以便在明天开始的长假中有可读的东西。然而你最喜欢的网上书店只有一本库存了。你进行搜索，确认书可以在你出发前送到，然后将书加入你的购物车。接着你想起来还有一些其他的东西要买，所以继续浏览网站（你是否在网站只买一件东西？当然要充分利用包裹的费用了）。但当你查看某个防晒霜的客户反馈时，国内某个地方的某个人，进入网站，将那本书加入到自己的购物车，然后直接付款（他们急需解决桌子摇晃的问题，其中一条桌脚比其他的短的多）。 Consistency一个服务是一致的完整操作或完全不操作（A service that is consistent operates fully or not at all，精确起见列出原文，也有人将其简称为数据一致性）。Gilbert 和Lynch在他们的证明中使用“atomic”而不是consistent，技术上来讲更准确，因为严格来说，当用在数据库事务的属性中时，consistent是指ACID中的C，其含义是如果数据违反了某些预设的约束（preset constraints）就不能被持久化（persisted）。但如果你将其认为是分布式系统中的一个预设约束：不允许同一数据有不同的值，那么我认为这个抽象概念的漏洞就被堵住了（而且，如果Brewer使用atomic这个词，就会被称为AAP定理，那每次我们读它的时候都会被送进医院）（注：我估计是有口吃加白痴的嫌疑）。在前面购书的例子中，你将书加入购物车或无法加入。支付成功或不成功。你无法部分加入或部分支付一本书。库存中只有一本书，当天只有一个人能得到它。如果2个客户都可以完成订单流程（如完成支付），那么仓库中的和系统中的不一致性就会导致问题。在这个例子中也许并不是个大问题：某个人在假期中会很无聊或摆弄防晒霜，但如果将其扩大到数千个不一致性，并且涉及到金钱（例如：金融交易中关于买卖