分布式缓存的穿透、雪崩、击穿以及分布式锁

最新推荐文章于 2024-03-08 12:24:45 发布
最新推荐文章于 2024-03-08 12:24:45 发布
阅读量413 收藏 1
点赞数
分类专栏： 分布式 文章标签： redis java 分布式 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/shangshanzixu/article/details/115491751
版权

1.缓存穿透

什么是缓存穿透,咱们来咬文嚼字理解一下，穿透穿透，穿过了还透过去了。缓存穿透主要指的是服务器在某一时间内接收到了大量数据库根本不存在的记录的查询请求(可能是恶意攻击)，这些请求没有命中缓存，直接大量压向数据库最终导致服务不可用。
我们传统的查询缓存，大都是先看缓存中有没有，有的话直接从缓存取。如果没有则去数据库查询，如果查询到了则保存在缓存里，返回结果。如果没有的话则直接返回null。
这就导致了对于根本不存在的请求，我们每次都会查数据库，这其实就是上述问题出现的原因。对此有两种解决办法。
解决办法

  1. 针对于查询了根本不存在的数据出现的问题这个角度考虑，所以我们可以采用布隆过滤器，对于无效请求进行过滤。
  2. 针对于查过数据库没有的数据下次任然去数据库查询这个角度考虑，我们查询数据库之后，如果发现没有数据，不要直接给客户端返回null，我们可以在缓存中存放一个自定义的Null值，也可能是某种标志位，代表这个数据在数据库没有。但是这个缓存不能一直存在，应该设置例如30s这样的过期时间，等缓存过期后再去数据库看看有没有。

2.缓存雪崩

什么是缓存雪崩，咱们继续来咬文嚼字哈哈，雪崩雪崩、不就是很多缓存突然掉下去了吗？这就涉及到一个问题，因为我们要尽量保证缓存和数据库数据的一致性，缓存不可能永久存在，缓存应该是有有效时间的，过了有效时间就应该再去数据库查询。
缓存雪崩就是在某一时间段，缓存中的key大面积同时过期，导致大量请求直接压入到数据库，导致数据库被压垮。
我们来思考一下这个问题出现的原因，缓存大面积同时过期，那我们让他别同时过期不就行了
解决办法

  1. 在每个缓存过期时间的原有值上加上一个1-5min的随机值，这样就能有效避免缓存大面积同时过期。
  2. 补充一个楼主的个人观点：其实随着缓存的刷新，请求去查数据库是必然的，所以大面积过期的情况是一定会存在的，那么如何尽量维护我们服务的稳定可用呢？我们数据库是咋垮的？压力过大呗，我们在设计的时候，应该将热点数据尽量分散到各个数据库，平摊压力。这个不单单是解决这个问题的，而是我们本就应该如此设计。

3.缓存击穿

缓存击穿很容易和缓存穿透混淆，缓存击穿就像是单点打击，针对于某个热点key，他在某一时刻过期了，那么大量的请求就直接压入到数据库了。而缓存穿透是针对于根本不存在的数据的查询请求直接压入到数据库。
解决办法

  1. 简单暴力，“热点数据缓存过期了”,那某些不经常改的数据我们让他不过期不就完了哈哈哈，需要跟新的时候再手动更新一下。
  2. 主备缓存，主缓存过期了，先去备用缓存中查询，然后主缓存趁机查询数据库。
  3. 主流方案：既然是大量的请求要查数据库，我们排队加锁，一个一个查，但是第一个查到之后直接放入缓存中，后面拿到锁之后先看看缓存中此时还有没有，所以实际上只有一个请求会真正去查询数据库。

其实上述三个问题，都可以使用分布式锁解决，但是锁毕竟是一种效率较低的解决方法，我们对于不同问题应该去具体分析而不是套用万能公式，具体问题具体分析才是解决问题的真正方法，抓住引起问题的原因，从源头上解决才是根本

4.分布式锁

针对于缓存击穿的问题，我们需要使用分布式锁来解决，使得真正意义上只有一个请求会去查数据库。
在说分布式锁之前我们应该考虑一下，能不能使用本地锁？
这个问题在这个情况下，实际上是可以的，尽管我们的本地锁只能锁住本进程，但是针对于我们这个问题，假设我们有100台服务器，每个都锁自己，最多也有100个请求去查数据库，所以理论上是可以的。但是随着服务规模的扩大，一个服务有100个请求，那成百上千个呢？尽管可以，但是本地锁并不是明智的解决方案。

4.1分布式锁的实现方式

楼主比较熟悉的分布式锁的实现有两种，一个是zookeeper实现，一个是redis实现，后面会详细介绍redis实现分布式锁，咱们前面先简单提一下zookeeper怎么实现。
zookeeper实现，设置zookeeper的某个路径为锁路径，需要获取锁时，在锁路径下创建一个临时有序节点，然后判断当前节点是不是所有存在的节点的第一个节点，如果是的话则获取到锁，如果不是，则watcher前一个锁的删除事件，当前线程通watcher调用wait方法进行等待，当前一个锁的删除节点事件触发后，回调函数中调用notify方法，当前线程恢复执行，重新调用获取锁。
下面是实例代码

public class MyLock {
    // zk的连接串
    String IP = "192.168.60.130:2181";
    // 计数器对象
    CountDownLatch countDownLatch = new CountDownLatch(1);
    //ZooKeeper配置信息
    ZooKeeper zooKeeper;
    private static final String LOCK_ROOT_PATH = "/Locks";
    private static final String LOCK_NODE_NAME = "Lock_";
    private String lockPath;

    // 打开zookeeper连接
    public MyLock() {
        try {
            zooKeeper = new ZooKeeper(IP, 5000, new Watcher() {
                @Override
                public void process(WatchedEvent event) {
                    if (event.getType() == Event.EventType.None) {
                        if (event.getState() ==
                                Event.KeeperState.SyncConnected) {
                            System.out.println("连接成功!");
                            countDownLatch.countDown();
                        }
                    }
                }
            });
            countDownLatch.await();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    //获取锁
    public void acquireLock() throws Exception {
//创建锁节点
    createLock();

    //尝试获取锁
    attemptLock();

}

    //创建锁节点
    private void createLock() throws Exception {
//判断Locks是否存在，不存在创建
        Stat stat = zooKeeper.exists(LOCK_ROOT_PATH, false);
        if (stat == null) {
            zooKeeper.create(LOCK_ROOT_PATH, new byte[0],
                    ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
        }
// 创建临时有序节点
        lockPath = zooKeeper.create(LOCK_ROOT_PATH + "/" +
                        LOCK_NODE_NAME, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE,
                CreateMode.EPHEMERAL_SEQUENTIAL);
        System.out.println("节点创建成功:" + lockPath);
    }

    //监视器对象，监视上一个节点是否被删除
    Watcher watcher = new Watcher() {
        @Override
        public void process(WatchedEvent event) {
            if (event.getType() == Event.EventType.NodeDeleted) {
                synchronized (this) {
                    notifyAll();
                }
            }
        }
    };

    //尝试获取锁
    private void attemptLock() throws Exception {
// 获取Locks节点下的所有子节点
        List<String> list = zooKeeper.getChildren(LOCK_ROOT_PATH, false);
// 对子节点进行排序
        Collections.sort(list);
// /Locks/Lock_000000001
    int index = list.indexOf(lockPath.substring(LOCK_ROOT_PATH.length() + 1));
        if (index == 0) {
            System.out.println("获取锁成功!");
            return;
        } else {
// 上一个节点的路径
            String path = list.get(index ‐ 1);
            Stat stat = zooKeeper.exists(LOCK_ROOT_PATH + "/" + path,
                    watcher);
            if (stat == null) {
                attemptLock();
            } else {
                synchronized (watcher) {
                    watcher.wait();
                }
                attemptLock();
            }
        }
    }

    //释放锁
    public void releaseLock() throws Exception {
//删除临时有序节点
        zooKeeper.delete(this.lockPath,‐1);
        zooKeeper.close();
        System.out.println("锁已经释放:" + this.lockPath);
    }

    public static void main(String[] args) {
        try {
            MyLock myLock = new MyLock();
            myLock.createLock();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}
public class TicketSeller {
    private void sell() {
        System.out.println("售票开始");
// 线程随机休眠数毫秒，模拟现实中的费时操作
        int sleepMillis = 5000;
        try {
//代表复杂逻辑执行了一段时间
            Thread.sleep(sleepMillis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("售票结束");
    }

    public void sellTicketWithLock() throws Exception {
        MyLock lock = new MyLock();
// 获取锁
        lock.acquireLock();
        sell();
//释放锁
        lock.releaseLock();
    }

    public static void main(String[] args) throws Exception {
        TicketSeller ticketSeller = new TicketSeller();
        for (int i = 0; i < 10; i++) {
            ticketSeller.sellTicketWithLock();
        }
    }
}

Redis实现分布式锁

本地锁的之所以在分布式下失效就是因为锁有很多把，所以要实现分布式锁，使用一把锁就行了。redis实现分布式锁，类似于平时我们去公共卫生间上厕所，别人占着了我们就得等着，只有别人上完了我们才能继续上。
使用redis实现分布式锁有几个关键点

  1. 保证加锁和设置过期时间两个操作的原子性：set nx ex同时执行
  2. 保证判断锁内容和删除所两个操作的原子性：使用lua脚本
  3. 如何实现缓存过期时间的续期：使用一个新的线程在原线程正常工作的情况下不断续期

前面几个点我们先摆出来，我们来慢慢理一下如何使用redis实现分布式锁
redis设置分布式锁的思想是在redis中保存一个key，如果这个key已经存在了，那么说明有人抢到了这把锁，当抢到锁的人使用完了锁之后需要将锁删除。
针对于缓存击穿问题我们简单写一下下面的代码步骤

	Data = getDataFromCache();
	if(Data == null){
		while(!getLock());//如果取锁失败，进行自旋
		data = getDataFromCache();//再查询一遍缓存是否有数据
		if(data == null){
			data = getDataFromDB();
			putDataToCache();
			releaseLock();
			retrun data;
		}
	} 
	return Data;

下面是楼主最近在学习的谷粒商城项目的代码实例。代码的目的是获取一个catalogJson数据。

    @Override
    public Map<String, List<Catalog2Vo>> getCatalogJsonMap() {
        ValueOperations<String, String> ops = redisTemplate.opsForValue();
        //先从缓存中获取数据
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)){
            //如果缓存中没有数据，准备去数据库查询了、先获取锁
            try {
                while (!ops.setIfAbsent("lock", UUID.randomUUID().toString()));
                //拿到锁之后，先查一遍缓存，可能在等待锁的过程中，其他人已经查好放缓存里了
                catalogJson = ops.get("catalogJson");
                if (StringUtils.isEmpty(catalogJson)){
                    //缓存还是没有。去查数据库
                    Map<String, List<Catalog2Vo>> catalogJsonMap = getCatalogJsonMapFromDB();
                    ops.set("catalogJson",JSON.toJSONString(catalogJsonMap));
                    return catalogJsonMap;
                }
            } finally {
                redisTemplate.delete("lock");
            }
        }
        Map<String, List<Catalog2Vo>> jsonMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {
        });
        return jsonMap;
    }

但是上面的代码有一个很大的问题，假设我们一个服务设置锁了，但是他挂了，没有删除锁，那岂不是死锁了吗？所以我们的锁不能一直存在需要有过期时间。

  @Override
    public Map<String, List<Catalog2Vo>> getCatalogJsonMap() {
        ValueOperations<String, String> ops = redisTemplate.opsForValue();
        //先从缓存中获取数据
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)){
            //如果缓存中没有数据，准备去数据库查询了、先获取锁
            try {

                while (!ops.setIfAbsent("lock", UUID.randomUUID().toString()));
                //设置30s的过期时间
                redisTemplate.expire("lock",30,TimeUnit.SECONDS);
                //拿到锁之后，先查一遍缓存，可能在等待锁的过程中，其他人已经查好放缓存里了
                catalogJson = ops.get("catalogJson");
                if (StringUtils.isEmpty(catalogJson)){
                    //缓存还是没有。去查数据库
                    Map<String, List<Catalog2Vo>> catalogJsonMap = getCatalogJsonMapFromDB();
                    ops.set("catalogJson",JSON.toJSONString(catalogJsonMap));
                    return catalogJsonMap;
                }
            } finally {
                redisTemplate.delete("lock");
            }

        }
        Map<String, List<Catalog2Vo>> jsonMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {
        });
        return jsonMap;
    }

好了设置了30s过期时间，这样我们貌似没什么问题了，但是这还存在一个问题。我们是抢到锁之后，在设置的过期时间，我刚抢到锁就挂了，那还不是死锁了，所以这就是我们开头的三个问题的第一个：保证加锁与设置过期时间的原子性

while (!ops.setIfAbsent("lock", UUID.randomUUID().toString(),30,TimeUnit.SECONDS));

好了，我们过期时间也设置了，这会总没有什么问题了吧？
不，你想想我们设置的过期时间是30s，假设我们业务总共执行了40s，因为所有的锁都叫lock，那么我们执行到40s的时候，删除的肯定不是自己的锁，自己啪一下把别人的锁给删了，所以我们还需要判断我们删除的时候锁是不是自己的那把。如何确定呢，就是自己set的value是专属于自己的，这里使用时间戳+uuid的方式。

    @Override
    public Map<String, List<Catalog2Vo>> getCatalogJsonMap() {
        ValueOperations<String, String> ops = redisTemplate.opsForValue();
        //先从缓存中获取数据
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)){
            //如果缓存中没有数据，准备去数据库查询了、先获取锁
            String val = null;
            try {
                //设置30s的过期时间,加锁和过期时间一起设置
                val = System.currentTimeMillis() + UUID.randomUUID().toString();
                while (!ops.setIfAbsent("lock", val,30,TimeUnit.SECONDS));

                //拿到锁之后，先查一遍缓存，可能在等待锁的过程中，其他人已经查好放缓存里了
                catalogJson = ops.get("catalogJson");
                if (StringUtils.isEmpty(catalogJson)){
                    //缓存还是没有。去查数据库
                    Map<String, List<Catalog2Vo>> catalogJsonMap = getCatalogJsonMapFromDB();
                    ops.set("catalogJson",JSON.toJSONString(catalogJsonMap));
                    return catalogJsonMap;
                }
            } finally {
                String cacheVal = ops.get("lock");
                if (val.equals(cacheVal)){
                    redisTemplate.delete("lock");
                }
            }
        }
        Map<String, List<Catalog2Vo>> jsonMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {
        });
        return jsonMap;
    }

好，这样总没问题了吧？不，如果你获取val数据的时候，你的缓存还剩下最后0.1s，然后redis给你返回了你得数据，0.1s之后别的服务重新抢占了锁。你收到数据后，发现，噢是自己的锁，啪又一删，你有把人家的锁删了，所以这就引出了我们开头的第二个问题
：保证判断锁内容和删除所两个操作的原子性
这里使用lua脚本来进行锁的删除，lua脚本保证了我们获取值和删除是原子性的操作。

   @Override
    public Map<String, List<Catalog2Vo>> getCatalogJsonMap() {
        ValueOperations<String, String> ops = redisTemplate.opsForValue();
        //先从缓存中获取数据
        String catalogJson = ops.get("catalogJson");
        if (StringUtils.isEmpty(catalogJson)){
            //如果缓存中没有数据，准备去数据库查询了、先获取锁
            String val = null;
            try {
                //设置30s的过期时间,加锁和过期时间一起设置
                val = System.currentTimeMillis() + UUID.randomUUID().toString();
                while (!ops.setIfAbsent("lock", val,30,TimeUnit.SECONDS));

                //拿到锁之后，先查一遍缓存，可能在等待锁的过程中，其他人已经查好放缓存里了
                catalogJson = ops.get("catalogJson");
                if (StringUtils.isEmpty(catalogJson)){
                    //缓存还是没有。去查数据库
                    Map<String, List<Catalog2Vo>> catalogJsonMap = getCatalogJsonMapFromDB();
                    ops.set("catalogJson",JSON.toJSONString(catalogJsonMap));
                    return catalogJsonMap;
                }
            } finally {
                //删除锁
                RedisScript script = RedisScript.of("if redis.call(\"get\",KEYS[1]) == ARGV[1] then\n" +
                        "    return redis.call(\"del\",KEYS[1])\n" +
                        "else\n" +
                        "    return 0\n" +
                        "end", Long.class);
                redisTemplate.execute(script, Arrays.asList("lock"), val);

            }
        }
        Map<String, List<Catalog2Vo>> jsonMap = JSON.parseObject(catalogJson, new TypeReference<Map<String, List<Catalog2Vo>>>() {
        });
        return jsonMap;
    }

然后最后就剩下我们第三个问题啦，我们设置的过期时间肯定是固定的，但是我们的业务执行时间确实不确定的，那怎么办呢？如何给我们的缓存过期时间进行续期呢？
这里可以开一个线程去给我们自动续期，当我们业务线程还在工作时，另一个线程自动给我们的缓存时间进行续期。这样就完成了。
上面就是博主分享的全部内容了，楼主毕竟才疏学浅，如有错误望不吝赐教。
redis分布式锁参考官网： redis分布式锁.

shangshanzixu
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis缓存穿透，缓存击穿和缓存雪崩
12-14
一、缓存处理流程 处理Reids缓存引发的问题时，我们首先得知道缓存处理的一个流程，如下图： 二、缓存穿透，缓存击穿和缓存雪崩 缓存穿透 描述：缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1024”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。 解决方法: 1.接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截； 2.从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用
redis 的雪崩、击穿、穿透
01-08
缓存雪崩：redis中的很多key过期时间相同，过期时间到了之后，大量数据访问redis，然后redis访问数据库，redis受不了了，相当于缓存被击穿了 解决方案： 1、不要把大量的数据的超时时间设为同一个时间点，加个随机值 2、热点数据永远不过期 3、缓存数据库分布式部署   缓存击穿：一个key在失效的时刻，大量请求这个key，直接访问到数据中 解决方案： 1、热点数据永远不过期 2、加互斥锁   缓存穿透：大量获取缓存中不存在key的value，导致大量数据直接访问数据库 解决方案： 1、采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤；
redis缓存(穿透, 雪崩, 击穿, 数据不一致, 数据并发竞争 ), 分布式锁(watch乐观锁, setnx, redission)
最新发布
天涯芳草
03-08 1133
redis分布式缓存,redis缓存穿透,缓存雪崩
redis面试（一）
yshir
11-17 253
1、列举一个常用的Redis客户端的并发模型 Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。 Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在redis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。 对此有2种解决方法： 1.客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized 2.服
【分布式缓存】缓存穿透
wuychn
03-27 158
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。解决办法有缓存空对象和使用布隆过滤器。 一、缓存空数据 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存空对象会有两个问题： 第一，空值做了缓...
Redis6应用问题解决——缓存穿透，缓存击穿，缓存雪崩，分布式锁
dingxiao123的博客
06-30 367
分布式锁：当在分布式模型下，数据只有一份（或有限制），此时需要利用锁技术来控制某一时刻修改数据的进程数。这种锁即为分布式锁。为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就。
分布式系统: 缓存雪崩详解
m0_72410588的博客
09-03 81
缓存雪崩是指在分布式系统中，由于缓存层面的故障或异常，导致大量请求直接落到后端数据库上，从而引起数据库压力剧增，甚至导致数据库崩溃的现象。简而言之，就是缓存失效时，后端系统无法承受全部请求而崩溃。
让你深刻理解缓存击穿和分布式锁！
yikexiaolizi的博客
02-19 200
存击穿和分布式锁
加锁解决缓存击穿问题
Jak的博客
03-20 1494
一、加本地锁问题 1.1 本地锁分析 继上一篇Redis缓存中介绍，我们可以很容易解决缓存穿透(空结果缓存)，和缓存雪崩问题(加随机值)，对于缓存击穿问题，可以采用加锁的方式，但是，这个锁需要用什么样的锁，怎么来加这个锁，也是非常有讲究的，一不小心就可能导致各种问题。 这里我们先测试一下，加本地锁情况下的一些问题。 @Override public Map<String, List<Catelog2Vo>> getCatalogJson() {
分布式技术原理与实战45讲--39 第34讲：如何避免缓存穿透、缓存击穿、缓存雪崩？
g_z_q_的博客
02-25 117
这一课时的内容，分享了分布式缓存应用和面试的经典问题：缓存穿透、缓存击穿、缓存雪崩，以及对应这几种业务场景的解决方案。今天介绍的这几个问题场景，只是对缓存应用时一些高频问题的抽象，在实际业务开发中，永远都是具体情况具体分析，对不同的业务，适用不同的解决方案。你在应用缓存时有哪些心得体会，比如如何提高缓存命中率，如何处理热点 Key 等，欢迎留言进行分享。
【大厂面试题】分布式详细解析及其答案
07-06
1、Redis缓存穿透，缓存击穿，缓存雪崩原因+解决方案 2、Redis锁结合使用场景，需要注意什么?超时问题如何解决 在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发...
基于Redis解决缓存击穿、穿透和雪崩问题的通用解决方案，拿来即用.zip
01-04
基于Redis解决缓存击穿、穿透和雪崩问题的通用解决方案，拿来即用。支持存储对象、集合、简单数据类型等。无需提前将数据存入Redis，直接使用提供的分布式缓存接口查询数据即可，附带完善的单元测试用例，方便学习...
在分布式的环境下如何解决缓存穿透，雪崩，击穿问题以及使用redisson解决缓存击穿问题
qq_63763951的博客
01-15 965
为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。对于缓存击穿，我们可以将查询的数据条件都哈希到一个足够大的布隆过滤器中，用户发送的请求会先被布隆过滤器拦截，一定不存在的数据就直接拦截返回了，从而避免下一步对数据库的压力。不存在数据设置短过期时间：对于某个查询为空的数据，可以将这个空结果进行Redis缓存，但是设置很短的过期时间，比如30s，可以根据实际业务设定。当然这种方式比较粗暴，对于某些业务场景是不适合的。
高并发下缓存失效问题（穿透、雪崩、击穿），以及本地锁、Redis分布锁、Redisson锁、SpringCache使用
weixin_45941687的博客
06-07 2359
高并发下缓存失效问题（穿透、雪崩、击穿），以及本地锁、Redis分布锁、Redisson锁、SpringCache使用
Redis 缓存击穿问题 解决方案（一） 互斥锁
Decade_Faiz的博客
09-09 2050
第一个线程过来访问，获得锁，只有第一个线程能够去直接访问数据库，然后把数据写入缓存。第二个线程过来，没得到锁，只能不断重试去获得锁，直至第一个线程释放锁，然后第二个线程就能够直接从缓存中获得数据。一个查询产品信息的方法可能会同时存在缓存穿透和缓存击穿的问题，如何同时解决这两个问题这里暂不涉及，只关注如何解决缓存击穿问题。​ 为防止所有请求都直接访问数据库，于是就有了如下两种解决。​ 接下来编写业务方法，查询一个热门产品。​ 缓存带来的问题有很多，有。，加锁之后线程从原来的。来解决缓存击穿问题。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题？分布式情况下如何添加分布式锁
做笔记\记录遇到的程序bug
03-21 1874
查看控制台情况，理想情况是数据库只查询一次。实际上查询了多次，出现这个问题的原因就是一个用户查询完数据后，就释放了锁。还未将数据写入缓存的时候，第二个用户又拿到了锁。这个时候缓存中还未进行数据缓存，导致再次查询数据库。我这里用docker安装redis、查看容器运行情况。前提条件：已经安装了Redis。本地锁在分布式情况下是锁不住的。优化代码逻辑，压测过程同上。redis可视化工具查看。
Redis中的缓存穿透，缓存击穿，缓存雪崩，分布式锁
m0_57334678的博客
12-24 1125
Redis中的缓存穿透，缓存击穿，缓存雪崩，分布式锁
redis学习记录
云想的博客
08-12 244
redis学习记录 一.Redis与SpringBoot整合 1、 在pom.xml文件中引入redis相关依赖 <!-- redis --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- spring
redis的缓存穿透缓存击穿缓存雪崩
01-04
缓存穿透、缓存击穿和缓存雪崩是常见的缓存问题，下面是关于Redis的缓存穿透、缓存击穿和缓存雪崩的介绍： 1. 缓存穿透： 缓存穿透是指当一个请求查询一个不存在于缓存中的数据时，由于缓存无法命中，请求会直接访问数据库。这种情况下，如果有大量的请求查询不存在的数据，会导致数据库压力过大，影响系统性能。 2. 缓存击穿： 缓存击穿是指当一个热点数据的缓存过期或失效时，大量的请求同时访问该数据，导致缓存无法命中，请求会直接访问数据库。这种情况下，数据库会承受巨大的压力，可能导致数据库崩溃。 3. 缓存雪崩： 缓存雪崩是指当缓存中的大量数据同时过期或失效时，大量的请求会直接访问数据库，导致数据库压力剧增，性能下降甚至系统崩溃。缓存雪崩通常是由于缓存服务器故障、缓存设置不合理或者缓存数据过期时间设置不当等原因引起的。 为了避免缓存穿透、缓存击穿和缓存雪崩问题，可以采取以下措施： - 缓存穿透：可以在应用层对查询的数据进行校验，如果数据不存在，则不进行缓存操作，避免大量无效的请求访问数据库。 - 缓存击穿：可以互斥锁或分布式锁来保护热点数据的问，当缓存失效时，只允许一个请求访问数据库并更新缓存，其他请求等待缓存更新完成后再从缓存中获取数据。 - 缓存雪崩：可以采用多级缓存、缓存预热、设置合理的缓存过期时间等策略来避免大量缓存同时失效，保证系统的稳定性和性能。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值