分布式之缓存击穿

在谈论缓存击穿之前，我们先来回忆下从缓存中加载数据的逻辑，如下图所示

因此，如果黑客每次故意查询一个在缓存内必然不存在的数据，导致每次请求都要去存储层去查询，这样缓存就失去了意义。如果在大流量下数据库可能挂掉。这就是缓存击穿。
场景如下图所示:

我们正常人在登录首页的时候，都是根据userID来命中数据，然而黑客的目的是破坏你的系统，黑客可以随机生成一堆userID,然后将这些请求怼到你的服务器上，这些请求在缓存中不存在，就会穿过缓存，直接怼到数据库上,从而造成数据库连接异常。

解决方案

在这里我们给出三套解决方案，大家根据项目中的实际情况，选择使用.

讲下述三种方案前，我们先回忆下redis的setnx方法

SETNX key value

将 key 的值设为 value ，当且仅当 key 不存在。

若给定的 key 已经存在，则 SETNX 不做任何动作。

SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

可用版本：>= 1.0.0

时间复杂度： O(1)

返回值： 设置成功，返回 1。设置失败，返回 0 。

效果如下

redis> EXISTS job                # job 不存在
(integer) 0

redis> SETNX job "programmer"    # job 设置成功
(integer) 1

redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败
(integer) 0

redis> GET job                   # 没有被覆盖
"programmer"


1、使用互斥锁


该方法是比较普遍的做法，即，在根据key获得的value值为空时，先锁上，再从数据库加载，加载完毕，释放锁。若其他线程发现获取锁失败，则睡眠50ms后重试。


至于锁的类型，单机环境用并发包的Lock类型就行，集群环境则使用分布式锁( redis的setnx)


集群环境的redis的代码如下所示:


String get(String key) {
   String value = redis.get(key);
   if (value  == null) {
    if (redis.setnx(key_mutex, "1")) {
        // 3 min timeout to avoid mutex holder crash
        redis.expire(key_mutex, 3 * 60)
        value = db.get(key);
        redis.set(key, value);
        redis.delete(key_mutex);
    } else {
        //其他线程休息50毫秒后重试
        Thread.sleep(50);
        get(key);
    }
  }
}



　　


优点:


    

  1. 思路简单
    2. 

  2. 保证一致性
    3. 



缺点


    

  1. 代码复杂度增大
    2. 

  2. 存在死锁的风险
    3. 



2、异步构建缓存


在这种方案下，构建缓存采取异步策略，会从线程池中取线程来异步构建缓存，从而不会让所有的请求直接怼到数据库上。该方案redis自己维护一个timeout，当timeout小于System.currentTimeMillis()时，则进行缓存更新，否则直接返回value值。
集群环境的redis代码如下所示:


String get(final String key) {
        V v = redis.get(key);
        String value = v.getValue();
        long timeout = v.getTimeout();
        if (v.timeout <= System.currentTimeMillis()) {
            // 异步更新后台异常执行
            threadPool.execute(new Runnable() {
                public void run() {
                    String keyMutex = "mutex:" + key;
                    if (redis.setnx(keyMutex, "1")) {
                        // 3 min timeout to avoid mutex holder crash
                        redis.expire(keyMutex, 3 * 60);
                        String dbValue = db.get(key);
                        redis.set(key, dbValue);
                        redis.delete(keyMutex);
                    }
                }
            });
        }
        return value;
    }



　　


优点:


    

  1. 性价最佳，用户无需等待
    2. 



缺点


    

  1. 无法保证缓存一致性
    2. 



3、布隆过滤器


1、原理


布隆过滤器的巨大用处就是，能够迅速判断一个元素是否在一个集合中。因此他有如下三个使用场景:


    

  1. 网页爬虫对URL的去重，避免爬取相同的URL地址
    2. 

  2. 反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱（同理，垃圾短信）
    3. 

  3. 缓存击穿，将已存在的缓存放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。
    4. 



OK，接下来我们来谈谈布隆过滤器的原理
其内部维护一个全为0的bit数组，需要说明的是，布隆过滤器有一个误判率的概念，误判率越低，则数组越长，所占空间越大。误判率越高则数组越小，所占的空间越小。


假设，根据误判率，我们生成一个10位的bit数组，以及2个hash函数（f1,f2f1,f2），如下图所示(生成的数组的位数和hash函数的数量，我们不用去关心是如何生成的，有数学论文进行过专业的证明)。


假设输入集合为(N1,N2N1,N2),经过计算f1(N1)f1(N1)得到的数值得为2，f2(N1)f2(N1)得到的数值为5，则将数组下标为2和下表为5的位置置为1，如下图所示


同理，经过计算f1(N2)f1(N2)得到的数值得为3，f2(N2)f2(N2)得到的数值为6，则将数组下标为3和下表为6的位置置为1，如下图所示


这个时候，我们有第三个数N3N3，我们判断N3N3在不在集合(N1,N2N1,N2)中，就进行f1(N3)，f2(N3)f1(N3)，f2(N3)的计算


    

  1. 若值恰巧都位于上图的红色位置中，我们则认为，N3N3在集合(N1,N2N1,N2)中
    2. 

  2. 若值有一个不位于上图的红色位置中，我们则认为，N3N3不在集合(N1,N2N1,N2)中
    3. 



以上就是布隆过滤器的计算原理，下面我们进行性能测试，


2、性能测试


代码如下:


(1)新建一个maven工程，引入guava包



<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>22.0</version>
        </dependency>
    </dependencies>



　　


(2)测试一个元素是否属于一个百万元素集合所需耗时



package bloomfilter;

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
import java.nio.charset.Charset;

public class Test {
    private static int size = 1000000;

    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size);

    public static void main(String[] args) {
        for (int i = 0; i < size; i++) {
            bloomFilter.put(i);
        }
        long startTime = System.nanoTime(); // 获取开始时间

        //判断这一百万个数中是否包含29999这个数
        if (bloomFilter.mightContain(29999)) {
            System.out.println("命中了");
        }
        long endTime = System.nanoTime();   // 获取结束时间

        System.out.println("程序运行时间： " + (endTime - startTime) + "纳秒");

    }
}



　　


输出如下所示


命中了
程序运行时间： 219386纳秒



　　


也就是说，判断一个数是否属于一个百万级别的集合，只要0.219ms就可以完成，性能极佳。


(3)误判率的一些概念


首先，我们先不对误判率做显示的设置，进行一个测试，代码如下所示


package bloomfilter;

import java.util.ArrayList;
import java.util.List;

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;

public class Test {
    private static int size = 1000000;

    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size);

    public static void main(String[] args) {
        for (int i = 0; i < size; i++) {
            bloomFilter.put(i);
        }
        List<Integer> list = new ArrayList<Integer>(1000);  

        //故意取10000个不在过滤器里的值，看看有多少个会被认为在过滤器里
        for (int i = size + 10000; i < size + 20000; i++) {
            if (bloomFilter.mightContain(i)) {
                list.add(i);
            }
        }
        System.out.println("误判的数量：" + list.size()); 

    }
}



　　


输出结果如下


误判对数量：330



　　


如果上述代码所示，我们故意取10000个不在过滤器里的值，却还有330个被认为在过滤器里，这说明了误判率为0.03.即，在不做任何设置的情况下，默认的误判率为0.03。
下面上源码来证明：


接下来我们来看一下，误判率为0.03时，底层维护的bit数组的长度如下图所示


将bloomfilter的构造方法改为


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


即，此时误判率为0.01。在这种情况下，底层维护的bit数组的长度如下图所示

由此可见，误判率越低，则底层维护的数组越长，占用空间越大。因此，误判率实际取值，根据服务器所能够承受的负载来决定，不是拍脑袋瞎想的。


3、实际使用


redis伪代码如下所示


String get(String key) {
   String value = redis.get(key);
   if (value  == null) {
        if(!bloomfilter.mightContain(key)){
            return null;
        }else{
           value = db.get(key);
           redis.set(key, value);
        }
    }
    return value；
}



　　


优点:


    

  1. 思路简单
    2. 

  2. 保证一致性
    3. 

  3. 性能强
    4. 



缺点


    

  1. 代码复杂度增大
    2. 

  2. 需要另外维护一个集合来存放缓存的Key
    3. 

  3. 布隆过滤器不支持删值操作
    4. 



总结


在总结部分，来个漫画把。希望对大家找工作有帮助


作者：孤独烟 


出处：http://rjzheng.cnblogs.com/


本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。







小编积累多年的干货文档免费赠送，包含前端后端和测试，系统架构，高并发处理，优化等





原文地址：https://www.cnblogs.com/xdclass/p/9447576.html
				


				
时间： 2024-08-06 06:01:16 

		


		


	

	
	

		


		
分布式之缓存击穿的相关文章


								

		

			

                缓存穿透，缓存击穿，缓存雪崩解决方案分析
			

		

		

									

				本文转自:http://blog.csdn.net/zeb_perfect/article/details/54135506 前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义.在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞			

		

	

				

		

			

                缓存穿透、缓存击穿、缓存雪崩
			

		

		

									

				1.缓存穿透 当查询一条数据,该数据不存在缓存和数据库的时候,每次请求都会请求到数据库.这种现象就叫缓存穿透. 当一个人拿一个并不存在的 id 一直查询,就会产生大量的请求到数据库查询,数据库就可以因为压力过大而崩掉. 解决办法: 1).可以为这些查询不到的 id 在缓存中设置为 key,值设置为 null,这样就可以直接从缓存中拿到不需要请求数据库: 2).用一个布隆过滤,如果不存在布隆过滤中,说明肯定肯定不存在于缓存和数据库中. 优缺点:第一种解决方法,如果是攻击的时候用大量不存在的 id			

		

	

				

		

			

                redis 缓存击穿 看一篇成高手系列3
			

		

		

									

				什么是缓存击穿 在谈论缓存击穿之前,我们先来回忆下从缓存中加载数据的逻辑,如下图所示 因此,如果黑客每次故意查询一个在缓存内必然不存在的数据,导致每次请求都要去存储层去查询,这样缓存就失去了意义.如果在大流量下数据库可能挂掉.这就是缓存击穿. 场景如下图所示: 我们正常人在登录首页的时候,都是根据userID来命中数据,然而黑客的目的是破坏你的系统,黑客可以随机生成一堆userID,然后将这些请求怼到你的服务器上,这些请求在缓存中不存在,就会穿过缓存,直接怼到数据库上,从而造成数据库连接异常.			

		

	

				

		

			

                缓存穿透、缓存击穿、缓存雪崩区别和解决方案
			

		

		

									

				一.缓存处理流程 前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果. 二.缓存穿透 描述: 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大. 解决方案: 接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截: 从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-va			

		

	

				

		

			

                redis缓存穿透，缓存击穿，缓存雪崩原因+解决方案
			

		

		

									

				###一.前言在我们日常的开发中,无不都是使用数据库来进行数据的存储,由于一般的系统任务中通常不会存在高并发的情况,所以这样看起来并没有什么问题,可是一旦涉及大数据量的需求,比如一些商品抢购的情景,或者是主页访问量瞬间较大的时候,单一使用数据库来保存数据的系统会因为面向磁盘,磁盘读/写速度比较慢的问题而存在严重的性能弊端,一瞬间成千上万的请求到来,需要系统在极短的时间内完成成千上万次的读/写操作,这个时候往往不是数据库能够承受的,极其容易造成数据库系统瘫痪,最终导致服务宕机的严重生产问题. 为了			

		

	

				

		

			

                缓存穿透,缓存击穿,缓存雪崩
			

		

		

									

				本文链接:https://blog.csdn.net/kongtiao5/article/details/82771694 一.缓存处理流程 前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果. 二.缓存穿透 描述: 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大. 解决方案: 接口层增加校验			

		

	

				

		

			

                Redis_缓存穿透、缓存击穿、缓存雪崩
			

		

		

									

				一.缓存处理流程 前台请求,后台先从缓存中取数据,取到直接返回结果,取不到时从数据库中取,数据库取到更新缓存,并返回结果,数据库也没取到,那直接返回空结果. 二.缓存穿透 描述: 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大. 解决方案: 1. 接口层增加校验 , 或缓存空对象. 将 null 变成一个值. 也可以采用一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是			

		

	

				

		

			

                缓存穿透，缓存击穿，缓存雪崩的原理及解决方案
			

		

		

									

				前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义.在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞.举例:如发起为id为"-1"的数据或id为特别大不存在的数据.这时的用户很可能是攻击者,攻击会导致数据库压力过大.			

		

	

				

		

			

                如何设计缓存系统：缓存穿透，缓存击穿，缓存雪崩解决方案分析
			

		

		

									

				前言 设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义. 在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞. 解决方案 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bi