十一张图讲透原理，最细的增量拉取

发布时间：2025-11-05 04:09:16 来源：云智核 作者：数据库

一、张图最细前言

上一篇我们讲解了客户端首次获取注册表时，讲透需要从注册中心全量拉取注册表到本地存着。原理那后续如果有客户端注册、量拉下线的张图最细话，注册表肯定就发生变化了，讲透这个时候客户端就得更新本地注册表了，原理怎么更新呢?量拉下面我会带着大家一起来看下客户端第二次(这里代表全量获取后的下一次)获取注册表的方式。

题外话：之前写过一篇 Redis 主从同步的张图最细架构原理，里面也涉及到首次同步和第二次同步，讲透其实原理也类似，原理但是量拉 Redis 的主从同步原理要复杂些。强烈推荐配合着看一波：

镜 | 5 个维度深度剖析「主从架构」原理

二、张图最细增量获取引发的讲透问题

上面我们说到，当第一次获取全量信息后，原理本地就有注册信息了。那如果 Server 的注册表有更新，比如有服务注册、下线，Client 必须要重新获取一次注册表信息才行。

那是否可以重新全量拉取一次呢?

可以是可以，但是，如果注册表信息很大呢?比如有几百个微服务都注册上去了，服务器托管那一次拉取是非常耗时的，而且占用网络带宽，性能较差，这种方案是不靠谱的。

所以我们就需要用增量拉取注册信息表的方式，也就是说只拉取变化的数据，这样数据量就比较小了。如下图所示：

增量获取注册表

从源码里面我们可以看到，Eureka Client 通过调用 getAndUpdateDelta 方法获取增量的变化的注册表数据，Eureka Server 将变化的数据返回给 Client。

这里就有几个问题：

(1)Client 隔多久进行一次增量获取?

(2)Server 将变化的数据存放在哪里?

(3)Client 如何将变化的数据合并到本地注册表里面?

下面分别针对上面的几个问题进行解答。

三、间隔多久同步一次?

3.1 默认间隔时间

默认每隔 30 s 执行一次同步，如下图所示：

默认 30s 同步一次

这个 30 s 就是由变量 client.refresh.interval 定义的。

Eureka 每 30 s 会调用一个后台线程去拉取增量注册表，这个后台线程的名字叫做：cacheRefresh。如下所示：

间隔时间的企商汇源码

3.2 Client 发送拉取注册表的请求

就是调用 getDelta 方法，发送 HTTP请求调用 jersey 的 restful 接口，然后 Server 端的 Jersey 框架就会去处理这个请求了。发送请求的方法 getDelta 如下所示：

那么 Server 端如何过滤出增量的注册表信息呢?我们可以找到这个方法：getContainerDifferential。如下图所示：

这个方法主要干的活就是去获取最近改变的数据。接下来我们看下最近改变的数据存放在哪。

四、变化的数据存放在哪?

4.1 数据结构

其实就是放在这个队列里面：recentlyChangedQueue。

它的数据结构是一个并发安全的链表队列 ConcurrentLinkedQueue。

链表里面存放的元素就是最近变化的注册信息 RecentlyChangedItem。 

当有客户端注册的时候，这个链表里面的尾部就会追加一个对象。云服务器提供商

关于 ConcurrentLinkedQueue，还记得我之前写过的 18 种队列吗?不记得话看下这篇：

45张图庖丁解牛18种Queue，你知道几种?

ConcurrentLinkedQueue 是由链表结构组成的线程安全的先进先出无界队列。如下图所示：

ConcurrentLinkedQueue原理

4.2 内部构造

我觉得这个队列的构造还是非常值得我们学习的，我们来看下这个队列的构造，如下图所示：

增量数据内部构造

4.3 最近的数据

既然上面说到是最近改变的数据才会放进去，那这个最近是多近呢?1 分钟?2分钟?

通过源码我们找到了这个默认配置，三分钟刷新一次，也就是 180s 刷新一次。

那刷新了什么?刷新其实是会遍历这个队列：recentlyChangedQueue。

将队列里面的所有元素都遍历一遍，比对每个对象的最后更新时间是否超过了三分钟，如果超过了，就移除这个元素。如下图所示：

比较最后更新时间

当元素的最后更新时间超过 3 分钟未更新，则移除该元素。如下图所示：

移除元素

4.4 检查间隔

Server 端会将最近 3 分钟有更新的注册信息放入到队列中，超过 3 分钟未更新的数据将会被移除。那么多久会检查一次呢?

通过源码我们找到，每隔 30s 就会调用一次检查任务。如下图所示：

检查间隔

4.5 小结

五、客户端注册表合并

这里有个问题：客户端首次拿到的全量注册表，存放本地了。第二次拿到的是增量的注册表，怎么将两次的数据合并在一起呢?如下图所示：

注册表合并

下面我们来看看下客户端注册表合并的原理。

当客户端调用获取增量注册表的请求后，注册表会返回增量信息，然后客户端就会调用本地合并的方法：updateDelta。

合并注册表的原理图如下所示：

合并注册表的原理

首先就会遍历增量注册表，检查其中的每一项，不论 actionType 是新增、删除还是更新，如果本地本来就有，则执行后续的类型判断逻辑。

如果实例信息的名字在本地不存在则会先往本地注册表新增一个注册信息。然后本地肯定存在注册信息了，执行后续的判断逻辑。

当类型字段 actionType 等于新增或更新时，先删除后增加。

当类型字段 actionType 等于删除时，直接进行删除。

经过这一些列的逻辑之后，增量注册表和本地注册表就合并好了。

六、比对注册表

经过重重判断 + 合并操作，客户端终于完成了本地注册表的刷新，理论上来说，这个时候客户端的注册表应该和注册中心的注册表一致了。

但是如何确定是一致的呢?这里我们来考虑几种方案：

有没有既方便又准确的比对方式呢?

有的，那就是哈希比对。哈希比对的意思就是将两个对象经过哈希算法计算出两个 hash 值，如果两个 hash 值相等，则认为这两个对象相等。这种方式在代码中也非常常见，比如类的 hashcode() 方法。

从源码中，我们看到 Eureka Server 返回注册表时，会返回一个 hash 值，是将全量注册表 hash 之后的值。调用的是这个方法：getReconcileHashCode()。

如下图所示，获取增量注册表的接口，会返回增量注册表和 hashcode。

然后本地注册表合并后，再计算出一个 hashcode，和 Server 返回的 hashcode 进行比对，如果一致，说明本地注册表和 Server 端一致。如果不一致，则会进行一次全量拉取。

上面说的原理我们画一张原理图看下就清楚了：

七、总结

本篇文章可以用一张图来做总结，直接上图：

客户端注册表同步原理

提个问题：为什么 hash 比对会不一致?答案在文中哦! 

下篇，注册中心的缓存架构走起!

相关文章