面试官：聊一聊Redis 缓存问题
为什么要理解 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，总结来说是：
- 读的时候：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
- 更新的时候：先更新数据库，然后再删除缓存。
其具体逻辑如下：
- 失效：应用程序先从 cache 取数据，没有的到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从 cache 中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存淘汰。
为什么建议淘汰缓存，而不是更新缓存？
答：如果更新缓存，在并发写时，可能出现数据不一致的情况。
如果采用更新缓存，在 请求1 和 请求2 并发写 发生时，由于无法保证时序，此时不管先操作缓存还是先操作数据库，都可能出现：
- 请求1 先操作数据库，请求2 后操作数据库
- 请求2 先更新缓存，请求1 后更新了缓存
导致，数据库 和 缓存之间的数据不一致。
所以，Cache Aside Pattern 建议，删除缓存，而不是更新缓存。
为什么建议先操作数据库，再操作缓存？
答：如果先操作缓存，在读写并发时，可能出现数据不一致。
如果先操作缓存，在 请求1 和 请求2 并发读写 发生时，由于无法保证时序，可能出现：
- 写请求淘汰了缓存
- 写请求操作了数据库（主从同步没有完成）
- 读请求读了缓存（因为缓存被淘汰，所以没有命中）
- 读请求读了从库（读了一个旧数据）
- 读请求 set 回数据库（set 了一个旧数据）
- 数据库主从同步完成
导致，数据库和缓存的数据不一致
所以，Cache Aside Pattern 建议，先操作数据库，再操作缓存。
存在的问题？
答：如果先操作数据库，再淘汰缓存，在原子性被破坏时：
- 修改数据库成功了
- 淘汰缓存失败了
导致，数据库和缓存的数据不一致
举个例子：一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后之前的读操作再把旧的数据放进缓存，所以会造成脏数据，导致数据库和缓存的数据不一致。
但这个事件理论上会出现，不过，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢的多，而且还要锁表，而读操作必须在写操作前进入数据库操作，而又晚于写操作更新缓存，所有的这些条件都具备的概率基本不大。
解决方案：队列 + 重试机制
流程如下：
- 更新数据库数据；
- 缓存因为种种问题删除失败；
- 将需要删除的key发送至消息队列；
- 自己消费消息，获得需要删除的key；
- 继续重试删除操作，直到成功
缺点：对业务线代码造成大量的侵入。
解决方案：异步更新缓存（基于订阅binlog的同步机制）
技术整体思路：
MySQL binlog 增量订阅消费+消息队列+增量数据更新到Redis
- 读Redis ：热数据基本都在 Redis
- 写MySQL ：增删改都是操作 MySQL
- 更新 Redis 数据：MySQL的数据操作binlog 来更新到Redis
Redis 更新
- 数据操作主要分为两大块：
增量：MySQL 的update、insert、delete变更数据
- 一个是全量（将全部数据一次写入到Redis）
- 一个是增量（实时更新）
- 读取binlog 后分析，利用消息队列，推动更新各台的 Redis 缓存数据
这样一旦MySQL 中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送到Redis，Redis 再根据binlog中的记录，对Redis 进行更新。
其实这种机制，很类似 MySQL 的主从备份机制，因为 MySQL 的主备也是通过 binlog 来实现的数据一致性。
最后：
最近有一些小伙伴粉丝让我帮忙找一些 面试题 资料。为帮助开发者们提升面试技能、有机会入职BATJ等大厂公司，于是我翻遍了收藏的 5T 资料后特别制作了一个专辑一次整体放出。
说明一下：所有的面试题目都不是一成不变的，特别是像一线大厂，下面的面试题只是给大家一个借鉴作用，最主要的是给自己增加知识的储备，有备无患。大致内容包括了： 各类大小厂面经真题、Java 集合、JVM、多线程、并发编程、设计模式、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、spring面试题、spring cloud面试题、spring boot面试题、spring教程 笔记、spring boot教程笔记、最新阿里巴巴开发手册（63页PDF总结）、2022年Java面试手册一共整理了1184页PDF文档。
如需获取——点赞关注后私信(555)即可