阿里云的redis规范

  • 阿里云的redis规范已关闭评论
  • 242 人浏览
  • A+
所属分类:最新资讯

一、键值设计

1. key名设计

(1)【建议】: 可读性和可管理性

以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id

(2)【建议】:简洁性

保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:

(3)【强制】:不要包含特殊字符

反例:包含空格、换行、单双引号以及其他转义字符

2. value设计

(1)【强制】:拒绝bigkey(防止网卡流量、慢查询)

string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

反例:一个包含200万个元素的list。

非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会不出现在慢查询中(latency可查)),查找方法和删除方法

(2)【推荐】:选择适合的数据类型。

例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist,但也要注意节省内存和性能之间的平衡)

反例:

正例:

(3)【推荐】:控制key的生命周期,redis不是垃圾桶。

建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注idletime。

二、命令使用

1.【推荐】 O(N)命令关注N的数量

例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。

2.【推荐】:禁用命令

禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的方式渐进式处理。

3.【推荐】合理使用select

redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。

4.【推荐】使用批量操作提高效率

原生命令:例如mget、mset。

非原生命令:可以使用pipeline提高效率。

但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。

注意两者不同:

  1. 原生是原子操作,pipeline是非原子操作。
  2. pipeline可以打包不同的命令,原生做不到
  3. pipeline需要客户端和服务端同时支持。

5.【建议】Redis事务功能较弱,不建议过多使用

Redis的事务功能较弱(不支持回滚),而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)

6.【建议】Redis集群版本在使用Lua上有特殊要求:

1.所有key都应该由 KEYS 数组来传递,redis.call/pcall 里面调用的redis命令,key的位置,必须是KEYS array, 否则直接返回

error,"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array"

2.所有key,必须在1个slot上,否则直接返回

error, "-ERR eval/evalsha command keys must in same slot" 

7.【建议】必要情况下使用monitor命令时,要注意不要长时间使用。

三、客户端使用

1.【推荐】

避免多个应用使用一个Redis实例

正例:不相干的业务拆分,公共数据做服务化。

2.【推荐】

使用带有连接池的数据库,可以有效控制连接,同时提高效率:

3.【建议】

高并发下建议客户端添加熔断功能(例如netflix hystrix)

4.【推荐】

设置合理的密码,如有必要可以使用SSL加密访问(阿里云Redis支持)

5.【建议】

根据自身业务类型,选好maxmemory-policy(最大内存淘汰策略),设置好过期时间。

默认策略是volatile-lru,即超过最大内存后,在过期键中使用lru算法进行key的剔除,保证不过期数据不被删除,但是可能会出现OOM问题。

其他策略如下:

allkeys-lru:根据LRU算法删除键,不管数据有没有设置超时属性,直到腾出足够空间为止。

allkeys-random:随机删除所有键,直到腾出足够空间为止。

volatile-random:随机删除过期键,直到腾出足够空间为止。

volatile-ttl:根据键值对象的ttl属性,删除最近将要过期数据。如果没有,回退到noeviction策略。

noeviction:不会剔除任何数据,拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory",此时Redis只响应读操作。

bigkey

【强制】:拒绝bigkey(防止网卡流量、慢查询)

string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

反例:一个包含200万个元素的list。

非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会出现在慢查询中(latency可查))

一、什么是bigkey

在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)可以存储大约40亿个(2^32-1)个元素,但实际上中如果下面两种情况,我就会认为它是bigkey。

  1. 字符串类型:它的big体现在单个value值很大,一般认为超过10KB就是bigkey。
  2. 非字符串类型:哈希、列表、集合、有序集合,它们的big体现在元素个数太多。

二、危害

bigkey可以说就是Redis的老鼠屎,具体表现在:

1.内存空间不均匀:这样会不利于集群对内存的统一管理,存在丢失数据的隐患。

2.超时阻塞:由于Redis单线程的特性,操作bigkey的通常比较耗时,也就意味着阻塞Redis可能性越大,这样会造成客户端阻塞或者引起故障切换,它们通常出现在慢查询中。

例如,在Redis发现了这样的key,你就等着DBA找你吧。。

127.0.0.1:6379> hlen big:hash(integer) 2000000127.0.0.1:6379> hgetall big:hash1) "a"2) "1"此处省略400万行

3.网络拥塞:

bigkey也就意味着每次获取要产生的网络流量较大,假设一个bigkey为1MB,客户端每秒访问量为1000,那么每秒产生1000MB的流量,对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾,而且一般服务器会采用单机多实例的方式来部署,也就是说一个bigkey可能会对其他实例造成影响,其后果不堪设想。

4.过期删除:

有个bigkey,它安分守己(只执行简单的命令,例如hget、lpop、zscore等),但它设置了过期时间,当它过期后,会被删除,如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes),就会存在阻塞Redis的可能性,而且这个过期删除不会从主节点的慢查询发现(因为这个删除不是客户端产生的,是内部循环事件,可以从latency命令中获取或者从slave节点慢查询发现)。

5.迁移困难:

当需要对bigkey进行迁移(例如Redis cluster的迁移slot),实际上是通过migrate命令来完成的,migrate实际上是通过dump + restore + del三个命令组合成原子命令完成,如果是bigkey,可能会使迁移失败,而且较慢的migrate会阻塞Redis。

三、怎么产生的?

一般来说,bigkey的产生都是由于程序设计不当,或者对于数据规模预料不清楚造成的,来看几个:

(1) 社交类:粉丝列表,如果某些明星或者大v不精心设计下,必是bigkey。

(2) 统计类:例如按天存储某项功能或者网站的用户集合,除非没几个人用,否则必是bigkey。

(3) 缓存类:将数据从数据库load出来序列化放到Redis里,这个方式非常常用,但有两个地方需要注意,第一,是不是有必要把所有字段都缓存,第二,有没有相关关联的数据。

例如我之前遇到过一个例子,该同学将某明星一个专辑下所有视频信息都缓存一个巨大的json中,造成这个json达到6MB,后来这个明星发了一个官宣。。。这个我就不多说了,领盒饭去吧。

四、如何发现

1.redis-cli --bigkeys

redis-cli提供了--bigkeys来查找bigkey,例如下面就是一次执行结果:

-------- summary -------Biggest string found 'user:1' has 5 bytesBiggest list found 'taskflow:175448' has 97478 itemsBiggest set found 'redisServerSelect:set:11597' has 49 membersBiggest hash found 'loginUser:t:20180905' has 863 fieldsBiggest zset found 'hotkey:scan:instance:zset' has 3431 members40 strings with 200 bytes (00.00% of keys, avg size 5.00)2747619 lists with 14680289 items (99.86% of keys, avg size 5.34)2855 sets with 10305 members (00.10% of keys, avg size 3.61)13 hashs with 2433 fields (00.00% of keys, avg size 187.15)830 zsets with 14098 members (00.03% of keys, avg size 16.99)

可以看到--bigkeys给出了每种数据结构的top 1 bigkey,同时给出了每种数据类型的键值个数以及平均大小。

--bigkeys对问题的排查非常方便,但是在使用它时候也有几点需要注意。

  1. 建议在从节点执行,因为--bigkeys也是通过scan完成的。
  2. 建议在节点本机执行,这样可以减少网络开销。
  3. 如果没有从节点,可以使用--i参数,例如(--i 0.1 代表100毫秒执行一次)
  4. --bigkeys只能计算每种数据结构的top1,如果有些数据结构非常多的bigkey,也搞不定,毕竟不是自己写的东西嘛
  5. debug object

再来看一个场景:

你好,麻烦帮我查一下Redis里大于10KB的所有key

您好,帮忙查一下Redis中长度大于5000的hash key

是不是发现用--bigkeys不行了(当然如果改源码也不是太难),但有没有更快捷的方法,Redis提供了debug object ${key}命令获取键值的相关信息:

127.0.0.1:6379> hlen big:hash(integer) 5000000127.0.0.1:6379> debug object big:hashValue at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625559 lru_seconds_idle:2(1.08s)

其中serializedlength表示key对应的value序列化之后的字节数,当然如果是字符串类型,完全看可以执行strlen,例如:

127.0.0.1:6379> strlen key(integer) 947394

这样你就可以用scan + debug object的方式遍历Redis所有的键值,找到你需要阈值的数据了。

但是在使用debug object时候一定要注意以下几点:

(1) debug object bigkey本身可能就会比较慢,它本身就会存在阻塞Redis的可能

(2) 建议在从节点执行

(3) 建议在节点本地执行

(4) 如果不关系具体字节数,完全可以使用scan + strlen|hlen|llen|scard|zcard替代,他们都是o(1)

3 memory usage

上面的debug object可能会比较危险、而且不太准确(序列化后的长度),有没有更准确的呢?Redis 4.0开始提供memory usage命令可以计算每个键值的字节数(自身、以及相关指针开销,具体的细节后面有文章会分析),例如下面是一次执行结果:

127.0.0.1:6379> memory usage big:hash(integer) 318663444

下面我们来对比就可以看出来,当前系统就一个key,总内存消耗是400MB左右,memory usage相比debug object还是要精确一些的。

127.0.0.1:6379> dbsize(integer) 1127.0.0.1:6379> hlen big:hash(integer) 5000000#约300MB127.0.0.1:6379> memory usage big:hash(integer) 318663444#约85MB127.0.0.1:6379> debug object big:hashValue at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625814 lru_seconds_idle:9(1.06s)127.0.0.1:6379> info memory# Memoryused_memory_human:402.16M

如果你使用Redis 4.0+,你就可以用scan + memory usage(pipeline)了,而且很好的一点是,memory不会执行很慢,当然依然是建议从节点 + 本地 。

4.客户端

上面三种方式都有一个问题,就是马后炮,如果想很实时的找到bigkey,一方面你可以试试修改Redis源码,还有一种方式就是可以修改客户端,以jedis为例,可以在关键的出入口加上对应的检测机制,例如以Jedis的获取结果为例子:

protected Object readProtocolWithCheckingBroken() {	Object o = null;	try {		o = Protocol.read(inputStream);		return o;	}catch(JedisConnectionException exc) {		UsefulDataCollector.collectException(exc, getHostPort(), System.currentTimeMillis());		broken = true;		throw exc;	}finally {		if(o != null) {			if(o instanceof byte[]) {				byte[] bytes = (byte[]) o;				if (bytes.length > threshold) {					// 做很多事情,例如用ELK完成收集和展示				}			}		}	}}

5.监控报警

bigkey的大操作,通常会引起客户端输入或者输出缓冲区的异常,Redis提供了info clients里面包含的客户端输入缓冲区的字节数以及输出缓冲区的队列长度,可以重点关注下:

127.0.0.1:6379> info clientsclient_longest_output_list:xxxxxclient_biggest_input_buf:xxxxx

如果想知道具体的客户端,可以使用client list命令来查找

redis-cli client listid=3 addr=127.0.0.1:58500 fd=8 name= age=3978 idle=25 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=26263554 events=r cmd=hgetall

6.改源码

这个其实也是能做的,但是各方面成本比较高,对于一般公司来说不适用。

我个人的最佳实践就是:

(1) Redis端与客户端相结合:--bigkeys临时用、scan长期做排除隐患(尽可能本地化)、客户端实时监控。

(2) 监控报警要跟上

(3) debug object尽量少用

(4) 所有数据平台化

(5) 要和开发同学强调bigkey的危害

五、如何删除

如果发现了bigkey,而且确认是垃圾是不是直接del就可以了,来看一组数据:

可以看到对于string类型,删除速度还是可以接受的。但对于二级数据结构,随着元素个数的增长以及每个元素字节数的增大,删除速度会越来越慢,存在阻塞Redis的隐患。所以在删除它们时候建议采用渐进式的方式来完成:hscan、ltrim、sscan、zscan。

如果你使用Redis 4.0+,一条异步删除unlink就解决,就可以忽略下面内容。

1.字符串:

一般来说,对于string类型使用del命令不会产生阻塞。

del bigkey

2.hash

使用hscan命令,每次获取部分(例如100个)field-value,在利用hdel删除每个field(为了快速可以使用pipeline)。public void delBigHash(String bigKey) {	Jedis jedis = new Jedis("127.0.0.1", 6379);	// 游标	String cursor = "0";	while(true) {		ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan(bigKey, cursor, new ScanParams().count(100));		// 每次扫描后获取新的游标		cursor = scanResult.getStringCursor();		// 获取扫描结果		List<Entry<String, String>> list = scanResult.getResult();		if(list == null || list.size() == 0) {			continue;		}		String[] fields = getFieldsFrom(list);		// 删除多个field		jedis.hdel(bigKey, fields);		// 游标为0时停止		if(cursor.equals("0")) {			break;		}	}	// 最终删除key	jedis.del(bigKey);}/** * 获取field数组 */private String[] getFieldsFrom(List<Entry<String, String>> list) {	List<String> fields = new ArrayList<String>();	for (Entry<String, String> entry : list) {		fields.add(entry.getKey());	}	return fields.toArray(new String[fields.size()]);}

3.list

Redis并没有提供lscan这样的API来遍历列表类型,但是提供了ltrim这样的命令可以渐进式的删除列表元素,直到把列表删除。

public void delBigList(String bigKey) {	Jedis jedis = new Jedis("127.0.0.1", 6379);	long llen = jedis.llen(bigKey);	int counter = 0;	int left = 100;	while(counter < llen) {		// 每次从左侧截掉100个		jedis.ltrim(bigKey, left, llen);		counter += left;	}	// 最终删除key	jedis.del(bigKey);}

4.set

使用sscan命令,每次获取部分(例如100个)元素,在利用srem删除每个元素。

ublic void delBigSet(String bigKey) {	Jedis jedis = new Jedis("127.0.0.1", 6379);	// 游标	String cursor = "0";	while(true) {		ScanResult<String> scanResult = jedis.sscan(bigKey, cursor, new ScanParams().count(100));		// 每次扫描后获取新的游标		cursor = scanResult.getStringCursor();		// 获取扫描结果		List<String> list = scanResult.getResult();		if(list == null || list.size() == 0) {			continue;		}				jedis.srem(bigKey, list.toArray(new String[list.size()]));		// 游标为0时停止		if(cursor.equals("0")) {			break;		}	}	// 最终删除key	jedis.del(bigKey);}

5.sorted set

使用zscan命令,每次获取部分(例如100个)元素,在利用zremrangebyrank删除元素。public void delBigSortedSet(String bigKey) {	long startTime = System.currentTimeMillis();	Jedis jedis = new Jedis(HOST, PORT);	// 游标	String cursor = "0";	while(true) {		ScanResult<Tuple> scanResult = jedis.zscan(bigKey, cursor, new ScanParams().count(100));		// 每次扫描后获取新的游标		cursor = scanResult.getStringCursor();		// 获取扫描结果		List<Tuple> list = scanResult.getResult();		if(list == null || list.size() == 0) {			continue;		}		String[] members = getMembers(list);		jedis.zrem(bigKey, members);		// 游标为0时停止		if(cursor.equals("0")) {			break;		}	}	// 最终删除key	jedis.del(bigKey);}public void delBigSortedSet2(String bigKey) {	Jedis jedis = new Jedis(HOST, PORT);	long zcard = jedis.zcard(bigKey);	int counter = 0;	int incr = 100;	while(counter < zcard) {		jedis.zremrangeByRank(bigKey, 0, 100);		// 每次从左侧截掉100个		counter += incr;	}	// 最终删除key	jedis.del(bigKey);}

六、如何优化

1.拆

big list: list1、list2、...listN

big hash:可以做二次的hash,例如hash%100

日期类:key20190320、key20190321、key_20190322。

2.本地缓存

减少访问redis次数,降低危害,但是要注意这里有可能因此本地的一些开销(例如使用堆外内存会涉及序列化,bigkey对序列化的开销也不小)

7、总结:

由于开发人员对Redis的理解程度不同,在实际开发中出现bigkey在所难免,重要的能通过合理的检测机制及时找到它们,进行处理。作为开发人员应该在业务开发时不能将Redis简单暴力的使用,应该在数据结构的选择和设计上更加合理,例如出现了bigkey,要思考一下可不可以做一些优化(例如二级索引)尽量的让这些bigkey消失在业务中,如果bigkey不可避免,也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget,而不是hgetall),删除也是一样,尽量使用优雅的方式来处理。

本文源自头条号:老鱼谈生

腾讯云双十一活动