常见的消息类型包括无序消息(普通消息)、有序消息和延时消息三种。
概念：无序消息即没有顺序的消息，具体的：producer 只管发送消息，consumer 只管接收消息，消息和消息之间的顺序并没有保证，可能先发送的消息先消费，也可能先发送的消息后消费。举个简单例子，producer 依次发送 order id 为 1、2、3 的消息到 broker，consumer 接到的消息顺序有可能是 1、2、3，也有可能是 2、1、3 等情况，这就是普通消息。
优势：因为不需要保证消息的顺序，所以消息可以大规模并发地发送和消费，吞吐量很高，适合大部分场景。
概念：按照一定的先后顺序的消息类型，举个例子，producer 依次发送 order id 为 1、2、3 的消息到 broker，consumer 接到的消息顺序也就是 1、2、3 ，而不会出现普通消息那样的 2、1、3 等情况。
分类：有序消息分为全局有序消息和局部有序消息两种类型。
对于全局有序消息，将对应该类型的topic的queue数变为1，这样一来，只要 producer 按照 1、2、3、4 的顺序去发送消息，那么 consumer 自然也就按照 1、2、3、4 的顺序去消费，这就是全局有序消息。但由于一个topic只有一个queue，即使我们有多个producer实例和consumer实例也很难提高消息吞吐量，效率低下。
对于局部有序消息，实际上可看作吞吐量和有序之间的折中方案，以订单消息为例，订单消息可以再细分为订单创建、订单付款、订单完成等消息，这些消息都有相同的 orderId。对于某一个orderId只有顺序处理才符合业务逻辑。但不同orderId的消息是可以并行的，不会影响到业务。这时候就常见做法就是将orderId进行处理，将orderId相同的消息发送到topicB的同一个queue，不同orderId的消息发送到不同的queue中，从而实现局部有序。具体的，假设我们topicB有2个queue，那么我们可以对id取余，奇数的发往queue0，偶数的发往queue1，消费者按照queue消费时，就能保证queue0里面的消息有序消费，queue1里面的消息有序消费。由于一个topic可以有多个queue，假设queue数是n，理论上性能就是全局有序的n倍。
概念：延时消息，简单来说就是当producer将消息发送到broker后，会延时一定时间后才投递给consumer进行消费。RcoketMQ的延时等级为：1s，5s，10s，30s，1m，2m，3m，4m，5m，6m，7m，8m，9m，10m，20m，30m，1h，2h。level=0，表示不延时。level=1，表示 1 级延时，对应延时 1s。level=2 表示 2 级延时，对应5s，以此类推。
场景：适用于消息生产和消费之间有时间窗口要求的场景。比如说我们网购时，下单之后是有一个支付时间，超过这个时间未支付，系统就应该自动关闭该笔订单。那么在订单创建的时候就会就需要发送一条延时消息(延时15分钟)后投递给consumer，consumer接收消息后再对订单的支付状态进行判断是否关闭订单。
实现：Broker将延时消息以SCHEDULE_TOPIC_XXXX为topic名称将消息进行持久化，同时定时任务ScheduleMessageService通过不断读取topic为SCHEDULE_TOPIC_XXXX的queueId，判断延时时间达到后为会进行消息的还原处理，当消息被还原后就可以被消费者拉取消费了。
正常情况下，消费者消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发出的确认消息形式不同，例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offet的概念，简单说一下，就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。而消息幂等性实际上是保证消息不被重复消费，但是由于网络闪断、断电重启等原因可能导致消息队列无法确认已经发送过的消息是否已经被消费，当超过超时时间后会再次将消息发送给消费者，从而导致消息的重复消费。因此消息的幂等性无法由消息侧来保证，应该由业务方结合具体的业务来保证。
原文：https://www.cnblogs.com/huaiheng/p/13180181.html