阿里三面面试题：分布式服务注册中心该如何选型？我快哭了

看图一：

zookeeper

Zookeeper 服务注册与发现的原理则是 Leader + Follower 两种角色。只有 Leader 可以负责写，也就是服务注册，他可以把数据同步给所有的 Follower,读的时候，也就是服务发现，是 Leader 和 Follower 都可以进行读取。

看图二：

二、在一致性保证方面

==============================================================================

在分布式系统中，有一个非常出明的定理就是 CAP 定律了。这三者 Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）在一个分布式系统中是不可兼得的。

要么保证 CP 要么保证 AP。之前写过一篇分布式事物里面解释过为什么在这两种搭配里面选择，不过多阐述了。

Zookeeper 是有一个 Leader 节点会接收数据，然后同步写到其他的 Follower 节点去。一旦 leader 挂掉，就要重新进行选举新的 leader，在新选举 leader 未完成前，集群是不可用的，当 leader 选择好了，集群可以恢复继续写了，保证了数据的一致性，这个过程为了保证 C，牺牲了 A。

而 Eureka 是 peer 模式，可能数据还没有同步完成，结果自己就宕了。此时还是可以继续从别的机器上拉取注册信息，只是不是新的而以，这个过程服务可以向其他没有宕机的节点进行注册。

Eureka 保证了服务的可用性，当节点重新启动起来以后，数据还是会同步过来，一致性方面就是 最终一致性，所以 Eureka 保证了 A 牺牲了 C。

3、服务的时效性方面

Zookeeper 的时效性更好一些，注册或者是服务挂了，一般秒级别就能感知到。

而 Eureka，默认的配置可能会有从几十秒到分钟级别。上线一个新的服务，到其他人发现他可能要一分钟，还可能不止,因为 Spring Cloud 是通过 ribbon 去获取每个服务缓存的 Eureka 的注册表进行负载均衡的。ribbon 本身还有自己的缓存机制，还有自己的时间间隔。

当服务发生故障了，默认是隔 60 秒采取检查，发现这个服务上一次是在 60s 之前，Eureka 默认是超过 90 秒才会任务它已经死掉了。这时候差不多已经过去 2 分钟了。

再则，Eureka 里面默认是 30 秒才会把 ReadWrite 缓存的数据同步到 ReadOnly 缓存中，其他服务默认也是 30 秒 才会去重新拉取一次 ReadOnly 缓存到本地服务表中。这一趟下来算算时间还是很长的。

4、容量

zk 不太适合大规模的服务实例，因为服务上下线的时候需要瞬间推送数据通知到其他所有的实例，所以服务实例到几千个的时候，可能会导致网络带宽被打满。

Eureka 也是同样比较难支撑大规模的服务实例，因为它的每个节点都需要保存全量的实例数据，几千实例服务可能会扛不住。

5、Eureka 服务发现慢的问题及调优

zk 是因为一上线服务跟下线服务就会立马发生数据同步，同时有服务进行节点的监听，很快的时间内就可以感知到服务上线下线。所以基本上不需要怎么去优化。

我们在前面的 SpringCloud 底层原理文章中讲过 Eureka 的运行机制。没看过的同学，先去看看吧。

再

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

结合到上面的 Eureka 时效性问题，我们可以发现对于 Eureka 来说，由于他的缓存机制会导致服务会存在发现慢的问题。

我们可以针对下面的几个点来优化：

1. 优化服务发现时间；

2. 优化定时从 ReadWrite 缓存到 ReadOnly 缓存的时间；

3. 优化定时心跳检查的时间；