一 消息的分类
1.1 普通消息
1.1.1 同步消息
同步发送消息是指,Producer发出⼀条消息后,会在收到MQ返回的ACK之后才发下⼀条消息。该方式的消息可靠性最高,但消息发送效率太低。
代码层面:
1.1.2 异步发送消息
异步发送消息是指,Producer发出消息后无需等待MQ返回ACK,直接发送下⼀条消息。该方式的消息靠性可以得到保障,消息发送效率也可以。
代码层面
RocketMQ支持异步消息发送,这意味着生产者在发送消息后不会等待消息的发送结果,而是通过回调函数来处理发送结果(如记录表记录失败消息,进行重发机制)。这种方式适用于对实时性要求不高,但需要高并发处理的场景。
综述就是虽然RocketMQ的异步发送允许生产者在发送消息后不等待结果,但通过异步回调和内置的重试及流控机制,生产者最终可以确保消息的成功发送。
1.1.3 单向发送消息
单向发送消息是指,Producer仅负责发送消息,不等待、不处理MQ的ACK。该发送方式时MQ也不返回ACK。该方式的消息发送效率最高,但消息可靠性较差。
代码层面:
1.2 顺序消息
发送消息的顺序和消费者消费消息的顺序要保持一致。
例如,现在有TOPIC ORDER_STATUS (订单状态),其下有4个Queue队列,该Topic中的不同消息用于描述当前订单的不同状态。假设订单有状态:未支付、已支付、发货中、发货成功、发货失败。
当发送和消费参与的Queue只有一个时,所保证的有序是整个Topic中消息的顺序, 称为全局有序。
如果有多个Queue参与,其仅可保证在该Queue分区队列上的消息顺序,则称为分区有序。一般性的选择算法是,让选择key(或其hash值)与该Topic所包含的Queue的数量取模,其结果即为选择出的Queue的QueueId。
取模算法存在一个问题:不同选择key与Queue数量取模结果可能会是相同的,即不同选择key的消息可能会出现在相同的Queue,即同一个Consuemr可能会消费到不同选择key的消息。这个问题如何解决?一般性的作法是,从消息中获取到选择key,对其进行判断。若是当前Consumer需要消费的消息,则直接消费,否则,什么也不做。这种做法要求选择key要能够随着消息一起被 Consumer获取到。此时使用消息key作为选择key是比较好的做法。
1.3 延时消息*
典型的应用场景是,电商交易中超时未支付关闭订单的场景,12306平台订票超时未支付取消订票的场景。 当消息写入到Broker后,