redis优化指南:网络、内存、磁盘,阻塞点
redis,是基于内存的操作,因此CPU不是redis的性能瓶颈,则服务器的内存利用率、网络IO和磁盘读写是redis的主要性能瓶颈。
所以,接下来我们会从网络、内存、磁盘,阻塞点这四个方向进行优化。如果有相关术语不是很了解,推荐看前几期的redis内容或者翻阅相关资料。
网络优化
如果是客户端请求服务端,也就是“请求-响应”模式下,尽可能的使用批量处理来减少网络IO的开销。
批量处理的技术:原子性m批处理指令、pipline技术、redis、事务,lua脚本。
批处理减少网络IO开销
原子性m批量处理指令:string类型,推荐使用mget/mset代替get/set;hash类型,推荐使用hmget/hmset代替hget/hset。
pipline技术:在使用list、set和zset时有批量操作时可以使用pipeline技术。
redis事务:在特殊业务要求保证多个指令时推荐使用。
lua脚本:在需要保证多条指令原子性时推荐使用lua脚本,具体案例有分布式的解锁、秒杀和减库存。
节点间网络优化
在同一个局域网中搭建集群;
控制切分集群的节点数,redis实例上分配的哈希槽需要在不同实例之间传递,以及负债均衡实例删除时,数据会在不同实例之间传递。但哈希槽信息不大,而数据迁移是渐进式的,但不是主要的问题;
内存优化
控制key的长度:建议开发前先定义好规范,保证key在简单、清晰的前提下,尽可能把key按业务缩写。
杜绝bigkey:string类型的建议大小在20KB以内。hash、list、set和zset建议控制好阈值,推荐控制在5000以内。
key设置过期内:充分利用内存。
选择合适的数据结构
string类型,推荐使用整数型,它底层编码会选择整数型编码,内存开销小;
hash类型,推荐控制元素阈值,元素少时底层会用压缩列表数据结构,内存开销小;list类型,推荐控制元素阈值,元素少时底层会用压缩列表数据结构,内存开销小;set类型,推荐存储整数型,它底层编码会选择整数型编码,内存开销小;
zset类型,推荐控制元素阈值,元素少时底层会用压缩列表数据结构,内存开销小;
数据压缩:客户端在写入redis前可以采用snappy、gzip等压缩算法对数据压缩,减少内存占用,但客户端在读取数据后需要对数据做解压,会消耗更多的CPU。
开启内存淘汰策略
杜绝默认内存淘汰策略,请结合实际业务选择合适的淘汰策略,提高内存的利用率。
LRU:关注于访问次数,淘汰最近最少使用的key,使用场景比较广。redis的LRU采用一种近似LRU的算法,为key增加一个额外字段长度为24bit,为最后一次访问的时间戳。采取懒惰方式处理:当执行写入操作时如果超出最大内存就执行一次LRU淘汰算法,随机采样5(数量可设置)个key,淘汰掉最旧的key,如果淘汰后依旧超出最大内存则继续淘汰。
LFU:关注访问频率,在处理缓存污染时,推荐使用。
内存碎片优化问题
原因:一个是内存分配器的分配策略造成的,内存分配器是按照固定大小分配的,而不是按照实际申请的大小分配的,如申请字节以内,实际分配32字节;另一个是redis键值对删除之后会释放部分空间带来的内存碎片。
定位:通过指令INFO memory来观察men_fragmentation_ratio的指标;指标在1-1.5之间,则属于正常;指标大于1.5,则内存碎片率已经超过了50%,需要处理内存碎片了;
方案:重启redis实例;
开启redis自动内存碎片清理功能。
磁盘优化
物理搭建redis服务:持久化时,redis采用创建子进程的方式进行(会调用操作系统的fork系统),而虚拟机环境执行fork的耗时,要比物理机慢。
持久化优化机制
不开启持久化:redis只做缓存使用,则不需要开启持久化,减少磁盘的开销;
AOF优化:后台处理AOF,配置appenfsync everyec把数据持久化的刷盘操作,放到后台线程中去执行,尽量降低redis写磁盘对性能的影响;
不建高频率的做AOF持久化,AOF持久化默认频率是每秒1次,不建议修改这个配置,它已经能保证最多丢失1s数据了;
开启混合持久化,redis4.0支持混合持久化 RDB+增量的AOF;
开启多线程配置,在redis6.0之前,持久化都是通过主线程fork子进程处理持久化,但是fork都是同步阻塞,6.0之后支持多进程来处理持久化操作;
集群优化
slave做持久优化:master不做持久化,尽可能分摊master磁盘IO的压力;主从优化:增量模式,主从同步方式指定为增量模式,不会选择全量的RDB模式,全模式是一个非常消耗性能;采用级联同步模式,一主多从时,多个salve都来master这里同步数据,会直接拖跨master性能。
对于这个问题,redis支持级联同步的方式,即master只将数据同步给一个salve,然后其他的salve的数据都从这个salve同步,来缓解master压力。
实际大小建议不超过6G。实例太大会在主从同步会有卡顿现象,严重时会拖垮master。
在异常重启时会重放AOF,如果实例过大数据恢复会异常的缓慢。
阻塞点优化
分析:由于Redis处理请求和指令时是单线程,则它的性能瓶颈点是同步阻塞问题。
bigkey问题
危害:读写bigkey可能会导致超时,而redis是单线程操作数据,严重的会导致阻塞整个redis服务。而且一个key只会被分割到一个节点,无法分摊速写压力。bigkey探测:自带命令bredis-cli-bigkeys。redis自带指令,只能找出五种数据类型里最大的key,并没有太大作用,不是很推荐。python扫描脚本。可以定位到具体key,但准确度不高,不推荐。
rdb_bigkeys工具。go写的⼀款⼯具,时间执⾏快且准确度⾼,还可以可直接导出到csv⽂件,⽅便查看,推荐。
优化:对于⾮string类型bigkey,可以对元素集合进⾏分割,拆分成多个,如将⼀个bigkey拆分成1000个key,则key的后缀使⽤hash取模1000。
使用本地缓存,如redis里存放业务id+版本号,将具体内容放在本地缓存,每次查询先查redis缓存,再同本地缓存核对版本号。
优化bigkey一般都是伤筋动谷,推荐开发时就定义好规范,避免bigkey问题。
过期策略
定时删除:每过期key都给一个定时job,到期了就直接删除,内存利用率高,cpu占用高。惰性删除:当查询到key时,才判断key是否过期,如果过期则删除,cpu占用低,内存利用率。定期删除:每隔一段时间扫描一次,过期key直接删除,cpu和我内存利用率一般。
1.贪心策略。redis会将设置为过期key,单独放到一个字典中。
2.扫描过程。从过期字典中挑选出20个key,删除20个key中已过期的key。如果删除的key占比超过了1/4则重复步骤1。
基于以上逻辑为了解决循环过度导致线程卡死的现象,在算法上加上超时时间的机制,默认时间是25ms。
3.扫描频率:redis默认是每秒10次过期扫描。
redis默认是开启惰性删除+定期删除。
优化:开启lazy-free,释放内存的耗时操作,将会放到后台线程中去执行,redis4.0+支持。
开启多线程模式,在redis6.0之前过期策略都是主线程的同步操作,6.0之后采用多线程去处理。
复杂度高指令
推荐使用scan分批次查询,不要使用keys。不适用聚合操作:redis是单线程模型处理请求,在执行复杂度过高的命令(消耗更多CPU资源)时后面的请求会排队导致延迟,如SINTER、SINTERSTORW、ZUNIONSTORE、ZINTERSTORE等。推荐使用scan分批次查出集合中元素,在客户端做聚合计算。
容器类数据操作:当容器类元素非常多时,直接查询会存在由于网络为你导致的延迟,推荐分批次查询。
当容器类元素非常多时,直接删除key时有可能导致redis卡顿,推荐分批次删除。