【缓存】生产问题
分布式缓存的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
所有与缓存设计相关的设计点
1、容量规划
- 缓存内容的大小
- 缓存内容的数量
- 淘汰策略
- 缓存的数据结构
- 每秒的读峰值
- 每秒的写峰值
2、性能优化
- 线程模型
- 预热方法
- 缓存分片
- 冷热数据的比例
3、高可用
- 复制模型
- 失效转移
- 持久策略
- 缓存重建
4、缓存监控
- 缓存服务监控
- 缓存容量监控
- 缓存请求监控
- 缓存响应时间监控
5、注意事项
- 是否有可能发生缓存穿透
- 是否有大对象
- 是否使用缓存实现分布式锁
- 是否使用缓存支持的脚本（Lua）
- 是否避免了Race Condition
缓存淘汰策略
- FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会导致命中率很低。
- LRU：最近最少使用算法，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。仍然有个问题，如果有个数据在 1 分钟访问了 1000次，再后 1 分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。
- 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)
真正支撑高并发及高可用的复杂系统中缓存架构？
节选自： 【中华石杉】亿级流量电商详情页系统的大型高并发与高可用缓存架构实战 P1
如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与恢复？： Redis企业级集群架构
如何支撑高性能及高并发到极致？同时缓存架构最终的安全保护层？：（nginx+luna）+redis+ehcache三级缓存架构
如何解决大value缓存的全量更新效率低下问题？：缓存维度化拆分解决方案
如何将缓存命令率提升到极致？： 双层nginx部署架构，一致性hash流量分发策略
如何解决高并发场景下，如何解决数据库与缓存双写时树不一致情况？：数据库+缓存双写一致性解决方案
如何解决高并发场景下，缓存重建时的分布式并发冲突问题？：基于zookeeper分布式锁的缓存并发重建解决方案
如何解决高并发场景下，缓存冷启动Mysql瞬间被打死问题？：基于storm实时统计热数据的分布式快速缓存预热解决方案
如何解决高并发场景下，缓存雪崩问题？事前+事中+事后的三层解决方案
如何解决高并发场景下，缓存穿透问题？避免Mysql带来过大压力：缓存穿透解决方案
如何解决高并发场景下，缓存失效问题？避免给redis集群带来过大压力？: 缓存失效解决方案
如何解决热点缓存导致单机负荷瞬间超高？：基于storm的实时热点发现，及毫秒级实时热点缓存负载均衡降级
