• 【多级缓存】


    传统的缓存策略一般是请求到达Tomcat后,先查询Redis,如果未命中则查询数据库,如图:在这里插入图片描述
    存在下面的问题:

    • 请求要经过Tomcat处理,Tomcat的性能成为整个系统的瓶颈

    • Redis缓存失效时,会对数据库产生冲击

    多级缓存就是充分利用请求处理的每个环节,分别添加缓存,减轻Tomcat压力,提升服务性能
    在多级缓存架构中,Nginx内部需要编写本地缓存查询Redis查询Tomcat查询的业务逻辑,因此这样的nginx服务不再是一个反向代理服务器,而是一个编写业务的Web服务器了

    在这里插入图片描述

    可见,多级缓存的关键有两个:

    • 一个是在nginx中编写业务,实现nginx本地缓存、Redis、Tomcat的查询
    • 另一个就是在Tomcat中实现JVM进程缓存
    • Nginx编程则会用到OpenResty框架结合Lua这样的语言。

    1. JVM进程缓存

    案例:
    需求:利用Caffeine实现下列需求:

    • 给根据id查询商品的业务添加缓存,缓存未命中时查询数据库
    • 给根据id查询商品库存的业务添加缓存,缓存未命中时查询数据库
    • 缓存初始大小为100
    • 缓存上限为10000

    首先,我们需要定义两个Caffeine的缓存对象,分别保存商品、库存的缓存数据。
    在item-service的com.heima.item.config包下定义CaffeineConfig类:
    在这里插入图片描述
    然后,修改item-service中的com.heima.item.web包下的ItemController类,添加缓存逻辑:
    在这里插入图片描述

    2. Lua语法

    Nginx编程需要用到Lua语言,因此学习Lua的基本语法。
    Lua中支持的常见数据类型包括:
    在这里插入图片描述
    需求:自定义一个函数,可以打印table,当参数为nil时,打印错误信息
    在这里插入图片描述

    3. 实现多级缓存

    多级缓存的实现离不开Nginx编程,而Nginx编程又离不开OpenResty。
    在这里插入图片描述

    • windows上的nginx用来做反向代理服务,将前端的查询商品的ajax请求代理到OpenResty集群
    • OpenResty集群用来编写多级缓存业务

    3.1 反向代理流程

    现在,商品详情页使用的是假的商品数据。不过在浏览器中,可以看到页面有发起ajax请求查询真实商品数据。在这里插入图片描述
    请求地址是localhost,端口是80,就被windows上安装的Nginx服务给接收到了。然后代理给了OpenResty集群:
    在这里插入图片描述

    3.2 OpenResty快速入门

    在这里插入图片描述
    可以看到商品id是以路径占位符方式传递的,因此可以利用正则表达式匹配的方式来获取ID

    OpenResty的很多功能都依赖于其目录下的Lua库,需要在nginx.conf中指定依赖库的目录,并导入依赖:
    1)添加对OpenResty的Lua模块的加载在这里插入图片描述
    2)获取商品id在这里插入图片描述

    3)编写item.lua在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    4. 查询Tomcat

    4.1 发送http请求的API

    nginx提供了内部API用以发送http请求:在这里插入图片描述
    返回的响应内容包括:

    • resp.status:响应状态码
    • resp.header:响应头,是一个table
    • resp.body:响应体,就是响应数据

    注意:这里的path是路径,并不包含IP和端口。这个请求会被nginx内部的server监听并处理。但是我们希望这个请求发送到Tomcat服务器,所以还需要编写一个server来对这个路径做反向代理:在这里插入图片描述

    4.2 封装http工具

    1)添加反向代理,到windows的Java服务

    因为item-service中的接口都是/item开头,所以我们监听/item路径,代理到windows上的tomcat服务。在这里插入图片描述
    以后,只要我们调用ngx.location.capture("/item"),就一定能发送请求到windows的tomcat服务。

    2)封装工具类
    在这里插入图片描述
    所以,自定义的http工具也需要放到这个目录下。
    /usr/local/openresty/lualib目录下,新建一个common.lua文件:内容如下:
    在这里插入图片描述
    这个工具将read_http函数封装到_M这个table类型的变量中,并且返回,这类似于导出。

    使用的时候,可以利用require('common')来导入该函数库,这里的common是函数库的文件名。
    3)实现商品查询
    最后,我们修改/usr/local/openresty/lua/item.lua文件,利用刚刚封装的函数库实现对tomcat的查询:在这里插入图片描述
    这里查询到的结果是json字符串,并且包含商品、库存两个json字符串,页面最终需要的是把两个json拼接为一个json:
    在这里插入图片描述
    这就需要我们先把JSON变为lua的table,完成数据整合后,再转为JSON。
    OpenResty提供了一个cjson的模块用来处理JSON的序列化和反序列化。
    下面,我们修改之前的item.lua中的业务,添加json处理功能:在这里插入图片描述

    4.3 基于ID负载均衡

    刚才的代码中,我们的tomcat是单机部署。而实际开发中,tomcat一定是集群模式:
    因此,OpenResty需要对tomcat集群做负载均衡。

    而默认的负载均衡规则是轮询模式,当我们查询/item/10001时:

    • 第一次会访问8081端口的tomcat服务,在该服务内部就形成了JVM进程缓存
    • 第二次会访问8082端口的tomcat服务,该服务内部没有JVM缓存(因为JVM缓存无法共享),会查询数据库

    如果能让同一个商品,每次查询时都访问同一个tomcat服务,那么JVM缓存就一定能生效了。

    也就是说,我们需要根据商品id做负载均衡,而不是轮询。

    nginx根据请求路径做hash运算,把得到的数值对tomcat服务的数量取余,余数是几,就访问第几个服务,实现负载均衡。

    实现
    修改/usr/local/openresty/nginx/conf/nginx.conf文件,实现基于ID做负载均衡。
    首先,定义tomcat集群,并设置基于路径做负载均衡:在这里插入图片描述

    4.4 流程小结

    在这里插入图片描述
    首先进来的localhost:80会由Nginx拦截代理到openresty,openresty会将路径为/api/item/(***)这样的路径解析出访问的商品id,之后通过将/item这样的路径代理发送到windows电脑中的Tomcat服务器查询,当tomcat中线程缓存有则返回,没有则去数据库查询。

    5. Redis缓存查询

    冷启动:服务刚刚启动时,Redis中并没有缓存,如果所有商品数据都在第一次查询时添加缓存,可能会给数据库带来较大压力。

    缓存预热:在实际开发中,我们可以利用大数据统计用户访问的热点数据,在项目启动时将这些热点数据提前查询并保存到Redis中。
    我们数据量较少,并且没有数据统计相关功能,目前可以在启动时将所有数据都放入缓存中。
    在这里插入图片描述
    4)编写初始化类

    缓存预热需要在项目启动时完成,并且必须是拿到RedisTemplate之后。

    这里我们利用InitializingBean接口来实现,因为InitializingBean可以在对象被Spring创建并且成员变量全部注入后执行。在这里插入图片描述
    现在,Redis缓存已经准备就绪,我们可以再OpenResty中实现查询Redis的逻辑了。如下图红框所示:在这里插入图片描述
    当请求进入OpenResty之后:

    • 优先查询Redis缓存
    • 如果Redis缓存未命中,再查询Tomcat

    封装Redis工具
    OpenResty提供了操作Redis的模块,我们只要引入该模块就能直接使用。但是为了方便,我们将Redis操作封装到之前的common.lua工具库中。
    修改/usr/local/openresty/lualib/common.lua文件:
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    完整的common.lua:

    -- 导入redis
    local redis = require('resty.redis')
    -- 初始化redis
    local red = redis:new()
    red:set_timeouts(1000, 1000, 1000)
    
    -- 关闭redis连接的工具方法,其实是放入连接池
    local function close_redis(red)
        local pool_max_idle_time = 10000 -- 连接的空闲时间,单位是毫秒
        local pool_size = 100 --连接池大小
        local ok, err = red:set_keepalive(pool_max_idle_time, pool_size)
        if not ok then
            ngx.log(ngx.ERR, "放入redis连接池失败: ", err)
        end
    end
    
    -- 查询redis的方法 ip和port是redis地址,key是查询的key
    local function read_redis(ip, port, key)
        -- 获取一个连接
        local ok, err = red:connect(ip, port)
        if not ok then
            ngx.log(ngx.ERR, "连接redis失败 : ", err)
            return nil
        end
        -- 查询redis
        local resp, err = red:get(key)
        -- 查询失败处理
        if not resp then
            ngx.log(ngx.ERR, "查询Redis失败: ", err, ", key = " , key)
        end
        --得到的数据为空处理
        if resp == ngx.null then
            resp = nil
            ngx.log(ngx.ERR, "查询Redis数据为空, key = ", key)
        end
        close_redis(red)
        return resp
    end
    
    -- 封装函数,发送http请求,并解析响应
    local function read_http(path, params)
        local resp = ngx.location.capture(path,{
            method = ngx.HTTP_GET,
            args = params,
        })
        if not resp then
            -- 记录错误信息,返回404
            ngx.log(ngx.ERR, "http查询失败, path: ", path , ", args: ", args)
            ngx.exit(404)
        end
        return resp.body
    end
    -- 将方法导出
    local _M = {  
        read_http = read_http,
        read_redis = read_redis
    }  
    return _M
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58

    5.1 实现Redis查询

    接下来,我们就可以去修改item.lua文件,实现对Redis的查询了。
    查询逻辑是:

    • 根据id查询Redis
    • 如果查询失败则继续查询Tomcat
    • 将查询结果返回

    1)修改/usr/local/openresty/lua/item.lua文件,添加一个查询函数:
    在这里插入图片描述
    2)而后修改商品查询、库存查询的业务:在这里插入图片描述

    6. Nginx本地缓存

    现在,整个多级缓存中只差最后一环,也就是nginx的本地缓存了。如图:
    在这里插入图片描述

    6.1 本地缓存API

    OpenResty为Nginx提供了shard dict的功能,可以在nginx的多个worker之间共享数据,实现缓存功能。
    1)开启共享字典,在nginx.conf的http下添加配置:在这里插入图片描述
    2)操作共享字典:在这里插入图片描述

    6.2 实现本地缓存查询

    1)修改/usr/local/openresty/lua/item.lua文件,修改read_data查询函数,添加本地缓存逻辑:在这里插入图片描述
    2)修改item.lua中查询商品和库存的业务,实现最新的read_data函数:在这里插入图片描述
    其实就是多了缓存时间参数,过期后nginx缓存会自动删除,下次访问即可更新缓存。
    3)完整的item.lua文件:

    -- 导入common函数库
    local common = require('common')
    local read_http = common.read_http
    local read_redis = common.read_redis
    -- 导入cjson库
    local cjson = require('cjson')
    -- 导入共享词典,本地缓存
    local item_cache = ngx.shared.item_cache
    
    -- 封装查询函数
    function read_data(key, expire, path, params)
        -- 查询本地缓存
        local val = item_cache:get(key)
        if not val then
            ngx.log(ngx.ERR, "本地缓存查询失败,尝试查询Redis, key: ", key)
            -- 查询redis
            val = read_redis("127.0.0.1", 6379, key)
            -- 判断查询结果
            if not val then
                ngx.log(ngx.ERR, "redis查询失败,尝试查询http, key: ", key)
                -- redis查询失败,去查询http
                val = read_http(path, params)
            end
        end
        -- 查询成功,把数据写入本地缓存
        item_cache:set(key, val, expire)
        -- 返回数据
        return val
    end
    
    -- 获取路径参数
    local id = ngx.var[1]
    
    -- 查询商品信息
    local itemJSON = read_data("item:id:" .. id, 1800,  "/item/" .. id, nil)
    -- 查询库存信息
    local stockJSON = read_data("item:stock:id:" .. id, 60, "/item/stock/" .. id, nil)
    
    -- JSON转化为lua的table
    local item = cjson.decode(itemJSON)
    local stock = cjson.decode(stockJSON)
    -- 组合数据
    item.stock = stock.stock
    item.sold = stock.sold
    
    -- 把item序列化为json 返回结果
    ngx.say(cjson.encode(item))
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47

    7. 缓存同步

    大多数情况下,浏览器查询到的都是缓存数据,如果缓存数据与数据库数据存在较大差异,可能会产生比较严重的后果。

    所以我们必须保证数据库数据、缓存数据的一致性,这就是缓存与数据库的同步。

    7.1 数据同步策略

    缓存数据同步的常见方式有三种:

    设置有效期:给缓存设置有效期,到期后自动删除。再次查询时更新

    • 优势:简单、方便
    • 缺点:时效性差,缓存过期之前可能不一致
    • 场景:更新频率较低,时效性要求低的业务

    同步双写:在修改数据库的同时,直接修改缓存

    • 优势:时效性强,缓存与数据库强一致
    • 缺点:有代码侵入,耦合度高;
    • 场景:对一致性、时效性要求较高的缓存数据

    异步通知:修改数据库时发送事件通知,相关服务监听到通知后修改缓存数据

    • 优势:低耦合,可以同时通知多个缓存服务
    • 缺点:时效性一般,可能存在中间不一致状态
    • 场景:时效性要求一般,有多个服务需要同步

    而异步实现又可以基于MQ或者Canal来实现:
    1)基于MQ的异步通知:在这里插入图片描述
    解读:

    • 商品服务完成对数据的修改后,只需要发送一条消息到MQ中。
    • 缓存服务监听MQ消息,然后完成对缓存的更新,依然有少量的代码侵入。

    2)基于Canal的通知在这里插入图片描述

    解读:

    • 商品服务完成商品修改后,业务直接结束,没有任何代码侵入
    • Canal监听MySQL变化,当发现变化后,立即通知缓存服务
    • 缓存服务接收到canal通知,更新缓存,代码零侵入

    7.2 安装Canal

    Canal是基于mysql的主从同步来实现的,MySQL主从同步的原理如下:在这里插入图片描述

    • 1)MySQL master 将数据变更写入二进制日志( binary log),其中记录的数据叫做binary log events
    • 2)MySQL slave 将 master 的 binary log events拷贝到它的中继日志(relay log)
    • 3)MySQL slave 重放 relay log 中事件,将数据变更反映它自己的数据

    而Canal就是把自己伪装成MySQL的一个slave节点,从而监听master的binary log变化。再把得到的变化信息通知给Canal的客户端,进而完成与数据库的同步。
    在这里插入图片描述

    步骤

    1. 引入依赖在这里插入图片描述
    2. 编写配置:在这里插入图片描述
    3. 修改Item实体类:通过@Id、@Column、@Transient注解完成Item与数据库表字段的映射:在这里插入图片描述
    4. 编写监听器:
      通过实现EntryHandler接口编写监听器,监听Canal消息。注意两点:
    • 实现类通过@CanalTable("tb_item")指定监听的表信息
    • EntryHandler的泛型是与表对应的实体类
    package com.heima.item.canal;
    
    import com.github.benmanes.caffeine.cache.Cache;
    import com.heima.item.config.RedisHandler;
    import com.heima.item.pojo.Item;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Component;
    import top.javatool.canal.client.annotation.CanalTable;
    import top.javatool.canal.client.handler.EntryHandler;
    
    @CanalTable("tb_item")
    @Component
    public class ItemHandler implements EntryHandler<Item> {
    
        @Autowired
        private RedisHandler redisHandler;
        @Autowired
        private Cache<Long, Item> itemCache;
    
        @Override
        public void insert(Item item) {
            // 写数据到JVM进程缓存
            itemCache.put(item.getId(), item);
            // 写数据到redis
            redisHandler.saveItem(item);
        }
    
        @Override
        public void update(Item before, Item after) {
            // 写数据到JVM进程缓存
            itemCache.put(after.getId(), after);
            // 写数据到redis
            redisHandler.saveItem(after);
        }
    
        @Override
        public void delete(Item item) {
            // 删除数据到JVM进程缓存
            itemCache.invalidate(item.getId());
            // 删除数据到redis
            redisHandler.deleteItemById(item.getId());
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43

    在这里对Redis的操作都封装到了RedisHandler这个对象中,是我们之前做缓存预热时编写的一个类,内容如下:

    package com.heima.item.config;
    
    import com.fasterxml.jackson.core.JsonProcessingException;
    import com.fasterxml.jackson.databind.ObjectMapper;
    import com.heima.item.pojo.Item;
    import com.heima.item.pojo.ItemStock;
    import com.heima.item.service.IItemService;
    import com.heima.item.service.IItemStockService;
    import org.springframework.beans.factory.InitializingBean;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.data.redis.core.StringRedisTemplate;
    import org.springframework.stereotype.Component;
    
    import java.util.List;
    
    @Component
    public class RedisHandler implements InitializingBean {
    
        @Autowired
        private StringRedisTemplate redisTemplate;
    
        @Autowired
        private IItemService itemService;
        @Autowired
        private IItemStockService stockService;
    
        private static final ObjectMapper MAPPER = new ObjectMapper();
    
        @Override
        public void afterPropertiesSet() throws Exception {
            // 初始化缓存
            // 1.查询商品信息
            List<Item> itemList = itemService.list();
            // 2.放入缓存
            for (Item item : itemList) {
                // 2.1.item序列化为JSON
                String json = MAPPER.writeValueAsString(item);
                // 2.2.存入redis
                redisTemplate.opsForValue().set("item:id:" + item.getId(), json);
            }
    
            // 3.查询商品库存信息
            List<ItemStock> stockList = stockService.list();
            // 4.放入缓存
            for (ItemStock stock : stockList) {
                // 2.1.item序列化为JSON
                String json = MAPPER.writeValueAsString(stock);
                // 2.2.存入redis
                redisTemplate.opsForValue().set("item:stock:id:" + stock.getId(), json);
            }
        }
    
        public void saveItem(Item item) {
            try {
                String json = MAPPER.writeValueAsString(item);
                redisTemplate.opsForValue().set("item:id:" + item.getId(), json);
            } catch (JsonProcessingException e) {
                throw new RuntimeException(e);
            }
        }
    
        public void deleteItemById(Long id) {
            redisTemplate.delete("item:id:" + id);
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65

    8. 总结

    在这里插入图片描述
    首先用户发一个请求,先经过Nginx(此处Nginx作为静态资源服务器与反向代理服务器)返回一个静态资源,经过浏览器渲染给呈现出来,但是上面的数据都是假的,此时前端会发一些ajax请求后端数据,先吧请求发送给Nginx,因为Nginx中有本地缓存,所以还是将请求路由(这里类似于redis的槽),确保同一个请求路由到同一个Nginx服务器,当Nginx接收到请求时,首先会查看本地缓存有没有,没有的话先在redis缓存中找,当redis中也没有的话才访问Tomcat,此时Tomcat会先在JVM进程缓存中去找,再没有的话才去数据库查,然后针对缓存同步来说的话,用canal监听mysql的binlog日志,其实canal就是伪装成一个slave节点,当监听到binlog变换时,通知给java客户端,然后在程序中进行缓存同步的操作。其实canal在代码中的话就是实现EntryHandler<>这个接口重写里面的insert、update、delete方法,将redis和jvm进程缓存进行更新操作。

  • 相关阅读:
    偏向锁、轻量级锁、重量级锁的理解和适用场景
    C++内存模型与名称空间总结,看这一篇就够了
    2万字一网通办远程视频踏勘建设方案67页
    【Java】注解 之 定义注解
    HTML学习笔记
    尚硅谷Vue
    推荐接口压测报告
    [Python人工智能] 三十七.Keras构建无监督学习Autoencoder模型及MNIST聚类可视化详解
    阅读笔记——RetinaFace: Single-stage Dense Face Localisation in the Wild
    时间序列预测:用电量预测 07 灰色预测算法
  • 原文地址:https://blog.csdn.net/qq_51240148/article/details/133556865