学会这几个技巧,让 Redis 大 key 问题远离你

标签: 技巧 redis key | 发表时间:2019-09-28 17:47 | 作者:jack
出处:https://www.diycode.cc/

个推作为国内第三方推送市场的早期进入者,专注于为开发者提供高效稳定的推送服务,经过9年的积累和发展,服务了包括新浪、滴滴在内的数十万APP。由于我们推送业务对并发量、速度要求很高,为此,我们选择了高性能的内存数据库Redis。然而,在实际业务场景中我们也遇到了一些Redis大key造成的服务阻塞问题,因此积累了一些应对经验。本文将对大key的发现、解决大key删除造成的阻塞做相应的介绍。

Redis大key的一些场景及问题

大key场景

Redis使用者应该都遇到过大key相关的场景,比如:
1、热门话题下评论、答案排序场景。
2、大V的粉丝列表。
3、使用不恰当,或者对业务预估不准确、不及时进行处理垃圾数据等。

大key问题

由于Redis主线程为单线程模型,大key也会带来一些问题,如:
1、集群模式在slot分片均匀情况下,会出现数据和查询倾斜情况,部分有大key的Redis节点占用内存多,QPS高。

2、大key相关的删除或者自动过期时,会出现qps突降或者突升的情况,极端情况下,会造成主从复制异常,Redis服务阻塞无法响应请求。大key的体积与删除耗时可参考下表:

key类型
field数量
耗时
Hash
~100万
~1000ms
List
~100万
~1000ms
Set
~100万
~1000ms
Sorted Set
~100万
~1000ms

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

redis-rdb-tools工具

关于rdb工具的详细介绍请查看链接 https://github.com/sripathikrishnan/redis-rdb-tools,在此只介绍内存相关的使用方法。基本的命令为 rdb -c memory dump.rdb (其中dump.rdb为Redis实例的rdb文件,可通过bgsave生成)。

输出结果如下:
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element
0,hash,hello1,1050,ziplist,86,22,
0,hash,hello2,2517,ziplist,222,8,
0,hash,hello3,2523,ziplist,156,12,
0,hash,hello4,62020,hashtable,776,32,
0,hash,hello5,71420,hashtable,1168,12,

可以看到输出的信息包括数据类型,key、内存大小、编码类型等。Rdb工具优点在于获取的key信息详细、可选参数多、支持定制化需求,结果信息可选择json或csv格式,后续处理方便,其缺点是需要离线操作,获取结果时间较长。

redis-cli --bigkeys命令

Redis-cli --bigkeys是redis-cli自带的一个命令。它对整个redis进行扫描,寻找较大的key,并打印统计结果。

例如redis-cli -p 6379 --bigkeys

Scanning the entire keyspace to find biggest keys as well as

average sizes per key type. You can use -i 0.1 to sleep 0.1 sec

per 100 SCAN commands (not usually needed).

[00.72%] Biggest hash found so far 'hello6' with 43 fields
[02.81%] Biggest string found so far 'hello7' with 31 bytes
[05.15%] Biggest string found so far 'hello8' with 32 bytes
[26.94%] Biggest hash found so far 'hello9' with 1795 fields
[32.00%] Biggest hash found so far 'hello10' with 4671 fields
[35.55%] Biggest string found so far 'hello11' with 36 bytes

-------- summary -------

Sampled 293070 keys in the keyspace!
Total key length in bytes is 8731143 (avg len 29.79)

Biggest string found 'hello11' has 36 bytes
Biggest hash found 'hello10' has 4671 fields

238027 strings with 2300436 bytes (81.22% of keys, avg size 9.66)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
55043 hashs with 289965 fields (18.78% of keys, avg size 5.27)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

我们可以看到打印结果分为两部分,扫描过程部分,只显示了扫描到当前阶段里最大的key。summary部分给出了每种数据结构中最大的Key以及统计信息。

redis-cli --bigkeys的优点是可以在线扫描,不阻塞服务;缺点是信息较少,内容不够精确。扫描结果中只有string类型是以字节长度为衡量标准的。List、set、zset等都是以元素个数作为衡量标准,元素个数多不能说明占用内存就一定多。

自定义Python扫描脚本

通过strlen、hlen、scard等命令获取字节大小或者元素个数,扫描结果比redis-cli --keys更精细,但是缺点和redis-cli --keys一样,不赘述。

总之,之前的方法要么是用时较长离线解析,或者是不够详细的抽样扫描,离理想的以内存为维度的在线扫描获取详细信息有一定距离。由于在redis4.0前,没有lazy free机制;针对扫描出来的大key,DBA只能通过hscan、sscan、zscan方式渐进删除若干个元素;但面对过期删除键的场景,这种取巧的删除就无能为力。我们只能祈祷自动清理过期key刚好在系统低峰时,降低对业务的影响。

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

下面我们从源码(摘自Redis 5.0.4版本)来理解memory usage和lazyfree的特点。

memory usage

{"memory",memoryCommand,-2,"rR",0,NULL,0,0,0,0,0}
(server.c 285⾏)

void memoryCommand(client c) {
/
... /
/
计算key大小是通过抽样部分field来估算总大小。 /
else if (!strcasecmp(c->argv[1]->ptr,"usage") && c->argc >= 3) {
size_t usage = objectComputeSize(dictGetVal(de),samples);
/
...*/
}
}
(object.c 1299⾏)

从上述源码看到memory usage是通过调用objectComputeSize来计算key的大小。我们来看objectComputeSize函数的逻辑。

define OBJ_COMPUTE_SIZE_DEF_SAMPLES 5 /* Default sample size. */

size_t objectComputeSize(robj o, size_t sample_size) {
/
...代码对数据类型进行了分类,此处只取hash类型说明 /
/
... /
/
循环抽样个field,累加获取抽样样本内存值,默认抽样样本为5*/
while((de = dictNext(di)) != NULL && samples < sample_size) {
ele = dictGetKey(de);
ele2 = dictGetVal(de);
elesize += sdsAllocSize(ele) + sdsAllocSize(ele2);
elesize += sizeof(struct dictEntry);
samples++;
}
dictReleaseIterator(di);
/ 根据上一步计算的抽样样本内存值除以样本量,再乘以总的filed个数计算总内存值/
if (samples) asize += (double)elesize/samples*dictSize(d);
/ .../
}
(object.c 779⾏)

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

我们可以通过Python脚本在集群低峰时扫描Redis,用较小的代价去获取所有key的内存大小。以下为部分伪代码,可根据实际情况设置大key阈值进行预警。

for key in r.scan_iter(count=1000):
redis-cli = '/usr/bin/redis-cli'
configcmd = '%s -h %s -p %s memory usage %s' % (redis-cli, rip,rport,key)
keymemory = commands.getoutput(configcmd)

lazyfree机制

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

/* Background job opcodes */

define BIO_LAZY_FREE 2 /* Deferred objects freeing. */

(bio.h 38⾏)

下面我们以unlink命令为例,来理解lazyfree的实现原理。

{"unlink",unlinkCommand,-2,"wF",0,NULL,1,-1,1,0,0},
(server.c 137⾏)

void unlinkCommand(client *c) {
delGenericCommand(c,1);
}
(db.c 490⾏)

通过这几段源码可以看出del命令和unlink命令都是调用delGenericCommand,唯一的差别在于第二个参数不一样。这个参数就是异步删除参数。

/* This command implements DEL and LAZYDEL. /
void delGenericCommand(client *c, int lazy) {
/
... /
int deleted = lazy ? dbAsyncDelete(c->db,c->argv[j]) :
dbSyncDelete(c->db,c->argv[j]);
/
...*/
}
(db.c 468⾏)

可以看到delGenericCommand函数根据lazy参数来决定是同步删除还是异步删除。当执行unlink命令时,传入lazy参数值1,调用异步删除函数dbAsyncDelete。否则执行del命令传入参数值0,调用同步删除函数dbSyncDelete。我们重点来看异步删除dbAsyncDelete的实现逻辑:

define LAZYFREE_THRESHOLD 64

/ 定义后台删除的阈值,key的元素大于该阈值时才真正丢给后台线程去删除/
int dbAsyncDelete(redisDb db, robj *key) {
/
... /
/*lazyfreeGetFreeEffort来获取val对象所包含的元素个数
/
size_t free_effort = lazyfreeGetFreeEffort(val);

/* 对删除key进行判断,满足阈值条件时进行后台删除 /
if (free_effort > LAZYFREE_THRESHOLD && val->refcount == 1) {
atomicIncr(lazyfree_objects,1);
bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL);
/
将删除对象放入BIO_LAZY_FREE后台线程任务队列 /
dictSetVal(db->dict,de,NULL);
/
将第一步获取到的val值设置为null*/
}
/ .../
}
(lazyfree.c 53⾏)

上面提到了当删除key满足阈值条件时,会将key放入BIO_LAZY_FREE后台线程任务队列。接下来我们来看BIO_LAZY_FREE后台线程。

/ .../
else if (type == BIO_LAZY_FREE) {
if (job->arg1)
/* 后台删除对象函数,调用decrRefCount减少key的引用计数,引用计数为0时会真正的释放资源 /
lazyfreeFreeObjectFromBioThread(job->arg1);
else if (job->arg2 && job->arg3)
/
后台清空数据库字典,调用dictRelease循环遍历数据库字典删除所有key /
lazyfreeFreeDatabaseFromBioThread(job->arg2,job->arg3);
else if (job->arg3)
/
后台删除key-slots映射表,在Redis集群模式下会用*/
lazyfreeFreeSlotsMapFromBioThread(job->arg3);
}
(bio.c 197⾏)

unlink命令的逻辑可以总结为:执行unlink调用delGenericCommand函数传入lazy参数值1,来调用异步删除函数dbAsyncDelete,将满足阈值的大key放入BIO_LAZY_FREE后台线程任务队列进行异步删除。类似的后台删除命令还有flushdb async、flushall async。它们的原理都是获取删除标识进行判断,然后调用异步删除函数emptyDbAsnyc来清空数据库。这些命令具体的实现逻辑可自行查看flushdbCommand部分源码,在此不做赘述。

除了主动的大key删除和数据库清空操作外,过期key驱逐引发的删除操作也会阻塞Redis服务。因此Redis4.0除了增加上述三个后台删除的命令外,还增加了4个后台删除配置项,分别为slave-lazy-flush、lazyfree-lazy-eviction、lazyfree-lazy-expire和lazyfree-lazy-server-del。

slave-lazy-flush:slave接收完RDB文件后清空数据选项。建议大家开启slave-lazy-flush,这样可减少slave节点flush操作时间,从而降低主从全量同步耗时的可能性。
lazyfree-lazy-eviction:内存用满逐出选项。若开启此选项可能导致淘汰key的内存释放不够及时,内存超用。
lazyfree-lazy-expire:过期key删除选项。建议开启。
lazyfree-lazy-server-del:内部删除选项,比如rename命令将oldkey修改为一个已存在的newkey时,会先将newkey删除掉。如果newkey是一个大key,可能会引起阻塞删除。建议开启。

上述四个后台删除相关的参数实现逻辑差异不大,都是通过参数选项进行判断,从而选择是否采用dbAsyncDelete或者emptyDbAsync进行异步删除。

总结
在某些业务场景下,Redis大key的问题是难以避免的,但是,memory usage命令和lazyfree机制分别提供了内存维度的抽样算法和异步删除优化功能,这些特性有助于我们在实际业务中更好的预防大key的产生和解决大key造成的阻塞。关于Redis内核的优化思路也可从Redis作者Antirez的博客中窥测一二,他提出"Lazy Redis is better Redis"、"Slow commands threading"(允许在不同的线程中执行慢操作命令),异步化应该是Redis优化的主要方向。

Redis作为个推消息推送的一项重要的基础服务,性能的好坏至关重要。个推将Redis版本从2.8升级到5.0后,有效地解决了部分大key删除或过期造成的阻塞问题。未来,个推将会持续关注Redis 5.0及后续的Redis 6.0,与大家共同探讨如何更好地使用Redis。

参考文档:
1、 http://antirez.com/news/93
2、 http://antirez.com/news/126

相关 [技巧 redis key] 推荐:

学会这几个技巧,让 Redis 大 key 问题远离你

- - DiyCode - 致力于构建开发工程师高端交流分享社区社区
个推作为国内第三方推送市场的早期进入者,专注于为开发者提供高效稳定的推送服务,经过9年的积累和发展,服务了包括新浪、滴滴在内的数十万APP. 由于我们推送业务对并发量、速度要求很高,为此,我们选择了高性能的内存数据库Redis. 然而,在实际业务场景中我们也遇到了一些Redis大key造成的服务阻塞问题,因此积累了一些应对经验.

使用key/value数据库redis和TTSERVER的体会

- - 开源软件 - ITeye博客
redis是一个类似memcached的key/value存储系统,它支持存储的value类型相对较多,包括string(字符串)、 list(链表)、set(集合)和zset(有序集合). 在此基础上,redis支持各种不同方式的排序. 与memcached一样,为了保证效率,数据都是缓存在内存中.

Redis 下key的过期时间详解 :expire

- - zzm
memcached 和 redis 的set命令都有expire参数,可以设置key的过期时间. 但是redis是一个可以对数据持久化的key-value database,它的key过期策略还是和memcached有所不同的. redis通过expire命令来设置key的过期时间. 语法:redis.expire(key, expiration).

Redis 大数据量(百亿级)Key存储需求及解决方案

- - 掘金 架构
最近我在思考实时数仓问题的时候,想到了巨量的redis的存储的问题,然后翻阅到这篇文章,与各位分享. 该应用场景为DMP缓存存储需求,DMP需要管理非常多的第三方id数据,其中包括各媒体cookie与自身cookie(以下统称supperid)的mapping关系,还包括了supperid的人口标签、移动端id(主要是idfa和imei)的人口标签,以及一些黑名单id、ip等数据.

Redis监控技巧

- - NoSQLFan
本文来自 Bugsnag的联合创始人 Simon Maynard的系列文章,作者根据几年来对 Redis的使用经历,对Redis 监控方法进行了系统性的总结,干货很多,值得一看. 原文链接: Redis Masterclass – Part 2, Monitoring. Redis 监控最直接的方法当然就是使用系统提供的 info 命令来做了,你只需要执行下面一条命令,就能获得 Redis 系统的状态报告.

10 个 Redis 建议/技巧

- - 外刊IT评论
Redis 在当前的技术社区里是非常热门的. 从来自 Antirez 一个小小的个人项目到成为内存数据存储行业的标准,Redis已经走过了很长的一段路. 随之而来的一系列最佳实践,使得大多数人可以正确地使用 Redis. 下面我们将探索正确使用 Redis 的10个技巧. Okay,以挑战这个命令开始这篇文章,或许并不是一个好的方式,但其确实可能是最重要的一点.

镀金键盘帽:Gold Key

- Paul - 爱…稀奇~{新鲜:科技:创意:有趣}
传统上而言,判断一个人是不是暴发户,最主要不是看小三的数量,也不是看有没有玛莎拉蒂,最重要的是——看他有没有一颗金牙. 这在改革刚开放那会,一颗金灿灿的门牙,简直就是“老子很有钱”的代名词,可比名片管用多了~. 所以,从这个角度而言,如果你怀念着那个光辉的时代,并想给自己来点后现代的色彩,那么,一颗镀金键盘帽(Gold Key)就是必须的了~4美元一颗,这里有售:chihapaura.com,用来替换自己键盘上的数字“4”,那“仇恨”吸得,我kao,即便是美美也不过如是啊.

mysql中的ON DUPLICATE KEY UPDATE

- - haohtml's blog
INSERT INTO ON DUPLICATE KEY UPDATE 与 REPLACE INTO,两个命令可以处理重复键值问题,在实际上它之间有什么区别呢. 前提条件是这个表必须有一个唯一索引或主键. 1、REPLACE发现重复的先删除再插入,如果记录有多个字段,在插入的时候如果有的字段没有赋值,那么新插入的记录这些字段为空.

10 个很多人不知道的 Redis 使用技巧

- - DockOne.io
【编者的话】Redis 在当前的技术社区里是非常热门的. 从来自 Antirez 一个小小的个人项目到成为内存数据存储行业的标准,Redis已经走过了很长的一段路. 随之而来的一系列最佳实践,使得大多数人可以正确地使用 Redis. 下面我们将探索正确使用 Redis 的10个技巧. 1、停止使用 KEYS *.

Tair: 淘宝的key/value解决方案

- duxin - 若海的blog
今天我们对外开源了Tair,Tair是由淘宝开发的key/value解决方案,你可以在这里获取更多信息. Tair在淘宝有着大规模的应用,在你登录淘宝、查看商品详情页面、在淘江湖和好友“捣浆糊”等等时候,后面都在直接或间接的和Tair交互. Tair是一个分布式的key/value结构数据的解决方案,系统默认支持基于内存和文件的存储引擎,对应于通常我们所说的缓存和持久化存储.