以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id
trade order:1
保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如
user:{uid}:friends:messages:{mid} 简化为u:{uid}:fr:m:{mid}
反例:包含空格、换行、单双引号以及其他转义字符
在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)可以存储大约40亿个(2^32 -1)个元素,但实际中如果下面两种情况,就会认为是bigkey
非字符串的bigkey,不要用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞)
bigkey的危害:
bigkey的产生:
一般来说,bigkey的产生都是由于程序设计不当,或者对于数据规模预料不清楚造成的,例子如下:
如何优化bigkey
1.拆
biglist: list1、list2、…listN
big hash: 可以将数段分段存储,比如一个大的key,假设存了100万的用户数据,可以拆分成200个key,每个key下面存放5000个用户数据
2.如果bigkey不可避免,也要思考以下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget,而不是hgetall),删除也是一样,尽量使用优雅的方式来处理
例如:实体类型(要合理控制和使用数据结构,但也要注意节省内存和性能之间的平衡)
反例:
set user:1:name tom
set user:1:age 19
set user:1:favor football
正例:
hmset user:1 name tom age 19 favor football
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期)
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替
禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的方式渐进式处理
redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰
原生命令:例如mget、mset
非原生命令:可以使用pipeline提高效率
但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)注意两者不同:
原生命令是原子操作,pipeline是非原子操作
pipeline可以打包不同的命令,原生命令做不到
pipeline需要客户端和服务端同时支持