-
Redis总结（三）
目录
什么是缓存预热、缓存雪崩、缓存击穿、缓存穿透？
缓存预热
缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
缓存雪崩
当大量key同时过期或Redis故障宕机时，如果有大量的用户请求，都无法再Redis中处理，于是全部请求都直接访问数据库，从而导致数据库压力骤增，严重会导致数据库宕机，从而形成一系列连锁反应，造成整个数据库崩溃，这就是缓存雪崩。
解决方案
针对Redis故障宕机
1.采用Redis集群，避免单机出现问题导致整个缓存服务都没法使用
2.服务熔断或请求限流机制：因为Redis宕机而导致的缓存雪崩问题时，可以启动服务熔断机制，暂停业务应用对缓存服务的访问，直接返回错误，不再继续访问数据库，从而降低对数据库的压力，保证数据库系统的正常运行，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。
服务熔断机制是保护数据库的正常允许，但是暂停了业务应用访问缓存服系统，全部业务都无法正常工作，为了减少对业务的影响，我们可以启用请求限流机制，只是将少部分请求发送到数据库进行处理，再多的请求就在入口处直接拒绝服务，等到Redis恢复正常并把缓存预热完后，在解除请求的限流机制。
针对大量key同时过期
1.均匀key过期时间，应避免大量key同一时间过期。
2.互斥锁：在线程处理业务请求时，如果发现访问的数据不在Redis数据库中，就加个互斥锁，保证同一时间只有一个请求从数据库中读取数据，再将缓存更新到Redis中。（设置互斥锁时，最好设置超时时间，避免当请求拿到锁后，这个请求发生某种情况一直阻塞，无法释放锁，导致其他请求也拿不到锁，系统发生无响应现象）。
3.后台更新缓存：业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并让更新缓存的工作交由后台线程定时更新。
缓存击穿
如果缓存中的某个热点数据过期了，此时大量请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库就很容易被高并发的请求冲垮，这就是缓存击穿。
解决方案
1.互斥锁方案，保证同一时间只有一个业务线程在更新缓存，未获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
2.不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；
3.差异失效时间：新建两块缓存，主A从B，先更新B在更新A，严格按照这个顺序。当查询缓存时，先查询主缓存A，如果A中没有所需数据，在查询从缓存B。
缓存穿透
当用户访问数据时，数据既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库压力骤增，这就是缓存穿透。
缓存穿透的发生一般有两种情况：
1.业务操作失误，缓存中的数据和数据库中的数据都被删除了，所以导致缓存和数据库中都没有数据；
2.黑客恶意攻击。故意大量访问不存在的数据的业务。
解决方案
1.非法请求的限制：当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
2.设置空值或默认值：当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。
3.使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在：我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在，即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。
需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是：布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。
总结
数据库和缓存如何保证一致性？
先更新缓存还是先更新数据库？
先不考虑并发问题，正常情况下，无论谁先谁后，都会更新成功，但异常情况下可能会发生【第一步操作成功、第二步操作失败的情况】
异常情况下引发的数据一致性问题
1.先更新数据库，再更新缓存
更新数据库成功，更新缓存失败，那么此时数据库中是最新值，缓存中是旧值，之后读到的就是旧值，只有当缓存失效后，才能从数据库中得到正确得值。
2.先更新缓存，再更新数据库
更新缓存成功，更新数据库失败，那么此时缓存中是最新值，数据库中是旧值，之后读到的是缓存中的新值，但当缓存失效后，从数据库中又会读到旧值。
并发情况下引发的一致性问题
1.先更新数据库，再更新缓存
假如有两个请求，请求A和请求B，同时更新同一条数据可能会出现这样的情况：
请求A先将数据库中数据更新为1，然后在更新缓存前，请求B将数据库数据更新为2，紧接着也把缓存更新为2，然后 请求A将缓存更新为1，此时数据库中数据为1，缓存中数据为2，出现了缓存和数据库中数据不一致情况。
解决方案
1.采用分布式锁：在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。
2.设置过期时间：在更新完缓存时，给缓存加上较短的过期时间，这样即时出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。
2.先更新缓存，再更新数据库
假如有两个请求，请求A和请求B，同时更新同一条数据可能会出现这样的情况：
A 请求先将缓存的数据更新为 1，然后在更新数据库前，B 请求来了， 将缓存的数据更新为 2，紧接着把数据库更新为 2，然后 A 请求将数据库的数据更新为 1。
此时，数据库中的数据是 1，而缓存中的数据却是 2，出现了缓存和数据库中的数据不一致的现象。
先删除缓存再更新数据库还是先更新数据库再删除缓存？
所以，无论是「先更新数据库，再更新缓存」，还是「先更新缓存，再更新数据库」，这两个方案都存在并发问题，当两个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现象。
此时需要考虑另一种方案：删除缓存。在更新数据时，不更新缓存，而是删除缓存中的数据。然后，到读取数据时，发现缓存中没了数据之后，再从数据库中读取数据，更新到缓存中。即Cache Aside（旁路缓存）策略。
对于异常情况，但凡第二步操作失败，肯应会引起数据不一致，这里重点介绍并发问题带来的数据不一致情况。
并发情况下引发的一致性问题
1.先删除缓存，再更新数据库
有两个请求，请求A进行写操作，请求B进行读操作
（1）请求A进行写操作，删除redis缓存后，工作正在进行中，更新mysql......A还么有彻底更新完mysql，还没commit
（2）请求B开工查询，查询redis发现缓存不存在(被A从redis中删除了)
（3）请求B继续，去数据库查询得到了mysql中的旧值(A还没有更新完)
（4）请求B将旧值写回redis缓存
（5）请求A将新值写入mysql数据库
上述情况会出现数据不一致情况
解决方案
1.延迟双删：在线程 A 删除缓存、更新完数据库之后，先「休眠一会」，再「删除」一次缓存。
- #删除缓存
- redis.delKey(X)
- #更新数据库
- db.update(X)
- #睡眠
- Thread.sleep(N)
- #再删除缓存
- redis.delKey(X)
加了个睡眠时间，主要是为了确保请求 A 在睡眠的时候，请求 B 能够在这这一段时间完成「从数据库读取数据，再把缺失的缓存写入缓存」的操作，然后请求 A 睡眠完，再删除缓存。
所以，请求 A 的睡眠时间就需要大于请求 B 「从数据库读取数据 + 写入缓存」的时间。
2.先更新数据库，再删除缓存
继续用「读 + 写」请求的并发的场景来分析。
假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。
最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。
从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。
因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。
而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。
如何保证两步都成功？
前面我们分析到，无论是更新缓存还是删除缓存，只要第二步发生失败，那么就会导致数据库和缓存不一致。
1.重试机制
可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。
- 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
- 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。
2.订阅数据库变更日志：
「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。
于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除。
总结
文章参考：
2.小林coding：图解Redis介绍 | 小林coding
3. 尚硅谷Redis7实战：尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练（附redis面试题）_哔哩哔哩_bilibili
4.javaguide:Java 面试指南 | JavaGuide(Java面试 + 学习指南)
5.水滴与银弹公众号：缓存和数据库一致性问题，看这篇就够了 (qq.com)
-
相关阅读:
JavaScript权威指南第七版 第二章笔记：词法结构
官宣｜HelpLook现已入驻钉钉应用市场，助力企业知识管理知识
js--事件流、事件委托、事件阶段
PMP有没有必要续证？
Maven高级
【UE C++】设置游戏模式
CSP-J第二轮试题-2022年-4题
出方向链路负载均衡技术（原理部分）
MobaXterm下docker容器中运行界面程序
系分 - 数学与经济管理
- 原文地址：https://blog.csdn.net/zssxcj/article/details/132742409