一、前言上一篇我们讲解了客户端首次获取注册表时需要从注册中心全量拉取注册表到本地存着。那后续如果有客户端注册、下线的话注册表肯定就发生变化了这个时候客户端就得更新本地注册表了怎么更新呢下面我会带着大家一起来看下客户端第二次这里代表全量获取后的下一次获取注册表的方式。题外话之前写过一篇 Redis 主从同步的架构原理里面也涉及到首次同步和第二次同步其实原理也类似但是 Redis 的主从同步原理要复杂些。强烈推荐配合着看一波镜 | 5 个维度深度剖析「主从架构」原理二、增量获取引发的问题上面我们说到当第一次获取全量信息后本地就有注册信息了。那如果 Server 的注册表有更新比如有服务注册、下线Client 必须要重新获取一次注册表信息才行。那是否可以重新全量拉取一次呢可以是可以但是如果注册表信息很大呢比如有几百个微服务都注册上去了那一次拉取是非常耗时的而且占用网络带宽性能较差这种方案是不靠谱的。所以我们就需要用增量拉取注册信息表的方式也就是说只拉取变化的数据这样数据量就比较小了。如下图所示增量获取注册表从源码里面我们可以看到Eureka Client 通过调用 getAndUpdateDelta 方法获取增量的变化的注册表数据Eureka Server 将变化的数据返回给 Client。这里就有几个问题1Client 隔多久进行一次增量获取2Server 将变化的数据存放在哪里3Client 如何将变化的数据合并到本地注册表里面下面分别针对上面的几个问题进行解答。三、间隔多久同步一次3.1 默认间隔时间默认每隔 30 s 执行一次同步如下图所示默认 30s 同步一次这个 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。ConcurrentLinkedQueueRecentlyChangedItem当有客户端注册的时候这个链表里面的尾部就会追加一个对象。关于 ConcurrentLinkedQueue还记得我之前写过的 18 种队列吗不记得话看下这篇45张图庖丁解牛18种Queue你知道几种ConcurrentLinkedQueue 是由链表结构组成的线程安全的先进先出无界队列。如下图所示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 比对会不一致答案在文中哦