典型回答

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

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

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

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

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

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

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

扩展知识

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

1、并发能力受限

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

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

2、发消息复杂

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

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

3、可能导致数据倾斜

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