Redis性能压测和影响性能的指标分析

线上故障

最近，公司线上某个虚拟机Redis节点因突发异常，导致 CPU 100%, 无法处理请求。

场景：因历史原因，这个Redis 是单点主从结构，一直没有迁移到集群

现象：Redis  master（以下称 A） 突然CPU100%，平时30%左右，当时 telnet 端口不通，部署Redis master 的虚拟机都无法连接登录，但是 telnet 该虚拟机上 其他服务端口是通的。

紧急处理方式：把slave (以下称 B)切换为 master , B的 CPU 也100%，此时大部分请求还是超时，偶尔有返回 RT 很长，600ms 的都有。意味着提升为master 的节点也没有提供服务的能力。

最后只能切量到其他Redis备用节点（实体机）。CPU 降了下来，RT 恢复正常，故障解决。

 

思考1： 为什么主 突然 100% CPU? 

我当时的想法：Redis 是单进程单线程，能将 CPU 拉高的原因有以下几点：

• 并发高，连接数高、QPS 暴涨
• RDB fork 了大量子线程
• 密集型数据过期，集中的过期回收线程导致

然后找运维修改 redis 配置，关闭 save.

情况并未好转，

思考2: 为何 slave 提升为主的节点，也不可用？

当时分析是，主配置不够好，扛不住 master 全量且过来的 请求。最后切换为配置好的实体机Redis节点。

 

以上其实都是根据理论 加 经验的推断，没有有力的数据来说明，所以，只能对线上相同配置的 Redis 做压力测试，才能通过数据来准确分析。

 

压测

压测需要注意的点：

• 尽量解决真实业务情况（不通类型操作占比、数据value 量）
• 压测虚拟机Redis 和 实体机 Redis 的差异

压测结果

1. 相同压力下，虚拟机CPU占用高于实体机，同比压力增长下，虚拟机的CPU使用正常更快。CPU指标差30%左右。
2. RT 与 连接数成正相关， RT越长，需要的连接数越多。
3. 连接数 和 吞吐量（OPS）成 负相关，当 连接数达 6000时，OPS 5万多，是QPS高峰时的一半。
4. 单台Redis节点性能受连接数影响较严重：Redis 单进程单线程，当连接越多时，需要花费更多的时间来轮询处理socket 连接， 处理reids 命令操作的CPU 时间就会变少，连接达到一定量（3500左右），严重影响吞吐量。
5. 单台Redis实体机节点，连接数上限：6000。此时QPS上限：56000

连接达到7000多时，报以下错：

1. Could not get a resource from the pool

2. java.net.SocketTimeoutException: connect timed out

3. java.net.SocketTimeoutException: Read timed out

Redis线程池参数优化经验分享：

当项目中开始出现以上1报错时， 很多人第一反应是连接池连接不够了，调大 max-idle 和 max-active 参数，其实这样做是不对的，因为连接不够用，其实我们应该反过来思考，为什么连接不够？ 是因为 RT 过长，导致连接没有尽快释放到连接池，所以首先应该查找有没有慢查询，是不是 较多慢查询导致 RT 增长。

通过监控业务并发、大致可以算出需要的连接数，max-active 设置一个稍微偏大的数即可，如果真出现 波峰，也应该是 fast fail, 然后对失败的请求做降级 或者 异常处理，否则会出现大量堆积。

同样，超时时间在高并发环境下，也应当尽量设置小，防止堆积。

谨记：Redis 虽然使用了 IO多路复用，提升了性能，但单线程模型，也决定了它的性能受连接数影响严重。

 

优化建议

1. 去单点故障：单Redis节点，无法保证高可用；挂掉一台，即不可用。
    
2. 多节点、集群：在保证性能的前提下，单台的连接数支持有限。建议扩节点，比如多加从节点，读写分离；或者使用Redis集群方案Codis。
    
3. 连接数优化：各业务使用方，确定并发量，合理设置Redis客户端连接池连接数上限，满足业务情况下，尽量降低上限。
    
4. 超时优化：客户端应设置合理的soTimeout超时时间，并发越高的服务，超时时间应越短，否则堆积严重；最长不应超3000ms，建议1000ms, 超时异常时做好 重试、降级等处理即可。
    
5. 业务隔离：不同的项目、业务，应适当考虑共用缓存Key占比，占比较少时，应使用不同的Redis 节点，降低耦合，防止雪崩效应。若跨项目使用缓存，也应调用RPC接口，通过缓存对应服务接口获取。