RocketMq 各类消息消费与发送原理分析

最新推荐文章于 2024-05-27 13:19:59 发布
最新推荐文章于 2024-05-27 13:19:59 发布
阅读量761 收藏
点赞数
分类专栏： MQ 文章标签： rocketmq java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38650898/article/details/127232380
版权

文章目录

消息存储结构

参考阿里官方文章：https://mp.weixin.qq.com/s/PzDO-UCLzxqDbFoHbS47Sg

1、延迟消息源码分析

在rocketMq的broker配置中有一个配置可以配置消息重试的时间等级：

messageDelayLevel =1s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s 5s

然后在发送的时候可以设置消息的延迟等级

    Message msg = new Message("base", "Tag1", ("Hello World" + i).getBytes());
    //设定延迟时间
    msg.setDelayTimeLevel(10);

发送到broker后最终由CommitLog提交时会判断是否是延迟消息，如果是的话会保存真实的topic属性，然后修改topic为SCHEDULE_TOPIC_XXXX提交，源码如下：
在这里插入图片描述
你会发现每种延迟级别分别有一个队列，所以一共有18个队列：
在这里插入图片描述
延迟消息会由DeliverDelayedMessageTimerTask#executeOnTimeup中取出消费队列中的时间戳和当前时间对比，如果到时间了，则重新发送一条原始的消息，源码可查看ScheduleMessageService中的start方法和executeOnTimeup方法：

      public void executeOnTimeup() {
            ConsumeQueue cq =
                ScheduleMessageService.this.defaultMessageStore.findConsumeQueue(TopicValidator.RMQ_SYS_SCHEDULE_TOPIC,
                    delayLevel2QueueId(delayLevel));

            long failScheduleOffset = offset;

            if (cq != null) {
                SelectMappedBufferResult bufferCQ = cq.getIndexBuffer(this.offset);
                if (bufferCQ != null) {
                    try {
                        long nextOffset = offset;
                        int i = 0;
                        ConsumeQueueExt.CqExtUnit cqExtUnit = new ConsumeQueueExt.CqExtUnit();
                        for (; i < bufferCQ.getSize(); i += ConsumeQueue.CQ_STORE_UNIT_SIZE) {
                            long offsetPy = bufferCQ.getByteBuffer().getLong();
                            int sizePy = bufferCQ.getByteBuffer().getInt();
                            // 延迟队列存的是发送的时候的时间戳
                            long tagsCode = bufferCQ.getByteBuffer().getLong();

                            if (cq.isExtAddr(tagsCode)) {
                                if (cq.getExt(tagsCode, cqExtUnit)) {
                                    tagsCode = cqExtUnit.getTagsCode();
                                } else {
                                    //can't find ext content.So re compute tags code.
                                    log.error("[BUG] can't find consume queue extend file content!addr={}, offsetPy={}, sizePy={}",
                                        tagsCode, offsetPy, sizePy);
                                    long msgStoreTime = defaultMessageStore.getCommitLog().pickupStoreTimestamp(offsetPy, sizePy);
                                    tagsCode = computeDeliverTimestamp(delayLevel, msgStoreTime);
                                }
                            }

                            long now = System.currentTimeMillis();
                            long deliverTimestamp = this.correctDeliverTimestamp(now, tagsCode);

                            nextOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);

                            long countdown = deliverTimestamp - now;

                            if (countdown <= 0) {
                                MessageExt msgExt =
                                    ScheduleMessageService.this.defaultMessageStore.lookMessageByOffset(
                                        offsetPy, sizePy);

                                if (msgExt != null) {
                                    try {
                                    	// 构造新的消息
                                        MessageExtBrokerInner msgInner = this.messageTimeup(msgExt);
                                        if (TopicValidator.RMQ_SYS_TRANS_HALF_TOPIC.equals(msgInner.getTopic())) {
                                            log.error("[BUG] the real topic of schedule msg is {}, discard the msg. msg={}",
                                                    msgInner.getTopic(), msgInner);
                                            continue;
                                        }
                                        // 发送新的消息
                                        PutMessageResult putMessageResult =
                                            ScheduleMessageService.this.writeMessageStore
                                                .putMessage(msgInner);

                                        if (putMessageResult != null
                                            && putMessageResult.getPutMessageStatus() == PutMessageStatus.PUT_OK) {
                                            continue;
                                        } else {
                                            // XXX: warn and notify me
                                            log.error(
                                                "ScheduleMessageService, a message time up, but reput it failed, topic: {} msgId {}",
                                                msgExt.getTopic(), msgExt.getMsgId());
                                            ScheduleMessageService.this.timer.schedule(
                                                new DeliverDelayedMessageTimerTask(this.delayLevel,
                                                    nextOffset), DELAY_FOR_A_PERIOD);
                                            ScheduleMessageService.this.updateOffset(this.delayLevel,
                                                nextOffset);
                                            return;
                                        }
                                    } catch (Exception e) {
                                        /*
                                         * XXX: warn and notify me



                                         */
                                        log.error(
                                            "ScheduleMessageService, messageTimeup execute error, drop it. msgExt="
                                                + msgExt + ", nextOffset=" + nextOffset + ",offsetPy="
                                                + offsetPy + ",sizePy=" + sizePy, e);
                                    }
                                }
                            } else {
                                ScheduleMessageService.this.timer.schedule(
                                    new DeliverDelayedMessageTimerTask(this.delayLevel, nextOffset),
                                    countdown);
                                ScheduleMessageService.this.updateOffset(this.delayLevel, nextOffset);
                                return;
                            }
                        } // end of for

                        nextOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);
                        ScheduleMessageService.this.timer.schedule(new DeliverDelayedMessageTimerTask(
                            this.delayLevel, nextOffset), DELAY_FOR_A_WHILE);
                        ScheduleMessageService.this.updateOffset(this.delayLevel, nextOffset);
                        return;
                    } finally {

                        bufferCQ.release();
                    }
                } // end of if (bufferCQ != null)
                else {

                    long cqMinOffset = cq.getMinOffsetInQueue();
                    if (offset < cqMinOffset) {
                        failScheduleOffset = cqMinOffset;
                        log.error("schedule CQ offset invalid. offset=" + offset + ", cqMinOffset="
                            + cqMinOffset + ", queueId=" + cq.getQueueId());
                    }
                }
            } // end of if (cq != null)

            ScheduleMessageService.this.timer.schedule(new DeliverDelayedMessageTimerTask(this.delayLevel,
                failScheduleOffset), DELAY_FOR_A_WHILE);
        }

2、消息重试与进入死信队列源码分析

我们以DefaultMQPushConsumer自动消息推送（其实还是拉取）为例，在消费者启动流程中，如果集群模式的话，默认会订阅一个%RETRY%+group 消息重试的topic

源码位置：org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#copySubscription
在这里插入图片描述

那么broker是怎么知道消息要重试的呢？ 很明显得消费者来告诉它，消费者在拉取消息消费的时候，会根据监听器的执行结果决定是提交消息还是消息重试，消息拉取的源码位置主要在DefaultMQPushConsumerImpl#pullMessage，下面主要是拉取消息回调源码：

 PullCallback pullCallback = new PullCallback() {
            @Override
            public void onSuccess(PullResult pullResult) {
                if (pullResult != null) {
                    pullResult = DefaultMQPushConsumerImpl.this.pullAPIWrapper.processPullResult(pullRequest.getMessageQueue(), pullResult,
                        subscriptionData);

                    switch (pullResult.getPullStatus()) {
                        case FOUND:
                            long prevRequestOffset = pullRequest.getNextOffset();
                            pullRequest.setNextOffset(pullResult.getNextBeginOffset());
                            long pullRT = System.currentTimeMillis() - beginTimestamp;
                            DefaultMQPushConsumerImpl.this.getConsumerStatsManager().incPullRT(pullRequest.getConsumerGroup(),
                                pullRequest.getMessageQueue().getTopic(), pullRT);

                            long firstMsgOffset = Long.MAX_VALUE;
                            if (pullResult.getMsgFoundList() == null || pullResult.getMsgFoundList().isEmpty()) {
                                DefaultMQPushConsumerImpl.this.executePullRequestImmediately(pullRequest);
                            } else {
                                firstMsgOffset = pullResult.getMsgFoundList().get(0).getQueueOffset();

                                DefaultMQPushConsumerImpl.this.getConsumerStatsManager().incPullTPS(pullRequest.getConsumerGroup(),
                                    pullRequest.getMessageQueue().getTopic(), pullResult.getMsgFoundList().size());

                                boolean dispatchToConsume = processQueue.putMessage(pullResult.getMsgFoundList());
                                // ====== 拉取到消息呢会提交消息消费的请求
                                DefaultMQPushConsumerImpl.this.consumeMessageService.submitConsumeRequest(
                                    pullResult.getMsgFoundList(),
                                    processQueue,
                                    pullRequest.getMessageQueue(),
                                    dispatchToConsume);

                                if (DefaultMQPushConsumerImpl.this.defaultMQPushConsumer.getPullInterval() > 0) {
                                    DefaultMQPushConsumerImpl.this.executePullRequestLater(pullRequest,
                                        DefaultMQPushConsumerImpl.this.defaultMQPushConsumer.getPullInterval());
                                } else {
                                    DefaultMQPushConsumerImpl.this.executePullRequestImmediately(pullRequest);
                                }
                            }

                            if (pullResult.getNextBeginOffset() < prevRequestOffset
                                || firstMsgOffset < prevRequestOffset) {
                                log.warn(
                                    "[BUG] pull message result maybe data wrong, nextBeginOffset: {} firstMsgOffset: {} prevRequestOffset: {}",
                                    pullResult.getNextBeginOffset(),
                                    firstMsgOffset,
                                    prevRequestOffset);
                            }

                            break;
                        case NO_NEW_MSG:
                        case NO_MATCHED_MSG:
                            pullRequest.setNextOffset(pullResult.getNextBeginOffset());

                            DefaultMQPushConsumerImpl.this.correctTagsOffset(pullRequest);

                            DefaultMQPushConsumerImpl.this.executePullRequestImmediately(pullRequest);
                            break;
                        case OFFSET_ILLEGAL:
                            log.warn("the pull request offset illegal, {} {}",
                                pullRequest.toString(), pullResult.toString());
                            pullRequest.setNextOffset(pullResult.getNextBeginOffset());

                            pullRequest.getProcessQueue().setDropped(true);
                            DefaultMQPushConsumerImpl.this.executeTaskLater(new Runnable() {

                                @Override
                                public void run() {
                                    try {
                                        DefaultMQPushConsumerImpl.this.offsetStore.updateOffset(pullRequest.getMessageQueue(),
                                            pullRequest.getNextOffset(), false);

                                        DefaultMQPushConsumerImpl.this.offsetStore.persist(pullRequest.getMessageQueue());

                                        DefaultMQPushConsumerImpl.this.rebalanceImpl.removeProcessQueue(pullRequest.getMessageQueue());

                                        log.warn("fix the pull request offset, {}", pullRequest);
                                    } catch (Throwable e) {
                                        log.error("executeTaskLater Exception", e);
                                    }
                                }
                            }, 10000);
                            break;
                        default:
                            break;
                    }
                }
            }

            @Override
            public void onException(Throwable e) {
                if (!pullRequest.getMessageQueue().getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                    log.warn("execute the pull request exception", e);
                }

                DefaultMQPushConsumerImpl.this.executePullRequestLater(pullRequest, pullTimeDelayMillsWhenException);
            }
        };

上面注释的代码就是去消费消息的源码，进一步跟踪的话，最终会由ConsumeMessageConcurrentlyService.ConsumeRequest这个runnable并交给线程池来执行，listener在消费完消息会返回一个状态status：

public enum ConsumeConcurrentlyStatus {
    /**
     * Success consumption
     */
    CONSUME_SUCCESS,
    /**
     * Failure consumption,later try to consume
     */
    RECONSUME_LATER;
}

如果消息消费失败，需要重新消费呢，就会发送一个MessageBack的消息给broker并且会给msg设置一个延迟等级，比如ConsumeConcurrentlyContext中的delayLevelWhenNextConsume默认就是0

broker在收到消息后呢，会交给SendMessageProcessor消息后置处理器来处理MessageBack消息，它是怎么处理的呢？

  1. 判断重试次数，如果超过了最大次数，则会放入死信队列（%DLQ%+group）
  2. 否则判断延迟等级，设置消息的延迟等级，设置真实的topic到属性中，设置发送topic为%RETRY%+group，然后在发送消息。

那消费者是怎么消费到重试消息的呢？

  1. 重试的消息是有延迟的是吧，所以会现在SCHEDULE_TOPIC_XXXX队列中，到时间了就会到%RETRY%+group队列中。
  2. 消息消费者如果是集群模式的话，默认也会订阅%RETRY%+group这个topic的消息，当消费者消费到这个topic的消息的时候，会先判断是不是重试的消息，如果是，则将属性中的真实的topic拿出来替换一下消息的topic然后在交给消息监听器去真正的消费。

源码位置主要如下：
在这里插入图片描述

    public void resetRetryAndNamespace(final List<MessageExt> msgs, String consumerGroup) {
        final String groupTopic = MixAll.getRetryTopic(consumerGroup);
        for (MessageExt msg : msgs) {
        	// 如果是重试的消息，会先替换一下topic再去消费
            String retryTopic = msg.getProperty(MessageConst.PROPERTY_RETRY_TOPIC);
            if (retryTopic != null && groupTopic.equals(msg.getTopic())) {
                msg.setTopic(retryTopic);
            }

            if (StringUtils.isNotEmpty(this.defaultMQPushConsumer.getNamespace())) {
                msg.setTopic(NamespaceUtil.withoutNamespace(msg.getTopic(), this.defaultMQPushConsumer.getNamespace()));
            }
        }
    }

3、事务消息发送、提交、回查源码分析

1、half预提交消息发送与接收处理

事务消息需要实现事务监听器的接口，在发送的时候会执行以下几步：

  1. 前置校验，清除掉延迟等级的设置内容，设置TRAN_MSG属性为true，设置PGROUP属性为produceGroup标识为事务消息
  2. 发送消息至broker，事务消息发送失败会一直重试，一直到达到最大重试次数

发送源码位置在：DefaultMQProducerImpl#sendDefaultImpl 中，broker在收到消息的时候也是由SendMessageProcessor处理，会判断TRAN_MSG属性是不是true，如果是true，会调用TransactionalMessageServiceImpl.asyncPrepareMessage发送半提交消息到RMQ_SYS_TRANS_HALF_TOPIC下的队列中去，源码如下：
在这里插入图片描述
在这里插入图片描述

2、提交、回滚事务消息

事务监听器transactionListener执行完业务流程后，会返回一个状态：

public enum LocalTransactionState {
    COMMIT_MESSAGE, // 提交
    ROLLBACK_MESSAGE, // 回滚
    UNKNOW,  // 未知回查
}

然后会调用DefaultMQProducerImpl#endTransaction向broker发送事务提交的请求，事务状态通过设置requestHeader的CommitOrRollback来标识，主要源码如下：

    public void endTransaction(
        final SendResult sendResult,
        final LocalTransactionState localTransactionState,
        final Throwable localException) throws RemotingException, MQBrokerException, InterruptedException, UnknownHostException {
        final MessageId id;
        if (sendResult.getOffsetMsgId() != null) {
            id = MessageDecoder.decodeMessageId(sendResult.getOffsetMsgId());
        } else {
            id = MessageDecoder.decodeMessageId(sendResult.getMsgId());
        }
        String transactionId = sendResult.getTransactionId();
        final String brokerAddr = this.mQClientFactory.findBrokerAddressInPublish(sendResult.getMessageQueue().getBrokerName());
        EndTransactionRequestHeader requestHeader = new EndTransactionRequestHeader();
        requestHeader.setTransactionId(transactionId);
        requestHeader.setCommitLogOffset(id.getOffset());
        switch (localTransactionState) {
            case COMMIT_MESSAGE:
                requestHeader.setCommitOrRollback(MessageSysFlag.TRANSACTION_COMMIT_TYPE);
                break;
            case ROLLBACK_MESSAGE:
                requestHeader.setCommitOrRollback(MessageSysFlag.TRANSACTION_ROLLBACK_TYPE);
                break;
            case UNKNOW:
                requestHeader.setCommitOrRollback(MessageSysFlag.TRANSACTION_NOT_TYPE);
                break;
            default:
                break;
        }

        requestHeader.setProducerGroup(this.defaultMQProducer.getProducerGroup());
        requestHeader.setTranStateTableOffset(sendResult.getQueueOffset());
        requestHeader.setMsgId(sendResult.getMsgId());
        String remark = localException != null ? ("executeLocalTransactionBranch exception: " + localException.toString()) : null;
        this.mQClientFactory.getMQClientAPIImpl().endTransactionOneway(brokerAddr, requestHeader, remark,
            this.defaultMQProducer.getSendMsgTimeout());
    }

broker在接收到提交事务的请求后，交给EndTransactionProcessor后置处理来处理，主要处理源码如下：

// 略
if (MessageSysFlag.TRANSACTION_COMMIT_TYPE == requestHeader.getCommitOrRollback()) {
	// 根据预提交消息的偏移量获取到half消息
    result = this.brokerController.getTransactionalMessageService().commitMessage(requestHeader);
    if (result.getResponseCode() == ResponseCode.SUCCESS) {
    	// 检查
        RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader);
        if (res.getCode() == ResponseCode.SUCCESS) {
        	// 封装成真实的需要提交的信息
            MessageExtBrokerInner msgInner = endMessageTransaction(result.getPrepareMessage());
            msgInner.setSysFlag(MessageSysFlag.resetTransactionValue(msgInner.getSysFlag(), requestHeader.getCommitOrRollback()));
            msgInner.setQueueOffset(requestHeader.getTranStateTableOffset());
            msgInner.setPreparedTransactionOffset(requestHeader.getCommitLogOffset());
            msgInner.setStoreTimestamp(result.getPrepareMessage().getStoreTimestamp());
            MessageAccessor.clearProperty(msgInner, MessageConst.PROPERTY_TRANSACTION_PREPARED);
            // 发送真的的消息到topic中
            RemotingCommand sendResult = sendFinalMessage(msgInner);
            if (sendResult.getCode() == ResponseCode.SUCCESS) {
                
                // 删除half消息,其实是将half消息存在到提交topic下去
               this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage());
            }
            return sendResult;
        }
        return res;
    }
} else if (MessageSysFlag.TRANSACTION_ROLLBACK_TYPE == requestHeader.getCommitOrRollback()) {
    result = this.brokerController.getTransactionalMessageService().rollbackMessage(requestHeader);
    if (result.getResponseCode() == ResponseCode.SUCCESS) {
        RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader);
        if (res.getCode() == ResponseCode.SUCCESS) {
            this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage());
        }
        return res;
    }
}

消息的提交和回滚有一处需要注意的地方是，deletePrepareMessage删除half消息是将half消息的偏移量存储到一个topic为RMQ_SYS_TRANS_OP_HALF_TOPIC，tag为d的队列中去。

看到这，对消息提交、回滚做了说明，无论消息是提交还是回滚，消息都会被put到topic为RMQ_SYS_TRANS_OP_HALF_TOPIC的队列中，总结下两个Topic的作用

  • RMQ_SYS_TRANS_HALF_TOPIC：prepare消息的主题，事务消息首先先进入到该主题。
  • RMQ_SYS_TRANS_OP_HALF_TOPIC：当消息服务器收到事务消息的提交或回滚请求后，会将消息存储在该主题下

3、事务消息回查源码分析

事务消息回查的实现在TransactionalMessageCheckService中，代码如下
在这里插入图片描述

详细分析下TransactionalMessageService#check方法

在这里插入图片描述
再来看下for循环中处理逻辑，由于代码较长，分段截取并注释说明

  1. 先从halfQueue，opQueue中取出对应offSet
    在这里插入图片描述

  2. 根据halfQueue，opQueue判断出opQueue中哪些消息已经处理过，哪些没处理过，处理过的opQueue offSet放入doneOpOffset中，拿opQueue中消息体内的halfQueue的offSet(已经处理过的半消息offSet)与当前halfQueue的offSet做比较
    在这里插入图片描述
    在这里插入图片描述

  3. 接下来就到了消息回查的实现关键，源码如下：
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    这里有个要注意的地方是：putBackHalfMsgQueue，将msgExt重新提交到half队列中去，并且重置了msgExt的偏移量，然后去回查msgExt消息。
    这么做是因为当前获取的msgExt消费偏移量在回查后已经更新了，当重试消息再次失败或者成功的时候，会以putBackHalfMsgQueue
    添加的消息为基准去第二次重试、回滚或者成功操作。不然的话，回查失败就不在回查了！

  4. 具体事务回查代码逻辑AbstractTransactionalMessageCheckListener#resolveHalfMsg中，启动了一个线程池来进行事务回查，就是向可用的produceGroup的生产者实例发送请求，然后生产者会执行回查操作，然后就是重复操作了
    在这里插入图片描述
    接收事务回查请求逻辑在ClientRemotingProcessor#checkTransactionState中，各种请求的接受者的查询逻辑可以根据RequestCode中的变量值来找，看下具体代码：
    在这里插入图片描述
    至于checkTransactionState，与事务提交部分代码较为相似，只不过这里是调用TransactionListener#checkLocalTransaction来得到事务执行状态码localTransactionState，再根据localTransactionState来发送commit/rollback请求，不再赘述：
    在这里插入图片描述

小柒7
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
RocketMQ 消费者消息回发 解析——图解、源码级解析
如切如磋，如琢如磨
09-16 2113
📆 最近更新：2022年9月9日🍊 个人简介：通信工程本硕💪、Java程序员🌕。做过科研paper，发过专利，优秀的程序员不应该只是CRUD。
RocketMQ Push消息给消费者 解析——图解、源码级解析
如切如磋，如琢如磨
09-09 1881
文章目录概述Push消息消费流程开启消息消费接收消息 概述 RocketMQ中消费者有两种方式获得消息来消费：Push模式和Pull模式 Push模式：服务端将消息推送到客户端 Pull模式：客户端不断请求服务端，或许消息 实际上这两种模式的底层实现都是采用的Consumer主动拉取消息的方式 在Push方式里，把Consumer轮询过程封装起来了，并注册了MessageListener监听器，当拉取到消息后唤醒监听器来消费，所以感觉消息就像是被服务端推过来的一样 在Pull模式中，Consumer
RocketMQ 消费失败了，怎么处理？
最新发布
2401_83384536的博客
05-27 685
消费者消费失败后，会把消费发回给 Broker 进行处理。下图是客户端处理流程：Broker 收到消息后，会把消息重新发送到 CommitLog，发送到 CommitLog 之前，首先会修改 Topic 为 SCHEDULE_TOPIC_XXXX，这样就发送到了延时队列，延时队列再根据延时级别把消息投递到原始的队列，这样消费者就能再次拉取到。流程如下图：从流程来看，消费者批量拉取消息，如果部分消息消费失败，那就会整批全部重试。所以做好幂等是必要的。
rockerMq实现消费者动态上下线
qq_34468174的博客
08-21 2336
需求： 1.通过接口方式动态控制消费者的上线和下线，通过配置的方式，实现对接不同rocketmq系统的不同消息队列的消费； 2.从消息队列中读取到消息后，将对映值映射到实现配置好的数据模板中，转换为模板格式的数据； 直切主题，实现动态上下线的两个主要类： 1.配置类，存储消费者连接对象，可以扩展为redis <dependency> <groupId>org.apache.rocketmq</groupId> <ar...
RocketMQ-消息消费
程序员劝退师的博客
12-19 625
前言 消费者从Broker中获取消息方式有两种，pull拉取方式和push推送方式，消费者组对于消息消费的模式又分为两种，集群消费Clustering和广播消费Broadcasting Pull/Push消费类型 Pull拉取模式 Consumer主动从Broker中拉取消息，主动权在Consumer控制。一旦获取了批量消息，就会启动消费国成，不过，该方式的实时性较弱，即Broker中有了新的消息时消费者并不能即使发现并消费者 Push推送模式 该模式下Broker收到数据后悔主动推送给Consumer，该
RocketMQ是如何发送和消费消息的
njq774327136的博客
09-25 1511
RocketMQ是如何发送和消费消息的
消息中间件—RocketMQ消息发送
01-27
本文来自于jianshu，文章介绍了RocketMQ网络架构图以及RocketMQ发送普通消息的全流程解读等相关内容。摘要：使用客户端发送一条消息很Easy，在这背后RocketMQ完成了怎么样的操作呢？大道至简，消息队列可以简单概括...
RocketMq事务消息发送代码流程详解
08-18
RocketMq事务消息发送代码流程详解 RocketMq是一种流行的开源消息队列系统，事务消息是其核心功能之一。事务消息发送代码流程详解是指在RocketMq中实现事务消息发送的整个过程。下面我们将详细介绍RocketMq事务消息...
分布式开放消息系统(RocketMQ)的原理与实践
02-25
消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了3条消息，分别是订单创建、订单付款、订单完成。消费时，要按照这个顺序消费才有意义。但同时订单之间又是可以并行消费的。假如生产者...
RocketMQ：发送消息与接收实例
08-28
为了理解并使用这些功能，你需要了解 RocketMQ 的基本架构，包括 NameServer（路由注册与发现）、Broker（消息存储与转发）、Producer（消息生产者）和 Consumer（消息消费者）。其中，Producer 负责创建消息并发送...
RocketMQ5.0.0消息消费＜三＞ _ 消息消费
爱我所爱0505
03-14 495
本章节介绍PUSH模式下的消息拉取及负载均衡后的消息消费。消费线程池消费消息失败后，进行消息ACK确认，进入重新消息队列。消息成功后，根据广播/集群模式更新消费进度。
rocketmq的生产者和消费者发送消息到接收消息的执行过程
m0_37609060的博客
03-10 816
***producer发送message到consumer，然后执行start方法，开启本次事务，通过sendMessageInTransaction发送消息给消费者 消息会被封装到TransactionSendResult中（调用它的set方法），然后executeLocalTransaction方法执行事务并且设置 LocalTransactionState的值，方法结束后使用checkLocalTransac
rocketmq 消息消费后处理机制
万物皆字节
05-25 4192
rocketmq 消息消费失败处理机制
RabbitMQ(二) - RabbitMQ与消息发布确认与返回、消费确认
玄霄
08-05 2328
SpringBoot与RabbitMQ整合后，对RabbitClient的“确认”进行了封装、使用方式与RabbitMQ官网不一致；
RocketMQ源码分析----Consumer消费进度相关
菜鸟一名
12-28 1408
在Consumer消费的时候总有几个疑问： 消费完成后，这个消费进度存在哪里 消费完成后，还没保存消费进度就挂了，会不会导致重复消费 Consumer 消费进度保存 消费完成后，会返回一个ConsumeConcurrentlyStatus.CONSUME_SUCCESS告诉MQ消费成功，以MessageListener的consumeMessage为入口分析。 消费的时候，是以ConsumeR...
RabbitMQ学习笔记（二）消息确认机制
qq_42331185的博客
07-14 2244
1、我的另一篇文章中介绍了RabbitMQ的交换机类型、消费类型，经过一系列的demo测试时，我们在RabbitMQ的后台监控中可以发现一个现象，就是消息在被成功消费后，队列中就没有这个消息了，也就是删除了，那么疑问来了，RabbitMQ是怎么知道这个消息该不该被删除？什么时候删除？2、除了消费者，那么生产者怎么知道自己消息是否发送成功到RabbitMQ中了？解决这个疑问的方式就是：RabbitMQ消息确认机制。
RocketMq基础详解
weixin_36741151的博客
01-30 1740
在RocketMq中有四个部分组成，分别是Producer，Consumer，Broker，以及NameServer，类比于生活中的邮局，分别是发信者，收信者，负责暂存，传输的邮局，以及协调各个地方邮局的管理机构。
RocketMQ常见错误与解决方案
我引源,你思考
07-21 3896
1. 通过rocketmq-console查询Topic是否存在2. 查看配置文件, Broker是否开启了自动创建Topic，参数为：autoCreateTopicEnable, 该参数默认为true,但在生产环境不建议开启。3. 如果开启了自动创建Topic，但还是抛出这个错误，这个时候请检查客户端(Producer)连接的Nameserver地址是否与Broker中配置的nameserver地址是否一致。RocketMQ每一分钟打印前一分钟内消息发送的耗时情况分布。
python rabitmq_详解Python操作RabbitMQ服务器消息队列的远程结果返回
weixin_39619478的博客
11-24 148
先说一下笔者这里的测试环境：Ubuntu14.04 + Python 2.7.4RabbitMQ服务器sudo apt-get install rabbitmq-serverPython使用RabbitMQ需要Pika库sudo pip install pika远程结果返回消息发送端发送消息出去后没有结果返回。如果只是单纯发送消息，当然没有问题了，但是在实际中，常常会需要接收端将收到的消息进行处理...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值