大数据篇：CAP定理

大数据篇：CAP定理

经过前两章，我们学习了两个重要概念：一致性和可用性。

今天我会讲述与这两个概念相关的一个定理：CAP定理（CAP Theorem）。

CAP定理

CAP这个概念最初是由埃里克·布鲁尔博士提出的。

在两年后，赛思·吉尔伯特和麻省理工学院的南希·林奇教授在他们的论文：Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition- Tolerant Web Services .

他们证明在这篇论文证明了，在任意分布式系统中。一致性（Consistent）、可用性（Availability）和分区容错性（Partition-tolerance）这个三种属性最多只能同时存在两个属性。

下面我们对这三个属性在进一步进行解释（对论文感兴趣的童鞋可以百度进行阅读）

C属性：一致性

这里的一致性指的是线性一致性。保证所有分布式环境下的操作就像在单机上完成的一样，也就是像下图所画出来的一样，Server A、B、C的状态都是一致的。

假设现在有两个操作：操作A、操作B，操作A操作后系统的状态为A状态，操作B操作后系统的状态为B状态。

如果说操作A是在操作B之前操作的，那么系统的状态B一定要比系统的状态A更加的新。

讲到这里，可能很多童鞋都没有看懂，那么没关系我们通过一个例子来更加的理解这种关系。

我们设计了一个分布式的商品秒杀系统，在这个系统中，商品的存货状态分别在服务器A和服务器B中，我们把他的存货状态定义为“有货状态”和“无货状态”，一开始的时候系统A、系统B的状态都为”有货状态“。

过了一段时间，商品被秒杀完了，后台需要对这两台服务器的商品状态更改为无货状态。

因为分布式环境，商品状态在Server A更新完成，显示无货状态。而在Server B，因为服务器的网络延迟导致更新未完成，显示有货状态。

这时，恰巧有两人同时使用这个购物车系统，先后发送了查询请求到后台。

我们假设用户A先发送查询请求，这个查询发送到了Server A，并成功返回无货状态。用户B随后也对该商品发送查询请求，这个查询发送到了Server B上，并成功返回商品是有货状态。

我们知道，这时我们的系统应该是无货状态的，用户A的操作又是在用户B的操作之前的，要是这个系统满足线性一致性的话，用户B的操作应该看到无货状态才对。

这时我们可以说这个系统并不满足线性一致性。

A属性：可用性

在分布式系统中，任意非故障的服务器都必须对客户的请求产生响应。

当分布式系统满足可用性的时候，不管出现什么状况（除非所有服务器全部崩溃），都能返回消息。

也就是说，当客户端向系统发送请求时，只要有一台服务器是未崩溃的，就必须最终响应客户端。

P属性：分区容错性

分区

在一个分布式系统中，如果出现一些故障，可能会使得部分系节点之间无法联通。由于故障节点不能联通，导致整个网络就会被分成几块区域（可以说是脑裂），从而使数据分散在这些无法联通的区域中，可以说这里发生了分区错误。

容错

指分布式系统，发生了一些错误，也需要容忍，系统仍能返回信息。

分区容错性

指的是系统允许网络丢失从一个节点发送到另一个节点的任意多条消息。

我们得明白，在现代网络，节点出现故障或者网络丢包都是时长发生的。如果没有分区容错性，也就是系统不允许这些节点通讯出现任何错误的话，那么我们日常所用到的很多系统就不能再继续工作了。

所以在大部分的情况下，系统设计都会保留P属性，而在C和A中二选一。

CAP的应用

论文中论证了在任意系统中，我们最多保留CAP属性中的两种，也就是CP或者AP或者CA。

那么在我们平常开发中有哪些CP系统、AP系统、CA系统呢？

CP（满足一致性和分区容错性）系统：Hbase、MongoDB、Redis等，这些存储的架构都放弃了高可用性（High Availability 俗称HA），而选择CP属性。

AP（满足可用性和分区容错性）系统：Amazon Dynamo、Apache Cassandra 、Tokyo等存储系统都属于AP系统

CA（满足一致性和可用性）系统：Apache Kafka、传统的关系型数据库（Mysql、Postgres等）等都是属于CA系统

上面说了P属性在现代网络时代中，基本是必选项，而kafka为什么放弃P选择CA属性呢？

放弃了P属性的Kafka

在Kafka的0.8版本后，kafka引入了Replication的概念，Kafla Relocaton通过讲数据复制到不同的节点上，从而增强了数据的持久性（Durability）和可用性（Availability）。在Kafka Replication的系统设计中，所有数据日志存储是设计在同一个数据中心（Data Center）里面的，也就是，在同一个数据中心里网络分区出现的可能性非常小的。

它的具体结构大概是这样的，在Kafka数据副本（Data Replication）的设计中，先通过zk（Zookeeper）选举一个领导者节点（Leader）。这个领导者节点维护一组被称作同步数据副本（In-sync-replica）的节点，所有数据的写入都必须记录在这个领导者节点中记录。

举个例子：假设数据中心有三台服务器，一台被成为领导者节点，另外两台用来保存数据副本，分别为Replication1和Replication2，这两个节点是被领导者节点维护的数据副本。领导者节点知道维护了两个同步数据副本。

当用户写入一条数据"Hello World"

用户输入“Hello World”发送给了领导者。

领导者先保存数据在本地，然后发送消息给Replication1、Replication2。

Replication1、Replication2收到消息并保存，回复领导者节点保存成功。

领导者收到健康信号，保存副本在本地，返回给客户端写入成功。

图中绿色部分表示领导者节点的本地日志，记录哪个节点是健康的

假设其中一个副本与领导者无法进行通讯，那么流程是怎样呢？

用户输入“Hello World”发送给了领导者。

领导者先保存数据在本地，然后发送消息给Replication1、Replication2。

Replication1收到消息并保存，回复领导者节点保存成功，Replication2由于网络问题，未收到信息，不保存。

领导者收到Replication1的健康信号，保存副本在本地，返回给客户端写入成功。

如果Replication1也无法响应，kafka允许只有一个节点在工作，那就是Leader节点，流程如下：

用户输入“Hello World”发送给了领导者。

领导者先保存数据在本地，然后发送消息给Replication1、Replication2。

领导者未收到两个节点的健康信息，直接返回客户端保存成功。

当然最坏的情况下是领导节点也挂了，就会由zk选举出一个新的领导节点。

总结

通过这一篇文章的讲解，我们了解了CAP理论的由来，以及对CAP理论各个属性的介绍，知道一致性、可用性、分区容错性，只能选择两种属性进行保留，但是其实经过了20来年的演化，人们对CAP各属性也有了各自的定义了。

作为我们这种开发者，需要更熟悉这些理论，以便我们在设计中做出最好的抉择。

下期预告：如何区分批处理和流处理