RocketMQ 针对不同的业务场景还提供了普通消息、事务消息、顺序消息和延时(定时)消息等几种消息类型
消息回溯
消息类型
1. 普通消息
不需要保证消息的顺序，所以消息可以大规模并发地发送和消费，吞吐量很高，适合大部分场景
2. 顺序消息
顺序消息是RocketMQ提供的一种严格按照顺序来发布和消费的消息。顺序发布和顺序消费是指对于指定的一个 Topic，生产者按照一定的先后顺序发布消息；消费者按照既定的先后顺序订阅消息，即先发布的消息一定会先被客户端接收到。 两种类型 全局顺序：对于指定的一个 Topic，所有消息将按照严格的先入先出（FIFO）的顺序，进行顺序发布和顺序消费； 分区顺序：对于指定的一个 Topic，所有消息根据 Sharding Key 进行区块分区，同一个分区内的消息将按照严格的 FIFO 的顺序，进行顺发布和顺序消费，可以保证一个消息被一个进程消费。 在注册场景中，可使用用户 ID 作为 Sharding Key 来进行分区，同一个分区下的新建、更新或删除注册信息的消息必须按照 FIFO 的顺序发布和消费。
3. 定时、延时消息
定时消息：Producer 将消息发送到消息队列服务端，但并不期望立马投递这条消息，而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费，该消息即定时消息。 延时消息：Producer 将消息发送到消息队列服务端，但并不期望立马投递这条消息，而是延迟一定时间后才投递到 Consumer 进行消费，该消息即延时消息。 阿里云版支持任意维度的延时消息，并且支持定时消息；开源版只支持固定level的延时消息。
4. 事务消息
Half : 半事务消息
RocketMQ提供类似 X/Open XA 的分布式事务功能，通过RocketMQ事务消息能达到分布式事务的最终一致。 半事务消息 暂不能投递的消息，发送方已经成功地将消息发送到了消息队列 服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。 消息回查 由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该询问过程即消息回查。
https://blog.csdn.net/daijiguo/article/details/89059963
消息重试
顺序消息重试
对于顺序消息，当消费者消费消息失败后，RocketMQ会自动不断地进行消息重试（每次间隔时间为 1 秒），这时，应用会出现消息消费被阻塞的情况。建议使用顺序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。
无序消息重试
对于无序消息（普通、定时、延时、事务消息），当消费者消费消息失败时，可以通过设置返回状态达到消息重试的结果。 无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
参考文章
若有收获，就点个赞吧
0 人点赞
