RocketMQ系列之顺序消息原理解析（八）

已于 2022-05-31 13:49:19 修改
阅读量400 收藏
点赞数
分类专栏： 消息中间件rocketMq源码解析 文章标签： rocketMq 源码解析 顺序消息
于 2020-11-10 09:07:25 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u012394095/article/details/109591733
版权

前言

本文是个系列文章，源码的阅读很多在前文中讲过，很多时候不会从源码入口开始讲起， 本文主要讲的是普通消息的客户端线程处理模型，以push模式为准

rocketMq的顺序消息，通过两种机制来保证消息只会被一个线程处理

  1. borker维护全局队列锁
  2. 客户端内维护了局部队列锁，保证在一个JVM应用里面，这个队列只会被一个线程消费。

我们回顾一下rocketMQ的顺序消息的大致原理，通过队列内部的offset的有序性来保证单个队列里面的有序性，只需要同一个队列只有一个消费者一个线程消费，那么就可以保证消息是有序的被消费的。

接下来我们带着几个问题来看源码

  1. broker的全局锁是如何维护的？维护全局锁有什么作用

  2. 当新增消费者或者减少消费者的时候，如何保证全局顺序消费。

broker全局锁

ConsumeMessageOrderlyService 该类在初始化的时候会生成一个定时器，这个

public ConsumeMessageOrderlyService(DefaultMQPushConsumerImpl defaultMQPushConsumerImpl,
       // ....省略代码
        this.scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(new ThreadFactoryImpl("ConsumeMessageScheduledThread_"));
    }
                                    
// 启动
 public void start() {
        if (MessageModel.CLUSTERING.equals(ConsumeMessageOrderlyService.
                                           this.defaultMQPushConsumerImpl.messageModel())) {
            this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
                @Override
                public void run() {
                    ConsumeMessageOrderlyService.this.lockMQPeriodically();
                }
            }, 1000 * 1, ProcessQueue.REBALANCE_LOCK_INTERVAL, TimeUnit.MILLISECONDS);
        }
    }

上面的代码，初始化了一个定时线程池，然后在ConsumeMessageOrderlyService启动的时候，创建了一个任务，1s执行一次，lockMQPeriodically这个方法就是给当前客户端所消费的所有队列去borker进行上锁。全局锁就是在这里进行上的

lockMQPeriodically
public synchronized void lockMQPeriodically() {
        if (!this.stopped) {
            this.defaultMQPushConsumerImpl.getRebalanceImpl().lockAll();
        }
    }
lockAll
public void lockAll() {
        // 获取borker和队列信息
        HashMap<String, Set<MessageQueue>> brokerMqs = this.buildProcessQueueTableByBrokerName();

        Iterator<Entry<String, Set<MessageQueue>>> it = brokerMqs.entrySet().iterator();
        while (it.hasNext()) {
            Entry<String, Set<MessageQueue>> entry = it.next();
            final String brokerName = entry.getKey();
            final Set<MessageQueue> mqs = entry.getValue();

            if (mqs.isEmpty())
                continue;
            // 获取borker
            FindBrokerResult findBrokerResult = this.mQClientFactory.
              findBrokerAddressInSubscribe(brokerName, MixAll.MASTER_ID, true);
            if (findBrokerResult != null) {
                LockBatchRequestBody requestBody = new LockBatchRequestBody();
                requestBody.setConsumerGroup(this.consumerGroup);
                requestBody.setClientId(this.mQClientFactory.getClientId());
                requestBody.setMqSet(mqs);

                try {
                    // 进行全局锁上锁
                    Set<MessageQueue> lockOKMQSet =
                      this.mQClientFactory.getMQClientAPIImpl().lockBatchMQ(
                      findBrokerResult.getBrokerAddr(), requestBody, 1000);
                  // 设置上锁成功的ProcessQueue 的locked = true
                  for (MessageQueue mq : lockOKMQSet) {
                        ProcessQueue processQueue = this.processQueueTable.get(mq);
                        if (processQueue != null) {
                            if (!processQueue.isLocked()) {
                                log.info("the message queue locked OK, Group: {} {}", this.consumerGroup, mq);
                            }
                            processQueue.setLocked(true);
                            processQueue.setLastLockTimestamp(System.currentTimeMillis());
                        }
                    }
                  // 设置上锁失败的ProcessQueue 的locked = false
                    for (MessageQueue mq : mqs) {
                        if (!lockOKMQSet.contains(mq)) {
                            ProcessQueue processQueue = this.processQueueTable.get(mq);
                            if (processQueue != null) {
                                processQueue.setLocked(false);
                                log.warn("the message queue locked Failed, Group: {} {}", this.consumerGroup, mq);
                            }
                        }
                    }
                } catch (Exception e) {
                    log.error("lockBatchMQ exception, " + mqs, e);
                }
            }
        }
    }
  1. 发起队列上锁请求
  2. 设置上锁成功的ProcessQueue 的locked = true
  3. 设置上锁失败的ProcessQueue 的locked = false

ProcessQueue里面的locked属性在进行顺序消费的时候会频繁的使用到

borker上锁

AdminBrokerProcessor 这个是borker里面的代码入口，RequestCode.LOCK_BATCH_MQ 找到switch里面的这个，进入lockBatchMQ方法

private RemotingCommand lockBatchMQ(ChannelHandlerContext ctx,
        RemotingCommand request) throws RemotingCommandException {
        final RemotingCommand response = RemotingCommand.createResponseCommand(null);
        LockBatchRequestBody requestBody = LockBatchRequestBody.decode(request.getBody(), LockBatchRequestBody.class);
			// 调用全局锁管理类进行上锁，将上锁成功的队列返回
        Set<MessageQueue> lockOKMQSet = this.brokerController.getRebalanceLockManager()
          .tryLockBatch(
            requestBody.getConsumerGroup(),
            requestBody.getMqSet(),
            requestBody.getClientId());
				// 返回上锁成功的队列
        LockBatchResponseBody responseBody = new LockBatchResponseBody();
        responseBody.setLockOKMQSet(lockOKMQSet);

        response.setBody(responseBody.encode());
        response.setCode(ResponseCode.SUCCESS);
        response.setRemark(null);
        return response;
    }

步骤说明：

  1. 调用全局锁管理类进行上锁，将上锁成功的队列返回
  2. 返回上锁成功的队列
RebalanceLockManager
public Set<MessageQueue> tryLockBatch(final String group, final Set<MessageQueue> mqs,
        final String clientId) {
        // 已经成功上锁的队列
        Set<MessageQueue> lockedMqs = new HashSet<MessageQueue>(mqs.size());
        // 没有上锁的队列
        Set<MessageQueue> notLockedMqs = new HashSet<MessageQueue>(mqs.size());

        for (MessageQueue mq : mqs) {
            // 判断当前队列，是否被当前的客户端持有，如果已经持有了，那么更新下持有时间和
            if (this.isLocked(group, mq, clientId)) {
                lockedMqs.add(mq);
            } else {
                notLockedMqs.add(mq);
            }
        }
        // 待上锁的队列不为空
        if (!notLockedMqs.isEmpty()) {
            try {
                // 加个锁
                this.lock.lockInterruptibly();
                try {
                    ConcurrentHashMap<MessageQueue, LockEntry> groupValue = this.
                      mqLockTable.get(group);
                    if (null == groupValue) {
                        groupValue = new ConcurrentHashMap<>(32);
                        this.mqLockTable.put(group, groupValue);
                    }
                    for (MessageQueue mq : notLockedMqs) {
                        // 根据队列获取锁信息
                        LockEntry lockEntry = groupValue.get(mq);
                        if (null == lockEntry) {
                            // 当锁为空的时候，表示这个锁没有持有，OK，被当前客户端持有
                            lockEntry = new LockEntry();
                            lockEntry.setClientId(clientId);
                            groupValue.put(mq, lockEntry);
                        }

                        // 锁被当前客户端持有，那么更新下最后的持有时间（这个地方再次判断是否为当前实例持有的原因是因为上面加了锁，有可能在锁等待的时候，上一个线程已经获取了锁，当前线程再次进入的时候，其实锁已经被持有了）
                        if (lockEntry.isLocked(clientId)) {
                            lockEntry.setLastUpdateTimestamp(System.currentTimeMillis());
                            lockedMqs.add(mq);
                            continue;
                        }

                        // 老的客户端ID
                        String oldClientId = lockEntry.getClientId();

                        // 锁是否过期，过期时间为当前时间减最后持有时间，是否大于60秒 ， 也就是60秒没有来续期则自动释放
                        if (lockEntry.isExpired()) {
                            lockEntry.setClientId(clientId);
                            lockEntry.setLastUpdateTimestamp(System.currentTimeMillis());
                            log.warn(
                                "tryLockBatch, message queue lock expired, I got it. Group: {} OldClientId: {} NewClientId: {} {}",
                                group,
                                oldClientId,
                                clientId,
                                mq);
                            lockedMqs.add(mq);
                            continue;
                        }

                        // 获取锁失败。
                        log.warn(
                            "tryLockBatch, message queue locked by other client. Group: {} OtherClientId: {} NewClientId: {} {}",group,oldClientId, clientId,mq);
                    }
                } finally {
                    this.lock.unlock();
                }
            } catch (InterruptedException e) {
                log.error("putMessage exception", e);
            }
        }

        return lockedMqs;
    }

步骤说明：

  1. 首先循环判断当前队列，是否被当前的客户端持有，如果已经持有了，那么更新下持有时间，对于当前线程未持有锁的队列，统一放到notLocakedMqs
  2. 维护了一个ConcurrentHashMap 用来存储锁，一个双层map，通过消费组和消息队列做为key
  3. 循环notLocakedMqs，经过以下的判断，来尝试获取全局锁
    1. 在全局锁mqLocakTable里面获取每个队列的全局锁信息，当获取为空时，说明当前队列没有被上锁，则当前客户端获取锁成功
    2. 判断锁是否被当前客户端持有，那么更新下最后的持有时间（这个地方再次判断是否为当前实例持有的原因是因为上面加了锁，有可能在锁等待的时候，上一个线程已经获取了锁，当前线程再次进入的时候，其实锁已经被持有了）
    3. 判断锁是否过期，过期时间为当前时间减最后持有时间，是否大于60秒 ， 也就是60秒没有来续期则自动释放
    4. 以上条件都不满足时，则该队列获取失败

全局锁的文本概念已经讲清楚了，那么接下来我们结合客户端来讲解全局锁的作用

回顾前文

在之前有写过rocektMq push模式的消息处理。

public boolean putMessage(final List<MessageExt> msgs) {
        boolean dispatchToConsume = false;
        try {
            this.lockTreeMap.writeLock().lockInterruptibly();
            try {
                int validMsgCnt = 0;
                for (MessageExt msg : msgs) {
                     MessageExt old = msgTreeMap.put(msg.getQueueOffset(), msg);
                    // treeMap返回值，如果返回空则表示不存在， 返回值不为空，则表示key重复，两个key值相等，则新值覆盖旧值，并返回新值
                    if (null == old) {
                        validMsgCnt++;
                        this.queueOffsetMax = msg.getQueueOffset();
                        msgSize.addAndGet(msg.getBody().length);
                    }
                }
                msgCount.addAndGet(validMsgCnt);
							// 如果treeMap不为空，并且不在消费，那么设置dispatchToConsume为true
                if (!msgTreeMap.isEmpty() && !this.consuming) {
                    dispatchToConsume = true;
                    this.consuming = true;
                }

                if (!msgs.isEmpty()) {
                    MessageExt messageExt = msgs.get(msgs.size() - 1);
                    String property = messageExt.getProperty(MessageConst.PROPERTY_MAX_OFFSET);
                    if (property != null) {
                        long accTotal = Long.parseLong(property) - messageExt.getQueueOffset();
                        if (accTotal > 0) {
                            this.msgAccCnt = accTotal;
                        }
                    }
                }
            } finally {
                this.lockTreeMap.writeLock().unlock();
            }
        } catch (InterruptedException e) {
            log.error("putMessage exception", e);
        }

        return dispatchToConsume;
    }

步骤说明：

1.将当前从broker拉取到的消息，放入到ProcessQueue里面的treeMap里面去，offset为key，消息为内容，这样就对消息做了有序存储了，这也是为什么单个队列的消息是有序的，因为全程都是按照offset来做的，offset小的在treemap上面

2.判断map里面的消息不能为空，然后呢当前队列没有被在消费，也就是consuming = false ， 这种情况下，就会设置dispatchToConsume = true , 这个参数主要是为了做顺序消息的时候使用，保证同一个队列只有一个线程在消费。

接下来我们看下顺序消息的消费模型

ConsumeMessageOrderlyService

@Override
    public void submitConsumeRequest(
        final List<MessageExt> msgs,
        final ProcessQueue processQueue,
        final MessageQueue messageQueue,
        final boolean dispathToConsume) {
        if (dispathToConsume) {
            ConsumeRequest consumeRequest = new ConsumeRequest(processQueue, messageQueue);
            this.consumeExecutor.submit(consumeRequest);
        }
    }

如果dispathToConsume = true的情况下，才会构建一个ConsumerRequest , 也就是一个消费任务放到线程池里面去，进行任务消费。

下面我们看下ConsumerRequest的run方法。

 @Override
        public void run() {
            if (this.processQueue.isDropped()) {
                log.warn("run, the message queue not be able to consume, because it's dropped. {}", this.messageQueue);
                return;
            }
            // 根据messageQueue设置锁， 如果能够获取到锁，那么就继续往下执行，获取不到不能执行
            final Object objLock = messageQueueLock.fetchLockObject(this.messageQueue);
            synchronized (objLock) {
                // 消费模式==广播消费，或者 全局队列上锁&&锁没有过期
                if (MessageModel.BROADCASTING.equals(ConsumeMessageOrderlyService.this.                          defaultMQPushConsumerImpl.messageModel())|| (this.processQueue.isLocked() && !this.processQueue.isLockExpired())) {
                    final long beginTime = System.currentTimeMillis();
                    for (boolean continueConsume = true; continueConsume; ) {
                        if (this.processQueue.isDropped()) {
                            break;
                        }
                        // 没有上锁
                        if (MessageModel.CLUSTERING.equals(ConsumeMessageOrderlyService.
     this.defaultMQPushConsumerImpl.messageModel()) && !this.processQueue.isLocked()) {
                       ConsumeMessageOrderlyService.this.tryLockLaterAndReconsume(
                         this.messageQueue, this.processQueue, 10);
                            break;
                        }
                        // 锁过期
                        if (MessageModel.CLUSTERING.equals(ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.messageModel())
                            && this.processQueue.isLockExpired()) {
                            log.warn("the message queue lock expired, so consume later, {}", this.messageQueue);
                            ConsumeMessageOrderlyService.this.tryLockLaterAndReconsume(this.messageQueue, this.processQueue, 10);
                            break;
                        }
                        // 消费任务一次运行的最大时间。可以通过-Drocketmq.client.maxTimeConsumeContinuously来设置，默认为60s。
                        long interval = System.currentTimeMillis() - beginTime;
                        if (interval > MAX_TIME_CONSUME_CONTINUOUSLY) {
                            ConsumeMessageOrderlyService.this.submitConsumeRequestLater(processQueue, messageQueue, 10);
                            break;
                        }
                        // 消费批次大小，默认为1， 也就是一个一个消费，实际生产环境可以调整大
                        final int consumeBatchSize =
                            ConsumeMessageOrderlyService.this.defaultMQPushConsumer.getConsumeMessageBatchMaxSize();

                        // 从treeMap里面依次获取对应数量的消息出来。
                        List<MessageExt> msgs = this.processQueue.takeMessags(consumeBatchSize);
                        // 设置消息的topic为RETRY_TOPIC, 防止消费失败的时候需要重试
                        defaultMQPushConsumerImpl.resetRetryAndNamespace(msgs, defaultMQPushConsumer.getConsumerGroup());
                        if (!msgs.isEmpty()) {
                            final ConsumeOrderlyContext context = new ConsumeOrderlyContext(this.messageQueue);

                            ConsumeOrderlyStatus status = null;

                            ConsumeMessageContext consumeMessageContext = null;
                            if (ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.hasHook()) {
                                consumeMessageContext = new ConsumeMessageContext();
                                consumeMessageContext
                                    .setConsumerGroup(ConsumeMessageOrderlyService.this.defaultMQPushConsumer.getConsumerGroup());
                                consumeMessageContext.setNamespace(defaultMQPushConsumer.getNamespace());
                                consumeMessageContext.setMq(messageQueue);
                                consumeMessageContext.setMsgList(msgs);
                                consumeMessageContext.setSuccess(false);
                                // init the consume context type
                                consumeMessageContext.setProps(new HashMap<String, String>());
                                ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.executeHookBefore(consumeMessageContext);
                            }
                            // 获取当前的系统指针
                            long beginTimestamp = System.currentTimeMillis();
                            ConsumeReturnType returnType = ConsumeReturnType.SUCCESS;
                            // 查看是否有异常
                            boolean hasException = false;
                            try {
                                // 队列锁---防止顺序消息被重复消费，
                                this.processQueue.getLockConsume().lock();
                                if (this.processQueue.isDropped()) {
                                    log.warn("consumeMessage, the message queue not be able to consume, because it's dropped. {}",
                                        this.messageQueue);
                                    break;
                                }
                                // 进行消息消费
                                status = messageListener.consumeMessage(Collections.unmodifiableList(msgs), context);
                            } catch (Throwable e) {
                                log.warn("consumeMessage exception: {} Group: {} Msgs: {} MQ: {}",
                                    RemotingHelper.exceptionSimpleDesc(e),
                                    ConsumeMessageOrderlyService.this.consumerGroup,
                                    msgs,
                                    messageQueue);
                                hasException = true;
                            } finally {
                                // 消费锁释放
                                this.processQueue.getLockConsume().unlock();
                            }
                            // 状态为空，或者属于错误的状态时，打印日志
                            if (null == status
                                || ConsumeOrderlyStatus.ROLLBACK == status
                                || ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT == status) {
                                log.warn("consumeMessage Orderly return not OK, Group: {} Msgs: {} MQ: {}",
                                    ConsumeMessageOrderlyService.this.consumerGroup,
                                    msgs,
                                    messageQueue);
                            }
                            // 获取消费者执行的时间
                            long consumeRT = System.currentTimeMillis() - beginTimestamp;
                            if (null == status) {
                                // 是否存在异常
                                if (hasException) {
                                    returnType = ConsumeReturnType.EXCEPTION;
                                } else {
                                    returnType = ConsumeReturnType.RETURNNULL;
                                }
                            } else if (consumeRT >= defaultMQPushConsumer.getConsumeTimeout() * 60 * 1000) {
                                // 判断是否超时，如果是超时的话
                                returnType = ConsumeReturnType.TIME_OUT;
                            } else if (ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT == status) {
                                //稍后消费，表示消费失败
                                returnType = ConsumeReturnType.FAILED;
                            } else if (ConsumeOrderlyStatus.SUCCESS == status) {
                                // 消费成功
                                returnType = ConsumeReturnType.SUCCESS;
                            }

                            if (ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.hasHook()) {
                                consumeMessageContext.getProps().put(MixAll.CONSUME_CONTEXT_TYPE, returnType.name());
                            }

                            if (null == status) {
                                // 当状态为空时，说明需要稍后消费，顺序消费就是这样，一定要这个消费完成了才会继续
                                status = ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;
                            }

                            if (ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.hasHook()) {
                                consumeMessageContext.setStatus(status.toString());
                                consumeMessageContext
                                    .setSuccess(ConsumeOrderlyStatus.SUCCESS == status || ConsumeOrderlyStatus.COMMIT == status);
                                ConsumeMessageOrderlyService.this.defaultMQPushConsumerImpl.executeHookAfter(consumeMessageContext);
                            }
                            // 收集统计数据
                            ConsumeMessageOrderlyService.this.getConsumerStatsManager()
                                .incConsumeRT(ConsumeMessageOrderlyService.this.consumerGroup, messageQueue.getTopic(), consumeRT);
                            // 处理消费结果，这个在下面说下
                            continueConsume = ConsumeMessageOrderlyService.this.processConsumeResult(msgs, status, context, this);
                        } else {
                            continueConsume = false;
                        }
                    }
                } else {
                    if (this.processQueue.isDropped()) {
                        log.warn("the message queue not be able to consume, because it's dropped. {}", this.messageQueue);
                        return;
                    }
                    // 当队列没有上锁，那么会走这一块，然后进行上锁，这块最终又会重新执行到上面的代码里面去
                    ConsumeMessageOrderlyService.this.tryLockLaterAndReconsume(this.messageQueue, this.processQueue, 100);
                }
            }
        }

上面的代码很长，但是实际的步骤概括起来还是比较简单的

步骤说明：

  1. 首先获取本地的队列锁，本地的队列锁获取成功，则进行处理，获取失败的话则进入调用tryLockLaterAndReconsume延迟消费，放入一个定时线程池里面，等会再试
  2. 解下来的很长一段代码都是判断全局锁是否上锁成功，全局锁是否过期，只有全局锁在成功的状态，那么才可以继续处理
  3. 调用监听器进行消费，接下来就是消费状态的判断，如果出现异常，status=null, 也是会进行重试消费处理的。
  4. 对结果进行处理，当状态是SUSPEND_CURRENT_QUEUE_A_MOMENT的时候会进行重试

回答开篇：

1.当新增消费者或者减少消费者的时候，如何保证全局顺序消费。

消费者数量变更的时候，会触发负载均衡，客户端会重新计算消费的队列，这个时候会把不需要再消费的队列的全局锁释放掉，同时还是去borker里面对新消费的队列进行上锁，如果上锁失败，那么这个队列的消息是不能消费的，只有上锁成功才能被消费。

sharedCode源码交流群，欢迎喜欢阅读源码的朋友加群，添加下面的微信， 备注”加群“ 。

sharedCode
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
五张图带你理解 RocketMQ 顺序消息实现机制
java_beautiful的博客
06-27 656
大家好，我是君哥。今天聊一聊 RocketMQ 的顺序消息实现机制。 在有些场景下，使用 MQ 需要保证消息的顺序性，比如在电商系统中，用户提交订单、支付订单、订单出库这 3 个消息应该保证顺序性，如下图：...
RocketMq顺序消息原理
luzhensmart的专栏
05-21 829
关键特性以及其实现原理 一、顺序消息 消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照这个顺序消费才有意义。但同时订单之间又是可以并行消费的。 假如生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？你脑中想到的可能是这样： 你可能会采用这种方式保证消息顺序 M1发送到S1后，M2发送到S2，如果要保证M1先于M2被消费，那么需要M1到达消费端后，通知S2，然后S2再将M2发送到消费端
2024年RocketMQ-顺序消息原理详解（上）_rocketmq顺序消息原理，源码解读-别再说你不知道HashMap原理
最新发布
2401_84910911的博客
05-14 331
/否则，创建一个定时任务，延迟this.defaultMQPushConsumer.getPullInterval()毫秒后再新增一个拉取请求。//对拉取到的消息排序，dispatchToConsume表示是否启动线程池，为什么有这个参数，下文介绍。//如果没有加锁或者过期，则发起请求对队列进行加锁，并增加一个定时任务，稍后重新对消息进行消费。//下面两个if判断，主要是检查当前队列是否在broker端已经加锁还有锁是否过期，//检查是否设置了拉取间隔，默认是0，如果是0，则调用。
RocketMQ顺序消息实现原理分析
程序员小潘
09-14 2255
1. 前言 顺序消息是RocketMQ的特性之一，它可以让Consumer消费消息的顺序严格按照消息的发送顺序来进行。例如：一条订单产生的三条消息：订单创建、订单付款、订单完成。消费时要按照这个顺序依次消费才有意义，但是不同的订单之间这些消息是可以并行消费的。 顺序消息可以分为全局有序和分区有序，绝大部分场景下，分区有序就已经能够满足需求了，因此本文会重点分析。 ​ 全局有序：某个Topic下所有的消息都是有序的，所有消息按照严格的先进先出的顺序进行生产和消费，要求Topic下只能有一个分区队列，且Cons
RocketMQ实现顺序消息原理分析
发现问题，面对问题，分析问题，解决问题，总结问题
05-17 2590
顺序消费也称为有序消费，原理是同一个消息队列只允许Consumer中的一个消费线程拉取消费。Consumer中有个消费线程池，多个线程会同时消费消息。在顺序消费的场景下消费线程请求到Broker时会先申请独占锁，获得锁的请求则允许消费。
RocketMQ-顺序消息原理详解（上）
龚厂长的博客
12-24 2394
本文基于RocketMQ 4.7.1版本 rocketmq提供了顺序消息的功能，可以保证消息以生产的顺序被消费，用官网上的话就是“FIFO order”。该功能在某些场景下非常有用，比如mysql的binlog日志，还有订单处理场景，订单的生成、支付、撤销必须是有序的。 本文将首先给出一个顺序消息的例子，然后基于该例子介绍顺序消息的原理。 文章目录一、为什么会出现消息乱序消费二、顺序消息代码示例 一、为什么会出现消息乱序消费 rocketmq的一个主题下可以创建多个队列， 二、顺序消息代码示例 本文提供.
RocketMQ_原理解析
09-13
RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性： 支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 支持拉（pull）和推（push...
RocketMQ高级原理：深入剖析消息系统的核心机制
12-22
《RocketMQ高级原理：深入剖析消息系统的核心机制》是一篇深度解析RocketMQ核心机制的文章，旨在帮助读者理解和掌握这款分布式消息中间件的工作原理。RocketMQ是阿里巴巴开源的一款高性能、高可用的消息中间件，广泛...
RocketMQ入门实战及源码解析.7z
06-23
1. 概念：RocketMQ是一个基于发布/订阅模式的消息队列，支持事务消息、定时/延时消息、顺序消息等多种特性，广泛应用于互联网行业的订单处理、支付、推荐系统等领域。 2. 架构：RocketMQ由NameServer、Producer、...
RocketMQ原理分析.rar
05-11
本压缩包“RocketMQ原理分析.rar”包含了对RocketMQ核心机制的深入解析，旨在帮助用户理解其工作原理。 RocketMQ的核心组件包括Producer、Consumer、NameServer和Broker四个部分： 1. **Producer**: 生产者是消息...
Rocketmq-顺序消息底层原理
帅帆的博客
05-14 762
Rocketmq只能保证局部顺序，不能保证全局顺序消息 在RocketMQ中提供了基于队列(分区)的顺序消费。 RocketMQ中顺序性主要指的是消息顺序消费。RocketMQ 中每一个消费组一个单独的线程池并发消费拉取到的消息，即消费端是多线程消费。而顺序消费的并发度等于该消费者分配到的队列数。 RokcetMQ的完成顺序性主要是由3把琐来实现的。下图是RocketMQ顺序消费的工作原理： 1、消费端在启动时首先会进行队列负载机制，遵循一个消费者可以分配多个队列，但一个队列只会被一个消..
【RocketMQ】顺序消费消息实现原理分析
blblccc
12-15 1256
顺序消息是指对于一个指定的 Topic ，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。向Broker申请的消息队列锁集群模式下一个消息队列同一时刻只能被同一个消费组下的某一个消费者进行，为了避免负载均衡等原因引起的变动，消费者会向Broker发送请求对消息队列进行加锁，如果加锁成功，记录到消息队列对应的中的locked变量中。消息队列锁对应对应的Object对象锁，消费者在处理拉取到的消息时，由于可以开启多线程进行处理，所以处理消息前需要对。
rocketmq--特性之顺序消息
convict_EVA的专栏
09-11 1370
应用场景：     网购的时候，我们需要下单，那么下单需要假如有三个顺序，第一、创建订单 ，第二：订单付款，第三：订单完成。也就是这个三个环节要有顺序，这个订单才有意义。RocketMQ可以保证顺序消费   实现原理：     produce在发送消息的时候，把消息发到同一个队列（queue）中。发送消息的时候可以实现MessageQueueSelector类的select 方法，返回的就是que...
源码分析RocketMQ顺序消息消费实现原理
热门推荐
中间件兴趣圈
03-02 1万+
所谓顺序消费，rocketmq支持同一消费队列上的消息顺序消费。 消息消费涉及3个点： 1、消息队列重新负载 2、消息拉取 3、消息消费 按照消息消费步骤来揭开RocketMQ顺序消息消费实现原理。 1、消息队列负载 RocketMQ在同一个JVM进程拥有一个clientConfigId(客户端ID)，该JVM进程中不同的消息消费组的消息客户端ID相同，因为在JVM进程中对于每一个C...
rocketMq浅析-顺序消息
hery的博客
08-26 391
一 什么是顺序消息 顺序消息（FIFO 消息）是 MQ 提供的一种严格按照顺序进行发布和消费的消息类型。顺序消息由两个部分组成：顺序发布和顺序消费。 顺序消息包含两种类型： 分区顺序：一个Partition内所有的消息按照先进先出的顺序进行发布和消费。 全局顺序：一个Topic内所有的消息按照先进先出的顺序进行发布和消费。 多线程中若没有因果关系则没有顺序。那么用户在多线程中去发消息就意味着用户不关心那些在不同线程中被发送的消息的顺序。即多线程发送的消息，不同线程间的消息不是顺序发布的，同一线程的消息是顺序
消息中间件：RocketMQ 介绍（特性、术语、原理、优缺点、消息顺序、消息重复）
愿我如星君如月 ... 夜夜流光相皎洁 ...
08-14 8117
消息中间件的作用 1. 应用解耦 2. 异步处理 比如用户注册场景，注册主流程完成以后，需要调用邮件系统发送邮件通知用户注册成功，可能还需要调用其他系统。这是串行的，如果一个系统依赖很多系统，那么这个主流程会比较长，耦合度高，整个系统维护成本也会越来越高。那么我们就可以使用消息中间件来进行解耦，通过发布订阅模式，完成用户注册之后，向中间件发送消息，这样就可以马上给用户返回，至于后续工作其他系...
RocketMQ学习(八)——RocketMQ顺序消息
hxyascx的博客
11-26 1414
顺序消息 消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照顺序依次消费才有意义。与此同时多笔订单之间又是可以并行消费的。首先来看如下示例： 假如生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？你脑中想到的可能是这样： 这样可以保证M1先于M2到达MQServer（生产者等待M1发送成功后再发送M...
RocketMQ之消息的顺序发送与消费
我能在河边钓一整天的鱼
03-21 351
目录 顺序消息 生产者 消费者 顺序消息 在某些业务中，consumer在消费消息时，是需要按照生产者发送消息的顺序进行消费的，比如在电商系统中，订单的消息，会有创建订单、订单支付、订单完成，如果消息的顺序发生改变，那么这样的消息就没有意义了。 (想实现订单的需求，生产时必须让每一笔订单单独存在于一个队列中，消费时在指定队列中按顺序消费) 生产者 在代码中...
分布式开放消息系统(RocketMQ)的原理与实践
02-25
本文来自于简书，介绍了关键特性以及其实现原理，RocketMQ最佳实践，专业术语和整体架构等知识。消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了3条消息，分别是订单创建、订单付款、订单完成。消费时，要按照这个顺序消费才有意义。但同时订单之间又是可以并行消费的。假如生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？你脑中想到的可能是这样：你可能会采用这种方式保证消息顺序M1发送到S1后，M2发送到S2，如果要保证M1先于M2被消费，那么需要M1到达消费端后，通知S2，然后S2再将M2发送到消费端。这个模型存在的问题是，如果M1和M2分别发送到两台S

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值