《重新定义Spring Cloud实战》——3.3.2　AP优于CP

3.3.2　AP优于CP

分布式系统领域有个重要的CAP理论，该理论由加州大学伯克利分校的Eric Brewer教授提出，由麻省理工学院的Seth Gilbert和Nancy Lynch进行理论证明。该理论提到了分布式系统的CAP三个特性：

Consistency：数据一致性，即数据在存在多副本的情况下，可能由于网络、机器故障、软件系统等问题导致数据写入部分副本成功，部分副本失败，进而造成副本之间数据不一致，存在冲突。满足一致性则要求对数据的更新操作成功之后，多副本的数据保持一致。

Availability：在任何时候客户端对集群进行读写操作时，请求能够正常响应，即在一定的延时内完成。

Partition Tolerance：分区容忍性，即发生通信故障的时候，整个集群被分割为多个无法相互通信的分区时，集群仍然可用。

对于分布式系统来说，一般网络条件相对不可控，出现网络分区是不可避免的，因此系统必须具备分区容忍性。在这个前提下分布式系统的设计则在AP及CP之间进行选择。不过不能理解为CAP三者之间必须三选二，它们三者之间不是对等和可以相互替换的。在分布式系统领域，P是一个客观存在的事实，不可绕过，所以P与AC之间不是对等关系。

对于ZooKeeper，它是"C"P的，之所以C加引号是因为ZooKeeper默认并不是严格的强一致，比如客户端A提交一个写操作，ZooKeeper在过半数节点操作成功之后就返回，此时假设客户端B的读操作请求到的是A写操作尚未同步到的节点，那么读取到的就不是客户端A写操作成功之后的数据。如果在使用的时候需要强一致，则需要在读取数据的时候先执行一下sync操作，即与leader节点先同步下数据，这样才能保证强一致。在极端的情况下发生网络分区的时候，如果leader节点不在non-quorum分区，那么对这个分区上节点的读写请求将会报错，无法满足Availability特性。

Eureka是在部署在AWS的背景下设计的，其设计者认为，在云端，特别是在大规模部署的情况下，失败是不可避免的，可能因为Eureka自身部署失败，注册的服务不可用，或者由于网络分区导致服务不可用，因此不能回避这个问题。要拥抱这个问题，就需要Eureka在网络分区的时候，还能够正常提供服务注册及发现功能，因此Eureka选择满足Availability这个特性。Peter Kelley在《Eureka! Why You Shouldn抰 Use ZooKeeper for Service Discovery》（https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764）一文中指出，在实际生产实践中，服务注册及发现中心保留可用及过期的数据总比丢失掉可用的数据好。这样的话，应用实例的注册信息在集群的所有节点间并不是强一致的，这就需要客户端能够支持负载均衡及失败重试。在Netflix的生态中，由ribbon提供这个功能。