CAP原则以及zookeeper和eureka的区别

之前裸辞了最近刚找完工作，有点忙，后续闲了会多更新一些。

1.CAP原则

指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

在分区的情况下,各节点如果无法相互进行网络通信,那就只能在一致性和可用性中选取其一
如果选择在连接不到别的节点时不对外提供服务,就保证了一致性抛弃了可用性
如果选择在连接不到别的节点时依然对外提供服务,就保证了可用性抛弃了一致性

所以如果既想保证可用性又想保证一致性,那就只能避免分区,即抛弃了分区容忍性

2.zookeeper的选择

从概念上来说，ZooKeeper它所做的就是确保对数据的修改都会被复制到集合体中超过半数的节点上。如果少于半数的机器出现故障，则最少有一台机器会保存最新的状态，那么这台机器就是我们的Leader。其余的副本最终也会更新到这个状态。如果 Leader挂了，由于其他机器保存了Leader的副本，那就可以从中选出一台机器作为新的Leader继续提供服务。
从原则上来说,zookeeper保证了强一致性,但实际上写操作的2pc提交不需要所有的节点都投票通过,而是超过半数的节点投票通过即可,那么有的节点有可能没有第一时间接收到写操作的同步而leader已经通过该写操作,这样的话连接到该节点的服务只能说得到了数据单调一致性的保障,而不是强一致性的保障。但是总的来说，zookeeper是相当偏向于一致性而非可用性的服务注册与管理中间件，需要注意的是这也会大幅度增加写入数据的性能成本，但是一般情况下作为服务中心写入的数据并不多，还在可接受的范围内。

3.eureka的选择

相对于zookeeper，eureka相当偏向于A而非C，即是说一台连接不到集群的eureka节点依然可以对外提供服务,即使提供的数据不一定是最新的,但是在某些情况下总比服务之间宕机要好。

在eureka集群中，如果某个节点发生宕机，eureka不会有类似zookeeper选举的行为,即不会对外停止服务。客户端请求会切换到别的eureka节点，当宕机的服务器重新恢复后会被再次加入集群管理中同步别的eureka server保存的注册信息。当网络分割故障发生时，每个eureka server节点都能继续对外提供服务。

eureka server还有心跳机制，默认情况下eureka server一段时间内没有接受服务提供者发送的心跳就会将其剔除，但是也有可能是eureka server发生了网络分区故障。如果eureka server在一段时间内丢失了大量心跳，那么会进入自我保护模式，此时有以下行为模式：
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

eureka client还拥有缓存功能，即使所有的eureka server都不可用，那么client依然能够使用本地缓存连接已缓存的一些服务。

4.总结

总的来说，eureka更加偏向于cap中的可用性原则而非一致性，那么什么时候采用什么中间件呢，可能要根据具体业务分析。

如果是支付相关，无法容忍注册服务列表的不一致，那么就要使用更加能保证一致性的zookeeper，如果是推送新闻等服务，短暂的不一致比起服务宕机影响更小