CAP、BASE理论详解

CAP理论：

C（一致性）：所有的节点上的数据保持一致。

A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败。

P（分区容错）：即因为网络问题，导致系统内部有消息丢失，或更严重的产生网络分区，也就是脑裂。

任何分布式系统在可用性、一致性、分区容错性方面，不能兼得，最多只能得其二，因此，任何分布式系统的设计只是在三者中的不同取舍而已。

分区容错性：

只要是分布式系统，那么就需要网络，而网络始终是一个不稳定因素，所以P始终存在！所以CAP中的P不是你想不想的问题，而是因为网络不稳定因素的存在，必然需要保证的容错性！

可用性：

每个请求都可以接受到一个响应，无论是响应成功还是失败，无论响应的数据是最新的还是过期的。

一致性：

一致性问题出现的根源在于：数据复制。那么为什么会有数据复制？拿Mysql数据库来举例，如果只有一个Mysql节点，那么就不存在一致性的问题。但是Mysql单例不能保证高可用啊，或是为了支撑高并发量，多弄了几个从库来做读写分离，此时的Mysql就变成了分布式集群，你看，数据复制出现了。一致性可以分为：强一致性、弱一致性、最终一致性。

强一致性：即分布式集群对外表现为各个节点数据始终一致。同步复制可以保证强一致性。那么什么是同步复制？打个比方：一个更新请求打到主库上，主库自己更新后，主库向所有从库复制数据，待所有复制结束之后，主库对外返回：更新成功。

弱一致性：即分布式集群对外表现为各个节点数据不一定保持一致。异步复制导致弱一致性。那什么是异步复制呢？还是打个比方：一个更新请求打到主库上，主库自己更新后，就对外返回：更新成功，然后主库再向所有从库复制数据。异步复制时虽然外部知道了更新成功，但是如果立刻访问某个从库，拿到的还是旧数据。异步复制导致弱一致性。

最终一致性：即分布式集群对外表现为各个节点的数据虽然在某个时刻内不一定一致，但过了这个时间窗口之后，最终各个节点的数据会保持一致。

场景分析：

所有的分布式中间件都会涉及到CAP的问题，包括Mysql、Kafka、Redis等等。那我们结合场景看看什么样的分布式中间件是CP，什么样的又是AP。

CP without A：

假设一个场景：写请求打到主节点，主节点更新并将数据复制到从节点，所有从节点更新完成之后，主节点对外返回请求：更新成功。首先，需要等待所有从节点更新完成会是一个耗时的过程，响应会很慢，降低了可用性；其次，如果其中一个从节点宕机了，那么主节点一直得到响应，这个请求便一直得到响应，就丧失了可用性。这便是保证了强一致性，而牺牲了可用性。

AP wihtout C：

假设一个场景：写请求打到主节点，主节点更新后，对外返回请求：更新成功。然后主节点向其他从节点复制数据。请求响应很快，首先，虽然请求响应更新成功，但是此时若是访问从节点，获取到的还是旧数据，数据会产生不一致的情况；其次，如果主节点复制数据到某个从节点的过程中发送了数据丢失，那么以后访问该从节点的请求获取到的始终是旧数据，数据永远不一致了。这便是保证了可用性，而牺牲了一致性。

BASE理论：

在实际系统设计时，不能走极端，只有一致性没有可用性的系统是脆弱的，而只有可用性没有一致性的系统是没有价值的。所以有了BASE理论。

基本可用：Basically Available，响应时间上会牺牲一点，给数据复制做出一定妥协。

软状态：Soft State，各个节点数据会有一定的时间窗口内数据不一致，这个时间窗口内的状态为软状态，接受数据延迟。

最终一致性：Eventually Consistent，不可能一直是软状态，当过了这个时间窗口之后，各个节点的数据最终会恢复到一致。