Redis高级之——Redis的企业级应用（预热，雪崩，击穿，穿透）

最新推荐文章于 2024-05-28 09:13:23 发布

Alienware^

最新推荐文章于 2024-05-28 09:13:23 发布

阅读量719

点赞数

分类专栏： Redis 文章标签： redis

本文链接：https://blog.csdn.net/weixin_45417821/article/details/107711159

版权

Redis 专栏收录该内容

41 篇文章 1 订阅

订阅专栏

文章目录

企业级解决方案
缓存预热
缓存雪崩
- 常见问题：
缓存击穿
通俗的说解决方法
缓存降级

企业级解决方案

缓存预热

缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

“宕机”
服务器启动后迅速宕机

问题排查

请求数量较高
主从之间数据吞吐量较大，数据同步操作频度较高

缓存预热的思路

a.提前给redis中嵌入部分数据，再提供服务
b.肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二redis根本就容纳不下所有的数据
c.需要更具当天的具体访问情况，试试统计出频率较高的热数据
d.然后将访问频率较高的热数据写入到redis，肯定是热数据也比较多，我们也得多个服务并行的读取数据去写，并行的分布式的缓存预热
e.然后将嵌入的热数据的redis对外提供服务，这样就不至于冷启动，直接让数据库奔溃了

具体的实时方案：

nginx+lua将访问量上报到kafka中要统计出来当前最新的实时的热数据是哪些，我们就得将商品详情页访问的请求对应的流量，日志，实时上报到kafka中。
storm从kafka中消费数据，实时统计出每个商品的访问次数，访问次数基于LRU内存数据结构的存储方案，优先用内存中的一个LRUMap去存放，性能高，而且没有外部依赖，否则的话，依赖redis,我们就是要防止reids挂掉数据丢失的情况，就不合适了；用mysql，扛不住高并发读写；用hbase，hadoop生态系统，维护麻烦，太重了，其实我们只要统计出一段时间访问最频繁的商品，然后对它们进行访问计数，同时维护出一个前N个访问最多的商品list即可，计算好每个task大致要存放的商品访问次数的数量，计算出大小，然后构建一个LURMap,apache commons collections有开源的实现，设定好map的最大大小，就会自动根据LRU算法去剔除多余的数据，保证内存使用限制，即使有部分数据被干掉了，然后下次来重新开始技术，也没什么关系，因为如果他被LRU算法干掉，那么它就不是热数据，说明最近一段时间很少访问，
每个storm task启动的时候，基于zk分布式锁，将自己的id写入zk的一个节点中
每个storm task负责完成自己这里的热数据的统计，比如每次计数过后，维护一个钱1000个商品的list，每次计算完都更新这个list
写一个后台线程，每个一段时间，比如一分钟，将排名钱1000的热数据list,同步到zk中

缓存雪崩

缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

常见问题：

数据库服务器崩溃（1）

系统平稳运行过程中，忽然数据库连接量激增
应用服务器无法及时处理请求
大量408，500错误页面出现
客户反复刷新页面获取数据
数据库崩溃
应用服务器崩溃
重启应用服务器无效
Redis服务器崩溃
Redis集群崩溃
重启数据库后再次被瞬间流量放倒

问题排查

在一个较短的时间内，缓存中较多的key集中过期
此周期内请求访问过期的数据，redis未命中，redis向数据库获取数据
数据库同时接收到大量的请求无法及时处理
Redis大量请求被积压，开始出现超时现象
数据库流量激增，数据库崩溃
重启后仍然面对缓存中无数据可用
Redis服务器资源被严重占用，Redis服务器崩溃
Redis集群呈现崩塌，集群瓦解
应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃
应用服务器，redis，数据库全部重启，效果不理想

问题分析

短时间范围内
大量key集中过期

解决方案（道）

更多的页面静态化处理
构建多级缓存架构

Nginx缓存+redis缓存+ehcache缓存
检测Mysql严重耗时业务进行优化

对数据库的瓶颈排查：例如超时查询、耗时较高事务等
灾难预警机制

监控redis服务器性能指标
- CPU占用、CPU使用率
- 内存容量
- 查询平均响应时间
- 线程数
限流、降级

短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务低速运转后再逐步放开访问

解决方案（术）

LRU与LFU切换
数据有效期策略调整
- 根据业务数据有效期进行分类错峰，A类90分钟，B类80分钟，C类70分钟
- 过期时间使用固定时间+随机值的形式，稀释集中到期的key的数量
超热数据使用永久key
定期维护（自动+人工）

对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时
加锁

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法！（慎用！）
伪代码：
在这里插入图片描述

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

还有一个解决办法解决方案是：给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存，

在这里插入图片描述

解释说明：

1、缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存；

2、缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

关于缓存崩溃的解决方法，这里提出了三种方案：使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间，还有一各被称为“二级缓存”的解决方法，有兴趣的读者可以自行研究。

缓存击穿

缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中redis后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个key的过期监控难度较高，配合雪崩处理策略即可。

数据库服务器崩溃（2）

系统平稳运行过程中
数据库连接量瞬间激增
Redis服务器无大量key过期
Redis内存平稳，无波动
Redis服务器CPU正常
数据库崩溃

问题排查

Redis中某个key过期，该key访问量巨大
多个数据请求从服务器直接压到Redis后，均未命中
Redis在短时间内发起了大量对数据库中同一数据的访问

问题分析

单个key高热数据
key过期

解决方案（术）

预先设定

以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息key的过期时长

注意：购物节不仅仅指当天，以及后续若干天，访问峰值呈现逐渐降低的趋势

现场调整

监控访问量，对自然流量激增的数据延长过期时间或设置为永久性key

后台刷新数据

启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失

二级缓存

设置不同的失效时间，保障不会被同时淘汰就行

加锁

分布式锁，防止被击穿，但是要注意也是性能瓶颈，慎重！

通俗的说解决方法

方案一

后台定义一个job(定时任务)专门主动更新缓存数据.比如,一个缓存中的数据过期时间是30分钟,那么job每隔29分钟定时刷新数据(将从数据库中查到的数据更新到缓存中).
这种方案比较容易理解，但会增加系统复杂度。比较适合那些 key 相对固定,cache 粒度较大的业务，key 比较分散的则不太适合，实现起来也比较复杂。

// 方法1:
 
public synchronized List<String> getData01() {
 
	List<String> result = new ArrayList<String>();
 
	// 从缓存读取数据
 
	result = getDataFromCache();
 
		if (result.isEmpty()) {
 
	// 从数据库查询数据
 
	   result = getDataFromDB();
 
	// 将查询到的数据写入缓存
 
	  setDataToCache(result);
 
	}
 
	return result;
 
}

这种方式确实能够防止缓存失效时高并发到数据库,但是缓存没有失效的时候,在从缓存中拿数据时需要排队取锁,这必然会大大的降低了系统的吞吐量.

方案二

将缓存key的过期时间(绝对时间)一起保存到缓存中(可以拼接,可以添加新字段,可以采用单独的key保存…不管用什么方式,只要两者建立好关联关系就行).在每次执行get操作后,都将get出来的缓存过期时间与当前系统时间做一个对比,如果缓存过期时间-当前系统时间<=1分钟(自定义的一个值),则主动更新缓存.这样就能保证缓存中的数据始终是最新的(和方案一一样,让数据不过期.)
这种方案在特殊情况下也会有问题。假设缓存过期时间是12:00，而 11:59
到 12:00这 1 分钟时间里恰好没有 get 请求过来，又恰好请求都在 11:30 分的时
候高并发过来，那就悲剧了。这种情况比较极端，但并不是没有可能。因为“高
并发”也可能是阶段性在某个时间点爆发。

static Object lock = new Object();
 
 
 
public List<String> getData02() {
 
	List<String> result = new ArrayList<String>();
 
	// 从缓存读取数据
 
	result = getDataFromCache();
 
	if (result.isEmpty()) {
 
		synchronized (lock) {
 
		// 从数据库查询数据
 
		result = getDataFromDB();
 
		// 将查询到的数据写入缓存
 
		setDataToCache(result);
 
		}
 
	}
 
	return result;
 
}

这个方法在缓存命中的时候,系统的吞吐量不会受影响,但是当缓存失效时,请求还是会打到数据库,只不过不是高并发而是阻塞而已.但是,这样会造成用户体验不佳,并且还给数据库带来额外压力.

方案三

采用 L1 (一级缓存)和 L2(二级缓存) 缓存方式，L1 缓存失效时间短，L2 缓存失效时间长。请求优先从 L1 缓存获取数据，如果 L1缓存未命中则加锁，只有 1 个线程获取到锁,这个线程再从数据库中读取数据并将数据再更新到到 L1 缓存和 L2 缓存中，而其他线程依旧从 L2 缓存获取数据并返回。
这种方式，主要是通过避免缓存同时失效并结合锁机制实现。所以，当数据更
新时，只能淘汰 L1 缓存，不能同时将 L1 和 L2 中的缓存同时淘汰。L2 缓存中
可能会存在脏数据，需要业务能够容忍这种短时间的不一致。而且，这种方案
可能会造成额外的缓存空间浪费。


public List<String> getData03() {
 
	List<String> result = new ArrayList<String>();
 
	// 从缓存读取数据
 
	result = getDataFromCache();
 
	if (result.isEmpty()) {
 
		synchronized (lock) {
 
	//双重判断,第二个以及之后的请求不必去找数据库,直接命中缓存
 
	// 查询缓存
 
		result = getDataFromCache();
 
			if (result.isEmpty()) {
 
			// 从数据库查询数据
 
			result = getDataFromDB();
 
			// 将查询到的数据写入缓存
 
			setDataToCache(result);
 
			}
 
		}
 
	}
 
		return result;
 
}

这种方式确实能够防止缓存失效时高并发到数据库,但是缓存没有失效的时候,在从缓存中拿数据时需要排队取锁,这必然会大大的降低了系统的吞吐量.

方案四

加锁

static Lock reenLock = new ReentrantLock();
 
 
 
public List<String> getData04() throws InterruptedException {
 
	List<String> result = new ArrayList<String>();
 
	// 从缓存读取数据
 
	result = getDataFromCache();
 
	if (result.isEmpty()) {
 
		if (reenLock.tryLock()) {
 
			try {
 
				System.out.println("我拿到锁了,从DB获取数据库后写入缓存");
 
				// 从数据库查询数据
 
				result = getDataFromDB();
 
				// 将查询到的数据写入缓存
 
				setDataToCache(result);
 
			} finally {
 
				reenLock.unlock();// 释放锁
 
					}
 
 
 
			} else {
 
				result = getDataFromCache();// 先查一下缓存
 
					if (result.isEmpty()) {
 
						System.out.println("我没拿到锁,缓存也没数据,先小憩一下");
 
					Thread.sleep(100);// 小憩一会儿
 
					return getData04();// 重试
 
					}
 
				}
 
			}
 
		return result;
 
}

最后使用互斥锁的方式来实现，粗暴临时方法，将热点数据设置为永不过期。

缓存穿透

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

缓存系统的容量是有限的，不可能存储系统所有的数据，那么在查询未缓存数据的时候就会发生缓存穿透。
另一方面就是基于‘二八原则’，我们通常只会缓存常用的那 20% 的热点数据。
正常情况下的缓存穿透是没什么伤害的，但是如果你的系统遭遇攻击，存在大量的缓存穿透的话，那么可能就是一个麻烦了，如果大量的缓存穿透超过了后端服务器的承受能力，那么就有可能造成服务崩溃，这是不可接受的。

数据库服务器崩溃（3）

系统平稳运行过程中
应用服务器流量随时间增量较大
Redis服务器命中率随时间逐步降低
Redis内存平稳，内存无压力
Redis服务器CPU占用激增
数据库服务器压力激增
数据库崩溃

问题排查

Redis中大面积出现未命中
出现非正常URL访问

问题分析

获取的数据在数据库中也不存在，数据库查询未得到对应数据
Redis获取到null数据未进行持久化，直接返回
下次此类数据到达重复上述过程
出现黑客攻击服务器

为了避免缓存穿透其实有很多种解决方案。下面介绍几种。

解决方案（术）

缓存null

对查询结果为null的数据进行缓存（长期使用，定期清理），设定短时限，例如30-60秒，最高5分钟

Object nullValue = new Object();
try {
  Object valueFromDB = getFromDB(uid); //从数据库中查询数据
  if (valueFromDB == null) {
    cache.set(uid, nullValue, 30);   //如果从数据库中查询到空值，就把空值写入缓存，设置较短的超时时间
  } else {
    cache.set(uid, valueFromDB, 1000);
  }
} catch(Exception e) {
  cache.set(uid, nullValue, 10);
}

虽然这种方法可以解决缓存穿透的问题，但是这种方式也存在弊端，因为在缓存系统中存了大量的空值，浪费缓存的存储空间，如果缓存空间被占满了，还会还会剔除掉一些已经被缓存的用户信息反而会造成缓存命中率的下降。

白名单策略

提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置了数据白名单。当加载正常数据时，放

行，加载异常数据时直接拦截（效率偏低）

使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
实施监控

实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比

非活动时段波动：通常检测3-5倍，超过5倍纳入重点排查对象
活动时段波动：通常检测10-50倍，超过50倍纳入重点排查对象

根据倍数不同，启动不同的排查流程。然后使用黑名单进行防控（运营）

key加密

问题出现后，临时启动防灾业务key，对key进行业务层传输加密服务，设定校验程序，过来的key校验

例如每天随机分配60个加密串，挑选2到3个，混淆到页面数据id中，发现访问key不满足规则，驳回数据访问
布隆过滤器
我们可以这样考虑，可以先判断key值是否存在，如果不存在，则不访问redis，那这样就可以拦截大量的请求，布隆过滤器恰好可以实现这样的需求。
布隆过滤器本质是一个二进制向量，初始化的时候每一个位置都是0，如下图，比如说a经过hash算法后得到一个下标位置，接下来就会把下标的值改为1，图中所示的是没一个元素经过三次hash运算，每一个红线代表一次hash算法，为什么要运算三次呢，这是为了减少hash冲突，当然hash算法不一定是三次，经过多次不同维度的哈市算法后，就把a值映射到了二进制向量里面，这样的好处很多，可以节省空间，假如说a值是一串很长的字符串，那么经过映射后就可以只占三位长度，并且查找速度很快。

如果布隆过滤器判断元素存在，则不一定存在，如果不存在，则一定不存在
如何理解这句话，因为有可能你一个元素运算得到的下标恰好是别的元素的下标，如果经过运算后布隆过滤器判断不存在，也就是说至少有一个下标是为0的，那肯定是不存在的

布隆过滤器的使用
用Google的guava包已经有了布隆过滤器算法的实现，注意的是布隆过滤器有一定的误判率，不可能达到100%的精准，首先初始化项目的时候从数据库查询出来所有的key值，然后放到布隆过滤器中，guava包都实现了相应的put方法和hash算法。

加了布隆过滤器的过程如下
在这里插入图片描述

1，当应用访问的时候，先去布隆过滤器中判断kedy值，如果发觉没有key值不存在，直接返回
2、如果key值在布隆过滤器存在，则去访问redis，由于是有误判率的，所以redis也有可能不存在
3、那么这时候就去访问数据库，数据库不存在，那就直接返回空就行

如果误判率为3%，当有100万个请求同时过来的时候，布隆过滤器已经挡住了97万个请求，剩下3万个请求假如是误判的，这时候再访问数据库可以通过加锁的方式实现，只有竞争到锁了就去访问数据库，这样就完全可以解决缓存穿透问题

布隆过滤器的应用
比如说输入用户名的时候，可以马上检测出该用户名是否存在，黑名单机制，单词错误检测等

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

Alienware^

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
Redis高级之——Redis的企业级应用（预热，雪崩，击穿，穿透）

企业级解决方案缓存预热缓存预热的思路a.提前给redis中嵌入部分数据，再提供服务b.肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二redis根本就容纳不下所有的数据c.需要更具当天的具体访问情况，试试统计出频率较高的热数据d.然后将访问频率较高的热数据写入到redis，肯定是热数据也比较多，我们也得多个服务并行的读取数据去写，并行的分布式的缓存预热e.然后将嵌入的热数据的redis对外提供服务，这样就不至于冷启动，直接让数据库奔溃了具体的实时方案：
复制链接

扫一扫

专栏目录