大家好,我是悟空。
先说下哈,这篇文章画原理图用了很多时间,求个三连!
Eureka 注册中心系列文章已经写到第六篇了,这里汇总下:
上一篇我们讲解了客户端首次获取注册表时,需要从注册中心全量拉取注册表到本地存着。那后续如果有客户端注册、下线的话,注册表肯定就发生变化了,这个时候客户端就得更新本地注册表了,怎么更新呢?下面我会带着大家一起来看下客户端第二次(这里代表全量获取后的下一次)获取注册表的方式。
题外话:之前写过一篇 Redis 主从同步的架构原理,里面也涉及到首次同步和第二次同步,其实原理也类似,但是 Redis 的主从同步原理要复杂些。强烈推荐配合着看一波:
上面我们说到,当第一次获取全量信息后,本地就有注册信息了。那如果 Server 的注册表有更新,比如有服务注册、下线,Client 必须要重新获取一次注册表信息才行。
那是否可以重新全量拉取一次呢?
可以是可以,但是,如果注册表信息很大呢?比如有几百个微服务都注册上去了,那一次拉取是非常耗时的,而且占用网络带宽,性能较差,这种方案是不靠谱的。
所以我们就需要用增量拉取注册信息表的方式,也就是说只拉取变化的数据,这样数据量就比较小了。如下图所示:
增量获取注册表
从源码里面我们可以看到,Eureka Client 通过调用 getAndUpdateDelta 方法获取增量的变化的注册表数据,Eureka Server 将变化的数据返回给 Client。
这里就有几个问题:
(1)Client 隔多久进行一次增量获取? (2)Server 将变化的数据存放在哪里? (3)Client 如何将变化的数据合并到本地注册表里面?
下面分别针对上面的几个问题进行解答。
默认每隔 30 s 执行一次同步,如下图所示:
默认 30s 同步一次
这个 30 s 就是由变量 client.refresh.interval 定义的。
Eureka 每 30 s 会调用一个后台线程去拉取增量注册表,这个后台线程的名字叫做:cacheRefresh。如下所示:
间隔时间的源码
就是调用 getDelta 方法,发送 HTTP请求调用 jersey 的 restful 接口,然后 Server 端的 Jersey 框架就会去处理这个请求了。发送请求的方法 getDelta 如下所示:
eurekaTransport.queryClient.getDelta(remoteRegionsRef.get());
restful 接口的地址就长这样:
http://localhost:8080/v2/apps/delta
那么 Server 端如何过滤出增量的注册表信息呢?我们可以找到这个方法:getContainerDifferential。如下图所示:
这个方法主要干的活就是去获取最近改变的数据。接下来我们看下最近改变的数据存放在哪。
其实就是放在这个队列里面:recentlyChangedQueue。
它的数据结构是一个并发安全的链表队列 ConcurrentLinkedQueue。
链表里面存放的元素就是最近变化的注册信息 RecentlyChangedItem。
ConcurrentLinkedQueue<RecentlyChangedItem>
当有客户端注册的时候,这个链表里面的尾部就会追加一个对象。
关于 ConcurrentLinkedQueue,还记得我之前写过的 18 种队列吗?不记得话看下这篇:
ConcurrentLinkedQueue 是由链表结构组成的线程安全的先进先出无界队列。如下图所示:
ConcurrentLinkedQueue原理
我觉得这个队列的构造还是非常值得我们学习的,我们来看下这个队列的构造,如下图所示:
增量数据内部构造
RecentlyChangedItem
。既然上面说到是最近改变的数据才会放进去,那这个最近是多近呢?1 分钟?2分钟?
通过源码我们找到了这个默认配置,三分钟
刷新一次,也就是 180s 刷新一次。
那刷新了什么?刷新其实是会遍历这个队列:recentlyChangedQueue。
将队列里面的所有元素都遍历一遍,比对每个对象的最后更新时间是否超过了三分钟,如果超过了,就移除这个元素。如下图所示:
比较最后更新时间
当元素的最后更新时间超过 3 分钟未更新,则移除该元素。如下图所示:
移除元素
Server 端会将最近 3 分钟有更新的注册信息放入到队列中,超过 3 分钟未更新的数据将会被移除。那么多久会检查一次呢?
通过源码我们找到,每隔 30s 就会调用一次检查任务。如下图所示:
检查间隔
这里有个问题:客户端首次拿到的全量注册表,存放本地了。第二次拿到的是增量的注册表,怎么将两次的数据合并在一起呢?如下图所示:
注册表合并
下面我们来看看下客户端注册表合并的原理。
当客户端调用获取增量注册表的请求后,注册表会返回增量信息,然后客户端就会调用本地合并的方法:updateDelta。
合并注册表的原理图如下所示:
合并注册表的原理
经过这一些列的逻辑之后,增量注册表和本地注册表就合并好了。
经过重重判断 + 合并操作,客户端终于完成了本地注册表的刷新,理论上来说,这个时候客户端的注册表应该和注册中心的注册表一致了。
但是如何确定是一致的呢?这里我们来考虑几种方案:
有没有既方便又准确的比对方式呢?
有的,那就是哈希比对
。哈希比对的意思就是将两个对象经过哈希算法计算出两个 hash 值,如果两个 hash 值相等,则认为这两个对象相等。这种方式在代码中也非常常见,比如类的 hashcode() 方法。
从源码中,我们看到 Eureka Server 返回注册表时,会返回一个 hash 值,是将全量注册表 hash 之后的值。调用的是这个方法:getReconcileHashCode()。
如下图所示,获取增量注册表的接口,会返回增量注册表和 hashcode。
然后本地注册表合并后,再计算出一个 hashcode,和 Server 返回的 hashcode 进行比对,如果一致,说明本地注册表和 Server 端一致。如果不一致,则会进行一次全量拉取。
上面说的原理我们画一张原理图看下就清楚了:
本篇文章可以用一张图来做总结,直接上图:
客户端注册表同步原理
提个问题:为什么 hash 比对会不一致?答案在文中哦!
下篇,注册中心的缓存架构走起!
- END -
我是悟空,努力变强,变身超级赛亚人!