浅析Redis的BigKey(阿里巴巴技术协会ATA同步发送)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了浅析Redis的BigKey(阿里巴巴技术协会ATA同步发送)相关的知识,希望对你有一定的参考价值。

参考技术A 在完成事件接入的需求时,我们需要记录上一个批次拉取的事件,并与当前拉取到的事件做出比对,从而进行差分。我们目前的做法是使用redis来进行缓存:将上一个批次拉取到的事件缓存到一个list中。但是当事件数量过多时,value的大小会超过1M的限制,直接抛出异常。这其实是Tair出于性能的考虑而做出的限制,本文将谈谈我个人对于bigKey的理解。

顾名思义,bigKey指一个key对应的value占据的内存空间相对比较大,bigKey通常会有两种表现形式:

bigKey一旦产生,将会对tair的性能以及稳定性造成较大的影响,下面我将详细介绍一下bigKey的危害。

bigKey给tair带来的危害是多方面的,性能下降只是其中的一方面,极端情况下,bigKey甚至会导致缓存服务崩溃。下面我将从几个角度进行分析。

我们可以看到:

另外,在Redis执行异步重写操作时(bgrewriteaof),主线程会fork出一个子进程来执行重写命令,这个子进程会与主线程共享内存。当主线程收到了新增或者修改一个key的命令,主线程会申请一块额外的内存空间来保存数据。但如果这个key是一个bigKey时,主线程会去申请一块更大空间,同样会阻塞主线程(与JVM分配内存一样,涉及锁和同步)。如果申请不到足够的空间,会导致Swap甚至会有OOM的风险,这同样会降低Redis的性能和稳定性。

Tair中一个key最大为1M,我们就以1M举例,当访问这个key的QPS为1000时,每秒将会有1GB左右的流量,对于带宽来说将是一个较大压力。如果这个bigKey是一个热点key时,后果将不堪设想。

如果主从同步的 client-output-buffer-limit 设置过小,并且 master 存在大量bigKey(数据量很大),主从全量同步时可能会导致 buffer 溢出,溢出后主从全量同步就会失败。如果主从集群配置了哨兵,那么哨兵会让 slave 继续向 master 发起全量同步请求,然后 buffer 又溢出同步失败,如此反复,会形成复制风暴,这会浪费 master 大量的 CPU、内存、带宽资源,也会让 master 产生阻塞的风险。 另外,当我们使用Redis Cluster时,由于Redis Cluster采用了同步迁移的方式,bigKey同样会阻塞主线程。这里提一下Codis,Codis在迁移bigKey时,使用了异步迁移 + 指令拆分的方式,对于bigKey (集合类型) 中每个元素,用一条指令进行迁移,而不是把整个 bigKey 进行序列化后再整体传输。这种化整为零的方式,就避免了 bigKey 迁移时,因为要序列化大量数据而阻塞的问题。

当我们写入或者读取大量bigKey的时候,很有可能导致输入/输出缓冲区溢出。如果客户端占用的内存总量超过了服务器设置的maxmemory时(默认4GB),将会直接触发服务器的内存淘汰策略,如果有数据被淘汰,再要获取这些数据就需要到后端回源,间接降低了缓存系统的性能。同时,淘汰的如果是bigKey也同样会阻塞主线程。另外,在极端情况下,多个客户端占用了过多的内存将导致OOM,进而使得整个redis进程崩溃。

使用切片集群的时候,我们通常会将不同的key存放在不同的实例上,如果存在bigKey的话,会导致相应实例的数据量增大,内存压力也相应增大。

常用的做法是通过./redis-cli --bigkeys命令对整个redis中的键值对进行统计,输出每种数据类型中最大的 bigkey 的信息。一般会配合-i参数一起使用,控制扫描间隔,避免长时间扫描降低 Redis 实例的性能。另外该命令不要在业务高峰期使用。

或者我们可以通过debug object key 命令去查看serializedlength属性,serializedlength表示key对应的value序列化后的字节数,通过观察serializedlength的大小可以辅助排查bigKey。使用scan + debug object key命令,我们可以计算其中每个key的serializedlength,进而发现其中的bigKey,并做好相应的监控和处理。不过对于集合类型的bigKey,debug object key 命令的执行效率不高,存在阻塞redis的风险。

另外,在读取bigKey的时候,我们尽量不要一次性将全部数据读取出来,而是采用分批的方式进行读取:利用scan命令进行渐进式遍历,将大量数据分批多次读取出来,减小redis的压力,避免阻塞的风险。
同样的,在删除bigKey的时候我们也可以使用scan命令来进行批量删除。如果你是用的redis是4.0之后的版本,则可以利用unlink命令配合lazy free配置(需要手动开启)来进行异步删除,避免主线程阻塞。

阿里推荐的Redis使用规范,Redis就要这么用

一、键值设计

1、key名设计

可读性和可管理性

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

技术图片

简洁性

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

技术图片

不要包含特殊字符

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

2、value设计

拒绝bigkey

防止网卡流量、慢查询,string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

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

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

选择适合的数据类型

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

反例:

技术图片

正例:

技术图片

控制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以内,实际也和元素字节数有关)。

注意两者不同:

原生是原子操作,pipeline是非原子操作。

pipeline可以打包不同的命令,原生做不到

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 arrayrn" 2、所有key,必须在1个slot上,否则直接返回error, "-ERR eval/evalsha command keys must in same slotrn"

7、monitor命令

必要情况下使用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只响应读操作。

四、相关工具

1、数据同步

redis间数据同步可以使用:redis-port

2、big key搜索

redis大key搜索工具

3、热点key寻找

内部实现使用monitor,所以建议短时间使用facebook的redis-faina 阿里云Redis已经在内核层面解决热点key问题

五、删除bigkey

下面操作可以使用pipeline加速。

redis 4.0已经支持key的异步删除,欢迎使用。

1、Hash删除: hscan + hdel

技术图片

2、List删除: ltrim

技术图片

3、Set删除: sscan + srem

技术图片

4、SortedSet删除: zscan + zrem

技术图片

 



以上是关于浅析Redis的BigKey(阿里巴巴技术协会ATA同步发送)的主要内容,如果未能解决你的问题,请参考以下文章

redis架构模式(6)数据倾斜

Redis中的BigKey问题:排查与解决思路

java 删除的Redis中的bigKey

Redis中的BigKey问题:排查与解决思路

rdbtools分析redis bigkey

redis开发规范阿里云