一、现象描述
·现象1：收到 CPU 使用率过高的消息提醒：
·现象2：CPU 使用率的监控指标高。
·现象3：整体吞吐量变小、响应速度变慢。
二、排查与解决
| 序号 | 可能原因 | 原因分析 | 排查方法 | 解决方法 |
| 1 | 频繁建立短连接 | 实例大量资源消耗在处理频繁短连接上，引起 CPU 使用率较高，连接数较高，然而 QPS（集群每秒访问次数）未达到预期。 | 借助数据库智能管家 DBbrain 的诊断优化功能，分析数据库实例的实时会话统计视图及数据，确认是否存在连接数突增的现象。具体查询方式，请参见 实时会话。 | 将短连接调整为长连接，例如使用JedisPool 连接池连接。具体代码示例，请参见 Jedis 客户端。 |
| 2 | 存在高时间复杂度的命令。例如：sort、sunion、zunionstore 等。 | Redis 是单线程执行命令，执行复杂度高的命令，很可能阻塞其他命令。命令的时间复杂度越高，在执行时会消耗较多的资源，会引起 CPU 使用率上升。 | 执行高复杂度的命令，通常比较耗时，会相应产生慢日志。可借助数据库智能管家 DBbrain 的诊断优化功能进行慢日志分析，在慢日志信息列表中，查看是否存在高复杂度的命令。具体操作，请参见 慢日志分析。 | 使用复杂度较高命令，每次不要获取太多的数据，尽量操作少量的数据，让 Redis 可以及时处理返回。 |
| 3 | 读写负载过高，如存在对热点 Key 的大量访问或者存在大 Key。 | 热 Key 指的是那些在一段时间内访问频率特别高的键值。具体到业务场景，包括热点新闻、热门直播、秒杀活动等等。大量访问流量集中到一个实例中，达到单个实例的处理上限，引起 CPU 使用率上升。 | 可借助数据库智能管家 DBbrain 的诊断优化功能进行热 Key 分析，快速发现访问频次高的热 Key。具体操作，请参见 热 Key 分析。 | 热 Key：拆分复杂数据结构，将热点 Key 拆分为若干个新的 Key 分布到不同 Redis 节点上，从而减轻压力。以哈希类型为例，该热 Key 的类型是一个二级数据结构，该哈希元素个数可能较多，可以考虑将当前 hash 进行拆分。 |
| 4 | | 大 Key 指某个 Key 对应的 value 很大，占用的 Redis 空间很大。执行大 Key 相关读取或者删除操作时，会严重占用带宽和 CPU。 | 可借助数据库智能管家 DBbrain 的诊断优化功能进行大 Key 排查，针对数据库大 key 占用内存的情况进行监控分析。具体信息，请参见 内存分析。 | 大 Key：如果是 value 过大，你可以将对象拆分成多个 key-value，将操作压力平摊到多个 Redis 实例；如果是 Key 过多，你可以参考 hash 结构存储，将多个 Key 存储在一个 hash 结构中。 |
| 5 | | 读负载过高，达到资源上限。 | 借助数据库智能管家 DBbrain 的诊断优化功能，查看数据库实例性能趋势视图，分析 QPS、读写请求指标，确认是否由于读负载或者写负载过大导致 CPU 使用率偏高。具体信息，请参见 性能趋势。 | 读负载过高：通过 增加副本数量 来分摊读负载。开启副本只读，把当前实例的读请求转移在副本只读节点上，实现读取能力的弹性扩展，提升读写性能。具体操作，请参见 副本只读。 |
| 6 | | 写负载过大，内存规格不足。 | | 写负载过大：你可以通过 增加分片数量 的方式来分摊写负载。若实例为标准架构，请优先升级标准架构为集群架构，提升 CPU 处理能力。具体操作，请参见 升级实例架构。升级集群架构之前需要检测兼容性，请参见 标准架构迁移集群架构检查。 |
| 7 | 同一时间点大量的 Key 过期。 | Key 过期时间设置在同一时间点，到达过期时间点，Redis 将占用较大 CPU 资源处理 Key 的淘汰线程，引起短暂卡顿。 | 在控制台系统监控页面，排查指标key 过期数，确认是否某个时间点有大量的 Key 过期。具体操作，参见 5秒监控更新说明。 | 在业务逻辑中，分散过期时间，避免 Key 集中过期。 |
| 8 | 频繁切换 DB，即频繁执行 select 命令进行 DB 切换。 | 频繁切换 DB，带来资源的过度开销。 | 借助数据库智能管家 DBbrain 的延迟分析功能，对命令字分析中 select 命令的监控数据进行确认，确认是否存在 select 请求比较多的现象。具体查询方式，请参见 命令字分析。 | 如果存储不同业务，针对频繁切换 DB 的业务，建议分开存储。如果存储相同业务，评估 Key 名不冲突的前提下，考虑将数据存储在相同的 DB，减少 select 请求操作次数。 |