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

如何删除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可能导致数据丢失）

部署建议：

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

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

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

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

2、慢查询

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

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

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

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

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

slowlog-max-len：慢查询日志（本质是队列）的长度默认128，建议1000

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

3、命令及安全配置

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

出现的原因：

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

为了避免这样漏洞，可以：

4、内存配置

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

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

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

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

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

四、集群最佳实践

1、集群完整性问题

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

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

2、集群带宽问题

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

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

解决途径：

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

3、集群还是主从

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

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