redis缓存设计以及经典问题分析

1 缓存基本思想

1、不同的存储介质访问延迟不一样，相同成本存储容量不一样：

SSD/DISK、Memory、L3 cache、L2 cache、L1 cache 五种存储介质，访问延迟逐渐降低，但是同等成本的容量却逐渐增大。

2、时间局限性原理

被获取过一次的数据在未来会被多次获取

3、以空间换时间

开辟一块高速独立空间，提供高速访问

4、性能成本权衡

访问延迟性低、性能越高，等容量成本越高

2 缓存优势

1. 提升访问性能
2. 降低网络拥堵
3. 减轻服务负载
4. 增强可扩展性

3 缓存代价

1. 系统复杂性提高
2. 存储和部署成本变高
3. 数据一致性问题

4 缓存的三种模式

4.1 Cache Aside 旁路缓存

写操作：更新 DB 之后，直接将 key 从缓存中删除；

读操作：先读缓存，如果没有，则读 DB，同时将 DB 的数据同步到缓存中。

特点：业务端处理所有数据访问细节，同时利用 lazy 懒加载思想，更新 DB 之后，直接删除缓存并通过 DB 更新，确保数据以 DB 为准，可以大幅降低缓存和 DB 之间的不一致的概率。

缺点：

1、如果删除缓存失败，可能会有问题；

解决方法：失败增加监控

2、如果同时有比较高的QPS访问刚插入或者更新的数据，可能会打垮DB；

解决方法：使用多线程异步执行查询，防止这种问题。

场景：读多写少。比如用户数据，用户修改用户信息很少，但是各种业务场景用到用户数据的读场景比较多。

4.2 Read/Write Through

核心思想：读写缓存和 DB 的操作，都有一个中间的数据服务代理。

写操作：先查缓存，如果缓存不存在，则只更新 DB；如果缓存中存在，则先更新缓存，再更新DB，然后返回；

读操作：先查缓存，如果命中则直接返回。否则从 DB 中加载，然后回种到缓存中再返回。

特点：业务端不需要关心数据细节，系统隔离性好。

4.3 write-Back 或者 Write-Behind

承接 Write Through，写操作更新完缓存之后，异步回写数据到 DB 或者批量回写数据到 DB。

缺点：异步或者批量回写，可能会导致数据丢失。

特点：合并或者异步写 DB，DB 压力小。

使用场景：写频率很高，但是对于数据一致性要求不太高的业务。

5 redis 常见面试题

5.1 redis雪崩

概念：大量的应用请求无法在 Redis 缓存中进行处理，紧接着，
应用将大量请求发送到数据库层，导致数据库层的压力激增。

原因：

1、缓存中有大量数据同时过期，导致大量请求无法得到处理

2、Redis 缓存实例发生故障宕机了

解决方案：

原因1：方法1：避免给大量的数据设置相同的过期时间；方法2: 降级直接返回预定义信息、空值或是错误信息

原因2：方法1: 在业务系统中实现服务熔断或请求限流机制；方法2: 服务端 限流

事前预防：使用主从节点 构建Redis 缓存高可靠集群

5.2 击穿

概念：1、是发生在某个热点数据失效的场景下，大量请求直接访问 DB，DB 压力骤增，业务响应延迟。

原因：热点 key 过期失效或者同时失效。

解决办法：热点 key 不设置过期时间；或者设置过期时间为基础时间+随机时间。

5.3 穿透

概念：要访问的数据既不在 Redis 缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据。

原因：1、业务层误删除数据了；2、恶意攻击：专门访问数据库中没有的数据。

解决方法：

1、缺省值或者空值

2、使用布隆过滤器快速判断数据是否存在，
避免从数据库中查询数据是否存在，减轻数据库压力。

3、前端进行请求检测

5.4 bigkey

概念：一个缓存 key，存储数据过多。比如一个上万记录的List；

危害：

1、造成内存分配不均匀。比如在 Redis cluster 或者 codis 中，会造成节点的内存使用不均匀；

2、超时阻塞。因为 Redis 单线程特性，如果操作某个 Bigkey 耗时比较久，则后面的请求会被阻塞。

3、网络阻塞，消耗带宽。

4、过期删除，会很慢，会阻塞redis。如果 Bigkey 设置了过期时间，当过期后，这个 key 会被删除，假如没有使用 Redis 4.0 的过期异步删除，
就会存在阻塞 Redis 的可能性，并且慢查询中查不到（因为这个删除是内部循环事件）。

如何发现：

redis命令： redis-cli --bigkeys

解决方法：

1、删除bigkey。

1. redis4.0 之后，异步删除；
2. 集合类型：用scan，读取部分数据删除；
3. hash类型，用Hscan，读取部分数据删除

2、拆分

1. string类型，拆分成多个key
2. 集合或者hash类型，拆分成多个list或者hash

5.5 热key

概念: 所谓热key问题就是，突然有几十万的请求去访问redis上的某个特定key。
那么，这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机。

解决：

1、二级缓存——本地缓存。比如利用ehcache，或者一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中。
针对这种热key请求，会直接从jvm中取，而不会走到redis层。

2、备份热key。不要让key走到同一台redis上不就行了。我们把这个key，在多个redis上都存一份不就好了。
接下来，有热key请求进来的时候，我们就在有备份的redis上随机选取一台，进行访问取值，返回数据。

思维导图自取：https://www.processon.com/emb...

参考：https://segmentfault.com/a/11...