大规模服务始终向注册核心进行注册、发送心跳、服务发现，对于注册核心来说，高并发的读写申请压力是十分微小的，通常注册核心是怎么保障高性能呢？

RocketMQ

RocketMQ 的 NameServer 不仅作为 Broker 的注册核心，他还须要存储路由的根底信息，所以他保护了多个数据结，包含 Topic 音讯队列路由信息、Broker 根底信息、Broker 集群信、Broker 状态信息等。

也就是说在进行 Broker 注册、Broker 删除的时候，是须要对多个数据结构进行批改。

在高并发场景下，RocketMQ 是通过读写锁来对这些数据结构保障数据的安全性。在同一时刻，NameServer 只能对一个 Broker 进行解决，然而在读的时候，却是能够多线程同时读取。

Nacos

Nacos 为了避免高并发的读写，用了 CopyOnWrite 的思维，然而并不是说他就不加锁了，他会对 Service 进行细粒度的加锁。

因为 CopyOnWrite 会占用空间，Nacos 复制的时候，仅针对相应的内存进行了复制，解决实现后，再把这部分内存替换回去。

Eureka

Eureka 则应用了多级缓存，包含只读缓存、读写缓存、注册表。这里援用 Eureka – 服务续约和注册、下线 (Server) 的图。

Zookeeper

Zookeeper 在并发量不是很大的状况是能够作为注册核心（在大数据畛域更多的是作为一个协调器），然而在并发量很大的时候，他有以下有余。

Zookeeper 是 CP 模型的，所以当服务注册的时候，必须有过半的 Zookeeper 节点保留胜利，这个服务才算保留胜利（但理论场景中，咱们并不需要放弃强一致性）。过半服务保留的工夫绝对单个节点来说，是比拟耗时的。

而且 CP 模型在网络分区的时候，会造成局部服务无奈进行注册，导致同一个区的服务因为注册核心的问题而无奈失常应用。

Zookeeper 通过长连贯来进行活性探测，并通过 Watch 机制来告诉服务，服务很大的时候，也给 Zookeeper 带来了肯定的性能损耗。