我们在项目开发过程中,有需要使用RocketMQ顺序消息的场景,该如何使用呢?顺序消息的原理是怎样的呢?本文进行了一些探讨。
一、顺序消息的定义
顺序消息(FIFO:First Input First Output)是一种严格按照顺序进行发布和消费的消息类型。要求消息的发布和消息消费都按照顺序进行。
二、顺序消息的设计
在探讨RocketMQ中的普通消息的实现之前,我们有必要了解一下顺序消息的设计。下面分几种场景进行讨论。
1、发布者、MQ、消费者均为单点时的设计
1)Producer发送消息M1至MQ,MQ收到消息后进行返回,Producer再发送M2。
2)Consumer消费M1,消费完进行返回。Consumer消费M2。
基于这种设计,Producer的顺序发送很好实现,Consumer的顺序消费需要考虑M1消费失败、或者返回超时的情况。
消费失败的处理:消费失败意味着收到了明确的失败编码,对于失败的处理可能有多种策略,例如直接抛弃,但是进行记录后人工干预;重试一定的次数,仍然失败则进行记录;重试一定的时间,仍然失败则进行记录等。
返回超时的处理:超时意味着消息可能被正常消费,也可能未被消费。可能的策略有:重试一定的次数或时间,仍然超时则进行记录。但这可能引入新的问题,消息的重复消费,从MQ层面上怎么解?
2、发布者集群、MQ单点、消费者集群时的设计
1)Producer1发送消息M1至MQ,MQ收到消息后进行返回,返回时是否需要通知每个Producer呢?我们认为可以只返回给Producer1,由调用方逻辑控制再发送M2。
2)Consumer1消费M1,消费完进行返回。Consumer2消费M2。
关于消费失败或者返回超时的情况,同单点时的设计。
我们观察到Producer的单点部署和集群部署对我们分析问题不会产生太大的干扰,消息发送的顺序性是可以由调用方逻辑控制的,基于此,我们再来考虑下面的情况。
3、发布者集群、MQ集群、消费者集群时的设计
1)Producer发送消息M1至MQ,MQ收到消息后进行返回,Producer再发送M2。
2)Consumer消费M1,消费完进行返回,需要同时返回给多个MQ Server,都成功后再消费M2。
这个模型存在这样的问题:如何保证多个MQ Server都收到成功消息?一条MQ的消费需要多个应答,是否合理?考虑到消费失败和消费超时,情况变得愈加复杂。
当MQ变为集群后,顺序消息的设