如何排查AWS ElastiCache Redis CPU使用率周期性跳升问题

命令捕获实操方案 #

• 开启慢日志抓异常命令：
  进入ElastiCache控制台对应集群的参数组配置页，调整两个参数：slowlog-log-slower-than设为1000（单位微秒，即超过1ms的命令都会被记录，排查完成后记得改回默认值避免额外资源消耗），slowlog-max-len设为1000保留足够日志量。整点异常时段结束后，执行SLOWLOG GET 1000即可导出所有慢命令记录，包含命令内容、执行时间、耗时、客户端IP，可直接筛选KEY、SET类请求。
• 短时间开启全命令审计：
  若慢日志未抓全，可在整点前5分钟用低权限客户端连接目标节点，执行MONITOR > redis_monitor.log，整点结束后10分钟停止采集。导出的日志可直接通过grep过滤KEY、SET关键字定位请求来源。注意：MONITOR命令本身会占用节点CPU资源，仅建议日常CPU使用率低于30%的节点使用，避免影响线上业务
• 客户端IP匹配定位：
  从CloudWatch中拉取整点时段的CurrConnections指标，查看是否有固定IP的新增连接，拿到IP后匹配内部定时任务平台的机器列表，可快速定位任务所属业务线。

根因验证思路 #

• 若捕获到KEY命令，优先确认是否使用了KEYS prefix:*这类全库扫描规则，该命令为O(n)复杂度，当键数量超过1万时很容易阻塞主线程拉高CPU。
• SET命令延迟升高大概率是KEY命令阻塞主线程导致的排队延迟，也可同步排查是否有单value超过100KB的大Key批量写入操作。
• 可在整点前后各执行一次INFO stats命令，对比keyspace_hits/keyspace_misses、commands_processed指标的涨幅，确认是否存在突发的批量请求。

临时规避方案 #

• 所有定时任务中的KEY命令直接替换为SCAN命令，分批迭代获取匹配键，不会阻塞Redis主线程。
• 若为必要的批量SET操作，建议将任务执行时间打散到非整点时段，避免集中请求拉高CPU使用率。

内容的提问来源于stack exchange，提问作者Nir