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