【面试突击】注册中心面试实战

欢迎关注公众号（通过文章导读关注：【11来了】），及时收到 AI 前沿项目工具及新技术 的推送
发送 资料 可领取 深入理解 Redis 系列文章结合电商场景讲解 Redis 使用场景、中间件系列笔记和编程高频电子书！

文章导读地址：点击查看文章导读！

感谢你的关注！

注册中心面试实战

注册中心技术选型：

在分布式系统中，注册中心肯定是必不可少的，那么对于注册中心如何选择呢？

如果使用 Dubbo 作为服务框架，那么 Dubbo 底层的注册中心使用的就是 ZooKeeper

如果使用 SpringCloud 作为服务框架，一般注册中心都会选择 Eureka 或者 Nacos，配套进行使用

注册中心原理：

那么注册中心的 原理 肯定是要了解的，通过注册中心可以用来做那些事情：

• 如何注册服务信息？
• 如何进行服务发现？
• 注册中心如何集群部署？

这些都是具体的原理方面的内容，不放在这里展开说了，主要了解一下在注册中心这里，会问哪些内容

我的专栏里就有 ZooKeeper 的内容，可以去查看一下

CAP 理论：在分布式系统中，被讨论最多的一个就是 CAP 理论，即一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition tolerance)无法同时满足，最多只能满足两个，因此大多数场景下都是满足 CP 或者 AP ，而注册中心就是用于分布式系统中的，因此需要去了解使用的注册中心符合 CAP 中的哪两个：

• 在 ZooKeeper 中，只有一个 Leader 可以写数据，写完数据之后会同步给其他的 Follower，如果 Leader 挂了，就会去重新选举一个 Leader，选举期间会出现短暂的 写 服务不可用情况，因此 ZK 中为了保证 C 而放弃了 A，所以 ZK 满足了 CP
• 在 Eureka 中，满足 AP，为了保证可用性而放弃了数据的一致性，怎么做的呢？Eureka 中各个节点都是平等的，所以某个节点宕机不会影响其他节点的工作，如果从一台机器中查询数据失败，那么可以尝试从其他的机器中查询，这里查到的数据可能不是最新的（不保证数据的一致性）

大规模服务实例场景下的表现：

对于 ZooKeeper 和 Eureka 来说，其实都不适合大规模的服务实例，因为如果服务实例数量达到几千上万，如果服务上下线，那么对于 zk 来说，需要去通知其他节点服务上下线，那么会导致 zk 的 网络瞬时流量很大，可能直接给 zk 所在机器的网络带宽打满，甚至直接打挂掉

对于 Eureka 来说也是，接收很多服务实例的请求，大量的心跳请求会导致 Eureka 压力太大

ZooKeeper 和 Eureka 一般也就能支撑几百上千的服务实例，

注册中心生产环境可以抗多少并发请求呢？

注册中心，一般会使用比较高配置的机器来部署，如 8C16G 或者 16C32G

那么一般来说，使用 8C16G 的机器部署，每秒钟抗几千的并发请求还是没有问题的，那么如果使用 16C32G 甚至 32C64G，可以抗更大数量的请求，并且对于注册中心以及后边要将到的网关，都会使用比较好的机器来部署，因为这些是 基础性的系统，如果出问题会导致服务大面积瘫痪

一般注册中心怎么部署呢？

可以去看一看 ZooKeeper 如何集群部署，部署细节可以简单了解一下，也不会问具体部署细节，但是要清楚 部署的流程

问的话，可能就是问 ZK 一般集群部署几台机器？部署的机器什么配置？

机器配置以及可以扛下请求数量在上边已经说过了，zk 部署集群的话，一般都是 小集群部署，1 主 2 从即可，zk 本身就不适合大集群部署，这与 zk 的架构设计有关，因为数据写入 Leader 之后，需要同步给 Follower 的，如果 Follower 数量过多，会导致同步速度很慢，影响 zk 的写性能