2023-09-15  阅读(1)
原文作者:王伟王胖胖 原文地址: https://blog.csdn.net/wangwei19871103/article/details/105621784

大致流程图

202309152311383311.png

获取全量服务信息

我们来讲下客户端获取全量服务信息的时候服务端是怎么做的。调用的是ApplicationsResourcegetContainers。主要就是创建一个缓存的Key对象,对象的属性值ResponseCacheImpl.ALL_APPS表示的就是全量,也就是获取缓存用的,缓存其实是个map。然后调用responseCache.getGZIP获取全量的服务信息。

     @GET
        public Response getContainers(@PathParam("version") String version,
                                      @HeaderParam(HEADER_ACCEPT) String acceptHeader,
                                      @HeaderParam(HEADER_ACCEPT_ENCODING) String acceptEncoding,
                                      @HeaderParam(EurekaAccept.HTTP_X_EUREKA_ACCEPT) String eurekaAccept,
                                      @Context UriInfo uriInfo,
                                      @Nullable @QueryParam("regions") String regionsStr) {
    
    
           	...      
    		//创建一个缓存对象
            Key cacheKey = new Key(Key.EntityType.Application,
                    ResponseCacheImpl.ALL_APPS,//全量
                    keyType, CurrentRequestVersion.get(), EurekaAccept.fromString(eurekaAccept), regions
            );
    
            Response response;
            if (acceptEncoding != null && acceptEncoding.contains(HEADER_GZIP_VALUE)) {
                response = Response.ok(responseCache.getGZIP(cacheKey))//获取压缩的数据
                        .header(HEADER_CONTENT_ENCODING, HEADER_GZIP_VALUE)
                        .header(HEADER_CONTENT_TYPE, returnMediaType)
                        .build();
            } else {
                response = Response.ok(responseCache.get(cacheKey))
                        .build();
            }
            ...
            return response;
        }

Key缓存的对象

这个对象没什么好看的,就是他重写了hashCode方法,也就是让map可以比对怎么样是同一个对象,map是根据hashCode相关算法比对的:

202309152311393492.png

202309152311400483.png

202309152311406654.png
可见不同的对象,只要传入的属性值相同,那么hashKey相同,hashCode()返回值就相同,在map中认为是同一个Key,就可以获取同一个对象。

ResponseCacheImpl的getGZIP

Key对象传进去,获取值,默认是用只读缓存的,其实内部有三级缓存,只读,读写,注册表。

202309152311412935.png

getValue获取值

可以看到,默认先启用读缓存readOnlyCacheMap,如果找到就返回了,否则再看读写缓存readWriteCacheMap,如果写缓存不存在,就会从注册表中获取,这个后面会说这么做的,存在的话就直接返回,然后都要保存到读缓存中。这里为什么要这样设计,读写分离,就是为了提高性能,写的时候不会影响到读,读也不会影响到写,当然这里会用定时器来进行数据的同步,但是不是实时的,为了性能,保证数据最终一致。

202309152311419286.png
这两个缓存的类型,LoadingCache是谷歌缓存框架里的,提供了一个方法,就是不存在的时候要怎么办,这里不存在的时候就可以去注册表中获取:

202309152311428107.png

readWriteCacheMap不存在的处理方式

如果读写缓存不存在,就会去注册表中获取,哪里看出来的呢,创建的时候:

202309152311434668.png

generatePayload

看下面的。

202309152311443229.png
然后直接用JSON编码后返回。

2023091523114507910.png

registry.getApplications()做了什么

2023091523114571311.png
内部就是获取了注册表的所有信息,封装成Applications对象:

2023091523114639012.png
最后计算出AppsHashCode后返回:

2023091523114715513.png

registry和Applications的结构大致如图

其实就是做了类型的转换,好编码后发到客户端,数据还是这些数据。

2023091523114771014.png

三级缓存基本讲完了,首先是读缓存,然后读写缓存,最后注册表,为了读写分离,后面讲他们怎么进行数据同步的。

好了,今天就到这里了,希望对学习理解有帮助,大神看见勿喷,仅为自己的学习理解,能力有限,请多包涵。


Java 面试宝典是大明哥全力打造的 Java 精品面试题,它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题,而是一套完整的 Java 知识体系,一套你 Java 知识点的扫盲贴。

它的内容包括:

  • 大厂真题:Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
  • 原创内容:Java 面试宝典内容全部都是大明哥原创,内容全面且通俗易懂,回答部分可以直接作为面试回答内容。
  • 持续更新:一次购买,永久有效。大明哥会持续更新 3+ 年,累计更新 1000+,宝典会不断迭代更新,保证最新、最全面。
  • 覆盖全面:本宝典累计更新 1000+,从 Java 入门到 Java 架构的高频面试题,实现 360° 全覆盖。
  • 不止面试:内容包含面试题解析、内容详解、知识扩展,它不仅仅只是一份面试题,更是一套完整的 Java 知识体系。
  • 宝典详情:https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
  • 宝典总览:https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
  • 宝典进展:https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw

目前 Java 面试宝典累计更新 400+ 道,总字数 42w+。大明哥还在持续更新中,下图是大明哥在 2024-12 月份的更新情况:

想了解详情的小伙伴,扫描下面二维码加大明哥微信【daming091】咨询

同时,大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ,回复【面试题】 即可免费领取。

阅读全文