Redis删除大key和大value问题

1个大小200MB的String键(String Object最大512MB)，内存空间占用较大；1个包含100000000(1kw)个字段的Hash键，对应访问模式(如hgetall)时间复杂度高

==测试 del 200MB String键耗时约1毫秒，而删除一个含有1kw个字段的Hash键，却会阻塞Redis进程数十秒==

在Redis集群中，应用程序尽量避免使用大键；直接影响容易导致集群的容量和请求出现”倾斜问题“

如果已经有大key了， 直接删除它，DEL命令可能阻塞Redis进程数十秒，对应用程序和Redis集群可用性造成严重的影响

一、直接删除大Key的风险

生产环境中遇到过多次因业务删除大Key，导致Redis阻塞，出现故障切换和应用程序雪崩的故障。测试删除集合类型大Key耗时，一般每秒可清理100w~数百w个元素; 如果数千w个元素的大Key时，会导致Redis阻塞上10秒可能导致集群判断Redis已经故障，出现故障切换；或应用程序出现雪崩的情况

Redis是单线程处理。单个耗时过大命令，导致阻塞其他命令，容易引起应用程序雪崩或Redis集群发生故障切换。所以避免在生产环境中使用耗时过大命令。

Redis删除大的集合键的耗时, 测试估算，可参考；和硬件环境、Redis版本和负载等因素有关

二、如何优雅地删除各类大Key

从Redis2.8版本开始支持SCAN命令，通过m次时间复杂度为O(1)的方式，遍历包含n个元素的大key.这样避免单个O(n)的大命令，导致Redis阻塞。 这里删除大key操作的思想也是如此。

==整体思路==

1. 通过各自数据类型提供出来的scan每次扫描固定量级，比如500个
2. 遍历这个500个 一次一个一个的调用删除动作

三、Redis Lazy Free

应该从3.4版本开始，Redis会支持==lazy delete free==的方式，删除大键的过程不会阻塞正常请求。

感兴趣的自己研究下~

四、禁用长耗时的查询命令

　　Redis绝大多数的读写命令的时间复杂度都是在O(1)到O(N)之间，其中O(1)就可以放心使用，但是O(N)就要当心了，因为N表示不确定性，数据越大，查询的速度就会越慢，因为Redis只用一个线程来做数据查询，如果这些指令非常耗时，就会造成Redis的阻塞，那么就会造成大量的延时。

要避免O(N)类的命令对Redis性能造成的影响，就要从以下几个方面进行改造： 　　1、禁止使用key * 命令； 2、避免一次查询所有成员，要使用 scan 命令进行分批的、游标式的遍历 3、通过机制严格空指Hset、Set、Scorted Set 等数据结构的大小 4、将排序、并集、交集等操作放在客户端执行，以减少Redis服务器的运行压力 5、删除一个大的数据时，可能会需要很长的时间，所以建议用异步删除的方式unlink，他会启动一个新的线程来删除目标数据，而不是阻塞Redis主线程。

了解

一个正常规模的表并精简高频字段的用户表存储reids数据量 实际观察过一个9700多用户的表用string存 大概消耗7~8M内存 如果改为hashtable存9700多用户 大概消耗8~9M内存，比string略多一点点

版权属于：dingzhenhua

本文链接：https://cloud.tencent.com/developer/article/2019333

转载时须注明出处及本声明