大数据时代的装逼利器之CAP理论

诸位读者在读这篇文章之前请先举个手，有没有谁听说过CAP理论，又有谁明白CAP理论到底是个什么东西的？作为新时代的码农和数据工程师，在大数据的浪潮下要是连CAP都不知道的话，那么我相信很容易这会成为诸位面试新职位的一个CAP，也会让大家在大数据时代显得特别的无知。

简单回顾一下CAP的历史，2000年由UC Berkeley的Eric Brewer提出，并由2002年被MIT的俩大牛证明，是目前一切重要的大数据和分布式系统的基础指导理论，所谓的CAP实际上是：Consistency， Availability 和 Partition Tolerance。

我们先解释一下这几个概念：

Partition Tolerance最容易理解。比如说大卸活人，如果是由你我来操刀，把人切成若干块，那么头也好手也罢脚也好，应该都成死人没反应了，自己还要进个班房吃颗花生米或者注射点什么。换成大卫科伯菲尔德来，那就是切完了，手也好脚也好，头也好，照样都能动。这个人是不是partition tolernce的取决于被partition以后是不是还能够正常工作。所以你我都没这个水平，换个人就可以做到partition tolerance。

Consistency呢，考虑一下湖对岸卖书的，总喜欢人oncall。组里的翠花正好要去夏威夷结婚，于是找了王二麻子商量能不能够换一下schedule。暗恋翠花很久的王二麻子架不住翠花的苦求就答应下来。这时候就找了系统管理员把下周的oncall从翠花换成了王二麻子。结果到了婚礼现场，婚礼进行了一半，已经静音但是连着蓝牙的翠花的手机突然想起来：呼叫翠花，呼叫翠花，有serv1，有serv1，赶紧上线，赶紧上线。这个写进去的是王二麻子，读出来的却是翠花，就不是consistent了。所谓的consistency就算在写操作后面发生的读操作，都会读到最新的版本。

Availability更好理解，还是举个栗子，湖对岸卖书的公司，网站down了，oncall服务紧锣密鼓的进行，但是因为需要被call起立的程序猿太多，结果，call着call着，系统就没办法继续call下去了。所谓的服务不available就算无法在有限的时间内完成服务了。

那么CAP定理说的是神马呢？CAP定理说, 任何一个系统，这仨只能选俩，不可能都满足。这话在理，要不怎么结婚是一夫一妻呢，来了小三就不对了。

盗个图给大家看看所有可能的选项。然而因为我们现在是生活在分布式系统的年代，所以P是永远不可能没有的，因此对于大数据来讲，只有AP和CP的选择了。既然是个定理就需要证明一下，严格的证明我不给了，简单一点的说说为什么AP和CP只能选一个吧。

假设看官您就算是个大数据系统吧，系统出了点问题，被大卫科伯菲尔德连腰砍成了两半。这个时候张三访问了系统的头部，写进了王二麻子下周值班。李四接着跑去腿部问，下周谁值班？ 问题是腿部和头部联系不上，所以只能做出下面两个选择之一：

1. 等联系上了头，核实一下，再回答，但是可能无限等下去
2. 不管三七二十一看看自己知道的是神马，凑和着回答就好，于是回答了翠花，就有了翠花婚礼被call的那一幕。

前者是CP牺牲的A，后者是AP牺牲了C。

那么我们关于CAP的故事讲完了么？其实没有。假如你就这样去面试，面试官肯定会说渣渣，来了一个背书的，fail。CAP理论是一个典型的worst case analysis，问题说一个网络平时不会莫名其妙断开，比如一个人也不会莫名其妙被切两半。那么如果不是worst case的时候CAP理论到底有神马鸟用呢？这实际上是这么多年以来分布式系统的发展过程中被反复的问然后反复的改变的一个问题。在死守worst case的时候必须牺牲某一个的前提下，不是worst case的时候我们应该干一些神马？这个问题才是诸位在面试系统架构和design的时候需要认真思考的。至于答案，其实我也不知道，有太多系统了，没有千篇一律的标准，具体问题具体分析才是王道。