为什么要理解 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机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
- 解决方案
缓存污染（或满了）
缓存污染问题说的是缓存中一些只会被访问一次或者几次的数据，被访问完后，再也不会被访问到，但这部分数据依然留存在缓存中，消耗缓存空间。
缓存污染会随着数据的持续增加而逐渐显露，随着服务的不断运行，缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的，如果缓存空间满了，再往缓存里写数据时就会有额外开销，影响 Redis 性能。这部分额外开销主要是指 写的时候判断淘汰策略，根据淘汰策略去选择要淘汰的数据，然后进行删除操作。
最大缓存设置多大？
建议把缓存容量设置为总数据量的 15% 到 30% ，兼顾访问性能和内存空间开销。
但是，缓存被写满是不可避免的，所以需要缓存淘汰策略。
数据库和缓存一致性
- 问题来源：
使用 Redis 做一个缓冲操作，让请求先访问到 Redis ，而不是直接访问 MysqL 数据库：
读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存（Redis）和数据库（MysqL）间的数据一致性问题。
不管是先写 MysqL 数据库，再删除 Redis 缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举个栗子：
- 如果删除缓存 Redis，但还没来得及 写库 MysqL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
- 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致的情况。
因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。
更新缓存的 Design Pattern 有四种：Cache Aside，Read Through，Write Through，Write Behind Caching
Cache Aside Pattern
最常用的是 Cache Aside Pattern，总结来说是：
其具体逻辑如下：
为什么建议淘汰缓存，而不是更新缓存？
答：如果更新缓存，在并发写时，可能出现数据不一致的情况。
如果采用更新缓存，在 请求1 和 请求2 并发写 发生时，由于无法保证时序，此时不管先操作缓存还是先操作数据库，都可能出现：
所以，Cache Aside Pattern 建议，删除缓存，而不是更新缓存。
为什么建议先操作数据库，再操作缓存？
答：如果先操作缓存，在读写并发时，可能出现数据不一致。
如果先操作缓存，在 请求1 和 请求2 并发读写 发生时，由于无法保证时序，可能出现：
- 写请求淘汰了缓存
- 写请求操作了数据库（主从同步没有完成）
- 读请求读了缓存（因为缓存被淘汰，所以没有命中）
- 读请求读了从库（读了一个旧数据）
- 读请求 set 回数据库（set 了一个旧数据）
- 数据库主从同步完成
导致，数据库和缓存的数据不一致
所以，Cache Aside Pattern 建议，先操作数据库，再操作缓存。
存在的问题？
答：如果先操作数据库，再淘汰缓存，在原子性被破坏时：
导致，数据库和缓存的数据不一致
举个例子：一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后之前的读操作再把旧的数据放进缓存，所以会造成脏数据，导致数据库和缓存的数据不一致。
但这个事件理论上会出现，不过，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢的多，而且还要锁表，而读操作必须在写操作前进入数据库操作，而又晚于写操作更新缓存，所有的这些条件都具备的概率基本不大。
解决方案：队列 + 重试机制
流程如下：
缺点：对业务线代码造成大量的侵入。
解决方案：异步更新缓存（基于订阅binlog的同步机制）
技术整体思路：
MysqL binlog 增量订阅消费+消息队列+增量数据更新到Redis
Redis 更新
