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.数据量太大的时候,优先保证热点数据进行提前加载到缓存。