RocketMq如何保证消息的顺序性

Kafka只支持同一个Partition内消息的顺序性一样,RocketMQ中也提供了基于队列(分区)的顺序消费。即同个队列内的消息可以做到有序,但是不同队列内的消息是无序的!

在RocketMq中,它的顺序消息通过客户端的三把锁以及同一队列顺序写入协同工作,确保消息从发送、存储到消费的全流程严格有序。其核心在于:

  • 分区一致性(同一业务逻辑的消息发送到同一个分区)
  • 存储顺序性(单线程顺序写入)
  • 消费串行化(单线程消费分区)

这种设计在需要严格顺序性的场景(如金融交易、订单处理)中非常关键。
RocketMQ 的顺序消息需要从 发送、存储、消费 三个环节严格控制顺序性,因此引入了三把锁:

锁类型作用阶段实现方式目标
发送端消息发送阶段, 固定 MessageQueue,确保同一业务逻辑的消息发送到同一个 MessageQueue,为后续的存储和消费顺序性奠定基础MessageQueueSelector消息分区一致性
Broker消息存储阶段, 确保同一 MessageQueue的消息按顺序写入磁盘CommmitLog顺序写机制+ConsumeQueue 分区索引,每个 MessageQueue 对应一个 ConsumeQueue 文件,记录消息在 CommitLog 中的位置(偏移量),确保同一 MessageQueue 的消息在 ConsumeQueue 中的顺序性消息存储顺序性
消费锁消息消费阶段,通过三把锁确保同一 MessageQueue的消息单线程串行消费分布式锁 + 本地锁 + ProcessQueue 锁
分布式锁:消费者向 Broker 申请分布式锁(默认每 20 秒续签),确保同一消费组内只有一个消费者能消费该 MessageQueue
本地锁:通过 MessageQueueLock 的 Synchronized 锁,确保同一消费者线程池中只有一个线程处理该 MessageQueue
ProcessQueue 锁:通过 ProcessQueue 的 ReentrantLock(consumeLock),防止消费过程中因负载均衡或重平衡导致 ProcessQueue 被删除
通过这三个组合确保同一 MessageQueue 的消息由单线程串行消费,避免多线程并发导致顺序错乱
消息消费顺序性

1.顺序消息的全流程

1.1 发送阶段:消息分区

生产者通过 MessageQueueSelector(如 ShardingKeySelector)将 同一业务逻辑的消息(如同一订单 ID)发送到 同一个 MessageQueue

当我们作为MQ的生产者需要发送顺序消息时,需要在Send方法中,传入一个MessageQueueSelector
MessageQueueSelector中需要实现一个select方法,这个方法就是用来定义要把消息发送到哪个MessageQueue的,通常可以使用取模法进行路由:

    public void send() {
        SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
            @Override
            public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
                Integer id = (Integer) arg;
                //根据参数,计算出一个要接收消息的MessageQueue的下标
                int index = id % mqs.size();
                //返回这个MessageQueue
                return mqs.get(index);
            }
        }, orderId);
    }

通过以上形式就可以将需要有序的消息发送到同一个队列中。需要注意的是,这里需要使用同步发送的方式!

1.2.存储阶段:顺序写入

Broker 接收到消息后,根据 MessageQueue 的物理分区(CommitLog + ConsumeQueue)进行 顺序写入。

同一 MessageQueue 的消息在物理文件中 RocketMQ 通过单线程写入 CommitLog 保证顺序性,按顺序追加写入,保证存储顺序性。

消息按照顺序发送的消息队列中之后,那么,消费者如何按照发送顺序进行消费呢?

1.3.消费阶段:串行消费

RocketMQ的MessageListener回调函数提供了两种消费模式:

  • 有序消费模式MessageListenerOrderly
  • 并发消费模式MessageListenerConcurrently。

所以,想要实现顺序消费,需要使用MessageListenerOrderly模式接收消息:

        consumer.registerMessagelistener(new MessagelistenerOrderly() {
            @Override
            public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
                System.out.printf("Receive order msg:" + new String(msgs.get(0) .getBody( )));
                return ConsumeOrderlyStatus.SUCCESS;
            }
        }, new ConsumeOrderlyContext());

当我们用以上方式注册一个消费之后,为了保证同一个队列中的有序消息可以被顺序消费,就要保证RocketMQ Broker只会把消息发送到同一个消费者上,这时候就需要加锁了。

在实现中,ConsumeMessageOrderlyService 初始化的时候,会启动一个定时任务,会尝试向 Broker 为当前消费者客户端申请分布式锁(第一把锁)。如果获取成功,那么后续消息将会只发给这个Consumer。

接下来在消息拉取的过程中,消费者会一次性拉取多条消息的,并且会将拉取到的消息放入 ProcessQueue,同时将消息提交到消费线程池进行执行。

那么拉取之后的消费过程,怎么保证顺序消费呢?这里就需要更多的锁了

RocketMQ在消费的过程中,需要申请 MessageQueue 锁,消费线程通过 MessageQueueLock 的 synchronized 锁(第二把锁)住当前 MessageQueue 的消费过程,确保在同一时间,一个队列中只有一个线程能处理列中的消息。

获取到 MessageQueue 的锁后,就可以从ProcessQueue中依次拉取一批消息处理了,但是这个过程中,为了保证消息不会出现重复消费,还需要对ProcessQueue进行加锁,通过 ProcessQueue 的 ReentrantLock。然后就可以开始处理业务逻辑了

总结下来就是三次加锁:

  • 首先锁定Broker上的MessageQueue,确保消息只会投递到唯一的消费者(分布式锁)
  • 然后对本地的MessageQueue加锁,确保只有一个线程能处理这个消息队列。(synchronized)
  • 最后对存储消息的ProcessQueue加锁,确保在重平衡的过程中不会出现消息的重复消费。(ReentrantLock)

在这里插入图片描述

里面有几个点需要大家注意下:

2.第三把锁有什么用?

前面介绍客户端加锁过程中,一共加了三把锁,那么,有没有想过这样一个问题,第三把锁如果不加的话,是不是也没问题?

因为我们已经对MessageQueue加锁了,为啥还需要对ProcessQueue再次加锁呢?

这里其实主要考虑的是重平衡(Rebalance)的问题

当我们的消费者集群,新增了一些消费者,发生重平衡的时候,某个队列可能会原来属于客户端A消费的,但是现在要重新分配给客户端B了。

这时候客户端A就需要把自己加在Broker上的锁解掉,而在这个解锁的过程中,就需要确保消息不能在消费过程中就被移除了,因为如果客户端A可能正在处理一部分消息,但是位点信息还没有提交,如果客户端B立马去消费队列中的消息,那存在一部分数据会被重复消费

那么如何判断消息是否正在消费中呢,就需要通过这个ProcessQueue上面的锁来判断了,也就是说在解锁的线程也需要尝试对ProcessQueue进行加锁,加锁成功才能进行解锁操作。以避免过程中有消息消费。

3.顺序消费存在的问题

通过上面的介绍,我们知道了RocketMQ的顺序消费是通过在消费者上多次加锁实现的,这种方式带来的问题就是会降低吞吐量,并且如果前面的消息阻寨,会导致更多消息阻塞。所以,顺序消息需要慎用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

ZNineSun

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值