Redis最佳实践 | 黑马Redis高级篇

目录

一、Redis键值设计

1、优雅的key结构

2、BigKey问题

什么是BigKey

BigKey的危害

如何发现BigKey

如何删除BigKey

3、恰当的数据类型

二、批处理优化

1、Pipeline

大量数据导入的方式

MSET

Pipeline

2、集群下的批处理

三、服务端优化

1、持久化配置

2、慢查询

3、命令及安全配置

4、内存配置

四、集群最佳实践

1、集群完整性问题

2、集群带宽问题

3、集群还是主从


一、Redis键值设计

1、优雅的key结构

Redis的Key虽然可以自定义,但是最好遵循下面的几个最佳实践约定:

遵循基本的格式: [业务名称]:[数据名]:[id] ,长度不超过44字节,不包含特殊字符

优点:

可读性强、避免key冲突、方便管理

2、BigKey问题

什么是BigKey

BigKey指以Key的大小和Key中成员的数量来综合判定

  • Key本身的数据量过大:一个String类型的Key,它的值为5MB
  • Key中的成员数过多:一个ZSET类型的Key,它的成员数量为10000个
  • Key中成员的数据量过大:一个Hash类型的Key,它的成员数量虽然只有1000个但这些成员的Value值总大小为100MB

推荐:

  • 单个key的value小于10KB
  • 对于集合类型的key,建议元素数量小于1000

BigKey的危害

网络堵塞:少量的QPS就可能导致带宽使用率被占满,导致Redis实例,乃至物理机变慢

数据倾斜:bigkey所在的redis内存使用率远远超过其他实例,无法让数据分片的内存资源达到均衡

Redis阻塞:对元素较多的hash、list、zset等做运算会耗时较久,使主线程被阻塞

CPU压力:对bigKey数据序列化和反序列化会导致cpu使用率飙升,影响redis实例

如何发现BigKey

Redis最佳实践 | 黑马Redis高级篇_第1张图片

如何删除BigKey

BigKey内存占用较多,即便是删除都很耗时,导致redis主线程堵塞,引发一些列问题

redis 3.0以下版本

如果是集合类型,则遍历BigKey(扫描)的元素,先逐个删除子元素,最后删除bigKey

redis4.0以后提供了异步删除的命令:unlink

3、恰当的数据类型

Redis最佳实践 | 黑马Redis高级篇_第2张图片

假如有hash类型的key,其中100万对feiid和value,feild是自增id,这个key什么问题怎么优化?

存在问题:

hash的entry数量超过500时,会使用哈希表而不是ziplist,内存占用较多

可以通过hash-max-ziplist-entries配置entry上限调大,但是如果entry过多会导致bigkey问题

优化方案

我们可以把hash打散的方式来优化

Redis最佳实践 | 黑马Redis高级篇_第3张图片

二、批处理优化

1、Pipeline

大量数据导入的方式

Redis最佳实践 | 黑马Redis高级篇_第4张图片

网络传输耗时相对来说是非常大的,所以我们要尽量避免多次请求

Redis最佳实践 | 黑马Redis高级篇_第5张图片

MSET

Redis提供了很多Mxxx这样的命令,可以实现批量插入数据

  • mset(只能处理字符串)
  • hmset(只能处理hash)

利用mset批量插入10万条数据:

Redis最佳实践 | 黑马Redis高级篇_第6张图片

注意:不要一次批处理中传输太多命令,否则单词命令占用带宽过多,会导致网络堵塞

Pipeline

MSET虽然可以批处理,但是却只能操作部分数据类型,有复杂数据类型的批处理需要,建议使用Pipeline功能:

Redis最佳实践 | 黑马Redis高级篇_第7张图片

Piepline是没有数据类型限制的可以任意做组合

但是Piepline的多个命令之间不像mset多条命令原子性,中间可能有其他代码执行,所以速度相对会比较慢

2、集群下的批处理

如MSET或Piepline这样的批处理需要一次请求中携带多条命令,而此时如果Redis是一个集群,那批处理命令的多个key必须落在一个插槽中,否则就会导致执行失败

Redis最佳实践 | 黑马Redis高级篇_第8张图片

其实当我们要实现集群下批处理的时候,直接使用spring提供的stringRedisTemplate就行,底层已经帮我们封装好了

Redis最佳实践 | 黑马Redis高级篇_第9张图片

底层是异步执行的并行的方式,第三种,性能最好的一种

三、服务端优化

1、持久化配置

Redis持久化虽然可以保证数据安全,但也会带来很多额外开销,因此持久化要遵循以下建议:

  • 用来做缓存的redis实例尽量不要开持久化功能
  • 建议关闭RDB持久化功能,使用AOF持久化
  • 利用脚本定期在slave节点做RDB,实现数据备份(不建议频繁做,一段时间做一次,尽量从节点做)
  • 合理的rewrite阈值,避免频繁的bgrewrite
  • 配置no-appendfsync-on-rewrite=yes,禁止rewrite期间做aof,避免aof引起堵塞。(因为在aof时主线程要将数据写到aof缓冲区,有独立线程刷盘,主线程还会判断耗时,如果耗时超过2秒,会堵塞主线程。这时加如正在执行bgrewrite,磁盘io会影响aof刷盘从而导致主线程堵塞,但是这个期间没有aof可能导致数据丢失)

Redis最佳实践 | 黑马Redis高级篇_第10张图片

部署建议:

redis实例的物理机要预留足够内存来应付fork(可能内存翻倍)和rewrite(重写也要读取内存)

单个redis实例内存上限不要太大。可以加快fork(如果单节点过大,要同步更多数据)的速度、减小主从同步、数据迁移压力

不要与cpu密集型应用部署一起

不要与高硬盘负载应用一起部署(因为重写也要大量io也会影响性能)

2、慢查询

慢查询:redis执行耗时超过某个阈值的命令

Redis最佳实践 | 黑马Redis高级篇_第11张图片

redis是单线程的,每次命令进来就会进入队列,如果执行慢查询,后面的都可能等待过久超时,所以我们解决掉慢查询

慢查询的阈值可以配置指定:

slowlog-log-slower-than:慢查询阈值,单位微妙。默认是10000,建议1000

慢查询会被放入慢查询日志中,日志长度有上限,可以配置:

slowlog-max-len:慢查询日志(本质是队列)的长度默认128,建议1000

Redis最佳实践 | 黑马Redis高级篇_第12张图片

我们可以用上面的命令找到他,加以分析解决,如果是数据结构问题,我们就选择更优的方案等

3、命令及安全配置

Redis会绑定0.0.0.0:6379,这样将redis服务暴露在公网上,而redis如果没有做身份认证,会出现严重安全漏洞, Redis未授权访问配合SSH key文件利用分析 - 腾讯云开发者社区-腾讯云

出现的原因:

  • Redis未设置密码
  • 利用了redis的config set命令动态修改redis配置
  • 使用root账号权限启动redis

为了避免这样漏洞,可以:

Redis最佳实践 | 黑马Redis高级篇_第13张图片

4、内存配置

当Redis内存不足,可能导致key频繁被删除,响应时间边长,qps不稳定等问题,当内存使用率达到90%就需要警惕,并快速定位到内存占用原因

Redis最佳实践 | 黑马Redis高级篇_第14张图片

Redis最佳实践 | 黑马Redis高级篇_第15张图片

Redis最佳实践 | 黑马Redis高级篇_第16张图片

我们要给普通客户端加上上限,默认都是没有上限,如果发的都是bigkey可能把内存占满

我们同时也要尽可能避免出现bigkey适当增大物理机的带宽

另外两个客户端都是有上限的,所以不用太担心内存溢出

可以通过下面命令看有没有移除: 

Redis最佳实践 | 黑马Redis高级篇_第17张图片

四、集群最佳实践

1、集群完整性问题

redis认为有插槽坏了就是有一部分数据丢失,影响数据完整性所以整个集群停止服务

但是我们开发看重可用性,所以不建议开启,部分插槽不可以集群也能服务

Redis最佳实践 | 黑马Redis高级篇_第18张图片

2、集群带宽问题

集群节点之间会不断相互ping确定其他节点状态,每次ping都包含:插槽信息、集群状态信息

集群中节点越多,集群状态信息数据量越大,10个节点相关信息可能达到1kb,此时每次集群互通需要的带宽会非常高

解决途径:

  • 避免大集群,集群节点数不要太多,最好少于1000,如果业务庞大,建立多个集群
  • 避免单个物理机中运行太多redis实例
  • 配置合适的cluster-node-timeout值

3、集群还是主从

集群虽然具备高可用性能,能实现自动故障恢复,但是如果使用不当,也会存在一些问题:

Redis最佳实践 | 黑马Redis高级篇_第19张图片

单体的redis已经达到百万级别的qps,并且也具备很强的高可用特性,如果主从能满足业务需求的情况下,尽量不搭建redis集群

你可能感兴趣的:(Redis,redis,缓存,数据库)