分布式系统那点事（CAP - BASE）

CAP

C（Consistency）：一致性。在同一时间点，各个节点的数据都是完全一致的。

A（Availability）：可用性。即服务在正常的响应时间内对每个请求做出响应。

P(Partition-tolerance)：分区容忍性。在分布式系统中，各个节点组成的网络应该是相互连通的，但是可能因为网络故障原因，导致节点间的网络被分割为多个网络分区，不同的网络分区之间是无法连通的，此时如果某个数据只在其中一个节点中保存，那么当网络分区出现后，与这个节点不连通的客户端就无法访问该数据了，此时分区是无法容忍的。

如何提高分区容忍性？一种方法就是将一份数据进行多次拷贝，存在不同的副本上，保证多个节点都存有该数据，那么当网络分区出现后，不同的网络分区都会存有该数据的副本，容忍性就提高了。

然而当把数据复制到多个节点后，与之带来的问题就是，多个节点的数据如何保证一致性呢？要么牺牲可用性保证一致性，要么牺牲一致性保证可用性。

为什么CAP只能三选二？

CA

对于有多个节点分布式系统中，P是必然存在的，如果只满足CA，那么只能是单机系统。对于关系型数据库，就是保证了CA，忽略了P，如果是数据库集群，一样会存在P的问题。

CP还是CA？

假设有两个节点n1和n2，数据data0存在两个节点上；

正常情况下，用户向n1发送数据更新的请求，n1的data0变更为data1，同时n1会通知n2进行数据变更，将n2节点的data0也变更为data1；但是，如果n1和n2两个节点间的网络发生异常，为了保证P，即n1和n2需要对外提供服务，此时，用户向n1发出请求更新数据data0变更为data1，由于n1和n2的网络断开，n2中的数据依然是data0，一种是选择C，那么需要等到n1和n2网络连通后，将n2的数据从data0变更为data1再向用户响应，那么就牺牲了可用性，系统无法在正常的响应时间内响应请求；一种是选择A，n1立刻响应用户，此时n2节点的数据为脏数据data0，牺牲了数据的一致性。

CAP选择？

在分布式系统中，P是必然存在的，虽然说关系型数据库保证了CA，但是如果要考虑集群、主从同步等，那么也需要考虑P的。

如果一个分布式系统不要求强的可用性，那么可以选择CP，一旦发生网络故障等异常情况，那么需要牺牲用户的体验，等待所有数据一致了再让用户访问系统。许多分布式数据库如redis，hbase和zookeeper等都是优先保证了CP的。（zookeeper是分布式协调服务，作用就是保证各个节点之间的数据同步）

如果为了用户体验，而允许中间态，追求最终数据一致性，那么可以选择AP，如12306购票，以及京东金融app出现的用户查看余额错误等。

一般来说，对于交易场景，C是必须保证的，如果网络发生故障，宁可不提供服务，也不能发生自损。其他的场景，一般会选择AP，舍弃了强一致性，追求最终一致性，这也是下面要说的BASE理论。

BASE

BASE指的是基本可用、软状态和最终一致性，是对CAP理论的补充。

基本可用

当分布式系统出现故障时，允许损失部分可用性，保证核心功能可用。比如在电商大促时，为了应对大流量、高并发的场景，部分用户可能会引导至降级页面，部分服务也会进行降级（如不允许进行还款和退款等），保证了交易的正常进行。这就是损失了部分的可用性。

软状态

允许系统中存在中间状态，但是不会影响系统整体可用性。在分布式系统中一般会存有一份数据的多个副本，允许不同节点间副本同步的延时。mysql主从同步就是这样。

最终一致性

所有副本经过一段时间后，最终能够保证数据处于一致的状态。

参考链接1-BASE

参考链接2-BASE