为什么要理解 Redis 缓存问题

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

当缓存库出现问题时，必须要考虑如下问题：

• 缓存穿透

• 缓存击穿

• 缓存雪崩

• 缓存污染（或者满了）

• 缓存和数据库一致性

缓存穿透

• 问题来源

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，而且出于容错考虑，如果从 数据库 查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 数据库 去查询，失去了缓存的意义。

在流量大的时候，可能数据库就挂掉了，要是有人利用不存在的 key 频繁攻击我们的应用，这就是漏洞。

如 发起 id 为“-1”的数据 或者 id 为特别大不存在的数据，这时的用户很可能是攻击者，攻击会导致数据库压力过大。

• 解决方案

• 接口层增加校验。如用户鉴权校验，id 做基础校验，id <= 0 的直接拦截。

• 从缓存取不到的数据，在数据库中也没有取到，这时也可以将 key-value对 写为 key-null ，缓存有效时间可以设置 短点 ，如 30秒（设置太长会导致正常情况下也没法使用）。这样就可以防止攻击用户反复用一个 id 暴力攻击。

• 布隆过滤器。bloomfilter 就类似于一个 hash set ，用户快速判断某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于 hash算法 和 容器大小。

缓存击穿

• 问题来源

缓存击穿是指 缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库取数据，引起数据库压力瞬间增大，造成压力过大。

• 解决方案

• 设置热点数据永不过期。

• 接口限流与熔断、降级。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些服务不可用时，进行熔断，失败快速返回机制。

• 加互斥锁（redis 分布式锁 或 ReentrantLock），第一个请求的线程可以拿到锁，拿到锁的线程查询到了数据之后设置缓存，其他线程获取锁失败会等待 50ms ，然后重新到缓存拿数据，这样就可以避免大量请求落到数据库。

• 
  

缓存雪崩

• 问题来源

缓存雪崩是指 缓存中大批量数据到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

• 解决方案

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象的发生。

2. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。

3. 设置热点数据永不过期。

缓存污染（或满了）

缓存污染问题说的是缓存中一些只会被访问一次或者几次的数据，被访问完后，再也不会被访问到，但这部分数据依然留存在缓存中，消耗缓存空间。

缓存污染会随着数据的持续增加而逐渐显露，随着服务的不断运行，缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的，如果缓存空间满了，再往缓存里写数据时就会有额外开销，影响 Redis 性能。这部分额外开销主要是指 写的时候判断淘汰策略，根据淘汰策略去选择要淘汰的数据，然后进行删除操作。

最大缓存设置多大？

建议把缓存容量设置为总数据量的 15% 到 30% ，兼顾访问性能和内存空间开销。

但是，缓存被写满是不可避免的，所以需要缓存淘汰策略。

数据库和缓存一致性

• 问题来源：

使用 Redis 做一个缓冲操作，让请求先访问到 Redis ，而不是直接访问 MySQL 数据库：

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存（Redis）和数据库（MySQL）间的数据一致性问题。

不管是先写 MySQL 数据库，再删除 Redis 缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举个栗子：

1. 如果删除缓存 Redis，但还没来得及 写库 MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2. 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致的情况。

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

更新缓存的 Design Pattern 有四种：Cache Aside，Read Through，Write Through，Write Behind Caching

Cache Aside Pattern

最常用的是 Cache Aside Pattern，总结来说是：

• 读的时候：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。

• 更新的时候：先更新数据库，然后再删除缓存。

其具体逻辑如下：

• 失效：应用程序先从 cache 取数据，没有的到，则从数据库中取数据，成功后，放到缓存中。

• 命中：应用程序从 cache 中取数据，取到后返回。

• 更新：先把数据存到数据库中，成功后，再让缓存淘汰。

为什么建议淘汰缓存，而不是更新缓存？

答：如果更新缓存，在并发写时，可能出现数据不一致的情况。

如果采用更新缓存，在 请求1 和 请求2 并发写 发生时，由于无法保证时序，此时不管先操作缓存还是先操作数据库，都可能出现：

1. 请求1 先操作数据库，请求2 后操作数据库

2. 请求2 先更新缓存，请求1 后更新了缓存

导致，数据库 和 缓存之间的数据不一致。

所以，Cache Aside Pattern 建议，删除缓存，而不是更新缓存。

为什么建议先操作数据库，再操作缓存？

答：如果先操作缓存，在读写并发时，可能出现数据不一致。

如果先操作缓存，在 请求1 和 请求2 并发读写 发生时，由于无法保证时序，可能出现：

1. 写请求淘汰了缓存

2. 写请求操作了数据库（主从同步没有完成）

3. 读请求读了缓存（因为缓存被淘汰，所以没有命中）

4. 读请求读了从库（读了一个旧数据）

5. 读请求 set 回数据库（set 了一个旧数据）

6. 数据库主从同步完成

导致，数据库和缓存的数据不一致

所以，Cache Aside Pattern 建议，先操作数据库，再操作缓存。

存在的问题？

答：如果先操作数据库，再淘汰缓存，在原子性被破坏时：

1. 修改数据库成功了

2. 淘汰缓存失败了

导致，数据库和缓存的数据不一致

举个例子：一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后之前的读操作再把旧的数据放进缓存，所以会造成脏数据，导致数据库和缓存的数据不一致。

但这个事件理论上会出现，不过，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢的多，而且还要锁表，而读操作必须在写操作前进入数据库操作，而又晚于写操作更新缓存，所有的这些条件都具备的概率基本不大。

解决方案：队列 + 重试机制

流程如下：

1. 更新数据库数据；

2. 缓存因为种种问题删除失败；

3. 将需要删除的key发送至消息队列；

4. 自己消费消息，获得需要删除的key；

5. 继续重试删除操作，直到成功

缺点：对业务线代码造成大量的侵入。

解决方案：异步更新缓存（基于订阅binlog的同步机制）

技术整体思路：

MySQL binlog 增量订阅消费+消息队列+增量数据更新到Redis

• 读Redis ：热数据基本都在 Redis

• 写MySQL ：增删改都是操作 MySQL

• 更新 Redis 数据：MySQL的数据操作binlog 来更新到Redis

Redis 更新

1. 数据操作主要分为两大块：

   增量：MySQL 的update、insert、delete变更数据

• 一个是全量（将全部数据一次写入到Redis）

• 一个是增量（实时更新）

2. 读取binlog 后分析，利用消息队列，推动更新各台的 Redis 缓存数据

   这样一旦MySQL 中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送到Redis，Redis 再根据binlog中的记录，对Redis 进行更新。

其实这种机制，很类似 MySQL 的主从备份机制，因为 MySQL 的主备也是通过 binlog 来实现的数据一致性。