Redis17-服务端优化
目录
持久化配置
慢查询
什么是慢查询
如何查看慢查询
命令及安全配置
内存配置
集群优化
持久化配置
Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：
- 用来做缓存的Redis实例尽量不要开启持久化功能
- 建议关闭RDB持久化功能，使用AOF持久化
- 利用脚本定期在slave节点做RDB，实现数据备份
- 设置合理的rewrite阈值，避免频繁的bgrewrite
- 配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞
部署有关建议：
- Redis实例的物理机要预留足够内存，应对fork和rewrite
- 单个Redis实例内存上限不要太大，例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
- 不要与CPU密集型应用部署在一起
- 不要与高硬盘负载应用一起部署。例如：数据库、消息队列
慢查询
什么是慢查询
在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集群