【缓存】生产问题

参考：

Redis中BigKey和HotKey的检测及处理详解

https://www.alibabacloud.com/blog/a-detailed-explanation-of-the-detection-and-processing-of-bigkey-and-hotkey-in-redis_598143?spm=a2796.7996630.8896513680.1.373a54b0xTX6yZ

Redis 热点键发现及常见解决方案

https://www.alibabacloud.com/blog/redis-hotspot-key-discovery-and-common-solutions_594446?spm=a2c65.11461447.0.0.19f33025TunEqe

分布式缓存的25个优秀实践与线上案例

https://mp.weixin.qq.com/s?spm=a2c6h.12873639.article-detail.21.9d6922actBebwt&__biz=MzIxMzEzMjM5NQ==&mid=2651029483&idx=1&sn=0730ae70a55826864330f8a77fe5a8c4&chksm=8c4caaefbb3b23f948dabe3e42ac4a95b6d9667f76a3c1bc21e1e14cf28df4c92bab392e03a9&scene=21#wechat_redirect

BigKey、HotKey的发现与处理  

https://www.alibabacloud.com/blog/a-detailed-explanation-of-the-detection-and-processing-of-bigkey-and-hotkey-in-redis_598143?spm=a2796.7996630.8896513680.1.373a54b0xTX6yZ

---

 

思考：

节选自：   【中华石杉】亿级流量电商详情页系统的大型高并发与高可用缓存架构实战  P1
如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与恢复？： Redis企业级集群架构
如何支撑高性能及高并发到极致？同时缓存架构最终的安全保护层？：（nginx+luna）+redis+ehcache三级缓存架构
如何解决大value缓存的全量更新效率低下问题？：缓存维度化拆分解决方案
如何将缓存命令率提升到极致？： 双层nginx部署架构，一致性hash流量分发策略
如何解决高并发场景下，如何解决数据库与缓存双写时树不一致情况？：数据库+缓存双写一致性解决方案
如何解决高并发场景下，缓存重建时的分布式并发冲突问题？：基于zookeeper分布式锁的缓存并发重建解决方案
如何解决高并发场景下，缓存冷启动Mysql瞬间被打死问题？：基于storm实时统计热数据的分布式快速缓存预热解决方案
如何解决高并发场景下，缓存雪崩问题？事前+事中+事后的三层解决方案
如何解决高并发场景下，缓存穿透问题？避免Mysql带来过大压力：缓存穿透解决方案
如何解决高并发场景下，缓存失效问题？避免给redis集群带来过大压力？: 缓存失效解决方案
如何解决热点缓存导致单机负荷瞬间超高？：基于storm的实时热点发现，及毫秒级实时热点缓存负载均衡降级

 

缓存设计的设计点

1、容量规划

• 缓存内容的大小
• 缓存内容的数量
• 淘汰策略
• 缓存的数据结构
• 每秒的读峰值
• 每秒的写峰值

2、性能优化

• 线程模型
• 预热方法
• 缓存分片
• 冷热数据的比例

3、高可用

• 复制模型
• 失效转移
• 持久策略
• 缓存重建

4、缓存监控

• 缓存服务监控
• 缓存容量监控
• 缓存请求监控
• 缓存响应时间监控

5、注意事项

• 是否有可能发生缓存穿透
• 是否有大对象
• 是否使用缓存实现分布式锁
• 是否使用缓存支持的脚本（Lua）
• 是否避免了Race Condition

---

缓存淘汰策略

1. FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会导致命中率很低。
2. LRU：最近最少使用算法，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。仍然有个问题，如果有个数据在 1 分钟访问了 1000次，再后 1 分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。
3. LFU：最近最少频率使用，利用额外的空间记录每个数据的使用频率，然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。

上面三种策略各有利弊，实现的成本也是一个比一个高，同时命中率也是一个比一个好。Guava Cache虽然有这么多的功能，但是本质上还是对LRU的封装。

LFU的局限性 ：在 LFU 中只要数据访问模式的概率分布随时间保持不变时，其命中率就能变得非常高。比如有部新剧出来了，我们使用 LFU 给他缓存下来，这部新剧在这几天大概访问了几亿次，这个访问频率也在我们的 LFU 中记录了几亿次。但是新剧总会过气的，比如一个月之后这个新剧的前几集其实已经过气了，但是他的访问量的确是太高了，其他的电视剧根本无法淘汰这个新剧，所以在这种模式下是有局限性。

LRU的优点和局限性 ：LRU可以很好的应对突发流量的情况，因为他不需要累计数据频率。但LRU通过历史数据来预测未来是局限的，它会认为最后到来的数据是最可能被再次访问的，从而给与它最高的优先级。

---

缓存一致性问题：

https://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453582112&idx=1&sn=005ffdf453d025a04b417179a2599f76&chksm=8cd1e442bba66d54263d5e78a10fa454e5511649d5c4bdf146dce377114cf90c8fc33fc87b00&scene=21#wechat_redirect

携程最终一致和强一致性缓存实践   https://cloud.tencent.com/developer/article/1851220

先更新数据库，后删除缓存

---

 缓存分类、应用场景、优缺点、生产缓存问题（雪崩、穿透、击穿、一致性）：https://new.qq.com/rain/a/20240124A012X400 

缓存分类：浏览器缓存、客户端缓存、CDN缓存、反向代理缓存、本地缓存、分布式缓存

1、缓存雪崩：大量的缓存同一时刻失效

　　典型问题：所有首页的Key失效时间都是12小时，秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库。

　　解决方案：

　　　　把每个Key的失效时间都加个随机值，这样可以保证数据不会在同一时间大面积失效

　　　　如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题；

　　　　或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间）

2、缓存穿透：数据库和缓存都没有的数据，每次都要经过缓存去访问数据库，大量的请求有可能导致DB宕机。

　　解决方案：

　　1.使用布隆过滤器（Bloom Filter）：一种快速判断元素是否存在的数据结构，它可以在很小的内存占用下，快速判断一个元素是否在一个集合中。将所有可能存在的数据哈希到一个足够大的位数组中，当一个请求过来时，先经过布隆过滤器判断是否存在于缓存中，如果不存在，则直接返回，避免对数据库的查询压力。

        2.空对象缓存：对于确定不存在的数据，在缓存中也存储一个空对象，表示该数据不存在。当请求访问这些不存在的数据时，直接从缓存中返回空对象，避免每次请求都穿透到数据库层进行查询。

        3.延迟双判：当一个查询请求穿透缓存到达数据库层后，先在数据库中进行查询，如果数据库也没有对应的数据，则将这个空结果写入缓存，并设置一个较短的过期时间。这样，下次相同的查询请求就会从缓存中得到空结果，而不会再次穿透到数据库。

        4.热点数据预加载：对于一些热点数据，在系统启动时或者在缓存过期前提前异步加载到缓存中，确保缓存的热点数据一直存在，避免被频繁请求的数据因为缓存过期而导致穿透问题。

        5.限流策略：针对频繁请求的特定数据，可以设置限流策略，例如使用令牌桶算法或漏桶算法，限制对这些数据的请求频率，减轻数据库的压力。

3、缓存击穿：指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

       关键词：强调单个热点Key过期+并发访问

　　解决方案：

　　　　设置热点数据永远不过期。或者加上互斥锁就能搞定了

 　　一般避免以上情况发生我们从三个时间段去分析下：

• • 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。

  • 事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL被打死。

  • 事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

4、数据库与缓存双写不一致问题（秒杀场景）

　　读多写少： 引入分布式锁的读写锁如Redisson.getReadWriteLock(lockKey) 

---

 

热Key和大Key问题

1、概念

BigKey 和 HotKey 的标准有所不同，但是很显然评判的维度是相同的：BigKey通常由数据大小和成员数量决定，而HotKey 则由 Redis 接收的请求频率和次数决定。

BigKey 的定义

一般我们将包含大量数据或大量成员和列表的键称为BigKey。以下是一些示例，可帮助您全面了解BigKey的特点。

• 一个 STRING 键，其值的大小为 5 MB（数据太大）。
• 具有 20,000 个元素的 LIST 键（列表中的元素数量过多）。
• 一个有 10,000 个成员的 ZSET 键（成员数量过多）。
• 一个 HASH 密钥，即使只包含 1,000 个成员，其大小也为 100MB（密钥的大小太大）。

需要注意的是，根据 Redis 的实际使用情况和业务场景，BigKey 的定义可能会有所不同。也就是说，您需要综合考虑所有因素来判断。在给出的示例中，您可以看到键的大小、成员和元素的一些具体数字，这不是 BigKey 的通用定义，它只是为了简化说明，不能作为事实上的标准。

HotKey的定义

当访问某个键的工作量明显高于其他键时，我们可以将其称为 HotKey。为了帮助您更好地理解 HotKeys 的样子，这里有一些示例，请查看以下内容。

• 一个Redis实例的每秒总访问量是1万次，而某个key的每秒访问量就达到了7千次（很明显这个key是一个HotKey，其访问量明显高于其他key）。
• 一个拥有数千个成员、总大小为 1MB 的 HASH 键每秒会收到大量 HGETALL 请求。（在这种情况下，我们称之为 HotKey，因为访问一个键所消耗的带宽明显高于访问其他键。）
• 一个拥有上万个成员的 ZSET key，每秒会收到大量的 ZRANGE 请求。（很明显，它的 CPU 运行时间明显高于其他 key 的请求时间。同样，我们可以说这种 CPU 消耗大的 key 是一个 HotKey。）

2、引发的典型问题：

在使用Redis时，BigKey和HotKey会带来各种各样的问题，最常见的就是性能下降、访问超时、访问倾斜、数据倾斜等。

BigKey 导致的典型问题

• 客户端的响应延迟，感觉就像 Redis 的速度变慢了。
• Redis 内存使用量持续增长，达到 maxmemory 导致 OOM 或者写阻塞，以及重要 key 被驱逐。
• 发生访问倾斜可能会导致某个 Redis 实例达到性能瓶颈，从而导致整个集群也达到性能瓶颈。这种情况下，Redis Cluster 中某个节点的内存使用量通常会远远超过其他节点，因为该节点上有对 BigKey 的访问请求，而 Redis Cluster 中数据迁移的最小粒度是导致该节点内存无法均衡的关键。也就是说，除非找到将 BigKey 划分为小 Key 的方法，否则该问题无法得到解决。
• Redis 应该提供的所有服务都会受到影响，因为 Redis 变得越来越慢，这都是因为 BigKey 上的读取请求占用了 Redis 的所有带宽。
• 删除BigKey时，主数据库长时间阻塞，导致同步中断或故障转移。

HotKey 引起的典型问题

• HotKeys通常需要较长的CPU运行时间，从而降低Redis的性能并影响其他请求。
• 某些 Redis 节点/机器上的热点（而不是分片到不同 Redis 节点的键上的热点）通常会阻止您充分利用 Redis 集群。因为这些节点的内存/CPU 负载会非常重，而其他节点的利用率却很低。
• 对于抢购、秒杀的场景，经常会出现超卖的情况，因为对应商品key的库存读请求数量太多，超出了Redis实例的性能承受能力。
• HotKeys 上的流量突然暴增到 Redis 能够承受的最大阈值，甚至导致缓存服务崩溃，也就是我们常说的 Redis 雪崩。如果发生这种情况，大量的请求会直接冲击后端数据库，导致数据库层负载过高，数据库可能无法承受而宕机，从而影响业务。

3、BigKey 和 HotKey 的常见原因

业务规划不充分、 Redis使用不当、无效数据堆积、访问量突然增加等都可能导致 BigKey 和 HotKey 问题。例如：

BigKey

1）使用Redis不合适的数据类型会引入BigKey问题，比如使用String类型的键存储较大的二进制文件会导致键的值过大。

2）业务上线前规划设计不足，没有制定合理的分片策略或者拆分计划，无法将单个key中的成员拆分到多个key中，导致某个key中的成员数量过多。

3）没有定期对HASH键中的无效数据进行清理，导致HASH键中成员不断增加，可能带来BigKey问题。

HotKey

1、由于热门产品、热门新闻、KOL（关键意见领袖）直播活动或大量玩家参与的在线游戏对战等原因，访问流量意外增加。

2、业务方逻辑故障，导致LIST键无法被消费，从而导致对应Key中的成员数量不断增加，并且没有减少的趋势。

3、请求切片数超出单台服务器的性能阈值：当服务器上访问某条数据时，通常会对数据进行拆分或者切片，在这个过程中，会访问服务器上对应的key，当访问量超过服务器的性能阈值时，就会出现热键问题。