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

卒获有所闻

已于 2023-02-04 18:46:40 修改

阅读量2.6k

点赞数 5

分类专栏： Redis 文章标签： redis 缓存数据库

于 2023-02-04 18:39:09 首次发布

本文链接：https://blog.csdn.net/weixin_54232666/article/details/128876553

版权

Redis 专栏收录该内容

16 篇文章 11 订阅

订阅专栏

文章详细介绍了Redis的键值设计最佳实践，包括优雅的key结构和避免BigKey的问题，以及如何发现和删除BigKey。批处理方面，讨论了Pipeline和MSET的使用。服务端优化涉及持久化配置、慢查询管理和命令安全。最后，文章提出了集群最佳实践，包括集群完整性和带宽问题的解决策略。

摘要由CSDN通过智能技术生成

一、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

如何删除BigKey

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

redis 3.0以下版本

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

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

3、恰当的数据类型

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

存在问题：

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

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

优化方案

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

二、批处理优化

1、Pipeline

大量数据导入的方式

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

MSET

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

mset（只能处理字符串）
hmset（只能处理hash）

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

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

Pipeline

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

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

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

2、集群下的批处理

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

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

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

三、服务端优化

1、持久化配置

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

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