键值设计
优雅的key结构
Redis的Key虽然可以自定义,但最好遵循下面的几个最佳实践约定:
- 遵循基本格式:[业务名称]:[数据名]:[id]
- 长度不超过44字节
- 不包含特殊字符
例如:我们的登录业务,保存用户信息,其key是这样的:login:user:10
- 可读性强
- 避免key冲突
- 方便管理
- 更节省内存: key是strihg类型,底层编码包含int、embstr和raw三种。embstr在小于44字节使用,采用连续内存空间,内存占用更小
127.0.0.1:6379>set num 123
OK
127.0.0.1:6379> type num
string
127.0.0.1:6379>object encoding num
"int"
127.0.0.1:6379> set name Jack
OK
127.0.0.1:6379> object encoding name
"embstr"
127.0.0.1:6379> type name
string
127.0.0.1:6379>set name aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
"raw"
127.0.0.1:6379>
拒绝BigKey
BigKey通常以Key的大小和Key中成员的数量来综合判定,例如:
- Key本身的数据量过大:一个String类型的Key,它的值为5MB。.
- Key中的成员数过多:一个ZSET类型的Key,它的成员数量为10,000个。
- Key中成员的数据量过大:一个Hash类型的Key,它的成员数量虽然只有1,000个但这些成员的Value(值)总大小为100 MB。
推荐值:
- 单个key的value小于10KB
- 对于集合类型的key,建议元素数量小于1000
BigKey的危害
网络阻塞
- 对BigKey执行读请求时,少量的QPS就可能导致带宽使用率被占满,导致Redis实例,乃至所在物理机变慢
数据倾斜
- BigKey所在的Redis实例内存使用率远超其他实例,无法使数据分片的内存资源达到均衡
Redis阻塞
- 对元素较多的hash、list、zset等做运算会耗时较旧,使主线程被阻塞
CPU压力
- 对BigKey的数据序列化和反序列化会导致CPU的使用率飙升,影响Redis实例和本机其它应用
如何发现BigKey
redis-cli --bigkeys
- 利用redis-cli提供的--bigkevs参数,可以遍历分析所有key,并返回Kev的整体统计信息与每个数据的Top1的big key
scan扫描
- 自己编程,利用scan扫描Redis中的所有key,利用stren、hlen等命令判断key的长度(此处不建议使用MEMORY USAGE)
第三方工具
- 利用第三方工具,如 Redis-Rdb-Tools分析RDB快照文件,全面分析内存使用情况
网络监控
- 自定义工具,监控进出Redis的网络数据,超出预警值时主动告警
如何删除BigKey
BigKey内存占用较多,即便时删除这样的key也需要耗费很长时间,导致Redis主线程阻塞,引发一系列问题。
redis 3.0 及以下版本
- 如果是集合类型,则遍历BigKey的元素,先逐个删除子元素,最后删除BigKey
Redis 4.0以后
- Redis在4.0后提供了异步删除的命令:unlink
恰当的数据结构
假如有hash类型的key,其中有100万对field和value,field是自增id,这个key存在什么问题?如何优化?
拆分为小的hash,将id/100作为key,将id %100 作为field,这样每100个元素为一个Hash
批处理优化
单个命令的执行流程
一次命令的响应时间=1次往返的网络传输耗时+1次Redis执行命令耗时
- 但由于redis执行命令的时间耗时很短,所以一次命令的响应时间就等于一次往返网络传输耗时
N条命令依次执行
- N次命令的响应时间=N次往返的网络传输耗时+N次Redis执行命令耗时
N条命令批量执行
- N次命令的响应时间=1次往返的网络传输耗时+N次Redis执行命令耗时
Redis提供了很多Mxxx这样的命令,可以实现批量插入数据,例如:
- mset
- hmset
Pipeline
MSET虽然可以批处理,但是却只能操作部分数据类型,因此如果有对复杂数据类型的批处理需要,建议使用Pipeline功能:
@Test
void testPipeline(){
//创建管道
Pipeline pipeline =jedis.pipelined();
for(inti=1;i<= 100000;i++){
// 放入命令到管道
pipeline.set("test:key_" +i,"value_"+ i);
if(i% 1000 == 0){/1 每放入1000条命令,批量执行
pipeline.sync();
}
}
}
集群下的批处理
如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令,而此时如果Redis是一个集群,那批处理命令的多个key必须落在一个插槽中,否则就会导致执行失败。
192.168.150.101:7003>mset name jack age 2l sex male
(error)CROsSSLOT Keys in request don't hash to the same slot
192.168.150.101:7003>
服务端优化
持久化配置
Redis的持久化虽然可以保证数据安全,但也会带来很多额外的开销,因此持久化请遵循下列建议:
- 用来做缓存的Redis实例尽量不要开启持久化功能
- 建议关闭RDB持久化功能,使用AOF持久化
- 利用脚本定期在slave节点做RDB,实现数据备份
- 设置合理的rewrite阈值,避免频繁的bgrewrite
- 配置no-appendfsync-on-rewrite=yes,禁止在rewrite期间做aof,避免因AOF引起的阻塞
部署有关建议:
- Redis实例的物理机要预留足够内存,应对fork和rewrite
- 单个Redis实例内存上限不要太大,例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
- 不要与CPU密集型应用部署在一起
- 不要与高硬盘负载应用一起部署。例如:数据库、消息队列
慢查询
慢查询:在Redis执行时耗时超过某个值的命令,称为慢查询。
慢查询的阈值可以通过配置指定:
- slowlog-log-slower-than:慢查询阈值,单位是微秒。默认是10000,建议1000慢查询会被放入慢查询日志中,日志的长度有上限,可以通过配置指定:
- slowlog-max-len:慢查询日志(本质是一个队列)的长度。默认是128,建议1000
127.0.0.1:6379> config get slowlog-max-len
1)"slowlog-max-len"
2)"128"
127.0.0.1:6379> config get slowlog-log-slower-than
1)"sloocag log-slower-than"
2)"1000"
修改这两个配置可以使用:config set命令:
127.0.0.1:6379> config set slowlog-log-slower-than 1000
OK
127.0.0.1:6379> config get slowlog-log-slower-than
1)"slowlog-log-slower-than"
2)"100"
命令及安全配置
Redis会绑定在0.0.0.0:6379,这样将会将Redis服务暴露到公网上,而Redis如果没有做身份认证,会出现严重的安全漏洞
漏洞出现的核心的原因有以下几点:
- Redis未设置密码
- 利用了Redis的config set命令动态修改Redis配置
- 使用了Root账号权限启动Redisipip
为了避免这样的漏洞,这里给出一些建议:
- Redis一定要设置密码
- 禁止线上使用下面命令:keys、flushall、flushdb、config set等命令。可以利用rename-command禁用
- bind:限制网卡,禁止外网网卡访问
- 开启防火墙
- 不要使用Root账户启动Redis
- 尽量不是有默认的端口
内存配置
当Redis内存不足时,可能导致Key频繁被删除、、响应时间变长、QPS不稳定等问题。当内存使用率达到90%以上时就需要我们警惕,并快速定位到内存占用的原因。
Redis提供了一些命令,可以查看到Redis目前的内存分配状态
- info memory
- memory xxx
内存缓冲区常见的有三种:
- 复制缓冲区:主从复制的repl backlog_buf,如果太小可能导致频繁的全量复制,影响性能。通过repl-backlog-size来设置,默认1mb
- AOF缓冲区:AOF刷盘之前的缓存区域,AOF执行rewrite的缓冲区。无法设置容量上限
- 客户端缓冲区:分为输入缓冲区和输出缓冲区,输入缓冲区最大1G且不能设置。输出缓冲区可以设置
Redis优化
在Redis的默认配置中,如果发现任意一个插槽不可用,则整个集群都会停止对外服务:
为了保证高可用特性,这里建议将 cluster-require-full-coverage配置为false
集群带宽问题
集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息至少包括:·
- 插槽信息
- 集群状态信息
集群中节点越多,集群状态信息数据量也越大,10个节点的相关信息可能达到1Kb,此时每次集群互通需要的带宽会非常高。
解决途径:
- 避免大集群,集群节点数不要太多,最好少于1000,如果业务庞大,则建立多个集群。
- 避免在单个物理机中运行太多Redis实例
- 配置合适的cluster-node-timeout值
集群还是主从
集群虽然具备高可用特性,能实现自动故障恢复,但是如果使用不当,也会存在一些问题:
- 集群完整性问题
- 集群带宽问题
- 数据倾斜问题
- 客户端性能问题
- 命令的集群兼容性问题
- lua和事务问题