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

最新推荐文章于 2022-08-11 20:51:39 发布
最新推荐文章于 2022-08-11 20:51:39 发布
阅读量492 收藏 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分布式锁.

深入理解分布式技术 - 探究缓存穿透、缓存击穿、缓存雪崩解决方案
小工匠
03-04 1万+
文章目录概述缓存穿透what缓存穿透发生的场景举例不合理的缓存失效策略恶意攻击如何规避缓存穿透 概述 缓存系统不得不考虑的问题是缓存穿透、缓存击穿与失效时的雪崩效应，这是避免不了的问题 。 今天我们来讨论下这几种问题的常见的解决思路 缓存穿透 what 顾名思义，是指业务请求穿过了缓存层，落到持久化存储上。在大多数场景下，我们应用缓存是为了承载前端业务请求，缓存被击穿以后，如果请求量比较大，则会导致数据库出现风险。 高并发的情况下， 单靠数据库是不能承载的，如果缓存不能很好的工作，可能会影响数据库
Redis的缓存穿透、缓存击穿、缓存雪崩
qq_48595067的博客
07-13 6501
缓存击穿和缓存雪崩都是与缓存相关的常见问题，它们有一些共同点，并可以采用类似的解决方法。
【分布式】缓存穿透、缓存雪崩，缓存击穿解决方案
weixin_33711641的博客
06-08 102
一、什么样的数据适合缓存 二、缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案： 1）有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可...
【分布式缓存】缓存穿透
wuychn
03-27 187
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。解决办法有缓存空对象和使用布隆过滤器。 一、缓存空数据 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存空对象会有两个问题： 第一，空值做了缓...
redis缓存穿透+分布式锁
yjq_javaxx的博客
07-04 156
1.redis缓存穿透 缓存没有该数据并且数据库中也没有该数据， 这是如果有大量的恶意请求来访问这种数据时，这些请求穿过缓存，到达数据库。 如何解决: 1.如果数据库中不存在该数据时，往缓存中存放一个空对象。该对象什么也不做。（缓存中会存在大量的冗余数据。设 置很短的过期时间）。 2. 使用布隆过滤器。理解为一个容器 把数据库中的所有数据id放入到布隆过滤器中 2.分布式锁 sspringboot项目中：application.properties： sprin.
从缓存击穿 看 分布式锁
wuqihawubito的博客
12-02 1055
文章目录缓存击穿解决方案：数据库角度缓存角度分布式锁 缓存击穿 在我们使用缓存时，会将从数据库里查询到的数据存到缓存中，并设置一个过期时间。就是当一个热点数据过期时，会有大量的访问到数据库中，给数据库造成很大压力，这就是缓存击穿。 解决方案： 那么缓存击穿的解决，我们可以从 缓存 和 数据库两方面入手。 数据库角度 对于数据库来说，就是短时间的大量请求无法承受，那么就让他承受的请求变成 1/100,1/1000，用 锁 可以达到这样的情况，之前 100 个，1000个请求都可以同时读，但是现在有了 锁， 一
Redis缓存穿透，缓存击穿和缓存雪崩
12-14
2. **分布式部署**：如果条件允许，可以采用分布式缓存部署，将热点数据分散在不同节点，减少单点压力。 3. **永不过期策略**：对于重要的热点数据，同样可以设置为永不过期。 以上是针对Redis缓存系统中可能出现的...
什么是redis缓存穿透 雪崩 ,如何应对解决 redis缓存穿透 雪崩 的解决办法
01-07
1. **缓存击穿**：不同于缓存穿透，缓存击穿是指某一个非常热的Key在缓存过期的瞬间，大量的请求同时穿透缓存到达数据库。处理方式通常是将该热Key设置为永不过期，或者采用互斥锁机制，确保只有一个请求去更新缓存...
缓存穿透、缓存雪崩、缓存击穿？
m0_71777195的博客
07-15 395
当然，除了上述方案，我们还可以限流、降级、熔断等服务层的措施，也可以考虑数据库层是否可以进行横向扩展，当缓存异常发生时，确保数据库能够抗住流量，不至于让整个系统崩溃。缓存雪崩是指只大量热点key同时失效的情况，如果是单个热点key，在不停的扛着大并发，在这个key失效的瞬间，持续的大并发请求就会击破缓存，直接请求到数据库，好像蛮力击穿一样。但当缓存中大量热点缓存采用了相同的实效时间，就会导致缓存在某一个时刻同时实效，请求全部转发到数据库，从而导致数据库压力骤增，甚至宕机。为什么说不得不考虑？...
Redis-应用问题（缓存穿透/缓存击穿/缓存雪崩/分布式锁）
萌萌虎的博客
08-11 633
对应的在并不存在，每次针对此的请求从，请求都会压到，从而可能压垮。比如用一个不存在的获取，不论还是都没有，若黑客利用此漏洞进行攻击可能压垮数据库。（访问不存在的数据）一个一定及的数据，由于缓存是时写的，并且出于考虑，如果从查不到数据则，这将导致这个不存在的数据都要到去查询，失去了的意义。...
缓存和分布式锁
menxinziwen的博客
08-29 235
缓存 缓存使用 为了系统性能的提升，我们一般都会将部分数据放入缓存中，加速访问。而 db 承担数据落盘工作。 哪些数据适合放入缓存？  即时性、数据一致性要求不高的  访问量大且更新频率不高的数据（读多，写少） 举例：电商类应用，商品分类，商品列表等适合缓存并加一个失效时间(根据数据更新频率来定)，后台如果发布一个商品，买家需要 5 分钟才能看到新的商品一般还是可以接受的。 伪代码实现 data = cache.load(id);//从缓存加载数据 If(data == null){ data = d
分布式系统 缓存穿透与失效时的雪崩效应
weixin_34010949的博客
06-16 65
缓存系统往往有两个问题须要面对和考虑：缓存穿透与失效时的雪崩效应。        1. 缓存穿透是指查询一个一定不存在的数据。因为缓存是不命中时被动写的，而且出于容错考虑。假设从存储层查不到数据则不写入缓存。这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。至于怎样有效地解决缓存穿透问题，最常见的则是採用布隆过滤器（这个东西。在我的此篇文章中有介绍：），将全部...
项目开发中的分布式缓存击穿以及处理方案
热门推荐
中年闰土的博客
05-21 23万+
什么是缓存击穿在谈论缓存击穿之前，我们先来回忆下从缓存中加载数据的逻辑，如下图所示因此，如果黑客每次故意查询一个在缓存内必然不存在的数据，导致每次请求都要去存储层去查询，这样缓存就失去了意义。如果在大流量下数据库可能挂掉。这就是缓存击穿。场景如下图所示:我们正常人在登录首页的时候，都是根据userID来命中数据，然而黑客的目的是破坏你的系统，黑客可以随机生成一堆userID,然后将这些请求怼到你的...
Redis-从缓存击穿、穿透、雪崩到分布式锁
Ives_WangShen的博客
11-02 560
详解缓存击穿、穿透、雪崩及其解决方案，以及Redis做分布式锁的场景和方案
分布式之缓存击穿
dev666的博客
08-10 196
在谈论缓存击穿之前，我们先来回忆下从缓存中加载数据的逻辑，如下图所示 因此，如果黑客每次故意查询一个在缓存内必然不存在的数据，导致每次请求都要去存储层去查询，这样缓存就失去了意义。如果在大流量下数据库可能挂掉。这就是缓存击穿。 场景如下图所示: 我们正常人在登录首页的时候，都是根据userID来命中数据，然而黑客的目的是破坏你的系统，黑客可以随机生成一堆userID,然后将这些请求怼到你的服务...
【分布式缓存】缓存击穿
wuychn
03-27 178
缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。 缓存击穿和缓存雪崩有点类似，区别是缓存击穿针对的是某一个非常热点的key，这个key在某一时刻失效造成所有请求都访问数据库；缓存雪崩是针对一系列缓存同时失效，造成大量请求访问数据库造成雪崩。 缓存击穿也可以使用加锁...
Redis应用问题(缓存穿透、击穿、雪崩以及分布式锁)
莫迪134
05-23 532
文章目录前言一、缓存穿透1.问题描述2.解决方案二、缓存击穿1.问题描述2.解决方案三、缓存雪崩1.问题描述2.解决方案四：分布式锁1.问题描述2.解决方案 前言 用户请求数据过程： 一、缓存穿透 1.问题描述 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。 例如：id为负数的请求，它会直接穿透缓存打在数据库上。这种请求一般都是恶意攻击。 图示： 2.解决方案 （1）对空值缓存
redis的缓存穿透缓存击穿缓存雪崩
最新发布
01-04
- 缓存击穿：可以互斥锁或分布式锁来保护热点数据的问，当缓存失效时，只允许一个请求访问数据库并更新缓存，其他请求等待缓存更新完成后再从缓存中获取数据。 - 缓存雪崩：可以采用多级缓存、缓存预热、设置合理的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值