zookeeper与eureka对比

对比学习，记忆才会更深刻，理解才会更深入，下面从CAP、时效性、容量，三个方面zookeeper与eureka进行对比

CAP

C( Consistency)：一致性
A(Availability)：可用性
P(Partition tolerance)：分区容错性

---

zookeeper保证了CP

服务B注册到ZKLeader上，必须强制同步到ZKFollower才算注册成功过

服务B注册到了Leader上，在同步期间ZKLeader挂掉了，在选举期间，不允许任何服务访问，因为还没有完全保证数据一致性，这样保证了数据的强一致

---

Eureka保证的AP

 服务B往Eureka上注册还没来得及同步，Eureka直接死掉了，但是Eureka保证了可用性，所以没关系，服务A还可以去另一个Eureka进行服务发现，这样读到是不一致的数据，因为根本就没有最新的B服务，但是可以保证最终一致性，因为B服务注册到Eureka然后给Eureka发心跳，发现Eureka死掉了，可以给另外一个Eureka发心跳重新注册，这个Eureka就能感知的B服务的存在，然后服务A去Eureka中去拉，就能感知到服务B

---

服务注册发现的时效性

服务B注册到ZKLeader上，然后同步到ZKFollower，再通知服务列表更新，整个过程是秒级的 服务B挂掉了，ZKLeader会感知到服务断开了，然后立即同步到ZKFollower，然后更新也是秒级

ZK时效性更好，注册或者是挂了，一般秒级就能感知到
eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别

readWriteCacheMap ： 此处存放的是最终的缓存， 当服务下线，过期，注册，状态变更，都会来清除这个缓存里面的数据。 然后通过CacheLoader进行缓存加载，在进行readWriteCacheMap.get(key)的时候，首先看这个缓存里面有没有该数据，如果没有则通过CacheLoader的load方法去加载，加载成功之后将数据放入缓存，同时返回数据

readOnlyCacheMap ： 这是一个JVM的CurrentHashMap只读缓存，这个主要是为了供客户端获取注册信息时使用，其缓存更新，依赖于定时器的更新，通过和readWriteCacheMap 的值做对比，如果数据不一致，则以readWriteCacheMap 的数据为准。

responseCacheUpdateIntervalMs ： readOnlyCacheMap 缓存更新的定时器时间间隔，默认为30秒

responseCacheAutoExpirationInSeconds : readWriteCacheMap 缓存过期时间，默认为 180 秒 。

eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别，上线一个新的服务实例，到其他人可以发现他，极端情况下，可能需要1分钟的时间，ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡。

服务故障，隔60秒才会去检测心跳，发现这个服务上一次心跳是在60秒之前，隔60秒去检查心跳，超过90秒没有心跳，才会认为他死了，2分钟都过去

30秒，才会更新缓存，30秒，其他服务才会拉去最新的注册表

---

容量

zk，不太适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千服务实例的时候，会导致网络带宽被大量占用

eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例

---

系统遇到服务过慢的问题，怎么优化和解决的

Eureka.server.responseCacheUpdateIntervalMs = 30000(服务端-定时同步)
Eureka.client.registryFetchIntervalSeconds = 30000( 客户端-从eureka服务器注册表中获取注册信息的时间间隔（s），默认为30秒)
	
Eureka.client.leaseRenewalIntervalInSeconds = 30(客户端-eureka客户需要多长时间发送心跳给eureka服务器，表明它仍然活着,默认为30 秒)
Eureka.server.evictionIntervalTimerInMs = 60000(服务端-检查心跳)
Eureka.instance.leaseExpirationDurationInSeconds = 90(服务端-Eureka服务器在接收到实例的最后一次发出的心跳后，需要等待多久才可以将此实例删除，默认为90秒) 

小结：
本篇文章只是小编的个人总结，有什么不对的地方，还希望大神指出。