如果系统中出现了大 key、热 key 等，往往会导致 Redis 变慢，但是这个慢该如何界定？多久算慢？1秒还是3秒？

这个肯定是没有标准答案，因为这个和你的硬件设备有关。

硬件差一些，平时响应时间都是 1s，突然有个响应 3s，那肯定算慢。

硬件好一些，平时响应都是 0.2s，突然有个响应 1s，那这个 1s 肯定算慢。

所以这个没有固定数据。

但是这个问题是有答案的。

所以今天我就想来和大家聊一聊这个话题，我们该如何去评估自己 Redis 的性能。

一 基准性能

评估 Redis 的性能应该有一个基准性能。

基准性能的评估应该摒弃网络影响，直接在服务端进行测试。

测试方式就是在系统压力较低，并且网络干扰小的情况下，获取到 Redis 的基本性能数据，Redis 中提供了相关的测试命令，我们可以直接使用：

命令中的 100 是测试执行的时间，100 表示 100s。

图片里的最大延迟是 16751 微秒，也就是 16.75 毫秒，那么这个数据就可以作为 Redis 的基线性能。

在 Redis 运行过程中，如果运行的延迟时间超过了 16.75*2 毫秒，那么就可以认为 Redis 的性能下降了，如果延迟时间在 16.75*2 毫秒以内，可以认为就是正常的波动。

不过需要注意，这个只是测试 Redis 本身的性能，并不包含网络波动导致的缓慢，所以大家测试的时候，一定要选择一个合适时机，即系统压力低且网络干扰小。

二 问题解决

当我们发现了 Redis 比较慢之后，问题该如何解决呢？

2.1 监控工具和日志分析

• 使用 Redis 内置命令：如 INFO, DEBUG OBJECT <key>, SLOWLOG 等命令可以帮助诊断性能问题。

• 监控工具：使用第三方监控工具如 Redis Commander, RedisInsight 或者 Grafana + Redis Exporter 等工具来监控 Redis 的运行状态。

2.2 分析 Redis 配置

• 检查配置文件：确认配置文件（redis.conf）中的设置是否合理，例如内存限制、持久化策略等。

• 调整参数：根据实际情况调整如 maxmemory、maxmemory-policy、appendonly、aof-rewrite-incremental-fsync 等配置选项。

2.3 数据结构和键空间分析

• 键空间统计：使用 KEYS * （不推荐频繁使用，因为它可能影响性能）或 SCAN 命令来获取键空间信息。

• 对象编码：使用 OBJECT ENCODING <key> 查看键的底层编码方式，了解数据结构是否适合当前的工作负载。

• 大键检测：查找是否存在大键，因为大键可能导致内存浪费和性能问题。

2.4 性能瓶颈定位

• CPU 使用率：检查 Redis 进程的 CPU 使用率，判断是否存在计算密集型操作。

• 内存使用：分析 Redis 的内存使用情况，确认是否有异常的内存增长。

• 网络延迟：检查客户端与 Redis 服务器之间的网络延迟。

• 磁盘 I/O：如果启用了持久化，检查磁盘 I/O 是否成为瓶颈。

2.5 客户端分析

• 客户端行为：检查客户端请求模式，是否频繁执行高成本命令。

• 并发连接数：确认客户端并发连接数是否过高。

• 命令执行时间：使用 MONITOR 命令观察命令执行时间和频率。

• 客户端库：检查使用的客户端库是否高效，是否有性能问题。

• 中间件：如果有使用任何中间件，确认它们没有引入额外的延迟。

2.6 操作系统和硬件

• 操作系统调优：确认操作系统配置是否合理，例如交换分区大小、文件系统类型等。

• 硬件资源：检查 CPU、内存和磁盘等硬件资源是否充足。

2.7 网络问题

• 网络拓扑：确认网络拓扑是否导致延迟或带宽问题。

• 防火墙和安全组：确认防火墙规则或安全组设置是否影响了 Redis 的正常通信。

2.8 应用程序层面

• 缓存策略：评估应用程序的缓存策略是否合理，是否有过多的重加载或不必要的缓存更新。

• 业务逻辑：审查应用程序的业务逻辑是否可以优化以减少对 Redis 的访问需求。

通过对上述各个方面的综合分析，通常可以找到导致 Redis 性能下降的原因，并采取相应的措施来解决问题。

来源： 江南一点雨