（1）Nacos如何支撑数十万服务注册的压力

小型企业来讲nacos压力没有那么大，但是想阿里，服务的数量可能会达到数万，那麽多的服务。当服务原来越多时，除了服务注册以外，还有服务的定时更新，心跳啊等等各样的请求，压力是很大的，nacos如何抗住折磨打的并发压力呢  ，一方面nacos将来肯定做集群，做负载均衡分担压力，另一方面在代码层面做很多优化，从而提升代码执行时的性能，下面分析nacos的源码，看一下做了那些优化      

服务名称校验：

addInstance 

getService、

 

tasks是一个阻塞队列 

有一个初始化方法，利用线程池执行阻塞对列中的 

notifier是一个可执行 

 

tasks阻塞队列不会影响性能，当队列中有元素时可以返回，没有元素时会等待，for这里面的死循环不会影响cpu的执行，不会忙等

这个取执行的动作是利用线程池是异步执行的，这个活跟服务注册没有关系

首先nacos要做成一个集群，集群对服务注册做负载均衡，减轻压力，其次：

（2）Nacos如何避免并发读写冲突问题

比如一些实例需要做注册，还有一些服务需要去剔除，还有一些更新，并行有好多的操作，在去修改集合的过程中，这个时候有人来读就会读到尚未修复完的数据

当有多个服务并发来写的时候，大家都来改，也有可能有写的冲突

前面讲到在添加实例的时候，添加了同步锁，对于单个服务内的多个实例，只能串行执行，就避免了并发的写冲突问题，不通的服务，你改你的service是没有影响的

他不是对整个Map去加锁，只是针对某个服务去加锁，是一种局部锁，不是全部资源，从而让不通服务可以并行执行，性能不会影响        

 

线程池在持续执行任务，他是一个单线程的任务调度的线程池，也能确保线程安全，他是单线程的，没有并行执行

在并发读写的时候

跟新的时候是，copy一份原来的数据，然后在这copy的数据中做修改，然后再覆盖原来的数据，当copy过来做修改的过程中，其他的微服务要来读取注册表的时候读取到的就是旧的实力列表，不会受到影响，就可以避免读写的操作

并发写的冲突，大家都copy完了，都去覆盖，会不会出现丢失更新，我们当时是给服务加了锁，同一个服务的多个实例只能串行执行

不通的服务，你copy你的也不会有影响

（3）Nacos俞Eureka的区别