目录
一、Redis键值设计
1、优雅的key结构
2、BigKey问题
什么是BigKey
BigKey的危害
如何发现BigKey
如何删除BigKey
3、恰当的数据类型
二、批处理优化
1、Pipeline
大量数据导入的方式
MSET
Pipeline
2、集群下的批处理
三、服务端优化
1、持久化配置
2、慢查询
3、命令及安全配置
4、内存配置
四、集群最佳实践
1、集群完整性问题
2、集群带宽问题
3、集群还是主从
Redis的Key虽然可以自定义,但是最好遵循下面的几个最佳实践约定:
遵循基本的格式: [业务名称]:[数据名]:[id] ,长度不超过44字节,不包含特殊字符
优点:
可读性强、避免key冲突、方便管理
BigKey指以Key的大小和Key中成员的数量来综合判定
推荐:
网络堵塞:少量的QPS就可能导致带宽使用率被占满,导致Redis实例,乃至物理机变慢
数据倾斜:bigkey所在的redis内存使用率远远超过其他实例,无法让数据分片的内存资源达到均衡
Redis阻塞:对元素较多的hash、list、zset等做运算会耗时较久,使主线程被阻塞
CPU压力:对bigKey数据序列化和反序列化会导致cpu使用率飙升,影响redis实例
BigKey内存占用较多,即便是删除都很耗时,导致redis主线程堵塞,引发一些列问题
redis 3.0以下版本
如果是集合类型,则遍历BigKey(扫描)的元素,先逐个删除子元素,最后删除bigKey
redis4.0以后提供了异步删除的命令:unlink
假如有hash类型的key,其中100万对feiid和value,feild是自增id,这个key什么问题怎么优化?
存在问题:
hash的entry数量超过500时,会使用哈希表而不是ziplist,内存占用较多
可以通过hash-max-ziplist-entries配置entry上限调大,但是如果entry过多会导致bigkey问题
优化方案
我们可以把hash打散的方式来优化
网络传输耗时相对来说是非常大的,所以我们要尽量避免多次请求
Redis提供了很多Mxxx这样的命令,可以实现批量插入数据
利用mset批量插入10万条数据:
注意:不要一次批处理中传输太多命令,否则单词命令占用带宽过多,会导致网络堵塞
MSET虽然可以批处理,但是却只能操作部分数据类型,有复杂数据类型的批处理需要,建议使用Pipeline功能:
Piepline是没有数据类型限制的可以任意做组合
但是Piepline的多个命令之间不像mset多条命令原子性,中间可能有其他代码执行,所以速度相对会比较慢
如MSET或Piepline这样的批处理需要一次请求中携带多条命令,而此时如果Redis是一个集群,那批处理命令的多个key必须落在一个插槽中,否则就会导致执行失败
其实当我们要实现集群下批处理的时候,直接使用spring提供的stringRedisTemplate就行,底层已经帮我们封装好了
底层是异步执行的并行的方式,第三种,性能最好的一种
Redis持久化虽然可以保证数据安全,但也会带来很多额外开销,因此持久化要遵循以下建议:
部署建议:
redis实例的物理机要预留足够内存来应付fork(可能内存翻倍)和rewrite(重写也要读取内存)
单个redis实例内存上限不要太大。可以加快fork(如果单节点过大,要同步更多数据)的速度、减小主从同步、数据迁移压力
不要与cpu密集型应用部署一起
不要与高硬盘负载应用一起部署(因为重写也要大量io也会影响性能)
慢查询:redis执行耗时超过某个阈值的命令
redis是单线程的,每次命令进来就会进入队列,如果执行慢查询,后面的都可能等待过久超时,所以我们解决掉慢查询
慢查询的阈值可以配置指定:
slowlog-log-slower-than:慢查询阈值,单位微妙。默认是10000,建议1000
慢查询会被放入慢查询日志中,日志长度有上限,可以配置:
slowlog-max-len:慢查询日志(本质是队列)的长度默认128,建议1000
我们可以用上面的命令找到他,加以分析解决,如果是数据结构问题,我们就选择更优的方案等
Redis会绑定0.0.0.0:6379,这样将redis服务暴露在公网上,而redis如果没有做身份认证,会出现严重安全漏洞, Redis未授权访问配合SSH key文件利用分析 - 腾讯云开发者社区-腾讯云
出现的原因:
为了避免这样漏洞,可以:
当Redis内存不足,可能导致key频繁被删除,响应时间边长,qps不稳定等问题,当内存使用率达到90%就需要警惕,并快速定位到内存占用原因
我们要给普通客户端加上上限,默认都是没有上限,如果发的都是bigkey可能把内存占满
我们同时也要尽可能避免出现bigkey适当增大物理机的带宽
另外两个客户端都是有上限的,所以不用太担心内存溢出
可以通过下面命令看有没有移除:
redis认为有插槽坏了就是有一部分数据丢失,影响数据完整性所以整个集群停止服务
但是我们开发看重可用性,所以不建议开启,部分插槽不可以集群也能服务
集群节点之间会不断相互ping确定其他节点状态,每次ping都包含:插槽信息、集群状态信息
集群中节点越多,集群状态信息数据量越大,10个节点相关信息可能达到1kb,此时每次集群互通需要的带宽会非常高
解决途径:
集群虽然具备高可用性能,能实现自动故障恢复,但是如果使用不当,也会存在一些问题:
单体的redis已经达到百万级别的qps,并且也具备很强的高可用特性,如果主从能满足业务需求的情况下,尽量不搭建redis集群