redis常见问题和解决方案汇总（redis的三大问题）

缓存穿透

访问不存在的key，导致每次都去DB查找，从而失去了缓存的意义，也加大了DB的压力。失去了缓存的意义，访问这些key频次高的话，会加大DB压力，甚至导致DB崩溃。

解决方案

• 使用布隆过滤器，将所有存在的key哈希到一个足够大的bitmap中。一个不存在的key一定能被挡住，但如果结果告诉程序某个key存在，并不一定存在（因为存在hash碰撞）。
• 回填空值到缓存，需要注意缓存过期时间

缓存击穿

由于设置了过期时间，如果在同一时间内一个key（热key）失效，如果某些时间内被高频词访问，那么造成缓存击穿。(缓存里没有，DB里有)

解决方案

redis写key的时候，先对key加锁，然后在读mysql，这样可防止同意时刻大量读请求到达mysql。

缓存雪崩

由于设置相同的过期时间，导致同一时间内大量的key失效。DB压力过大，甚至导致DB崩溃。

解决方案

设置过期时间时随机配置过期时间。

大键

数据量大的 key ，由于其数据大小远大于其他key，导致经过分片之后，某个具体存储这个 big key 的实例内存使用量远大于其他实例，造成内存不足，拖累整个集群的使用。

大key相关的删除或者自动过期时，会出现qps突降或者突升的情况，极端情况下，会造成主从复制异常，Redis服务阻塞无法响应请求。

key类型 field数量耗时

Hash~100万~1000ms

List~100万~1000ms

Set~100万~1000ms

Sorted Set~100万~1000ms

如何判断大键

• 字符串类型：一般认为超过 10k 的就是 bigkey，但是这个值和具体的 OPS 相关。
• 非字符串类型：体现在哈希，列表，集合类型元素过多。

Redis 4.0之前的大key的发现方法

• redis-rdb-tools工具。redis实例上执行bgsave，然后对dump出来的rdb文件进行分析，找到其中的大KEY。
• redis-cli --bigkeys命令。可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。
• 自定义的扫描脚本，以Python脚本居多，方法与redis-cli --bigkeys类似。
• debug object key命令。可以查看某个key序列化后的长度，每次只能查找单个key的信息。官方不推荐。

Redis 4.0之前的大key的删除方法

通过hscan、sscan、zscan方式渐进删除若干个元素;但面对过期删除键的场景,这种取巧的删除就无能为力。我们只能祈祷自动清理过期key刚好在系统低峰时，降低对业务的影响。

Redis 4.0之后的大key的发现方法

Redis 4.0引入了memory usage命令和lazyfree机制，不管是对大key的发现，还是解决大key删除或者过期造成的阻塞问题都有明显的提升。

memory usage：默认抽样5个field来循环累加计算整个key的内存大小，样本的数量决定了key的内存大小的准确性和计算成本，样本越大，循环次数越多，计算结果更精确，性能消耗也越多。

Redis 4.0之后的大key的删除方法

lazyfree机制：Lazyfree的原理是在删除的时候只进行逻辑删除，把key释放操作放在bio(Background I/O)单独的子线程处理中，减少删除大key对redis主线程的阻塞，有效地避免因删除大key带来的性能问题。在此提一下bio线程，很多人把Redis通常理解为单线程内存数据库, 其实不然。Redis将最主要的网络收发和执行命令等操作都放在了主工作线程，然而除此之外还有几个bio后台线程，从源码中可以看到有处理关闭文件和刷盘的后台线程，以及Redis4.0新增加的lazyfree线程。

解决方案

string类型

string类型的big key，建议不要存入redis，用文档型数据库MongoDB代替或者直接缓存到CDN上等方式优化。有些 key 不只是访问量大，数据量也很大，这个时候就要考虑这个 key 使用的场景，存储在redis集群中是否是合理的，是否使用其他组件来存储更合适；如果坚持要用 redis 来存储，可能考虑迁移出集群，采用一主一备（或1主多备）的架构来存储。

hash， set，zset，list

可以将这些元素分拆。以hash为例，原先的正常存取流程是 hget(hashKey, field) ; hset(hashKey, field, value)固定一个桶的数量，每次存取的时候，先在本地计算field的hash值，模除 10000，确定了该field落在哪个key上。

bitmap/布隆过滤器过大

过大可能引发内存淘汰机制，导致部分数据被移除。

解决方案

对大的bitmap拆分。利用多个hash函数计算key的哈希值后，最终key都落在一个bitmap上。

要保证多个hash函数计算后路由到同一个节点，那么才能提高查询效率。否则拆分后要查询多个节点才能拿到结果。拆分后bitmap虽然变小，当作为布隆过滤器使用时，其误判概率并不会随之增大。因为误判是概率是与哈希函数个数，集合元素数量及bitmap大小相关。