浅谈分布式CAP定理

互联网发展到如今，因为数据量大、操做并发高等问题，大部分网站项目都采用分布式的架构。

而分布式系统最大的特色数据分散，在不一样网络节点在某些时刻（数据未同步完，数据丢失），数据会不一致。

在2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜测：一致性、可用性和分区容错性三者没法在分布式系统中被同时知足，而且最多只能知足其中两个！

在2002年，Lynch证实其猜测，上升为定理。被这就是你们所认知的CAP定理。

CAP是全部分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。

CAP定义

所谓的CAP就是分布式系统的三个特性：

<!-- more -->

• Consistency，一致性。全部分布式节点的数据是否一致。
• Availability，可用性。在部分节点有问题的状况（数据不一致、节点故障）下，是否能继续响应服务（可用）。
• Partition tolerance，分区容错性。容许在节点（分区）数据不一致的状况。

深刻理解

有A、B、C三个分布式数据库。

当A、B、C的数据是彻底相同，那么就符合定理中的Consistency（一致性）。

假如A的数据与B的数据不相同，可是总体的服务（包含A、B、C的总体）没有宕机，依然能够对外系统服务，那么就符合定理中的Availability（可用性）。

分布式数据库是没有办法百分百时刻保持各个节点数据一致的。假设一个用户再A库上更新了一条记录，在更新完这一刻，A与B、C库的数据是不一致的。这种状况在分布式数据库上是必然存在的。这就是Partition tolerance（分区容错性）

当数据不一致的时候，一定是知足分区容错性，若是不知足，那么这个就不是一个可靠的分布式系统。

然而在数据不一致的状况下，系统要么选择优先保持数据一致性，这样的话。系统首先要作的是数据的同步操做，此时须要暂停系统的响应。这就是知足CP。

若系统优先选择可用性，那么在数据不一致的状况下，会在第一时间放弃一致性，让总体系统依然能运转工做。这就是AP。

因此，分布式系统在一般状况下，要不就知足CP，要不就知足AP。

那么有没有知足CA的呢？有，当分布式节点为1的时候，不存在P，天然就会知足CA了。

例子

上面说到，分区容错性是分布式系统中一定要知足的，须要权衡的是系统的一致性与可用性。那么常见的分布式系统是基于怎样的权衡设计的。

• Zookeeper

保证CP。当主节点故障的时候，Zookeeper会从新选主。此时Zookeeper是不可用的，须要等待选主结束才能从新提供注册服务。显然，Zookeeper在节点故障的时候，并无知足可用性的特性。在网络状况复杂的生产环境下，这样的的状况出现的几率也是有的。一旦出现，若是依赖Zookeeper的部分会卡顿，在大型系统上，很容易引发系统的雪崩。这也是大型项目不选Zookeeper当注册中心的缘由。

• Eureka

保证AP。在Eureka中，各个节点是平等的，它们相互注册。挂掉几个节点依然能够提供注册服务的（能够配置成挂掉的比例），若是链接的Eureka发现不可用，会自动切换到其余可用的几点上。另外，当一个服务尝试链接Eureka发现不可用的时候，切换到另一个Eureka服务上，有可能因为故障节点将来得及同步最新配置，因此这个服务读取的数据可能不是最新的。因此当不要求强一致性的状况下，Eureka做为注册中心更为可靠。

• Git

其实Git也是也是分布式数据库。它保证的是CP。很容易猜测到，云端的Git仓库于本地仓库一定是要保证数据的一致性的，若是不一致会先让数据一致再工做。当你修改完本地代码，想push代码到Git仓库上时，假如云端的HEAD与本地的HEAD不一致的时候，会先同步云端的HEAD到本地HEAD，再把本地的HEAD同步到云端。最终保证数据的一致性。

---

更多技术文章、精彩干货，请关注
博客：zackku.com
微信公众号：Zack说码