注册中心原理剖析

Eureka注册中心原理

1. eureka本身有三层缓存，只读缓存，读写缓存，服务注册表
2. 服务向注册中心注册时，会将信息写入服务注册表，修改服务注册表后会将信息立即写入读写缓存
3. 后台会有定时线程默认30秒，将读写缓存中的数据同步到只读缓存中
4. 服务启动后默认每隔30秒向eureka发送心跳请求，eureka注册中心会有线程定时（默认30秒）检测当前存活的服务节点是否有发送对应心跳请求，如果超过90秒都没有发送心跳则将该节点移除
5. 注册表只要发生修改都会及时同步到读写缓存中
6. 多级缓存的目的是为了解决多服务读写时对服务注册表加锁而引起的性能问题，读写缓存的存在可以解决对注册表的读取，因为定时线程只会在只读缓存和读写缓存间作同步，读写缓存的数据更新是靠注册表推送，所以注册表本身无需考虑读写并发问题

Nacos注册中心原理

Nacos服务注册表结构：

本身结构是ConcurrentHashMap

Map<namespace, Map<group::serivceName, Service>>

Service结构：Map<clusterName, Cluster>

Cluster结构：Set<Instance>

AP模式（Distro协议）

1. 接收到注册请求后首先判断是CP还是AP，AP模式下是临时节点，CP模式是持久化节点（持久化到磁盘文件）
2. 服务注册后将变化的事件信息放入队列（BlockingQueue）中
3. 会有后台线程不断从队列中取出事件信息，根据不同的事件，如注册节点是CHANGE事件，从注册表的map中取出服务名称对应的服务节点List<Instance>将新节点加入该List中；下线节点是DELETE事件，也就是将该节点从服务节点List移除，此处的事件类似Reactor模型的思想。
4. 更新节点不管是注册还是删除，在nacos中走的其实都是同一个方法updateIps，使用copy on write的方式，更新时首先new一个新的HashMap<服务名称，List<Instance>>，将旧注册列表中该服务名称对应的所有节点信息put到这个map中，之后所有的修改都是更新该map中的List<Instance>，最终将Cluster中的临时节点集合指针直接指向这个更新后的集合
5. 队列本身解决了多服务注册时的并发问题，无需加锁也不会发生写操作覆盖。
6. 其核心思想就是防止读写并发冲突，把原数据复制一份，操作完成后在合并回真正的注册表内存中
7. 本服务完成注册后，会将本次注册封装成一个延迟task放入nacos延迟任务类中的taskMap中，延迟时间为1s，如果有同服务名称多节点注册会将其合并为一个task，合并完成后如果更新节点数超过指定数量（默认1000），则会直接取消掉这个task的延迟时间，将其变为立即触发
8. 后台会有线程每隔100ms从这个ConcurrentHashMap中拿出所有需要执行的task进行处理，此时向集群内其他注册中心通过http同步更新数据
9. 服务节点默认5s向注册中心发送一次心跳，如果注册中心超过15s没有收到心跳就会将该服务节点标记为不健康，如果超过30s将该服务直接下线
10. 总结：nacos的AP模式其实和eureka本身差别不大，但是一方面使用copy on write思想取代了eureka的三级缓存，大幅度提升了服务发现速度（从几十秒缩短到几秒），另一方面nacos采用的是多节点批量更新，解决了上万服务节点场景集中上线时，eureka各节点间频繁进行上下线同步更新通信，导致注册中心QPS飙升的问题，以此可以支持大规模服务节点的注册

CP模式（Raft协议）

1. 注册时先判断当前节点是否是leader节点，如果不是leader会将本次注册请求转发到leader节点，只有leader节点才可以写数据
2. leader节点首先会将数据放入队列，之后通过队列消费将本次注册写入内存中
3. 同时nacos也会将本次注册信息写入磁盘，通过磁盘保证数据持久化
4. 主节点写入数据成功后，再将数据同步到其他从节点，此时使用CountDownLatch，构造参数为所有节点数 / 2 + 1，如果超过半数节点返回成功即通知客户端写入成功
5. RaftCore类中init方法，在初始化时会监测本机是否有已经持久化的磁盘文件，如果有会直接从其中恢复数据
6. 选主
7. 服务在等待一定随机时间后向其他节点发送投票信息，如果被超过半数以上节点选中，当前节点就会成为leader节点。
8. 此时其他节点可能还在等待随机时间。
9. leader节点会向其他节点发送心跳，告知我已经成为leader节点。其他节点停止等待，变成flower节点
10. leader节点会不断向flower节点发送心跳，flower节点会等待一定时间，如果超过等待时间没有收到leader节点的心跳，则认为leader节点挂掉进而重新选举