AWS ElastiCache Redis突发性能暴跌及跨AZ EC2 CPU异常求助

首先，结合你描述的所有异常点——Redis性能骤降、入方向数据包暴增、复制延迟飙升，同时仅可用区C的IIS实例CPU跑满——这几个事件几乎肯定是关联的，大概率是C区IIS的异常请求触发了Redis的性能雪崩，反过来Redis的响应延迟又加剧了IIS的CPU占用（比如大量请求阻塞重试、线程池耗尽后的上下文切换开销）。下面是针对你权限有限的情况，可逐步排查的方向：

一、先验证C区IIS与Redis异常的关联 #

这是最快速的突破口，因为两个异常同时发生，且仅C区出现CPU问题：

• 临时限流/暂停C区IIS的Redis相关服务：如果运维允许，尝试暂时停止C区IIS中依赖Redis的应用，或者用简单的限流方式降低其Redis请求量。观察Redis的读写耗时、复制延迟是否快速恢复，同时看C区IIS的CPU是否回落。如果是，直接坐实两者的关联。
• 检查IIS请求日志：查看C区IIS的访问日志，异常时间段内有没有某个接口/URL的请求量暴增？尤其是那些直接调用Redis的接口。如果日志里能看到大量重复或异常请求，基本能定位到应用层的问题。
• 查看IIS进程的线程状态：如果能拿到Windows任务管理器的权限，看CPU占比最高的w3wp.exe进程，有没有大量线程处于“等待”状态（尤其是等待Redis响应的线程）。如果权限足够，让运维帮忙抓个线程快照，能直接看到线程是否卡在Redis客户端调用上。

二、针对Redis集群的基础排查（利用AWS CloudWatch基础指标） #

即使权限有限，一般也能查看Redis的CloudWatch核心指标：

• 重点看CommandLatency指标：有没有特定命令（比如KEYS、HGETALL这类全量扫描命令，或者自定义的大value读写命令）的延迟突然飙升？这类命令会瞬间占用Redis的CPU，导致其他请求排队。
• 检查主节点的CPUUtilization和MemoryUsage：异常时间段内主节点的CPU是不是跑满了？如果主节点CPU被占满，不仅处理请求慢，还会导致复制同步的任务被积压，进而出现复制延迟。
• 分析NetworkIn指标：入方向数据包激增，结合IIS的情况，大概率是大量小请求并发涌入Redis（比如IIS的应用在循环重试请求），而不是网络层面的攻击或故障。

三、可能的常见场景推测 #

结合你的描述，最可能的几个原因：

1. C区IIS应用出现逻辑异常：比如最近上线的代码存在无限循环请求Redis、批量请求的参数错误（比如一次性请求大量key），或者缓存击穿/穿透后，大量请求直接打向Redis。
2. Redis客户端配置错误：C区IIS的Redis客户端突然改成了短连接（默认应该是长连接），导致每次请求都新建连接，瞬间产生大量TCP连接请求，压垮Redis的连接池，同时IIS这边因为频繁创建连接导致CPU飙升。
3. 跨AZ网络临时波动：虽然概率较低，但C区到A/B区的跨AZ网络如果出现延迟突增，会导致Redis请求超时，IIS应用触发重试机制，进而形成请求风暴，同时Redis因为处理大量超时请求的重试而负载过高。

四、权限有限情况下的替代方案 #

如果你没法直接访问Redis的日志或高级指标，可以：

• 让运维帮忙导出Redis的慢查询日志（异常时间段），里面会记录耗时超过阈值的请求，能直接看到有没有异常命令或大量重复请求。
• 让运维检查Redis集群的连接数指标（CloudWatch的ConnectedClients），异常时间段内连接数是不是突然暴增，且大部分来自C区的EC2实例IP。

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