Redis缓存基本问题

    技术2025-09-28  37

    缓存基本思路

    缓存作用

    提高性能保护数据库

    访问数据库和缓存最基本思路

    先查缓存,缓存没有再去查数据库

    public R selectOrderById(Integer id) { //查询缓存 Object redisObj = valueOperations.get(String.valueOf(id)); //命中缓存 if(redisObj != null) { //正常返回数据 return new R().setCode(200).setData(redisObj).setMsg("OK"); } try { Order order = orderMapper.selectOrderById(id); //查数据库 if (order != null) { valueOperations.set(String.valueOf(id), order); //加入缓存 return new R().setCode(200).setData(order).setMsg("OK"); } }finally { } return new R().setCode(500).setData(new NullValueResultDO()).setMsg("查询无果"); }

    缓存穿透

    查询一条缓存中没有,数据库中也没有的数据,查询压根不存在的数据

    解决方案

    缓存空对象

    防止同一个key多次重复查询数据库

    优点:

    容易维护

    缺点:

    效果差

    只能针对同一个key

    在redis保留了大量的无用空数据

    public R selectOrderById(Integer id) { //查询缓存 Object redisObj = valueOperations.get(String.valueOf(id)); //命中缓存 if(redisObj != null) { if(redisObj instanceof NullValueResultDO) {// 判断下次查询的是不是之前加的那个空对象 // 不让查询数据库了 return new R().setCode(200).setData(new NullValueResultDO).setMsg("OK"); } //正常返回数据 return new R().setCode(200).setData(redisObj).setMsg("OK"); } try { Order order = orderMapper.selectOrderById(id); //查数据库 if (order != null) { valueOperations.set(String.valueOf(id), order); //加入缓存 return new R().setCode(200).setData(order).setMsg("OK"); }else {// 数据库查不到,返回一个空对象 valueOperations.set(String.valueOf(id), new NullValueResultDO()); // 把空对象加入缓存 } }finally { } return new R().setCode(500).setData(new NullValueResultDO()).setMsg("查询无果"); }
    bloom过滤器

    优点:

    效果好最外层:bloomFilter 中层:缓存 内层:数据库

    缺点:

    代码难维护
    用框架创建一个布隆过滤器

    BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.01)

    相当于一个list

    param2:用户加入的数据数量

    param3:一个误判率 不能定义为0

    框架实现的布隆过滤器不能应用于分布式,只能单机

    框架是基于JVM内存的,位数组长度最高达21亿

    而用redis内存实现的(自定义)的可达42亿

    实现bloom过滤器

    需要一个位数组

    redis底层有实现位数组的数据结构 ----- bitMaps 位图

    setbit taibai 6 1 将taibai这个数据的位数组的第6位改成1

    需要多个hash函数(不同的) 上图就是三个hash函数

    利用hash函数对put进来的数据进行hash,然后对数组长度取余(防止越界),结果就是在位数组的下标, 上图的黄色位置(位置上0->1 位数组) 默认数组上是0,位数组

    查询时候也是一样对数据进行hash,然后对数组大小取余,必须满足所有位置上的结果都是1,就认定数据可能存在

    有可能查询不存在的数据,但是该数据经过hash,取余之后所有位置都是1,这就造成了误判,所以就有误判率

    精确性:

    hash函数个数,hash函数越多越精确数组长度越长,越精确容错率越小,底层的开销就越大
    布隆过滤器定义的函数
    isExist() public boolean isExist(String key) { long[] indexs = getIndexs(key); List list = redisTemplate.executePipelined(new RedisCallback<Object>() { @Nullable @Override public Object doInRedis(RedisConnection redisConnection) throws DataAccessException { redisConnection.openPipeline(); for (long index : indexs) { redisConnection.getBit("bf:taibai".getBytes(), index); } redisConnection.close(); return null; } }); return !list.contains(false);// 原理中讲到只要包含一个0就是绝对不存在,对应只要有一个false就是绝对不存在 } put() public void put(String key) { long[] indexs = getIndexs(key); redisTemplate.executePipelined(new RedisCallback<Object>() { @Nullable @Override public Object doInRedis(RedisConnection redisConnection) throws DataAccessException { redisConnection.openPipeline();// 批量操作,提高效率 for (long index : indexs) { redisConnection.setBit("bf:taibai".getBytes(),index,true);// key写死了 == setbit taibai 4343 1 } redisConnection.close(); return null; } }); } getIndexs() /** * 根据key获取bitmap下标 */ private long[] getIndexs(String key) { long hash1 = hash(key); long hash2 = hash1 >>> 16; long[] result = new long[numHashFunctions]; for (int i = 0; i < numHashFunctions; i++) {// 用同一个算法循环地去对key算不同的hash值==用多个不同的hash函数对key计算得到不同的hash值 long combinedHash = hash1 + i * hash2;// 使用一个动态值i代替不同的hash函数 if (combinedHash < 0) { combinedHash = ~combinedHash; } result[i] = combinedHash % numBits; } return result; } 不存在 getData() 和 delete() 没法取数据就是为了轻量化,高效率,bloom过滤器主要就是判断数据存在与否,而不关注取数据,如果存数据就太重了没有删除是因为 很有可能 两个不同数据经过算法之后在位数组同一个位置都有标记,如果要删除其中一个,就肯定要删除其对应数组上的标记,这样对另外一个数据就有影响 比如 1->0 另个数据就没法判断

    缓存击穿

    数据中有这条数据,但是缓存中没有

    出现原因

    一条数据刚刚在缓存中过期,正好被访问 (热点数据)首次访问的数据 (这种情况少)

    导致问题

    缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没 读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力 我们知道,使用缓存,如果获取不到,才会去数据库里获取。但是如果是热点 key,访问量非常的大,数据库在重 建缓存的时候,会出现很多线程同时重建的情况。因为高并发导致的大量热点的 key 在重建还没完成的时候,不断被重建缓存的过程,由于大量线程都去做重建缓存工作,导致服务器拖慢的情况。

    解决办法

    互斥锁

    // 两次查询缓存 双端检索机制 // 没有锁:100个线程同时访问,缓存中没,就同时挤到数据库 // 加锁:100个线程来,肯定有一个先拿到锁,剩下99个在那等着,然后第一个访问数据库,顺便添加到缓存,然后释放锁,这时剩下的线程就可以访问缓存而不是数据库 public R selectOrderById(Integer id) { //查询缓存 Object redisObj = valueOperations.get(String.valueOf(id)); //命中缓存 if(redisObj != null) { //正常返回数据 return new R().setCode(200).setData(redisObj).setMsg("OK"); } try { redisLock.lock(String.valueOf(id));// 加锁 // 查询缓存 redisObj = valueOperations.get(String.valueOf(id)); // 命中缓存 if(redisObj != null) { //正常返回数据 return new R().setCode(200).setData(redisObj).setMsg("OK"); } Order order = orderMapper.selectOrderById(id); //查数据库 if (order != null) { valueOperations.set(String.valueOf(id), order); //加入缓存 return new R().setCode(200).setData(order).setMsg("OK"); } }finally { redisLock.unlock(String.valueOf(id)); } return new R().setCode(500).setData(new NullValueResultDO()).setMsg("查询无果"); }

    缓存雪崩

    原因

    机器宕机,大部分数据失效

    缓存雪崩是指机器宕机或在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发 到DB,DB瞬时压力过重雪崩

    解决

    1:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。2:做二级缓存,A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期3:不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。4:如果缓存数据库是分布式部署,将热点数据均匀分布在不同搞得缓存数据库中

    数据一致性

    原因

    先更新数据库,后更新缓存先更新缓存,后更新数据库

    初步解决方案

    先删除缓存,再修改数据库,如果数据修改失败了,那么数据库中是旧值,缓存中是空的,不会出现数据不一致,因为读的时候缓存是空的,所以是访问数据库,拿到旧的数据

    仍存问题

    假如说线程A在删除缓存和更新数据库中间,被B线程加塞了,就会导致,B访问缓存为空,然后去访问数据库,从数据库中拿到旧数据加到缓存,结束后,线程A继续更新数据库,此时数据库中为新数据,缓存中是旧数据,就导致了数据不一致

    进一步解决方案

    延时双删

    串行化

    其他

    1.Pipeline

    注意:使用Pipeline的操作是非原子操作

    2.GEO

    GEOADD locations 116.419217 39.921133 beijin GEOPOS locations beijin GEODIST locations tianjin beijin km 计算距离 GEORADIUSBYMEMBER locations beijin 150 km 通过距离计算城市 注意:没有删除命令 它的本质是zset (type locations) 所以可以使用zrem key member 删除元素 zrange key 0 -1 表示所有 返回指定集合中所有value

    3.hyperLogLog

    Redis 在 2.8.9 版本添加了 HyperLogLog 结构。 Redis HyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大 时,计算基数所需的空间总是固定 的、并且是很小的 在 Redis 里面,每个 HyperLogLog 键只需要花费 12 KB 内存,就可以计算接近 2^64 个不同元素的基 数。这和计 算基数时,元素越多耗费内存就越多的集合形成鲜明对比。 PFADD 2017_03_06:taibai 'yes' 'yes' 'yes' 'yes' 'no' PFCOUNT 2017_03_06:taibai 统计有多少不同的值 1.PFADD 2017_09_08:taibai uuid9 uuid10 uu11 2.PFMERGE 2016_03_06:taibai 2017_09_08:taibai 合并 注意:本质还是字符串 ,有容错率,官方数据是0.81%

    4.bitmaps

    setbit taibai 500000 0 getbit taibai 500000 bitcount taibai Bitmap本质是string,是一串连续的2进制数字(0或1),每一位所在的位置为偏移(offset)。 string(Bitmap)最 大长度是512 MB,所以它们可以表示2 ^ 32=4294967296个不同的位。 /### 缓存基本思路

    Processed: 0.008, SQL: 9