redis大key,这里指的是大的集合数据类型,如(set/hash/list/sorted set),一个key包含很多元素。由于redis是单线程,在删除大key(千万级别的set集合)的时候,或者清理过期大key数据时,主线程忙于删除这个大key,会导致redis阻塞、崩溃,应用程序异常的情况。
一个例子
线上redis作为实时去重的一个工具,里面有6千万的用户guid,这么一个set集合,如果直接使用del删除,会导致redis严重阻塞。
1 10.1.254.18:6380> info memory 2 # Memory 3 used_memory:15175740016 4 used_memory_human:14.13G 5 used_memory_rss:22302339072 6 used_memory_peak:22351749192 7 used_memory_peak_human:20.82G 8 used_memory_lua:36864 9 mem_fragmentation_ratio:1.47 10 mem_allocator:jemalloc-3.6.0 11 10.1.254.18:6380> scard helper_2019-03-12 12 (integer) 64530980 13 10.1.254.18:6380> del helper_2019-03-12 14 (integer) 1 15 (81.23s) 16 10.1.254.18:6380> info memory 17 # Memory 18 used_memory:8466985704 19 used_memory_human:7.89G 20 used_memory_rss:10669453312 21 used_memory_peak:22351749192 22 used_memory_peak_human:20.82G 23 used_memory_lua:36864 24 mem_fragmentation_ratio:1.26 25 mem_allocator:jemalloc-3.6.0
可以看到,helper_2019-03-12这个key,是一个包含64530980个元素的集合,直接使用del删除命令,花的时间为:81.23s,在超时时间短的苛刻情况下,显然会发送超时,程序异常!好在,我们用的是连接池,没有出现问题。
分批删除
这种情况,应该使用sscan命令,批量删除set集合元素的方法。下面是一个Java代码分批删除redis中set集合的例子:
对于其它集合,也有对应的方法。
- hash key:通过hscan命令,每次获取500个字段,再用hdel命令;
- set key:使用sscan命令,每次扫描集合中500个元素,再用srem命令每次删除一个元素;
- list key:删除大的List键,未使用scan命令; 通过ltrim命令每次删除少量元素。
- sorted set key:删除大的有序集合键,和List类似,使用sortedset自带的zremrangebyrank命令,每次删除top 100个元素。
使用Python脚本批量删除
对于redis的监控和清理,通常会用一些Python脚本去做,简单、轻便。用java的话,再小的一个任务也要打包、发布,如果没有一套完善的开发、发布的流程,还是比较麻烦的。这时候,很多人倾向于写Python脚本,会Python的大部分人都是会Java的。
这里,还是以删除一个set集合为例:
1 # -*- coding:utf-8 -*- 2 3 import redis 4 5 def test(): 6 # StrictRedis创建连接时,这个连接由连接池管理,所以我们无需关注连接是否需要主动释放 7 re = redis.StrictRedis(host = "0.0.0.0",port = 6379,password = "123") 8 key = "test" 9 for i in range(100000): 10 re.sadd(key, i) 11 12 cursor = ‘0‘ 13 cou = 200 14 while cursor != 0: 15 cursor,data = re.sscan(name = key, cursor = cursor, count = cou) 16 for item in data: 17 re.srem(key, item) 18 print cursor 19 20 if __name__ == ‘__main__‘: 21 test()
后台删除之lazyfree机制
为了解决redis使用del命令删除大体积的key,或者使用flushdb、flushall删除数据库时,造成redis阻塞的情况,在redis 4.0引入了lazyfree机制,可将删除操作放在后台,让后台子线程(bio)执行,避免主线程阻塞。
lazy free的使用分为2类:第一类是与DEL命令对应的主动删除,第二类是过期key删除、maxmemory key驱逐淘汰删除。
主动删除
UNLINK命令是与DEL一样删除key功能的lazy free实现。唯一不同时,UNLINK在删除集合类键时,如果集合键的元素个数大于64个(详细后文),会把真正的内存释放操作,给单独的bio来操作。
127.0.0.1:7000> UNLINK mylist (integer) 1 FLUSHALL/FLUSHDB ASYNC 127.0.0.1:7000> flushall async //异步清理实例数据
被动删除
lazy free应用于被动删除中,目前有4种场景,每种场景对应一个配置参数; 默认都是关闭。
1 lazyfree-lazy-eviction no 2 lazyfree-lazy-expire no 3 lazyfree-lazy-server-del no 4 slave-lazy-flush no
lazyfree-lazy-eviction
针对redis内存使用达到maxmeory,并设置有淘汰策略时;在被动淘汰键时,是否采用lazy free机制;
因为此场景开启lazy free, 可能使用淘汰键的内存释放不及时,导致redis内存超用,超过maxmemory的限制。此场景使用时,请结合业务测试。
lazyfree-lazy-expire
针对设置有TTL的键,达到过期后,被redis清理删除时是否采用lazy free机制;
此场景建议开启,因TTL本身是自适应调整的速度。
lazyfree-lazy-server-del
针对有些指令在处理已存在的键时,会带有一个隐式的DEL键的操作。如rename命令,当目标键已存在,redis会先删除目标键,如果这些目标键是一个big key,那就会引入阻塞删除的性能问题。 此参数设置就是解决这类问题,建议可开启。
slave-lazy-flush
针对slave进行全量数据同步,slave在加载master的RDB文件前,会运行flushall来清理自己的数据场景,
参数设置决定是否采用异常flush机制。如果内存变动不大,建议可开启。可减少全量同步耗时,从而减少主库因输出缓冲区爆涨引起的内存使用增长。
expire及evict优化
redis在空闲时会进入activeExpireCycle循环删除过期key,每次循环都会率先计算一个执行时间,在循环中并不会遍历整个数据库,而是随机挑选一部分key查看是否到期,所以有时时间不会被耗尽(采取异步删除时更会加快清理过期key),剩余的时间就可以交给freeMemoryIfNeeded来执行。
参考链接:
http://mysql.taobao.org/monthly/2018/10/05/
https://blog.csdn.net/liu1390910/article/details/79728569
https://blog.csdn.net/wsliangjian/article/details/52329320
原文地址:https://www.cnblogs.com/data-magnifier/p/redis.html