先不管CAP是什么，就谈谈对于一个分布式的系统，它有哪些特征或行为。
（1）分布式系统会把服务部署在多个节点上
（2）每个节点都有可能存储数据，一份数据可能在多个节点上有副本
（3）节点之间通过网络进行数据的同步
假设有个服务，需要部署在3个节点上，每个节点都需要存储同一份数据id，id的初始值都是1。
再对节点1写入id=3时，由于此时发生网络闪断，节点1无法联系到节点2与节点3，那么此时访问节点1与节点2将会得到不一样的值，出现了不一致性。
此时修改节点1的副本数据，将id变为2
由于存在网络分区，无法将id的新值2同步到其他分区的节点下。
如果此时要满足A（可用性），且节点2与节点3只是在另外一个分区中，并没有发生节点本身的故障，由可用性的定义，三个节点都可以进行访问。
此时用户访问节点1，得到id=2，访问节点2时，得到id=1，发生数据不一致的情况。
所以，满足A的情况下，就满足不了C（一致性）。
如果一开始要满足C呢？
为了保证访问各个节点，都能用户最新更新的值，就要禁止任何对节点2与节点3的读写操作，这就违背了A。
所以，在满足C的情况下，就满足不了A。
既然在发生网络分区的时候，不能同时满足A与C，那么怎么在两者之间进行权衡呢？
选择AP
在发生网络分区的情况下，选择可用性，就要放弃一致性。
Eureka就是典型的AP系统
在Eureka集群中，各个server节点没有主从之分，都是相互平等的个体。
各个server节点会互相复制数据，产生冲突时，直接用最新的数据覆盖掉旧数据即可。
每一个client只会向一个server节点注册，server会将该client的ip等信息放入到注册列表中。
之后client会向server节点定时发送心跳并同时拉取注册列表到client的本地缓存中，超过一定时间不发送，server会将该client从注册列表中剔除。
如果一个client下线，首先需要过一段时间才能在server的注册列表中体现出来，随后才能在其他的client上的本地缓存中体现出来。因此client上本地缓存中的服务注册数据并不是最新的，因此这里不能保证强一致性。
一个server节点宕机或出现网络分区联系不上其他节点，其他节点仍然能提供注册与查询服务，因此保证了可用性。该server节点没有将自己的注册列表同步到其他节点，就会使得部分client的注册信息丢失，因此这里不能保证一致性。
当上述server节点重新上线或网络稳定后，就能将当前的注册列表同步到其他节点，整体又能达到最终一致性。
Eureka作为一个专门的服务注册与发现的系统，能够容忍数据不一致的情况（例如当A调用B，B已经下线，但A查询server时，依然能够获得B的注册信息。A随后发起对B的调用，结果肯定是调用失败，这个时候A选择重试或者直接熔断即可）。即使发生不一致的情况，也基本上是少数数据的不一致，如果这个时候直接强行让注册中心不可用，显然是忍受不了的。
