Redis 缓存。

Redis 缓存。

---

---

缓存击穿。

key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。

• 使用互斥锁（mutex key）。一个一个访问。

mutex
互斥量；互斥体；互斥；互斥锁；互斥对象

• 设置 key 永不过期（update 情况下删除缓存）。

---

缓存穿透。

用户想要查询一个数据，发现 Redis 中没有， 也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当高并发时，缓存都没有命中，于是都去请求数据库。这会给数据库造成很大的压力，甚至宕机，这时候就叫做出现了缓存穿透。

缓存击穿 v.s. 缓存穿透。

缓存击穿，是指一个 key 非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个 key 在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。而穿透是 Redis 和数据库中都没有该数据， 比如黑客发起的攻击。

---

缓存穿透解决。

布隆过滤器。

设置空值。

• 带来的问题。

• 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的值，因为这当中可能会有很多空值的键。
• 即使对空值设置了过期时间，还是会存在 Redis 和 db 的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响（生效后删除缓存）。

---

缓存雪崩。

缓存层出现了错误，不能正常工作了。于是所有的请求都会到达存储层，存储层的调用量暴增，造成存储层也会挂掉的情况。

---

缓存雪崩解决。

Redis 高可用（集群）。

加随机因子（根据商品冷热程度）。

限流降级（已经发生雪崩的情况下，系统构架级别策略）。

加锁排队（同缓存击穿）。

---

Redis 缓存与数据库双写一致性。

在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以就需要使用 Redis 做一个缓冲操作，让请求先访问到 Redis，而不是直接访问 MySQL 等数据库。

遇到数据不一致场景。

• 当更新数据时，如更新某商品的库存，当前商品库存是 100，现在要更新为 99，先更新数据库为 99，然后更新缓存，如果此时更新缓存失败了，这意味着数据库存的是 99，而缓存是 100。数据库和缓存不一致。

• 如果删除了缓存 Redis 记录，还没有来得及删除对应的数据库记录，另一个线程就来读取，发现缓存为空，则去数据库中读取数据，并写入缓存。数据库中没有此数据了，而缓存中有了。此时缓存中为脏数据。

因为写和读是并发的，没法保证顺序。就会出现缓存和数据库数据不一致问题。

---

解决方案。

延时双删策略。

该方案的问题在于需要评估自己项目读取业务逻辑的耗时。这么做的目的是确保请求结束时，写请求可以删除读请求造成的缓存脏数据。

当然这种策略还要考虑 Redis 和数据库评价同步的耗时。最后的写数据的休眠时间：在读数据业务逻辑耗时的基础上，加几百毫秒即可。eg. 休眠 1 秒。

麻烦。在并发操作多，集群数据量大的时候，不靠谱。

---

异步更新缓存 ~ 基于订阅 binlog 的同步机制。

该方案核心：使用消息队列对读写操作进行排序，保证了数据的一致性。当然，性能上可能相对要差。保证了数据的准确性。

---

Canal。

https://github.com/alibaba/canal/

• Canal 模拟 MySQL Slave 的交互协议，伪装自己为 MySQL Slave，向 MySQL Master 发送 dump 协议。

• MySQL Master 收到 dump 请求，开始推送 binary log 给 Slave（也就是 Canal）。

• Canal 解析 binary log 对象（原始为 Byte 流）。

• Canal 将解析后的对象数据推送给监听的中间件（实时主动推送，RabbitMQ 需要是在线状态）。