Redis MySQL MQ同时报警排查顺序

线上故障现场，最怕的就是告警一屏接一屏地冒出来。

刚看到接口超时，Redis 连接数又紧跟着涨了；MySQL 慢查询刚冒个头，MQ 又开始提示消息堆积。这种时候，群里往往最热闹：开发盯着应用日志，DBA 在数据库里翻，运维盯着机器负载，业务在催恢复时间。

如果这时候脑子里没有一套清晰的排查顺序，就很容易被各种告警牵着鼻子走。Redis 报警就去查 Redis，MySQL 报警就去查 MySQL，MQ 堆积就去加消费者。结果就是大家都在忙活，半小时过去了，业务还是该慢的慢。

多个组件同时报警时，其实有个更聪明的做法：先别急着判断“谁坏了”，而是把业务请求的完整路径理一遍——用户请求从哪进来，经过了哪些服务，读了哪些缓存，查了哪些库，又投递了哪些消息。顺着这条链路往下看，比在一堆红色告警里瞎转悠要有效得多。

先看业务入口

Redis、MySQL、MQ 这些，都属于后端依赖，用户根本看不到它们。用户能感知到的，只是页面打不开、订单提交失败了、接口一直在那转圈。

所以排查的第一步，建议先看入口层。比如网关、Nginx、应用接口、核心服务，重点看它们的错误率和响应时间。

先问清楚几个问题：

• 哪些接口开始变慢了？
• 是所有业务都受影响，还是就某几个接口出问题？
• 异常是从几点几分开始冒出来的？
• 最近有没有发布、配置调整、定时任务或者流量活动？
• 问题是不是集中在某个机房、云区域，或者某组应用实例上？

如果只有下单接口异常，那排查范围就可以缩到交易链路里。但如果登录、查询、支付、后台任务都慢了，就得重点看公共依赖，比如数据库主库、缓存集群、网络链路，或者共享服务。

很多时候，告警数量多，并不代表故障点多。一个慢 SQL、一个热点 key、一个异常的重试任务，都可能把整条链路拖住，然后引发一串连锁告警。

时间线比当前状态更有价值

故障现场看到的状态，往往是连锁反应之后的结果。

比如现在看到的是 Redis 连接数高、MySQL 连接数高、MQ 堆积也高，每个组件好像都有问题。但如果我们把时间往回拉，很可能会发现：MySQL 慢查询在 10:01 先出现，10:03 应用接口开始超时，10:05 Redis 连接数上涨，10:08 MQ 才开始堆积。

这个顺序非常有提示性：数据库变慢后，应用线程在等数据库返回，连接释放变慢，缓存访问也被拖住，消息消费能力跟着下降，最后才导致 MQ 堆积。

反过来，如果 MQ 在前面先开始堆积，消费者大量报错，随后数据库连接才上升，那问题就出在消费逻辑上——比如失败重试太频繁、批量任务异常，或者下游接口变慢。

时间线可以从这些地方找：

• 监控曲线的起涨时间
• 应用日志里的第一条错误
• 数据库的慢日志
• MQ 的消费延迟记录
• 发布平台和变更记录

不要只盯着当前红不红。红色告警只能说明现在有压力，而指标起涨的顺序，更能说明压力到底从哪传出来的。

Redis报警时，看它是不是被拖住了

Redis 报警通常包括连接数升高、响应变慢、命中率下降、内存水平高、慢命令增加。

看到 Redis 报警，不要马上认定就是 Redis 出故障了。先搞清楚它在链路里承担什么角色：是缓存热点数据，还是保存会话，或者是做分布式锁、计数器？

一个非常典型的场景是缓存击穿：某个热点 key 过期，大量请求直接打到数据库；数据库压力升高后，接口变慢，应用线程被占住，Redis 连接也迟迟释放不了。表面上看 Redis 和 MySQL 都报警了，但触发点可能是缓存策略没处理好。

还有一种情况是应用侧连接池配置不合理。流量上来后，应用不停地创建 Redis 连接，Redis 连接数涨得很快，但 Redis CPU 并不高，慢命令也不多。这时候问题可能在客户端连接管理，而不是服务端。

排查 Redis 时，可以重点看这几项：

• 慢命令是不是集中间出现
• 连接数是不是突然上升
• 命中率是不是明显下降
• 有没有大量 key 同时过期
• 内存是不是触发了淘汰策略

如果 Redis 的指标异常晚于接口超时，不妨先把它当作被影响的对象来看待，别急着重启。

MySQL报警时，先看慢查询和锁

MySQL 报警一出现，现场气氛很容易紧张。数据库是核心依赖，一旦处理不当，影响面会迅速扩大。

排查 MySQL 时，优先看慢查询、活跃连接、锁等待和资源水平。

有些故障看起来很复杂，最后查下来就是一个 SQL 没走索引。平时数据量小、流量低的时候看不出问题；高峰期一来，同一条 SQL 被频繁调用，扫描行数暴涨，数据库 CPU 被打高，应用连接池耗尽，接口开始超时。

还有一些问题来自事务：某个任务开启事务后长时间不提交，后续更新被锁住，应用端大量等待，数据库连接越来越多。Redis 和 MQ 随后报警，只是因为应用处理能力下降了。

MySQL 排查时建议看这些：

• 当前活跃连接数量
• 慢 SQL 是不是集中在某几条上
• 是否存在长事务
• 有没有锁等待
• CPU、IO、磁盘空间是否异常
• 应用连接池是否已经耗尽

如果确认是 SQL 或锁导致的问题，要先止血。比如临时下线有问题的接口、暂停批处理、限制流量、终止异常会话。等业务稳定后，再做索引优化、SQL 改写，或者事务调整。

MQ堆积时，别只想着加消费者

MQ 一堆积，很多人的第一反应就是加消费者。这个动作有时有效，但有时反而会让压力继续上升。

如果消费者处理消息时需要写 MySQL，而 MySQL 已经很慢了，再加消费者就等于让更多线程去抢数据库资源。消费速度可能没提升，数据库压力反而更大。

排查 MQ 要同时看生产端和消费端。

生产端要看消息是不是突然变多了。比如上游接口异常后反复重试，或者某个任务重复投递。消费端要看处理速度为什么下降——是消费逻辑报错、下游数据库慢，还是第三方接口超时。

还要看仔细重试队列和死信队列。有些系统失败后会快速重试，如果重试间隔太短，原本只是一个外部接口慢，最后会演变成整个消费集群都被重试消息压住。

MQ 堆积时可以按这个顺序来看：

• 生产速率有没有突增
• 消费速率有没有下降
• 消费失败率是否升高
• 消费逻辑依赖哪些服务
• 是否存在大量重试消息

在确认下游的承接能力之前，不建议盲目地扩消费者。

现场排障可以这样走

多个组件同时报警时，可以按一条固定路径来推进。

先看影响面。确认是核心业务受影响，还是非核心任务异常。如果影响核心交易，要尽快评估降级、限流，或者切换方案。

再看时间线。找出哪个指标先变化，哪个服务先报错，哪个接口先变慢。

接着看应用层。应用日志、线程池、连接池、接口耗时，通常能反映请求卡在了哪一步。很多中间件报警，最后都能在应用层看到线索。

然后看依赖组件。Redis、MySQL、MQ 分别确认状态，判断它们是触发点，还是被链路拖慢了。

最后看近期变更。发布、配置、定时任务、数据同步、促销活动，都可能是触发因素。线上问题和变更经常有关联，排障时不要漏掉这条线。

处理动作上，先止血，再修复。能降级就先降级，能限流就先限流，能暂停批任务就暂停。不要在业务高峰期做大范围的重启，或者复杂的变更。

重启要有判断

重启不是禁忌，但不能当作默认方案来用。

应用重启后，流量会重新打进来。如果数据库还没恢复，连接池可能很快又被打满。消费者重启后会重新拉消息，如果下游慢，MQ 堆积可能更严重。Redis 如果重启涉及加载数据，也可能带来短时间的不可用。

重启之前，至少想清楚三件事：

• 重启的对象是不是位于故障的起点？
• 重启后流量会不会冲击下游？
• 是否已经准备了限流、降级，或者回滚措施？

如果只是为了“试一下”，线上环境要非常谨慎。故障现场的每个动作都应该有目的，操作之后也要观察指标变化。

平时要把链路关系准备好

故障现场排查慢，很多时候不是因为命令不会敲，而是系统关系平时没有整理好。

一个接口调用了哪些服务，读哪个 Redis，查哪个 MySQL，写哪个 MQ，失败后怎么重试，超时时间设置多少——这些信息如果只在少数人脑子里，夜里出了问题就会非常被动。

建议平时至少准备这几类资料：

• 核心接口的链路图
• 应用与中间件的依赖关系
• 数据库的访问关系
• MQ 主题、生产者、消费者的对应表
• 发布和配置的变更记录

这些资料不需要一开始就做得特别复杂，能在故障时快速定位方向就有价值。系统越多，越需要这类基础信息。

告警也要做分层。业务入口告警的优先级，应该高于单个资源指标。核心链路告警，要比普通任务告警更醒目。告警内容尽量带上上下文，比如哪个应用连接数上涨、哪个接口耗时升高、是不是伴随着慢 SQL。

企业现场更需要长期维护

对企业来说，Redis、MySQL、MQ 同时报警并不稀奇，真正的难点在于现场能不能快速组织排查顺序。先确认影响面，再拉时间线，然后判断故障起点，最后选择止血动作——这套流程需要平时的积累。

如果企业系统数量多，内部运维人手又有限，还涉及多套数据库、缓存和消息队列，可以考虑让外部运维团队参与巡检和应急支持。这么做不是等问题爆发后临时找人，而是提前把风险点梳理出来，把处理流程跑顺。

总结

Redis、MySQL、MQ 一起报警时，别被告警数量吓住。先看业务入口，再看时间线，然后顺着应用链路查依赖组件。

Redis 可能只是连接被占住了，MySQL 可能被慢 SQL 或锁拖慢了，MQ 堆积也可能是消费端下游处理不过来。排查方向对了，很多告警会串成一条线。

线上故障处理，拼的是顺序感。先止血，再定位，再修复。别一上来就重启，也别看到哪个组件红了就只盯哪个组件。业务链路理清楚了，排障会稳很多。