书画网站建设方案策划,宁波拳头信息科技有限公司,抓关键词的方法10条,网站开发业务需求分析概述
Redis 的缓存异常问题#xff0c;除了数据不一致问题外#xff0c;还会面临其他三个问题#xff0c;分别是缓存雪崩、缓存击穿、缓存穿透。这三个问题#xff0c;一旦发生#xff0c;会导致大量的请求积压到数据库。若并发量很大#xff0c;就会导致数据库宕机或故…概述
Redis 的缓存异常问题除了数据不一致问题外还会面临其他三个问题分别是缓存雪崩、缓存击穿、缓存穿透。这三个问题一旦发生会导致大量的请求积压到数据库。若并发量很大就会导致数据库宕机或故障这是很严重的生产事故。 1.缓存雪崩
缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理应用将大量的请求发送到数据库层导致数据库层压力激增。
造成缓存雪崩的原因一般有两个应对的方案也不同。
1.1第一个原因是缓存中有大量的数据同时过期导致大量请求无法得到处理 具体来说当数据保存在缓存中并且设置了过期时间时如果在某一时刻大量数据同时过期此时应该在访问这些数据就发生缺失。紧接着应用就会把请求发送给数据库从数据库中读取数据。如果应用的并发请求量很大那么数据库的压力也就很大这会加剧影响到数据库的其他正常业务请求处理。 针对大量数据同时失效带来的缓存雪崩有两种解决方案。
A.可以避免给大量的数据设置相同的过期时间
如果业务层的确要求有些数据同时过期你可以在用 EXPIRE 命令给每个数据过期时给过期时间增加一个较小的随机数例如随机增加1~3分钟这样一来不同数据的过期时间有所差别但差别有不会太大既避免了大量数据同时过期又保证了这些数据基本在相近的时间失效仍能满足业务需求。
B.还可以通服务降级来应对雪崩。
所谓服务降级是指发送缓存雪崩时针对不同的数据采取不同的处理方式。
当业务访问的是非核心数据如电商商品属性时暂时停止从缓存中查询这些数据而是直接返回预定义信息、空值或错误信息。
当业务应用访问的是核心数据例如商品库存时仍然运行查询缓存如果缓存缺失也可以继续通过数据库读取。
这样一来只有部分过期数据的请求会发送到数据库数据库的压力也就没有那么大了。 1.2 第二个原因是 Redis 实例发送故障宕机了无法处理请求这会导致大量请求一下子积压到数据库层从而发生雪崩
一般来说一个 Redis 实例可以支持万级别的请求处理吞吐量而单个数据库可能只支持数钱级别的吞吐量。由于缓存雪崩Redis 缓存失效所以数据库可能因压力过大而崩溃。
有两个建议可以应对 Redis 宕机而引发的缓存雪崩。
第一个建议是在业务系统中实现服务熔断或请求限流机制
服务熔断是指在发送缓存雪崩时为了防止引发连锁的数据库雪崩甚至是整个系统的崩溃我们暂停业务应用对缓存系统的接口访问。即业务应用调用缓存接口时客户端并不把请求发给 Redis 实例而是直接返回等到 Redis 实例重新恢复后再允许应用请求发送到缓存系统。这样就避免了大量请求应缓存缺失而积压到数据库。
在业务系统运行时我们可以监测 Redis 缓存所在机器和数据库所在机器的负载指标如每秒请求书、CPU 利用率等。如果发现 Redis 缓存确实宕机了而数据库所在机器的负载压力突然增加例如每秒请求数激增此时就发生缓存雪崩了。我们可以启动熔断机制暂停业务应用对缓存服务的访问从而降低数据库的访问压力。 熔断服务虽然可以保证数据库的正常运行但是暂停了整个缓存系统的访问对业务应用的影响范围大。为了尽可能减少这种影响我们也可以进行请求限流。 请求限流是指我们在业务系统发请求入口前端控制每秒进入系统的请求数避免过多的请求被发送到数据库。
假设业务系统正常运行是请求入口允许每秒进入系统的请求是 1 万个其中9000 个请求都能在缓存中处理只有 1000 个请求会被应用发送到数据库。
一旦发生了缓存雪崩数据库每秒的请求突然增加到 1 万个此时就可以启动请求限流机制在请求入口前端只允许每秒进入 1000 个请求再多的请求就会在入口前端直接拒绝服务。所以使用了请求限流就可以避免大量并发请求压力传递到数据库层。 使用熔断或是请求限流来应对 Redis 实例宕机导致的缓存雪崩问题属于“事后诸葛亮”。
第二个建议是事前预防
通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis 缓存的主节点故障宕机了从节点还可以切换成主节点继续提供缓存服务避免了由于缓存实例宕机而导致的缓存雪崩问题。
2.缓存击穿
缓存击穿是指某个访问非常频繁的热点数据的请求无法在缓存中进行处理紧接着该访问该数据集的大量请求一下子都发送到了后端数据库导致了数据库压力激增会影响数据库处理其他请求。缓存击穿的情况经常发送在热点数据过期失效时如下所示 为避免缓存击穿给数据库带来的激增压力解决办法是对于访问特别频繁的热点数据我们就不设置过期时间了。这样一样对热点数据的服务请求都可以在缓存中进行处理。
3.缓存穿透
缓存穿透是指要访问的数据既不在 Redis 缓存中也不在数据库中导致请求在访问缓存时发生缓存缺失再去访问数据库但是发现数据库中也没有要访问的数据。此时应用也无法从数据库中读取数据再写入缓存这样一来缓存就成了摆设。如果应用持续有大量请求访问数据库就会同时给缓存和数据库带来巨大压力 缓存穿透一般在什么时候发生
业务层误操作缓存中和数据库中的数据被误删了所以缓存中和数据库中都没有数据。恶意攻击专门访问数据库中没有的数据。
一共有三种方案来应对缓存穿透的问题
3.1 第一种方案是缓存空值或缺省值
一旦发生缓存穿透我们就可以针对查询的数据在 Redis 中缓存一个空值或是业务层商定的缺省值。紧接着应用发送后的请求在进行查询时就可以直接从 Redis 中读取空值或缺省值返回给业务应用了避免了把大量请求发送给数据库。
3.2 第二种方案是使用布隆过滤器快速判断数据是否存在避免从数据库中查询数据是否存在减去数据库压力
先看下布隆过滤器是如何工作的。布隆过滤器由一个 初值都为 0 的 bit 数组 和 N 个哈希函数 组成它可以用来快速判断某个数据是否存在。当我们想标记某个数据存在时例如数据已被写入数据库布隆过滤器会通过三个操作完成标记
首先使用 N 个哈希函数分别计算这个数据的哈希值得到 N 个哈希值。然后把这个 N 个哈希值对 bit 数组的长度取模得到每个哈希值在数组中的位置。最后我们把对应的 bit 位设置为 1这就完成了在布隆过滤器中标记数据的操作。
如果数据不存在例如在数据库中没有写入数据我们也就没有用布隆过滤器标记过数据那么 bit 数组对应的 bit 位的值仍为 0。
当需要查询某个数据时我们就执行刚刚的计算过程先得到这个数据在 bit 数组中对应的 N 个位置。紧接着查看 bit 数组中这个 N 个位置上的 bit 值。只要这 N 个 bit 值有一个不为 1这就表明布隆过滤器没有对该数据做过标记所以查询的数据一定没有在数据库中保存。
图中布隆过滤器是一个包含 10 个 bit 位的数组使用 3 个哈希函数。当在布隆过滤器中标记 X 时X 会被计算 3 次哈希值并对 10 取模取模的结果分别是 1、3、7。所以bit 数组的第 1、3、7 位被设置为 1。当应用要查询 X 时只有查看数组的第 1、3、7 位是否为 1。只要有一个为 0那么 X 就肯定不在数据库中。
正式基于布隆过滤器的快速检测特性我们可以在把数据写入数据库时使用布隆过滤器做个标记。当缓存缺失后应用查询数据库时可以通过查询布隆过滤器快速判断数据是否存在。如果不存在就不用再去数据库中查询了。这样一来及时发送了缓存穿透大量请求只会查询 Redis 和布隆过滤器而不会积压请求到数据库。布隆过滤器可以使用 Redis 实现本身就能承受较大的并发压力。
3.3 最后一种方案是在请求入口的前端进行检测
缓存穿透的一个原因是有大量的恶意请求访问不存在的数据所以一个有效的应对方案是在请求入口前端对业务系统接收到的请求进行合法性检测把恶意请求例如请求参数不合发、请求字段不存在直接过滤掉不让他们访问后端缓存和数据库。这样一来也就不会出现缓存穿透问题了。
4.小结
我把三大问题的原因和应对方案总结到一张表格上。
问题原因应对方案缓存雪崩大量数据同时过期缓存实例宕机给缓存数据的过期时间加上小的随机数避免同时过期 服务降级 服务熔断 请求限流 Redis主从集群缓存击穿访问非常频繁的热点数据过期不给热点数据设置过期时间缓存穿透缓存和数据库中都没有要访问的数据缓存空值或缺省值 请求使用布隆过滤器快速判断请求入口前端对请求合法性进行检查
最后要强调以下服务熔断、服务降级、请求限流这些方法都属于“有损”方案在保证数据库和整体系统稳定的同事会对业务应用带来负面影响。
所以建议尽量使用预防方案
针对缓存雪崩合理的设置数据过期时间以及搭建高可靠缓存集群。针对缓存击穿在缓存访问非常频繁的热点数据时不要设置过期时间。针对缓存穿透提前在入口前端实现恶意请求检测、使用不容过滤器快速判断或者规范数据库的数据删除操作避免误删。
