SpringCloud 之分布式 CAP 定理

CAP 定理

• C、一致性、Consistency： 所有节点访问同一份最新的数据副本。
• A、可用性、Availability)： 保证每个请求不管成功或者失败都有响应。
• P、分区容错性、Partition tolerance： 大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区（partition）。 分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

P的理解： 在整个系统中某个区网络挂掉了，或者宕机了，并不影响整个系统的运作或者说使用。比如美国的服务器挂了，因为还有中国的服务器，所以系统正常运行。
分区容错是无法避免的，因此可以认为 CAP 的 P 总是成立。剩下的 C 和 A 无法同时做到。

分布式系统中实现一致性的 raft 算法、paxos
http://thesecretlivesofdata.com/raft/

Zookeeper(CP)： 集群 Leader 挂了会重新选举，此时暂停对外服务。
Eureka集群(AP)： 发现连接失败，则会自动切换至其他的节点，只要有一台还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）。
Nacos集群(AP)： Leader 挂了，不影响服务之间互相调用、不影响服务注册、不影响服务正常启动拉取配置文件。
Redis集群(AP)： Sentinel 模式如果 master 数据未及时同步到 slave，正常运行，不会阻塞等到数据同步到 slave才恢复。

实践：
比如现在有三台机器：Server1、Server2和Server3.在高可用方案中，三台机器要两两注册。比如S1要向S2、S3分别进行注册，目前他无法实现注册的传递性。 这样一来，如果Server1宕机，我们还可以继续从Server2和3中获取服务。
在CAP理论中，zookeeper更看重C和P，即一致性和分区容错性。但Eureka更在意的是A和P，A为高可用。zookeeper中有master和follower区别，当进入选举模式时，就无法正常对外提供服务。但Eureka中，集群是对等的，地位是相同的，虽不能保证一致性，但至少可以提供注册服务。 根据不同的业务场景，各有取舍吧。

为何CAP三者不可兼得

假设有两台服务器，一台放着应用A和数据库V，一台放着应用B和数据库V，他们之间的网络可以互通，也就相当于分布式系统的两个部分。
在满足一致性的时候，两台服务器 N1和N2，一开始两台服务器的数据是一样的，DB0=DB0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。

当用户通过N1中的A应用请求数据更新到服务器DB0后，这时N1中的服务器DB0变为DB1，通过分布式系统的数据同步更新操作，N2服务器中的数据库V0也更新为了DB1，这时，用户通过B向数据库发起请求得到的数据就是即时更新后的数据DB1。

上面是正常运作的情况，但分布式系统中，最大的问题就是网络传输问题，现在假设一种极端情况，N1和N2之间的网络断开了，但我们仍要支持这种网络异常，也就是满足分区容错性，那么这样能不能同时满足一致性和可用性呢？

假设N1和N2之间通信的时候网络突然出现故障，有用户向N1发送数据更新请求，那N1中的数据DB0将被更新为DB1，由于网络是断开的，N2中的数据库仍旧是DB0；

如果这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据DB1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据DB0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1。

上面的过程比较简单，但也说明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。也就是说分布式系统不可能同时满足三个特性。这就需要我们在搭建系统时进行取舍了。

参考：
浅谈Nacos中的CAP