Redis17-服务端优化

目录

持久化配置

慢查询

什么是慢查询

如何查看慢查询

命令及安全配置

内存配置

集群优化

---

持久化配置

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

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. 不要与高硬盘负载应用一起部署。例如：数据库、消息队列

慢查询

什么是慢查询

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

慢查询的危害：由于Redis是单线程的，所以当客户端发出指令后，它们都会进入到Redis底层的queue来执行，如果此时有一些慢查询的数据，就会导致大量请求阻塞，从而引起报错

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

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

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

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

如何查看慢查询

查看慢查询日志列表：

• slowlog len：查询慢查询日志长度
• slowlog get [n]：读取n条慢查询日志
• slowlog reset：清空慢查询列表

命令及安全配置

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

漏洞出现的核心原因：

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

建议：

• Redis一定要设置密码
• 禁止线上使用下面命令：keys、flushall、flushdb、config set等命令，可以利用rename-command禁用
• bind：限制网卡，禁止外网网卡访问
• 开启防火墙
• 不要使用Root账户启动Redis
• 尽量不是有默认的端口

内存配置

当Redis内存不足时，可能导致Key频繁被删除、响应时间变长、QPS不稳定等问题，当内存使用率达到90%以上时就需要我们警惕，并快速定位到内存占用的原因

内存占用	说明
数据内存	是Redis最主要的部分，存储Redis的键值信息。主要问题是BigKey问题、内存碎片问题
进程内存	Redis主进程本身运⾏肯定需要占⽤内存，如代码、常量池等等；这部分内存⼤约⼏兆，在⼤多数⽣产环境中与Redis数据占⽤的内存相⽐可以忽略
缓冲区内存	一般包括客户端缓冲区、AOF缓冲区、复制缓冲区等。客户端缓冲区又包括输入缓冲区和输出缓冲区两种。这部分内存占用波动较大，不当使用BigKey，可能导致内存溢出

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

• info memory：查看内存分配的情况
• memory xxx：查看key的主要占用情况

内存缓冲区常见的有三种：

• 复制缓冲区：主从复制的repl_backlog_buf，如果太小可能导致频繁的全量复制，影响性能。通过replbacklog-size来设置，默认1MB
• AOF缓冲区：AOF刷盘之前的缓存区域，AOF执行rewrite的缓冲区，无法设置容量上限
• 客户端缓冲区：分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置，输出缓冲区可以设置

默认配置没有上限

解决方案：

• 设置一个大小
• 增加带宽的大小，避免出现大量数据从而直接超过了Redis的承受能力

集群优化

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

• 集群完整性问题
• 集群带宽问题
• 数据倾斜问题
• 客户端性能问题
• 命令的集群兼容性问题
• lua和事务问题：在集群模式无法执行lua和事务

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

把如下配置修改成no，即有slot不能使用时，redis集群还是可以对外提供服务

问题2：集群带宽问题

集群节点之间会不断互相Ping来确定集群中其它节点的状态，每次Ping携带的信息至少包括：

• 插槽信息
• 集群状态信息

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

解决方案：

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

集群还是主从：

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