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

发布时间:2024年01月12日

🌈🌈🌈🌈🌈🌈🌈🌈
欢迎关注公众号(通过文章导读关注:【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 的写性能

文章来源:https://blog.csdn.net/qq_45260619/article/details/135562592
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。