Skip to content

面试速答(先看这里)

**一句话结论:**普通消息,就是很普通,没有什么特别的, 和顺序消息相比的话,就是消息发送到 MQ 后,消费者不保证严格按照发送顺序消费。

60秒标准回答:

普通消息,就是很普通,没有什么特别的, 和顺序消息相比的话,就是消息发送到 MQ 后,消费者不保证严格按照发送顺序消费。消息可能会被乱序消费

顺序消息是指生产者按照顺序发送消息,消费者也必需严格按顺序消费的消息。一般是通过绑定同一个分区来实现的

顺序消息一般用在对顺序性有严格要求的场景中,比如是涉及到状态流转,尤其是那种状态流转的时间间隔很短的

**答题顺序:**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点

回答主线:

  • **要点1:**顺序消息是指生产者按照顺序发送消息,消费者也必需严格按顺序消费的消息。
  • **要点2:**顺序消息一般用在对顺序性有严格要求的场景中,比如是涉及到状态流转,尤其是那种状态流转的时间间隔很短的。
  • **要点3:**但是大多数情况下,我们用顺序消息的并不多,因为这只对收消息的应用有好处,而对发送消息的应用没有什么好处,反而增加了复杂性(而且还有吞吐量低、维护成本高等缺点,后面扩展知识介绍)。
  • **要点4:**所以,实际上的大多数场景,并不一定会直接用MQ的顺序消息,而是倾向于消费者自己排序。
  • **要点5:**其实,顺序消息一般用的并不多,上面提了原因和替代方案。

**记忆锚点:**key → 消息按照 key 分配到固定队列或分区 → 相同 key 分区到同一个队列 → 这就导致消息无法并发 → 分区到同一个队列 → 分配到固定队列

易错提醒:

  • (以下部分为个人经验,如果面试官经验丰富,你就和他提,如果感觉他也就一般,就不要提了,他可能听不懂。
  • 如果顺序消息消费失败,需要重试,且必须保证重试后顺序仍然正确。

加分表达:

  • 顺序消息是指生产者按照顺序发送消息,消费者也必需严格按顺序消费的消息。
  • 顺序消息一般用在对顺序性有严格要求的场景中,比如是涉及到状态流转,尤其是那种状态流转的时间间隔很短的。
  • 如果系统是分别要处理这两个消息,那么可能就需要先处理确认收货,再处理订单完结,否则就会出问题的。

追问准备:

  • 围绕「key」:底层原理是什么?使用时有哪些边界和常见坑?
  • 围绕「消息按照 key 分配到固定队列或分区」:底层原理是什么?使用时有哪些边界和常见坑?
  • 围绕「相同 key 分区到同一个队列」:底层原理是什么?使用时有哪些边界和常见坑?
  • 如果线上出现异常,你会如何定位、验证并规避?

典型回答 ​

普通消息,就是很普通,没有什么特别的, 和顺序消息相比的话,就是消息发送到 MQ 后,消费者不保证严格按照发送顺序消费。消息可能会被乱序消费。

顺序消息是指生产者按照顺序发送消息,消费者也必需严格按顺序消费的消息。一般是通过绑定同一个分区来实现的。

📄 ✅RocketMQ如何保证消息的顺序性?

打开文档:✅RocketMQ如何保证消息的顺序性?

顺序消息一般用在对顺序性有严格要求的场景中,比如是涉及到状态流转,尤其是那种状态流转的时间间隔很短的。

比如贷款的还款成功消息和结清消息。交易的确认收货消息和订单完结消息,基本都是同时发生的。如果系统是分别要处理这两个消息,那么可能就需要先处理确认收货,再处理订单完结,否则就会出问题的。

(以下部分为个人经验,如果面试官经验丰富,你就和他提,如果感觉他也就一般,就不要提了,他可能听不懂。(手动狗头))

但是大多数情况下,我们用顺序消息的并不多,因为这只对收消息的应用有好处,而对发送消息的应用没有什么好处,反而增加了复杂性(而且还有吞吐量低、维护成本高等缺点,后面扩展知识介绍)。而要做顺序消息,又需要发送者来做代码改造,所以很多系统都不愿意改,比如交易系统,不可能这么改的。

所以,实际上的大多数场景,并不一定会直接用MQ的顺序消息,而是倾向于消费者自己排序。比如下面这篇文中介绍的几种方案:

📄 ✅MQ出现消息乱序了如何解决?

打开文档:✅MQ出现消息乱序了如何解决?

扩展知识 ​

顺序消息 ​

其实,顺序消息一般用的并不多,上面提了原因和替代方案。确实,他的缺点也比较明显。

1、并发能力受限

为了保证顺序,通常会把消息按照 key 分配到固定队列或分区。并且要求同一个 key 的消息串行消费。

这就导致消息无法并发消费,那么处理速度就会大大下降,尤其是当某个消息处理慢的话,会拖慢整个队列的速度。

2、发消息复杂

如果顺序消息消费失败,需要重试,且必须保证重试后顺序仍然正确。所以这种容错策略设计起来都比较复杂。

而且一旦一个消息处理失败,可能会阻塞后续消息的发送和消费。

3、可能导致数据倾斜

为了保证顺序,消息必须按照 相同 key 分区到同一个队列。如果业务 key 太多或者分布不均匀,会导致队列热点和消费不平衡。