分布式之CAP理论

CAP理论

起源于2000年，CAP定理称作布鲁尔定理。

CAP理论正式成为分布式领域的定理。

简介

CAP也就是Consistency（一致性）、Availablity（可用性）、Partition Tolerance（分区容错性）

CAP定理指出对于一个分布式系统来说，当设计读写操作时候，只能同时满足以下三点中的两个：

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

可用性：非故障的节点在合理的时间内返回合理的响应。

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

什么是网络分区

分布式系统，多个节点之前的网络本来是连通的，但是因为某些故障某些节点之间联通不聊了，整个网络分为几块区域，这就叫网络分区。

不是所谓的“3选2”

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1，也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性。

简单的说即使：CAP理论中P是一定要满足的，在此基础上，只能满足可用性A或者一致性C。

所以，分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。

ZooKeeper、HBase就是CP架构，Eureka就是AP架构，Nacos不仅支持AP架构也支持CP架构。

为什么不能选CA架构呢？

若系统出现分区，系统的某个节点进行写操作。为了保证C，必须要禁止其他结点的读写操作，这就是和A发生冲突了。如果为了保证A，其他节点的读写操作正常的话，那就是和C发生冲突了。

选择CP还是AP的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如CP架构。

如果网络分区正常的话，也就是不需要保证P的时候，C和A能够同时保持。

CAP实际应用案例

  我这里以注册中心来探讨一下CAP的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里以Dubbo为例说一说。

下图是Dubbo的架构图。注册中心Registry在其中扮演了什么角色呢？提供了什么服务呢？

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

常见的key作为注册中心的组件有：ZooKeeper、Eureka、Nacos....。

常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos

1、Zookeeper保证的是CP。任何时刻对ZooKeeper的读请求都能得到一致性的结果，但是ZooKeeper不保证每次请求的可用性比如在Leader选举过程中或者半数以上的及其不可用的时候，服务就是不可用的。

2、Eureka保证的则是AP。Eureka的设计的时候就是有限保证A（可用性）。在Eureka中不存在什么Leader节点，每个节点都是一样的、平等的。因此Eureka不会像ZooKeeper那样出现选举过程中或者半数以上的及其不可用的时候服务就是不可用的情况。Eureka保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。

3、Nacos不仅支持CP也支持AP。

总结

在进行分布式系统设计和开发时候，我们不应该仅仅局限在CAP问题上，还要关注系统的扩展性、可用性等等

在系统发生“分区”的情况下，CAP理论只能满足CP或者AP。要注意的是，这里的前提是系统发生了“分区”

如果系统么有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在P了。这个时候我们就可以同时保证C和A了。

最后！ 如果系统发生了“分区”，我们要考虑选择CP还是AP。如果系统没有发生“分区”的话，我们要思考如何保证CA。