请教一个面试题： MQ 顺序消费时出错，怎么处理？

[dumbbell5kg]

大致意思就是：MQ 顺序消费时，消息 2 依赖消息 1 ，消息 3 依赖消息 2 ，如果消息 2 出错了，后续还有几十万条消息，应该怎么处理？

• 我给出的方案是后续的消息先记到表里，等消息 2 能成功消费了，再重放表里的记录。
• 面试官回到：“它数量如果特别大的话，你要持久化能做下去吗？我们 MQ 的几十万条消息这边都在堵死，你发现出问题是两天前了，才会发现的报错，然后数据库整个都已经堵死在里面了。”

下面是面试官的原话：

• 假如我这个消息有顺序问题，前面一二三必须有依赖性，二依赖一，三依赖二，这时候如果前面的数据稍微出问题，能保证后面如果再读的话就发不出去了，因为比如说我有三个 update 语句，通过这种队列去消费了，然后你肯定要第一条消费完之后第二条消费对吧？不然第一条消费失败了，你直接拿第二条消费，还有第三条消费成功，那你怎么解决这个问题？
• 他第一条消费失败了，你怎么能处理呢，就保证他不会消费第二条或者是直接放在那里。
• 没成功的话就 hang 在那边，包括我们整个消费就不执行了，直接直接就业务就卡死了，只要你数据代码有问题，然后启动一下消费者，后面几万几十万进去都卡在那不动了。

[poltao]

根据他的回答来看用的不还是消息队列本身的机制嘛（加上业务消费出错直接报异常），没搞明白他问这个问题的意义是什么，这个面试题不好

[blackstack]

感觉他这个设计是有问题的，如果队列同时存在 N 个消费者，他又要怎么去控制消息消费的前后顺序？？

整个题目看起来是在一个错误的设计上，把一个问题复杂化，再寻找一个解决的方法来纠正整个错误。

[wangtian2020]

事务回滚不行吗

[meshell]

和二楼的想法一样。

[blackstack]

如果他每次依赖的消息数量是固定的，比如固定 3 个，那消费者每次取 3 条消息，取出后就进行消息确认，再对消息内的数据进行处理。

如果在处理的过程出现异常，将这三条存在异常的消息发到另外一个专门处理异常的队列，由另外一个消费者来处理这些异常数据。

如果他连每次依赖的消息数量都不固定，我还是认为这个设计是存在问题的。

[lyxxxh2]

[laravel - 任务链]( https://learnku.com/docs/laravel/10.x/queues/14873#f62992)
框架自带的队列,一般都有任务链吧。

[Amex]

别的不说 光是这个“发现出问题是两天前了”
没有 alarm 么
在我眼里能拖两天的问题说明不是啥严重的问题

[Amex]

另外 mq 自带 dlq 吧 把 message 放进去呗

[loveaeen]

tag 按照依赖进行消息区分，同类型打到一个分区里，减少队列堆积数。
然后要不就发到死信做二次消费，还报错就转人工吧。

[ytmsdy]

同意二楼的观点，这个消息队列设计的就是有问题的。为什么要设计一个相互依赖的消息队列？
为什么不在设计队列的时候，把一整个消费动作都整理成一个？反正一个出错了，整个事务都是要混滚的。

[Mithril]

@SeaTac 是的，几十万的消息堵了两天都没发现，说明这玩意压根就不重要，属于平时就没人看的东西。这种堵了就堵了，没出啥问题就删了完事。

[barnetime]

你不如问他 怎么保证消息的顺序性, 发送的时候时 123, 到 mq 变成了 213 (

[HDRiUZoPc6Y3l0Un]

有些面试官问的就是他们开发中遇到的问题，但可能本身就是设计缺陷，却要应聘者找答案给他解决，这种解决，每个人的方式都不一样，我能给你解决鸡毛啊。

[Mithril]

@ytmsdy 这种设计感觉就像是在用 NoSQL 去做 RDBMS 的活。好好的关系型数据库的事务和回滚机制不用，非要自己在程序里面加一堆的锁来回绕。

[me1onsoda]

不理解为什么会 hang 住，默认已经实现按序消费，1 消费了，消费 2 出错发回队列，后续的消息也重新发回队列，还是顺序消费的

[abc950309]

主流 MQ 都有顺序保证机制的，比如 Kafka 的 Message Key 。如果消费侧配置的没问题，就可以确保同一 Message Key 下的消息消费是有序的。

[adgfr32]

他这里设计有点拧巴，让消息之间有逻辑上的依赖可以，但是不代表有依赖就要等前置项消费完。
可以接收到一个消息找个地方暂存，然后这条消息就 ack ，当最后一个消息到，校验下是否收齐了，然后 merge 。

[adgfr32]

你的方案是对的，几十万消息根本就是特别低的量级，找个表存一下。
换句话说，如果他们的量只有几十万，直接同步做算了，为啥要整成异步，结果还在用同步的思想硬整异步的逻辑。

[bronyakaka]

1 、重试
2 、出错的消息标记为失败并入库，后续手动处理
3 、如果是强依赖，那根本不能消费处理后面的消息，直接告警算了。弱依赖就先消费存着呗

[siweipancc]

架构错误，为什么这么设计？