CAP定理在分布式系统的开发中，影响最大的就是CAP定理，它是分布式系统开发的理论基石。2000年，加州大学计算机科学家EricBrewer提出了CAP猜想。2002年麻省理工学院的SethGilbert和NancyLynch从理论上证明了CAP猜想。CAP猜想变成了CAP定理。一个系统不可能同时满足一致性、可用性和分区容忍度三个要素。”Consistency一致性是指在任何时候在一个节点上，访问任何一个节点返回的数据都是一致的。即client端写入一条数据后，server端将数据同步到整个系统，保证系统内的数据是相同的。可用性可用性意味着集群可以响应用户请求。PartitionTolerance分区容错是指当一个分区出现故障时，系统仍然对外提供服务。在分布式系统中，每个服务节点都是不可靠的。当某些节点出现异常，或者节点之间的通信出现异常时，整个系统就会出现分区问题。在分布式系统中，分区问题是客观存在的。的。CAP权衡CA系统选择CA，即不支持分区容错，只支持一致性和可用性。意味着不允许出现分区异常，网络一致性处于理想状态。但是，分布式系统之间的网络异常是客观存在的。如果回避P，分布式系统只能退回到单实例系统。CP因为分布式系统P是客观存在的，所以我们不得不在CP和AP之间做出选择。当发生网络分区时，两个分布式节点之间无法进行通信，我们对一个节点的修改操作不会同步到另一个节点，所以数据的“一致性”就得不到满足，因为两个分布式节点的数据for不再一致。除非我们牺牲“可用性”，即暂停分布式节点服务，否则当网络出现分区时，我们将不再提供修改数据的功能，继续对外提供服务，直到网络状况完全恢复。“选择CP时，这等同于放弃系统。可用性以换取一致性”。Zookeeper是一个选择CP的系统。在zookeeper集群中，有如下三种角色。Leader是事务请求的唯一调度器和处理者（事务请求是查询以外的请求）Follower处理非事务请求，参与Leader选举投票Observer处理非事务请求，不参与选举投票。当Leader服务器发生故障时，它会从Follower服务器中重新选举一个新的服务器作为Leader服务器。“在Leader服务器重新选举的过程中，交易请求会被暂停，直到选举出Leader服务器后才会执行这些请求。”即为了保证一致性，放弃了系统的可用性AP。“选择AP，就相当于放弃系统的一致性来换取可用性。”eureka是一个选择AP的系统，在zookeeper集群中有三个角色。不同的是，eureka集群中的每个节点扮演的角色都是一样的。他们通过互相注册来感知对方的存在。当有注册信息时，他们会同步。到集群中的其他节点。下面我将从源码的角度来分析eureka是如何放弃一致性来保证可用性的（放心，源码不会放出来，说说大概的思路。源码也比较简单。有兴趣可以看我的博客https://blog.csdn.net/zzti_erlie/article/details/104088914）eureka注册中心的信息保存在AbstractInstanceRegistry类的成员变量中//AbstractInstanceRegistryprivatefinalConcurrentHashMap
