Redis 问题排查与 QPS 评估

go-zero 社区核心贡献者 Mikael（go-zero-looklook  作者）找我沟通了一个关于 Redis 的问题。在解决后，我意识到，社区中很多同学可能也会遇到类似的问题。因此，抽空总结了一些关于 Redis 响应时长和 QPS 评估的经验，希望对大家有所帮助。

Redis 响应时长排查思路

Redis 的核心优势之一就是高性能。在没有大 Key和热 Key的情况下，响应速度通常非常快。但如果出现异常，尤其是响应时长过高，我们需要仔细排查。以下是一些关键点：

1. 正常情况下的响应时长

量化指标：

Redis 在正常情况下处理请求时长通常低于 1ms。

调用端指标上报中，一般会在 2ms 以内，即使是同城跨区访问，时延增加也不过 1ms。

异常判断：

如果响应时长（均值或 P99）超过 10ms，就需要开始排查原因。

2. 可能的性能瓶颈

大 Key 或热 Key：单次请求操作的数据量过大，导致 Redis 处理时间变长。CPU 负载过高：CPU 占用过高会直接影响性能。内存淘汰机制：内存即将耗尽时，Redis 会进行数据淘汰，导致响应变慢。大范围查询：如使用 SCAN、SORT 等命令，会触发较大的数据遍历。连接数过多：Redis 连接过载，可能引发排队等待，影响响应速度。

Redis 客户端可承载 QPS 计算方法

在 go-zero 中，使用了官方库 go-redis。这里按照 Redis 的部署模式，分别探讨单节点和集群模式下的 QPS 计算。

1. 连接数配置

单节点模式：

调用端每个 CPU 核心维护 10 个连接。假设是 4 核 CPU，总共就是 40 个连接。

集群模式：

调用端每个 CPU 核心对每个分片维护 5 个连接。假设有 2 个分片，4 核 CPU，总共至少 40 个连接。

2. QPS 计算公式

假设每个请求的平均处理时长为 2ms（包含网络延迟），那么单个连接每秒可处理 500 个请求。按照上面的连接数：

单节点 Redis：调用端每个核对应 10 个连接。假设是 4 核 CPU，总共就是 40 个连接。集群模式（至少两分片）：

调用端每个核对应每个分片 5 个连接，每个分片至少提供 10,000 QPS 的处理能力（如果是用来限流或者热 key 则可能请求打在单分片上）。

这种计算虽然粗略，但基本能够作为评估依据。如果遇到 Redis 连接数不足的问题，可以按照上述方法进行自查，分析瓶颈所在。

总结与建议

遇到 Redis 性能问题时，不能简单地通过增加连接数来解决。我们需要深入分析根因，定位到具体问题，找到真正的瓶颈。提升系统性能的关键在于理解 Redis 的工作机制，并针对性优化。