redis 常见问题

12 Redis 常见问题

12.1 缓存击穿

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

12.1.1 出现问题的原因

1、Key过期：对于第一个原因是因为在Redis中，Key有过期时间，如果某一个时刻(假如商城做活动,零点开始)key失效，那么零点之后对某一个商品查询请求将全都压到数据库上，导致数据库崩。

2、Key被页面置换淘汰：因为内存是有限的，要时时刻刻缓存新的数据，淘汰旧的数据，所以在一定的页面置换策略(常见页面置换算法图解)中，淘汰数据，如果某些商品做活动之前无人问津，势必会被淘汰。

12.1.2 解决思路

（1）维护一个定时任务，将快要过期的key重新设置；

（2）可以使用分布式锁，当在缓存中拿不到数据时，使用分布式锁去数据库中拿到数据后，重新设置到缓存；

12.1.2.1 使用分布式锁

正常的处理请求如图

由于key过期在所难免，高流量来到Redis时,根据Redis的单线程特性，可以认为任务是在队列里依次执行的，当请求到达Redis发现Key过期时，进行一个操作：设置锁，具体步骤如下：

1.请求到达Redis，发现Redis Key过期，查看有没有锁，没有锁的话回到队列后面排队

2.设置锁，注意，这儿应该是setnx()，而不是set()，因为可能有其他线程已经设置锁了

3.获取锁，拿到锁了就去数据库取数据，请求返回后释放锁。

这种思路比较简单，就是让一个线程回写缓存，其他线程等待回写缓存线程执行完，重新读缓存即可

这种方式引出新的问题：

1.同一时间只有一个线程读数据库然后回写缓存，其他线程都处于阻塞状态。如果是高并发场景，大量线程阻塞势必会降低吞吐量。

解决方案：热点数据永不过期或者维护一个定时任务，将快要过期的key重新设置

2. 如果拿到锁去拿数据的请求然后挂了怎么办，也就是锁没有释放，其他进程都在等锁。

解决方案：对锁设置一个过期时间，如果到达了过期时间还没释放就自动释放

12.2 缓存雪崩

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，请求直接落到数据库上，引起数据库压力过大甚至宕机。和缓存击穿不同的是，缓存击穿指大量并发查同一条数据，缓存雪崩是不指大量的热点数据过期时间相同，导致数据在同一时刻集体失效。造成瞬时数据库请求量大、压力骤增，引起雪崩，导致数据库存在被打挂的风险。

12.2.1出现问题的原因

大量的热点数据过期时间相同，导致数据在同一时刻集体失效。造成瞬时数据库请求量过大、压力骤增，引起雪崩，导致数据库存在被打挂的风险

12.2.2 解决方案

12.2.2.1 均匀过期

设置不同的过期时间，让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。

12.2.2.2 缓存永不过期

跟缓存击穿解决思路一致，缓存在物理上永远不过期，用一个异步的线程更新缓存

12.2.2.3 加互斥锁

跟缓存击穿解决思路一致，同一时间只让一个线程构建缓存，其他线程阻塞排队。

总结：

不用场景需要不同的解决方案，只是一味地强调解决雪崩的策略是随机过期时间，这个非常不准确，举个例子，银行做活动，之前这个利息系数为2%，过了零点系数改为3%，这种情况能将用户的对应的key改为随机过期吗？如果用的过去的数据叫脏数据。正确的思路是，首先要看看这个Key过期是不是时点性有关，时点性无关的话，可以随机过期时间解决。

如果是时点性有关，例如刚刚说的银行某一天改变某系数，那么就要利用强依赖击穿方案，策略是先过去的线程更新一下所有key

12.3 缓存穿透

缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍，然后返回空。

如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至击垮数据库系统。

12.3.1 解决方案

穿透主要原因是很多请求都在访问数据库不存在的数据，例如一个卖书的商城一直被请求查询茶叶产品，由于Redis缓存主要是用来缓存热点数据，对于数据库都不存在的数据,是没法缓存的，这种异常流量就会直接到达数据库并且返回"没有"的查询结果。应对这种请求，处理办法是对访问请求加一层过滤器，例如布隆过滤器、增强版布隆过滤器、布谷鸟过滤器。

12.3.1.1 参数合法性检查

接口请求参数的校验。对请求的接口进行鉴权，数据合法性的校验等；比如查询的userId不能是负值或者包含非法字符等。

12.3.1.2 返回空对象

当缓存未命中，查询持久层也为空，可以将返回的空对象写到缓存中，这样下次请求该key时直接从缓存中查询返回空对象，请求不会落到持久层数据库。为了避免存储过多空对象，通常会给空对象设置一个过期时间。

这种方法会存在两个问题：

1.如果有大量的key穿透，缓存空对象会占用宝贵的内存空间。

2.空对象的key设置了过期时间，在这段时间可能会存在缓存和持久层数据不一致的场景

12.3.1.3 布隆过滤器

布隆过滤器（Bloom Filter，简称BF）由Burton Howard Bloom在1970年提出，是一种空间效率高的概率型数据结构。布隆过滤器主要是解决大规模数据下不需要精确过滤的业务场景，如检查垃圾邮件地址，爬虫URL地址去重， 解决缓存穿透问题等。

布隆过滤器：在一个存在一定数量的集合中过滤一个对应的元素，判断该元素是否一定不在集合中或者可能在集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

布隆过滤器专门用来检测集合中是否存在特定的元素，如果在平时我们要判断一个元素是否在一个集合中，通常会采用查找比较的方法，下面分析不同的数据结构查找效率：

采用线性表存储，查找时间复杂度为O(N)采用平衡二叉排序树（AVL、红黑树）存储，查找时间复杂度为O(logN)采用哈希表存储，考虑到哈希碰撞，整体时间复杂度也要O[log(n/m)]当需要判断一个元素是否存在于海量数据集合中，不仅查找时间慢，还会占用大量存储空间。

布隆过滤器由一个长度为n比特的位数组（bit array）与k个哈希函数（hash function）组成的数据结构。位数组初始化均为0，所有的哈希函数都可以分别把输入数据尽量均匀地散列。当要向布隆过滤器中插入一个元素时，该元素经过k个哈希函数计算产生k个哈希值，以哈希值作为位数组中的下标，将所有k个对应的比特值由0置为1。

当要查询一个元素时，同样将其经过哈希函数计算产生哈希值，然后检查对应的k个比特值：如果有任意一个比特为0，表明该元素一定不在集合中；如果所有比特均为1，表明该集合有可能性在集合中。为什么不是一定在集合中呢？因为不同的元素计算的哈希值有可能一样，会出现哈希碰撞，导致一个不存在的元素有可能对应的比特位为1，这就是所谓“假阳性”（false positive）。相对地，“假阴性”（false negative）在BF中是绝不会出现的。

总结一下：布隆过滤器认为不在的，一定不会在集合中；布隆过滤器认为在的，可能在也可能不在集合中。

举个例子：下图是一个布隆过滤器，共有18个比特位，3个哈希函数。集合中三个元素x，y，z通过三个哈希函数散列到不同的比特位，并将比特位置为1。当查询元素w时，通过三个哈希函数计算，发现有一个比特位的值为0，可以肯定认为该元素不在集合中。

布隆过滤器优缺点

优点：

1.节省空间：不需要存储数据本身，只需要存储数据对应hash比特位

2.时间复杂度低：插入和查找的时间复杂度都为O(k)，k为哈希函数的个数

缺点：

1.存在假阳性：布隆过滤器判断存在，可能出现元素不在集合中；判断准确率取决于哈希函数的个数

2.不能删除元素：如果一个元素被删除，但是却不能从布隆过滤器中删除，这也是造成假阳性的原因了

12.3.1.3.1 数据结构

布隆过滤器是基于bitmap和若干个hash算法实现的

1）元素tie经过hash1，hash2，hash3运算出对应的三个值落到了数组下标为4，6，8的位置上，并将其位置的默认值0，修改成1。

2）元素niu同理落到了数组下标为1，3，4的位置上并将其位置的默认值0修改成1。

此时bitmap中已经存储了tie，niu数据元素。当请求想通过布隆过滤器判断tie元素在程序中是否存在时，通过hash运算结果到数组对应下标位置上发现值已经都被置为1，此时返回true。

12.3.1.3.2 一定不在集合中

​ 元素zhang通过布隆过滤器判断时，下标0，2都为0，则直接返回false。

也就是当判断不在bitmap中的元素时，经过hash运算得到的结果在bitmap中只要有一个为0，则该数据一定不存在。

12.3.1.3.3

12.4 缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统，这样就可以避免在用户请求的时候，先查询数据库，然后再将数据回写到缓存。

如果不进行预热， 那么 Redis 初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中， 对数据库造成流量的压力。

12.4.1 缓存预热的操作方法

1.数据量不大的时候，工程启动的时候进行加载缓存动作；

2.数据量大的时候，设置一个定时任务脚本，进行缓存的刷新；

3.数据量太大的时候，优先保证热点数据进行提前加载到缓存。