(1)Nacos如何支撑数十万服务注册的压力
小型企业来讲nacos压力没有那么大,但是想阿里,服务的数量可能会达到数万,那麽多的服务。当服务原来越多时,除了服务注册以外,还有服务的定时更新,心跳啊等等各样的请求,压力是很大的,nacos如何抗住折磨打的并发压力呢 ,一方面nacos将来肯定做集群,做负载均衡分担压力,另一方面在代码层面做很多优化,从而提升代码执行时的性能,下面分析nacos的源码,看一下做了那些优化
服务名称校验:
addInstance
getService、
tasks是一个阻塞队列
有一个初始化方法,利用线程池执行阻塞对列中的
notifier是一个可执行
tasks阻塞队列不会影响性能,当队列中有元素时可以返回,没有元素时会等待,for这里面的死循环不会影响cpu的执行,不会忙等
这个取执行的动作是利用线程池是异步执行的,这个活跟服务注册没有关系
首先nacos要做成一个集群,集群对服务注册做负载均衡,减轻压力,其次:
(2)Nacos如何避免并发读写冲突问题
比如一些实例需要做注册,还有一些服务需要去剔除,还有一些更新,并行有好多的操作,在去修改集合的过程中,这个时候有人来读就会读到尚未修复完的数据
当有多个服务并发来写的时候,大家都来改,也有可能有写的冲突
前面讲到在添加实例的时候,添加了同步锁,对于单个服务内的多个实例,只能串行执行,就避免了并发的写冲突问题,不通的服务,你改你的service是没有影响的
他不是对整个Map去加锁,只是针对某个服务去加锁,是一种局部锁,不是全部资源,从而让不通服务可以并行执行,性能不会影响
线程池在持续执行任务,他是一个单线程的任务调度的线程池,也能确保线程安全,他是单线程的,没有并行执行
在并发读写的时候
跟新的时候是,copy一份原来的数据,然后在这copy的数据中做修改,然后再覆盖原来的数据,当copy过来做修改的过程中,其他的微服务要来读取注册表的时候读取到的就是旧的实力列表,不会受到影响,就可以避免读写的操作
并发写的冲突,大家都copy完了,都去覆盖,会不会出现丢失更新,我们当时是给服务加了锁,同一个服务的多个实例只能串行执行
不通的服务,你copy你的也不会有影响