消息队列堆了几十万条，加了一倍消费者还是没降，是不是分区数卡住了？

消息队列堆了几十万条，加了一倍消费者还是没降，通常不是消费者数量不够，而是有效消费速率没起来。按 2026 年常见交付经验，先判断积压是短时暂停型还是长期失衡型，再算清积压量、消费速率、生产速率三个数；只有消费速率大于生产速率，追平才有意义。加消费者之前，还要核对分区数、顺序性要求和下游承压这三道闸门。

先分清两种积压：短时暂停型与长期失衡型

暂停型积压是消费端短时间停过，比如发版重启、下游超时、异常重试。它的特点是消费端恢复后，积压曲线会持续向下走。判断依据是看每小时积压量的斜率，连续在降通常不需要扩容。

失衡型积压是生产速率长期接近甚至超过消费速率，积压量每天在同一时段固定上涨，活动结束后也回不到零。这属于容量问题，不是恢复问题。把失衡型当暂停型去等，第二天积压还在。

• 看斜率：积压量在降，多半是暂停型；在涨或走平，多半是失衡型。
• 看错误：消费端有大量超时、重试日志，先解决重试风暴，再谈扩容。
• 看单条耗时：同一批消息单条处理耗时从几十毫秒涨到几百毫秒，多半是下游变慢，不是消费者不够。

要不要加消费者，先把三个数摆出来

判断积压能不能追平，本质上是一道除法题：追平时间约等于积压量除以（消费速率减去生产速率）。三个数分别是现有积压条数、消费速率（条/秒）、生产速率（条/秒）。只有消费速率大于生产速率，这个式子才有意义；如果消费速率小于生产速率，追平时间会是负数，含义是永远追不上。

用经验区间举例：积压 20 万条，消费速率 500 条/秒、生产速率 200 条/秒，差值 300，大约十几分钟能追平；如果消费速率只有 250 条/秒，差值只剩 50，同样 20 万条要一个多小时。差值的绝对值比消费速率本身更能决定追平速度，这也是不少团队加了一倍消费者，堆积曲线却没什么变化的原因。

• 消费速率要从消费端处理日志按分钟统计，不要只用一段时间平均值，平均值会把峰值抹掉。
• 生产速率要看业务峰值时段，不是看全天平均。
• 如果消费速率根本测不出来，说明消费端缺少可观测指标，这本身就是需要先补的一件事。

加消费者之前，先确认这三道闸门

闸门一：分区或队列数量够不够

多数消息队列实现里，一个分区在同一时刻通常只有一个消费者能拿到消息。消费者实例数超过分区数之后，多出来的实例基本在空转，扩容不会提升吞吐。常见做法是先把分区数扩上去，再同步增加消费者，两边数量大致对齐；具体对应关系可以按所用消息队列的官方文档核对。

闸门二：有没有顺序性要求

同一订单、同一用户的连续消息如果要求按序处理，就不能让它们分散到多个消费者并行消费。可行做法是按业务键分区，让同一个键的消息固定落到同一分区，这样既能并行，又不会乱序。顺序性约束下，能并行的是不同的键，不是同一条队列。

闸门三：下游扛不扛得住

消费端通常还要写库、调第三方接口。消费者从 4 个提到 20 个，数据库连接数、行锁等待、第三方限流往往先出问题，表现为消费更快了但失败率也更高，实际有效吞吐没涨。交付时要先核对下游的容量口径，再决定扩容幅度。

• 数据库：连接池上限、单表更新频率、是否集中在同一批行。
• 第三方接口：是否有 QPS 限制，超限是排队还是直接拒绝。
• 缓存：批量消费常带来批量查询，注意大 key 和热点 key。

三条路子的取舍：加消费者、提单条效率、降级丢弃

扩容只是其中一条路。加消费者见效快，但它解决的是同时处理更多条，解决不了单条处理太慢。相反，批量写、批量确认、减少每条消息的重复查询，改的是单条成本，见效慢一些，但在容量长期增长时更持久。取舍的关键是看积压属于短时峰值还是长期趋势。

• 加消费者：经验区间是几分钟到十几分钟看到曲线明显下拐；受分区数和下游容量限制，适合短时峰值。
• 提单条效率：把逐条写库改成批量提交、批量确认，常见的批量区间是 50~200 条一批，吞吐往往能提升数倍，但要注意部分失败时的处理语义。
• 降级或转存：只适合日志、埋点、统计这类可重放或可丢弃的消息；订单、支付、通知这类状态变更消息不能靠丢弃解决。

容易踩的三个坑

• 把重试风暴当成容量问题：消息一直失败被反复投递，看起来像积压，其实是消费逻辑在报错。
• 扩容后忘了回收：临时加的消费者实例没人下线，过段时间才发现成本变高。
• 只盯队列不看业务：积压清空了，但下游状态被写乱了，问题只是换了个地方出现。

交付现场的一段经验

交付现场里更常见的情况是：约束条件比较硬，甲方不接受丢消息，消费端还要调一个有 QPS 限制的第三方接口。这种情况下常规做法是先确认消费端没有报错（排除重试风暴），再按业务键扩分区并把消费者数量提到与分区对齐，同时把单条调用改成批量提交、批量确认。按这个顺序做，一次十几万条的积压，经验区间是几十分钟到两小时可以追平。代价也很明确：临时调整的批量大小和确认方式，第二天通常要做一次回归，因为批量确认会把部分失败的处理语义放大，稍不注意就会出现个别消息重复处理。先止损、再回归，是项目里比较常见的节奏。

适用场景与边界

适合走这套判断的情况：有独立消费端、积压量可观测、业务本身允许延迟几分钟到几小时的异步链路，比如通知推送、对账、统计汇总、数据同步。这类场景里，扩容和批量优化通常是有效的。

不适合、也不必上这套做法的情况：同步调用链路里用户正在等结果，那不是队列积压问题，而是接口超时和同步等待设计的问题；强顺序且不可按业务键分区的单一队列，加消费者会直接破坏顺序；下游是同一张表同一批行的高频更新，扩容只会让锁等待更明显。队列积压的本质是生产速率与消费速率的关系，扩容量只是这条等式里的一项，等式本身不成立时，扩容没有意义。

常见问题

积压几十万条，一般要多久才能消费完？

按积压量除以速率差估算，差值越大越快；如果差值小于生产速率的日常波动，追平时间会被不断拉长，甚至一直追不平。

消费者已经加了一倍，为什么堆积量没明显下降？

常见原因是消费者数超过了分区分片数，多出来的实例在空转，或者瓶颈已经转移到下游数据库和第三方接口。

能不能直接清空积压队列重新来？

只适合日志、埋点这类可重放或可丢弃的数据；订单、支付、通知这类状态变更消息清掉就是丢单，要先确认有没有重放来源。

顺序消息积压了，能不能临时多开消费者？

同一个业务键的消息不能并行处理，否则会乱序；常见做法是按业务键扩分区，让不同键并行、同键串行。

怎么提前发现积压，而不是等用户来投诉？

监控未确认数量或消费延迟的增长斜率，比只盯绝对条数更有效；按 2026 年常见做法，连续五到十分钟单调上升就值得看一眼。

遇到积压先别急着扩容：把积压曲线、消费速率、生产速率摆出来，判断是暂停型还是失衡型，再定加消费者、提单条效率还是降级处理。交付时会把这几步做成一张值班核对表，避免半夜盲目扩容。强顺序、强一致的核心链路，临时扩容不能替代容量规划与限流设计。