分布式之什么是CAP定理

[版权申明] 非商业目的注明出处可自由转载
出自：shusheng007

概述

前段时间看到微服务注册中心的如何选择问题，在比较 Netflix eureka 与 Apache zookeeper的时候，总是有人提到CAP定理。很久以前就听说过这个定理，但是当时没有去认真去理解它，这次认真研究了一下，作为笔记简单记录一下。

历史

根据维基百科记载，这个定理起源于加州大学柏克莱分校（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会（PODC）上提出的一个猜想。在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。

定义

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistency）

所有节点访问同一份最新的数据副本

• 可用性（Availability）

每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据

• 分区容错性（Partition tolerance）

分布式系统出现网络分区的时候，仍然能够对外提供服务。

如何理解

首先要明白这个理论是针对分布式系统的，如果你就一个服务且部署在一台机器上就根本涉及不到上面那三条，因为你的数据一定是一致的，如果应用不挂且网络不挂你的服务就一直可用的，任何一个挂了就直接不可用了，还有根本不可能涉及分区的概念。

就是因为分布式的存在才需要讨论上面那三个概念。假如我们有两服务，S1部署在北京机房，S2部署在天津机房。

一致性：

S1的数据改变了，它就需要通过网络同步给S2,使两边的数据保持一直。S2数据改变同理

可用性：

S1突然挂了，那么S2还可以继续提供服务，所以整个服务仍然是可用的(部分可用)，S2同理。

分区容错：

假设廊坊突然要修地铁，蓝翔一小伙一铲子下去把连接两个机房的光缆挖断了，这下有好戏看了。S1完全联系不到S2了，这就发生了分区，因为以前大家互相之间可以通信，可以看做是一个整体，现在互相之间无法通信，就都各自成了孤岛。此时系统设计者就面临一个抉择：是保一致性（PC），还是保可用性(PA)。为什么会这样呢？

如果你要保一致性，那么可用性就得被舍弃，反之亦然。

因为只是连接北京和天津这两个机房的光缆被挖断了，其他地方的用户仍然可以正常访问这两个机房的服务。假设S1是一个负责取钱的服务，而S2是一个负责结算的服务。如果王二狗能访问S1取出200万来，就要出事，因为S2根本不知道这回事，不进行扣款，二狗儿子学区房首付有了！也有可能S2无故扣了二狗200万，二狗瞬间加入了丐帮。这就是保可用性的代价，数据一致性被丢弃了，对于这种要求数据强一致性的场景，就要放弃可用性了，就是说一旦发生了分区，整个服务就不对外提供服务了。此时最好提示：“对不起，俺们服务正在升级，请24小时候再试。”其实就是不能用了，这也是银行的系统为什么总升级。但是有些场景对数据一致性要求较低，但对服务的可用性要求较高时保可用性，牺牲一致性。

总结

理论这玩意比较玄乎，还需要我们在实践中不断体会。一般认为当发生分区时，Eureka保A弃C,而ZooKeeper保C弃A。那么哪个更好呢？没有什么东西是最好的，需要看具体的使用场景了。