讲透原理，最细的增量拉取

大家好，我是悟空。

先说下哈，这篇文章画原理图用了很多时间，求个三连！

一、前言

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

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

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

二、增量获取引发的问题

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

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

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

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

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

这里就有几个问题：

（1）Client 隔多久进行一次增量获取？

（2）Server 将变化的数据存放在哪里？

（3）Client 如何将变化的数据合并到本地注册表里面？

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

三、间隔多久同步一次？

3.1 默认间隔时间

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

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

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

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

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

eurekaTransport.queryClient.getDelta(remoteRegionsRef.get());
restful 接口的地址就长这样：
http://localhost:8080/v2/apps/delta

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

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

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

4.1 数据结构

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

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

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

ConcurrentLinkedQueue<RecentlyChangedItem>

当有客户端注册的时候，这个链表里面的尾部就会追加一个对象。

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

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

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

4.2 内部构造

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

• 这个队列里面存放的对象是最近改变的对象 RecentlyChangedItem。
• RecentlyChangedItem 存有三个元素：实例信息、操作类型和最后更新时间。
• 实例信息：使用 Lease保存一个客户端的注册表信息，这个在第四篇讲解注册表结构已经介绍过。
• 操作类型：当有客户端发起注册、更新注册表、下线时，会设置 actionType，对应三种枚举值：新增、更新、删除。
• 最后更新时间：客户端注册信息发生改变时，需要同时更新最后更新时间。

4.3 最近的数据

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

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

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

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

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

4.4 检查间隔

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

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

4.5 小结

• Client 每隔 30 秒调用一次增量获取注册表的接口。
• Server 每隔 30 秒调用检查一次队列。
• 如果队列中有元素在 3 分钟以内都没有更新过，则从队列中移除该元素。

五、客户端注册表合并

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

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

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

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

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

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

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

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

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

六、比对注册表

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

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

• 再全量拉取一次注册表，和本地注册表进行比对。但是既然又要做一次全量拉取，那之前的增量拉取就没有必要了。
• 拉取增量注册表，Server 返回全量注册表的实例 id，客户端比对每个实例 id 是否存在，以及检查本地是否有多余的，如果能匹配上，则认为是一致的。但是这里也有一个问题，对于新增和更新的注册实例，得把更新的实例信息的字段一一比对才能确定是否一致，这就太麻烦了。另外还有一个致命的问题：如果客户端因为网络故障下线了，上一次最近 3 分钟的增量数据没有拉取到，那么相当于丢失了一次增量数据，这个时候，就不是完整的注册表信息了。

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

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

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

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

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

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

七、总结

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

• 客户端每隔 30s 获取一次增量数据，注册中心返回最近 3 分钟变化的注册信息，包含了新注册的、更新的和下线的服务实例。然后将增量注册表 + 全量注册表的 hash 值返回。

• 客户端将本地注册表 + 增量注册表进行合并。合并完成后，计算一个 hash 值，和 Server 返回的 hash 值进行比对，如果相等，则说明客户端的注册表和注册中心的注册表一致，同步完成。如果不一致，则还需要全量拉取一次。

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

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