优化

key 结构

1、key 最佳实践约定

(1)遵循基本格式:[业务名称]:[数据名]:[id]

(2)长度不超过 44 字节

(3)不包含特殊字符

2、优点

(1)可读性强

(2)避免 key 冲突

(3)方便管理

(4)节省内存:key 是 string 类型,底层编码包含 int、embstr、raw,embstr 在小于 44 字节使用,采用连续内存空间,内存占用更小

 

BigKey

1、通常以 Key 大小、Key 中成员的数量来综合判定

(1)Key 本身的数据量过大:一个 String 类型的 Key,它的值为 5MB

(2)Key 中成员数过多:一个 ZSET 类型的 Key,它的成员数量为 10000 个

(3)Key 中成员的数据量过大:一个 Hash 类型的 Key,它的成员数量有 1000 个,但成员的 Value(值)总大小为 100MB

2、推荐值

(1)单个 key 的 value 小于 10KB

(2)对于集合类型的 key,建议元素数量小于 1000

3、缺点

(1)网络阻塞:对 BigKey 执行读请求时,少量的 QPS 就可能导致带宽使用率被占满,导致 Redis 实例,所在物理机变慢

(2)数据倾斜:BigKey 所在的 Redis 实例内存使用率远超其他实例,无法使数据分片的内存资源达到均衡

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

(4)CPU 压力:对 BigKey 的数据序列化、反序列化会导致 CPU 的使用率飙升,影响 Redis 实例和本机其它应用

4、查找

(1)redis-cli --bigkeys:利用 redis-cli 提供的 --bigkeys 参数,可以遍历分析所有 key,并返回 Key 的整体统计信息与每个数据的 Top1 的 big key

(2)scan 扫描:利用 scan 扫描 Redis 中的所有 key,利用 strlen、hlen 等命令判断 key 的长度,不建议使用 MEMORY USAGE

(3)第三方工具:如 Redis-Rdb-Tools 分析 RDB 快照文件,全面分析内存使用情况

(4)网络监控:自定义工具,监控进出 Redis 的网络数据,超出预警值时主动告警

5、删除

(1)BigKey 内存占用较多,删除需要耗费很长时间,导致 Redis 主线程阻塞,引发一系列问题

(2)Redis 4.0 后,使用异步删除的命令:unlink

 

批量执行

1、Redis 原生 Mxxx 命令

(1)实现批量插入数据,例如:mset、hmset

(2)只能操作部分数据类型

2、对复杂数据类型的批处理,建议使用 Pipeline

3、事项

(1)不要在一次批处理中传输太多命令,否则单次命令占用带宽过多,会导致网络阻塞

(2)Pipeline 多个命令之间不具备原子性

4、集群下的批处理

(1)MSET 或 Pipeline 需要在一次请求中携带多条命令

(2)如果 Redis 是一个集群,批处理命令的多个 key 必须落在一个插槽中,否则就会导致执行失败

 

 

持久化建议

1、缓存 Redis 实例尽量不要开启持久化功能

2、建议关闭 RDB 持久化,而使用 AOF 持久化

3、利用脚本定期在 slave 节点做 RDB,实现数据备份

4、设置合理的 rewrite 阈值,避免频繁的 bgrewrite

5、配置 no-appendfsync-on-rewrite = yes,禁止在 rewrite 期间做 aof,避免因 AOF 引起的阻塞

 

部署建议

1、Redis 实例的物理机要预留足够内存,应对 fork 和 rewrite

2、单个 Redis 实例内存上限不要太大,例如:4G 或 8G,可以加快 fork 速度、减少主从同步、数据迁移压力

3、不要与 CPU 密集型应用部署在一起

4、不要与高硬盘负载应用一起部署,例如:数据库、消息队列

 

慢查询

1、在 Redis 执行时耗时超过某个阈值的命令,称为慢查询

2、slowlog-log-slower-than

(1)慢查询的阈值

(2)单位是微秒,默认是 10000,建议 1000

3、slowlog-max-len

(1)慢查询日志长度上限,默认 128,建议 1000

(2)慢查询日志本质是一个队列

4、查看慢查询日志列表

(1)slowlog len:查询慢查询日志长度

(2)slowlog get [n]:读取 n 条慢查询日志

(3)slowlog reset:清空慢查询列表

 

安全配置

1、Redis 会绑定在 0.0.0.0:6379,将 Redis 服务暴露到公网上,而 Redis 如果没有做身份认证,会出现严重的安全漏洞

2、出现漏洞的核心原因

(1)Redis 未设置密码

(2)利用 Redis 的 config set 命令动态修改 Redis 配置

(3)使用 Root 账号权限启动 Redis

3、建议

(1)Redis 必须设置密码

(2)禁止线上使用以下命令:keys、flushall、flushdb、config set 等命令,可以利用 rename-command 禁用

(3)bind:限制网卡,禁止外网网卡访问

(4)开启防火墙

(5)不使用 Root 账户启动 Redis

(6)修改默认端口

 

内存配置

1、内存使用率达到 90% 以上时,就需要快速定位到内存占用的原因

2、查看 Redis 目前的内存分配状态

(1)info memory

(2)memory xxx

3、内存缓冲区

(1)复制缓冲区:主从复制的 repl_backlog_buf,如果太小可能导致频繁的全量复制,影响性能,通过 repl-backlog-size 设置,默认 1MB

(2)AOF 缓冲区:AOF 刷盘之前的缓存区域,AOF 执行 rewrite 的缓冲区,无法设置容量上限

(3)客户端缓冲区:分为输入缓冲区、输出缓冲区,输入缓冲区最大 1GB 且不能设置,输出缓冲区可以设置

(4)配置格式

(4)默认配置

 

集群

1、完整性

(1)在 Redis 默认配置中,如果发现任意一个插槽不可用,则整个集群都会停止对外服务

(2)为了保证高可用,建议将 cluster-require-full-coverage 配置为 false

2、集群节点之间会不断的互相 Ping 来确定集群中其它节点的状态

3、每次 Ping 携带的信息至少包括

(1)插槽信息

(2)集群状态信息

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

5、解决

(1)避免大集群,集群节点数不要太多,最好少于 1000,如果业务庞大,则建立多个集群

(2)避免在单个物理机中运行太多 Redis 实例

(3)配置合适 cluster-node-timeout 值

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

posted @   半条咸鱼  阅读(170)  评论(0编辑  收藏  举报
(评论功能已被禁用)
相关博文:
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示