当前位置：首页 > news >正文

MQ 核心难题与解决方案

news 2026/6/17 7:58:00

消息堆积 (Message Accumulation)

面试回复话术：

“在生产环境中，消息堆积通常是因为消费者处理速度跟不上生产速度，或者消费者出现故障。
针对商旅系统中的**‘订单同步’或‘报表生成’**场景，如果发生堆积，我的处理方案是：
紧急扩容：如果是 Kafka 或 RocketMQ，我可以临时增加 Topic 的分区数（Partition/Queue），同时成倍增加消费者实例的数量，利用并行消费能力快速消化积压。
排查卡点：通过监控查看消费者日志，确认是因为数据库死锁、第三方接口超时（如航司接口响应慢），还是代码逻辑死循环。
临时降级：如果是因为下游数据库压力大，可以暂时让消费者只消费关键消息，非核心消息（如日志、非实时统计）暂存或丢弃，优先保证核心业务流程。”

技术应用场景：

场景：大促期间（如双11或暑运），大量用户同时下单，订单消息瞬间涌入 MQ。
技术点：
- Kafka：增加 Partition 数量，调整消费者组的max.poll.records参数。
- RocketMQ：利用其天然的负载均衡机制，动态增加消费者实例。

数据一致性 (Data Consistency)

面试回复话术：

“在分布式系统中，我主要追求最终一致性。
比如在**‘支付成功后扣减库存’或‘出票成功后发送通知’**的场景中，为了保证本地数据库事务和 MQ 消息发送的原子性，我通常采用以下方案：
RocketMQ 事务消息：利用 RocketMQ 的TransactionListener。先发送 Half Message，执行本地事务（如更新订单状态为‘已支付’），根据本地事务结果 Commit 或 Rollback 消息。如果本地事务成功但 Commit 失败，MQ 会回查本地事务状态。
本地消息表（通用方案）：如果使用的是 Kafka 或 RabbitMQ，我会在业务库中建一张‘消息表’。在同一个本地事务中，既更新业务数据，又插入一条消息记录。然后通过一个定时任务轮询这张表，将未发送的消息投递到 MQ。这能保证‘业务执行’和‘消息发送’要么都成功，要么都失败。”

技术应用场景：

场景：商旅订单支付。
流程：用户支付 -> 支付宝回调 -> 更新订单状态（本地事务） -> 发送 MQ 消息 -> 积分服务/发票服务消费。
关键点：绝不能先提交事务再发消息（可能导致消息发不出去，下游不知道支付成功）；也不能先发消息再提交事务（可能导致消息发了，但事务回滚了，下游收到假消息）。

重复消费与幂等性 (Idempotency)

面试回复话术：

“MQ 只能保证‘至少投递一次’，无法保证‘只投递一次’。网络抖动或消费者重启都可能导致重复消息。
因此，消费端的幂等性设计是必须的。
我的做法是：
数据库唯一键：比如在‘支付流水表’中，利用payment_id做唯一索引。插入时如果报DuplicateKeyException，则说明已处理过，直接忽略。
Redis 原子操作：在处理前，先用setnx设置一个 key（如order_process:{orderId}）。如果设置成功则处理业务，处理完删除或保留；如果设置失败，说明正在处理或已处理。
状态机检查：在更新订单状态时，带上状态条件。例如UPDATE order SET status = 2 WHERE id = 1 AND status = 1。如果重复消费，状态已经是 2，SQL 影响行数为 0，自然幂等。”

技术应用场景：

场景：退款接口。
风险：MQ 重试导致给用户退了两次款。
解决：在退款记录表中，以refund_request_id为唯一键，或者在 Redis 中记录refunded:{orderId}状态。

顺序消息 (Ordered Messages)

面试回复话术：

“并不是所有业务都需要全局有序，那会严重牺牲性能。大多数场景下，我们只需要**‘分区有序’。
比如在‘订单状态流转’**（创建 -> 支付 -> 发货）场景中，必须保证同一个订单的消息按顺序处理。
我的实现方案是：
发送端：使用 MQ 提供的 Hash 算法（如SendCallback中的MessageQueueSelector），将同一个orderId的消息都发送到同一个 Partition/Queue 中。
消费端：
Kafka：天然保证 Partition 内有序，单线程消费即可。
RocketMQ：使用MessageListenerOrderly。它会锁定当前队列，保证同一时刻只有一个线程消费该队列的消息。
注意：如果消费者内部使用了线程池异步处理，会破坏顺序性，必须在主线程串行处理，或者使用内存队列在应用层做二次排队。”

技术应用场景：

场景：商旅中的“改签”和“退票”操作。
逻辑：必须先处理“改签”成功，才能处理后续的“退票”。如果乱序，可能导致数据状态错误。通过将orderId作为 Hash Key，确保这两个操作进入同一个队列被顺序消费。

综合技术选型对比（面试加分项）

如果面试官问：“为什么选 RocketMQ/Kafka/RabbitMQ？” 你可以这样回答：

特性	RocketMQ(推荐用于核心业务)	Kafka(推荐用于日志/大数据)	RabbitMQ(推荐用于中小规模/低延迟)
核心优势	金融级可靠性、支持事务消息、支持延迟消息（如订单30分钟未支付自动关闭）。	极高的吞吐量，适合海量日志收集、用户行为追踪。	低延迟，路由灵活（Exchange），管理界面友好。
适用场景	订单交易、支付结算、削峰填谷。	用户行为日志、流式计算数据源。	即时通讯、任务分发。
你的选择	“在商旅/ToB业务中，因为涉及资金和订单状态，对数据可靠性要求极高，且我们需要‘延迟消息’来处理订单超时，所以我首选 RocketMQ。”

总结：如何在面试中串联这些点

面试官：你刚才提到了用 MQ 解耦，那如果 MQ 挂了或者消息丢了怎么办？

你的回答：

“这是一个非常好的问题。针对商旅业务的高可靠性要求，我是从三个层面来保障的：
防止消息丢失：
发送端：开启 Confirm 机制或事务消息，确保消息真正到达 Broker。
存储端：RocketMQ 配置同步刷盘（Sync Flush）和同步复制（Sync Replication），虽然牺牲一点性能，但保证数据不丢。
消费端：手动 ACK。只有业务逻辑完全执行成功后，才返回CONSUME_SUCCESS，否则返回RECONSUME_LATER让 MQ 稍后重试。
应对消息堆积：
我会配置监控报警（如 Prometheus + Grafana），一旦堆积阈值触发，自动触发脚本扩容消费者实例。
保证数据一致性：
正如我刚才提到的，利用本地消息表或RocketMQ事务消息，配合消费端的幂等性设计（Redis/DB唯一键），确保数据最终一致。”