Redis中BigKey与MoreKey优化详解_Redis

1.morekey

在redis中，morekey问题通常指的是当数据库中的key数量非常多时，使用如keys *这样的命令去检索所有的key，这会导致redis服务阻塞，影响正常业务。因为redis是单线程操作的，执行这类命令时会占用大量时间，从而阻塞其他操作。

keys * 这个指令有致命的弊端，在实际环境中最好不要使用

这个指令没有offset、limit 参数，是要一次性吐出所有满足条件的key，由于redis是单线程的，其所有操作都是原子的，而keys算法是遍历算法，复杂度是o(n)，如果实例中有千万级以上的 key，这个指令就会导致redis服务卡顿，所有读写redis 的其它的指令都会被延后甚至会超时报错，可能会引起缓存雪崩甚至数据库宕机。

生产上限制 keys * /flushdb/flushall等危险命令以防止误删误用？

通过配置文件设置禁用这些命令，redis.conf在security这一项中

为了避免morekey问题，redis提供了scan命令，它是一个基于游标的迭代器，用于以增量的方式迭代数据库中的key。scan命令不会像keys *那样一次性返回所有的key，而是返回一个游标和一批key，用户可以使用返回的游标进行下一次迭代，直到游标返回0，表示迭代结束。

这种方式可以避免阻塞redis服务，并且可以自定义每次迭代返回的key数量，减少一次性返回大量key对性能的影响。

scan命令用于迭代数据库中的数据库键

scan命令是一个基于游标的迭代器，每次被调用之后，都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为scan命令的游标参数，以此来延续之前的迭代过程。

scan返回一个包含两个元素的数组

1). 第一个元素是用于进行下一次迭代的新游标

2). 第二个元素则是一个数组，这个数组中包含了所有被迭代的元素如果新游标返回零表示迭代已结束

scan的遍历顺序

非常特别，它不是从第一维数组的第零位一直遍历到末尾，而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏

在实际使用中，应该避免使用keys *这样的命令，而是采用scan及其相关的迭代命令来处理大量key的情况。

这样可以有效地避免redis服务因处理大量key而造成的阻塞，确保redis的性能和稳定性

2.bigkey

redis中的bigkey指的是那些值（value）特别大的键（key），这可能包括大的字符串或者包含大量元素的集合类型（如list、set、hash、zset等）。

bigkey的存在可能会导致redis的性能问题，因为redis是单线程操作的，处理bigkey时可能会阻塞其他操作，影响整体性能。

通常我们说的bigkey，不是在值的key很大，而是指的key对应的value很大

string和二级结构

string是value，最大512mb 但是≥10kb就是bigkey
list、hash、set和zset，value个数超过5000就是bigkey
list：一个列表最多可以包含2^32-1个元素(4294967295，每个列表超过40亿个元素)。
hash：redis中每个hash可以存储2^32-1个键值对(40多亿)
set：集合中最大的成员数为2^32-1(4294967295，每个集合可存储40多亿个成员)

3.bigkey危害、产生与发现

3.1 危害

内存使用不均：在集群模式下可能导致某些节点内存使用过高。
请求阻塞：操作bigkey可能耗时较长，阻塞其他请求。
网络拥塞：bigkey可能会占用大量带宽，影响其他服务。
删除时阻塞：删除操作可能会阻塞redis，尤其是在bigkey设置了过期时间后

3.2 产生

社交类明星粉丝列表，典型案例粉丝逐步递增，热点事件
汇总统计某个报表，日月年经年累计

3.3 发现

redis-cli --bigkey命令：给出每种数据结构top 1 bigkey。同时给出每种数据类型的键值个数＋平均大小

缺点：想查询大于10kb的所有key，--bigkeys参数就无能为力了，需要用到memory usage来计算每个键值的字节数

redis-cli --bigkeys -a 111111
redis-cli -h 127.0.0.1 -p 6379 -a 111111 --bigkeys

#加上 -i 参数，每隔100 条 scan指令就会休眠0.1s.ops就不会剧烈抬升，但是扫描的时间会变长
redis-cli -h 127.0.0.1 -p 7001 --bigkeys -i 0.1

计算每个键值的字节数

memory usage key

4. 大key如何删除

普通命令

string: 一般用del，如果过于庞大使用unlink key 删除
hash: 使用hscan每次获取少量field-value，再使用hdel删除每个field
list：使用ltrim渐进式逐步删除，直到全部删除完成
set：使用sscan每次获取部分元素，在使用srem命令删除每个元素
zset：使用zscan每次获取部分元素，在使用zremrangebyrank命令删除每个元素

5.bigkey生产调优

分割bigkey：将一个大的key分割成多个小的key，例如将一个大的hash分割成多个小的hash。
清理bigkey：对于不再需要的bigkey，可以直接删除。在redis 4.0及以上版本，可以使用unlink命令异步删除key，避免阻塞。
监控内存：设置内存使用率的监控阈值，提前发现潜在的bigkey问题。
定期清理失效数据：对于存储大量数据的key，定期清理过期或无效数据。
使用合适的数据结构：避免不必要的复杂数据结构，或者使用更高效的数据结构来减少内存占用

redis.conf配置文件 lazy freeing相关说明

阻塞和非阻塞删除命令

优化配置

lazyfree-lazy-eviction：当 redis 内存达到阈值 maxmemory 时，将执行内存淘汰
lazyfree-lazy-expire：当设置了过期 key 的过期时间到了，将删除 key
lazyfree-lazy-server-del：这种主要用户提交 del 删除指令
replica-lazy-flush：主要用于复制过程中，全量同步的场景，从节点需要删除整个 db
lazyfree-lazy-user-del:修改del命令的默认行为，使之与unlink命令一样

在处理bigkey时，应该尽量避免在主节点上进行大规模的扫描或删除操作，以免影响线上服务。

可以考虑在从节点上进行这些操作，或者在业务低峰期进行。