Redis 常见问题的解决方案

快来打我* 2022-09-06 00:08 250阅读 0赞

### 目录 ###

*   *   *  缓存击穿、穿透、雪崩
         *   *  缓存击穿
             *  缓存穿透
             *  缓存雪崩
         *  双写一致性问题 | 缓存更新方式
         *  多线程的并发竞争问题
         *  单机瓶颈
         *  redis内存不足

### 缓存击穿、穿透、雪崩 ###

#### 缓存击穿 ####

某个热点key的缓存失效了，在缓存过期的那一刻，这个缓存key的所有请求都击穿到DB，造成DB压力增大。

解决方案

*  设置热点key永不过期，使用定时任务定时更新缓存
 *  使用分布式的互斥锁，对于同一个key，一个时间点只允许一个后端线程访问，但此种方式将压力转移到分布式锁上，对分布式锁的考验很大

#### 缓存穿透 ####

查询不存在数据，缓存中没有，数据库中也没有。由于缓存中没有，请求会穿透到数据库进行查询，如果频繁查询不存在的数据，频繁击穿到数据库，会导致数据库压力增大，甚至挂掉。

和缓存击穿的区别：缓存击穿是请求的数据缓存中没有、但数据库中有，缓存穿透是请求的数据缓存中、数据库中都没有。

解决方案

*  接口层增加数据校验，校验请求合理性；
 *  缓存中、数据库中都取不到查询数据时，可以设置一个值为null的key，设置短些的过期时间，防止同个key一直被攻击
 *  也可以使用布隆过滤器，把所有可能存在的数据添加到布隆过滤器的集合中，访问一个一定不存在的数据时会被布隆过滤器拦截掉

采用设置值为null的key可能导致redis中存在大量无用的key占用内存，使用之前需要看领导、编码规范是否允许。

#### 缓存雪崩 ####

大量的热点key同时过期（缓存的热点数据集中失效），造成DB压力骤增，严重的可能造成数据库宕机，引起一系列连锁反应，造成整个系统崩溃。

和缓存击穿的区别：缓存击穿是单个key过期，缓存雪崩是大量的key同时过期。

解决方案

*  应用启动时做缓存预热
 *  设置过期时间时加上一个随机值，分散key的过期时间
 *  或者设置热点数据永不过期（不设置过期时间），使用定时任务定时更新缓存
 *  使用hystrix之类的容错框架进行限流、服务降级，保证核心功能可用，避免引发级联故障
 *  如果不是分布式应用，也可以考虑引入本地缓存做多级缓存

设置热点数据永不过期（不设置过期时间），这个需要看公司编码规范而定，有的公司编码规范要求key都必须设置过期时间，防止死锁以及大量的无效key占用内存。

### 双写一致性问题 | 缓存更新方式 ###

双写一致性问题：业务需要更新数据库并更新redis，其中某个更新操作可能失败，造成数据库、缓存的数据不一致。

考虑点

*  先更新数据库还是先更新缓存
 *  更新缓存是直接更新，还是删除后下次请求时回种

经典的KV、DB读写模式（缓存+数据库读写模式）

*  读的时候，先读缓存，缓存中没有才去读数据库，从数据库中获取数据后回种到缓存中
 *  更新的时候，先更新数据库，再更新缓存

更新顺序：一般是先更新数据库，再更新缓存。

数据库更新结果是整个操作的关键，数据库更新失败意味着整个更新操作失败，没有必要、也不能再去更新缓存。

缓存更新方式：一般使用更新，如果缓存数据需要经过复杂计算得到，可以考虑使用删除。

删除方式可能导致缓存击穿，所以一般不用；如果这个缓存数据需要经过较为复杂的计算才能得到，且更新频率较高、查询频率较低，那么使用更新方式代价大，可能会出现频繁计算数据、更新缓存，但只查询了一两次的情况，这种情况可以考虑使用删除方式，性价比更高。

解决方案总结：如果业务要求强一致性，可以使用分布式事务；如果不要求强一致性，在数据库更新成功的前提下保证最终一致性即可，可以

*  使用异步任务补偿失败的缓存更新
 *  对缓存数据设置失效期，也就是数据不一致的最大容忍时间，即使存在脏数据，缓存过期回种时也会获取新数据
 *  在更新数据库的业务数据时做校验，比如 where 库存-1 > 0

### 多线程的并发竞争问题 ###

如果要连续操作redis上的数据，且整个操作要具有原子性，期间不能被后端的其它线程 | 其它redis客户端 访问，可以使用以下方式

*  使用分布式锁，redis客户端需要获取到分布式锁后才能操作这个key
 *  借助redis的单线程特性，只要实现这批指令的原子性即可：如果有对应的原生指令，可以使用原生指令，比如setnx、expire2个指令可以使用set lock key ex 60 nx 代替；如果这一系列指令比较常用，可以写成lua脚本

### 单机瓶颈 ###

单机版redis主要有2个瓶颈

*  存在单点故障问题，可用性低
 *  单机内存有限，redis可用容量受限

解决方案：采用redis集群方式进行部署

*  数据分散存储在多个master上，提升容量，分散存储压力
 *  slave做数据备份，sentinel监控集群状态，在master故障时迁移到slave上提高可用性

### redis内存不足 ###

redis内存不足时，一方面会使用内存淘汰策略回收内存，另一方面会使用虚拟内存，使用虚拟内存会与硬盘发生大量数据交换，导致redis服务器性能大幅下降。

redis内存不足的常见原因

*  机器内存配置较低
 *  随着版本迭代、业务拓展，使用的key越来越多
 *  存在大量的废弃的、无用的key，比如未设置过期时间
 *  缓存了大量的冷数据

解决方案

*  增加服务器内存
 *  增加redis集群的节点数量，分散存储压力
 *  及时清理废弃的、无效的key，尽量给key设置过期时间
 *  清理缓存的冷数据