`
Technoboy
  • 浏览: 157064 次
  • 性别: Icon_minigender_1
  • 来自: 大连
社区版块
存档分类
最新评论

RocketMQ原理解析-Consumer

阅读更多
1. 介绍
  Consumer默认使用DefaultMQPushConsumerImpl长轮询拉消息的方式来消费,可以保证实时性同Push一样。还可以参考example项目,使用DefaultMQPullConsumerImpl,由业务控制如果拉消息,更新消费进度等方式。

2. 集群模式VS广播模式
  集群模式:
  • 消息的消费进度,即consumerOffset.json保存在broker上。
  • 所有consumer平均消费topic的消息。
  • 消息消费失败后,consumer会发回broker,broker根据消费失败次数设置不同的delayLevel进行重发。
  • 相同topic不同的consumerGroup组成伪广播模式,可达到所有consumer都会收到消息。

  广播模式:
  • 消息的消费进度保存在consumer的机器上。
  • 所有的consumer都会收到topic下的消息。
  • 消息消费失败后直接丢弃,不会发回broker进行重投递。


3. ConsumeFromWhere
  consumer可以设置消费的起始点,MQ提供了三种方式:
 
  • CONSUME_FROM_LAST_OFFSET
  • CONSUME_FROM_FIRST_OFFSET
  • CONSUME_FROM_TIMESTAMP

  我们从源码的角度,理解这三种不同消费点的含义。DefaultMQPushConsumerImpl内部有一个类RebalancePushImpl,首先计算客户端需要拉取队列,然后到broker获取消费进度,获取消费offset代码在computePullFromWhere方法:
public long computePullFromWhere(MessageQueue mq) {
        long result = -1;
        final ConsumeFromWhere consumeFromWhere = this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeFromWhere();
        final OffsetStore offsetStore = this.defaultMQPushConsumerImpl.getOffsetStore();
        switch (consumeFromWhere) {
            case CONSUME_FROM_LAST_OFFSET_AND_FROM_MIN_WHEN_BOOT_FIRST:
            case CONSUME_FROM_MIN_OFFSET:
            case CONSUME_FROM_MAX_OFFSET:
            case CONSUME_FROM_LAST_OFFSET: {
                long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);
                if (lastOffset >= 0) {
                    result = lastOffset;
                }
                // First start,no offset
                else if (-1 == lastOffset) {
                    if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        result = 0L;
                    } else {
                        try {
                            result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);
                        } catch (MQClientException e) {
                            result = -1;
                        }
                    }
                } else {
                    result = -1;
                }
                break;
            }
            case CONSUME_FROM_FIRST_OFFSET: {
                long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);
                if (lastOffset >= 0) {
                    result = lastOffset;
                } else if (-1 == lastOffset) {
                    result = 0L;
                } else {
                    result = -1;
                }
                break;
            }
            case CONSUME_FROM_TIMESTAMP: {
                long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);
                if (lastOffset >= 0) {
                    result = lastOffset;
                } else if (-1 == lastOffset) {
                    if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        try {
                            result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);
                        } catch (MQClientException e) {
                            result = -1;
                        }
                    } else {
                        try {
                            long timestamp = UtilAll.parseDate(this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeTimestamp(),
                                    UtilAll.yyyyMMddHHmmss).getTime();
                            result = this.mQClientFactory.getMQAdminImpl().searchOffset(mq, timestamp);
                        } catch (MQClientException e) {
                            result = -1;
                        }
                    }
                } else {
                    result = -1;
                }
                break;
            }

            default:
                break;
        }

        return result;
    }

  首先看CONSUME_FROM_LAST_OFFSET的逻辑,lastOffset >= 0,意味着broker端有消费进度了,说明之前已经启动且消费了一些消息,那么就从返回的offset开始消费。当-1 == lastOffset,如果为重试队列,从头消费,为普通队列则从最大offset处消费。
  CONSUME_FROM_TIMESTAMP,如果为第一次启动,即-1 == lastOffset时,为普通队列的话,从设置的时间点开始消费,如果未设置时间点,默认从半小时前开始消费。
private String consumeTimestamp = UtilAll.timeMillisToHumanString3(System.currentTimeMillis() - (1000 * 60 * 30));


4. 拉消息
  Consumer的启动源码如下:
public void start() throws MQClientException {
        switch (this.serviceState) {
            case CREATE_JUST:
                log.info("the consumer [{}] start beginning. messageModel={}, isUnitMode={}", this.defaultMQPushConsumer.getConsumerGroup(),
                        this.defaultMQPushConsumer.getMessageModel(), this.defaultMQPushConsumer.isUnitMode());
                this.serviceState = ServiceState.START_FAILED;

                this.checkConfig();

                this.copySubscription();

                if (this.defaultMQPushConsumer.getMessageModel() == MessageModel.CLUSTERING) {
                    this.defaultMQPushConsumer.changeInstanceNameToPID();
                }

                this.mQClientFactory = MQClientManager.getInstance().getAndCreateMQClientInstance(this.defaultMQPushConsumer, this.rpcHook);

                this.rebalanceImpl.setConsumerGroup(this.defaultMQPushConsumer.getConsumerGroup());
                this.rebalanceImpl.setMessageModel(this.defaultMQPushConsumer.getMessageModel());
                this.rebalanceImpl.setAllocateMessageQueueStrategy(this.defaultMQPushConsumer.getAllocateMessageQueueStrategy());
                this.rebalanceImpl.setmQClientFactory(this.mQClientFactory);

                this.pullAPIWrapper = new PullAPIWrapper(//
                        mQClientFactory, //
                        this.defaultMQPushConsumer.getConsumerGroup(), isUnitMode());
                this.pullAPIWrapper.registerFilterMessageHook(filterMessageHookList);

                if (this.defaultMQPushConsumer.getOffsetStore() != null) {
                    this.offsetStore = this.defaultMQPushConsumer.getOffsetStore();
                } else {
                    switch (this.defaultMQPushConsumer.getMessageModel()) {
                        case BROADCASTING:
                            this.offsetStore = new LocalFileOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
                            break;
                        case CLUSTERING:
                            this.offsetStore = new RemoteBrokerOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
                            break;
                        default:
                            break;
                    }
                }
                this.offsetStore.load();

                if (this.getMessageListenerInner() instanceof MessageListenerOrderly) {
                    this.consumeOrderly = true;
                    this.consumeMessageService =
                            new ConsumeMessageOrderlyService(this, (MessageListenerOrderly) this.getMessageListenerInner());
                } else if (this.getMessageListenerInner() instanceof MessageListenerConcurrently) {
                    this.consumeOrderly = false;
                    this.consumeMessageService =
                            new ConsumeMessageConcurrentlyService(this, (MessageListenerConcurrently) this.getMessageListenerInner());
                }

               this.consumeMessageService.start();

                boolean registerOK = mQClientFactory.registerConsumer(this.defaultMQPushConsumer.getConsumerGroup(), this);
                if (!registerOK) {
                    this.serviceState = ServiceState.CREATE_JUST;
                    this.consumeMessageService.shutdown();
                    throw new MQClientException("The consumer group[" + this.defaultMQPushConsumer.getConsumerGroup()
                            + "] has been created before, specify another name please." + FAQUrl.suggestTodo(FAQUrl.GROUP_NAME_DUPLICATE_URL),
                            null);
                }

               mQClientFactory.start();
                log.info("the consumer [{}] start OK.", this.defaultMQPushConsumer.getConsumerGroup());
                this.serviceState = ServiceState.RUNNING;
                break;
            case RUNNING:
            case START_FAILED:
            case SHUTDOWN_ALREADY:
                throw new MQClientException("The PushConsumer service state not OK, maybe started once, "//
                        + this.serviceState//
                        + FAQUrl.suggestTodo(FAQUrl.CLIENT_SERVICE_NOT_OK),
                        null);
            default:
                break;
        }

        this.updateTopicSubscribeInfoWhenSubscriptionChanged();

        this.mQClientFactory.sendHeartbeatToAllBrokerWithLock();

        this.mQClientFactory.rebalanceImmediately();
    }

this.offsetStore.load();

  首先就是加载消息消费进度,BROADCASTING模式实例化LocalFileOffsetStore,CLUSTERING实例化RemoteBrokerOffsetStore,加载内存,以后所有的读写都是直接操作的内存数据,由定时任务每隔5s进行落盘。
this.consumeMessageService.start();

  为消费消息服务,默认实现为ConsumeMessageConcurrentlyService,即并发消费。
mQClientFactory.start();

  mQClientFactory的启动会建立和broker通道,定时任务,拉消息服务,负载均衡服务。由于拉消息的请求是由负载均衡发起,所以先说负载均衡服务。
  负载均衡服务由RebalanceService线程每隔20s做一次,跟踪代码最终会调用到RebalanceImpl#rebalanceByTopic方法:
case BROADCASTING: {
                Set<MessageQueue> mqSet = this.topicSubscribeInfoTable.get(topic);
                if (mqSet != null) {
                    boolean changed = this.updateProcessQueueTableInRebalance(topic, mqSet, isOrder);
                    if (changed) {
                        this.messageQueueChanged(topic, mqSet, mqSet);
                        log.info("messageQueueChanged {} {} {} {}", //
                                consumerGroup, //
                                topic, //
                                mqSet, //
                                mqSet);
                    }
                } else {
                    log.warn("doRebalance, {}, but the topic[{}] not exist.", consumerGroup, topic);
                }
                break;
            }

  广播模式,由于所有consumer都需要收到消息,所以不存在负载均衡策略。
List<String> cidAll = this.mQClientFactory.findConsumerIdList(topic, consumerGroup);

  集群模式下,首先通过topic和consumerGroup获取consumer列表,然后分配拉取消息队列,默认为平均分配策略AllocateMessageQueueAveragely。

  直接mock数据,可以看到AllocateMessageQueueAveragely的allocate方法,就是以上结论。
  得到当前consumer需要拉取的消息队列后,到RebalanceImpl#updateProcessQueueTableInRebalance进行拉取数据请求PullRequest构造,到DefaultMQPushConsumerImpl#pullMessage进行拉取消息前的逻辑整合,最终通过mQClientFactory内部的mQClientAPIImpl通道到broker异步拉取数据。
  回到DefaultMQPushConsumerImpl#pullMessage方法,看一下内部的逻辑:
long size = processQueue.getMsgCount().get();
        if (size > this.defaultMQPushConsumer.getPullThresholdForQueue()) {
            this.executePullRequestLater(pullRequest, PullTimeDelayMillsWhenFlowControl);
            if ((flowControlTimes1++ % 1000) == 0) {
                log.warn(
                        "the consumer message buffer is full, so do flow control, minOffset={}, maxOffset={}, size={}, pullRequest={}, flowControlTimes={}",
                        processQueue.getMsgTreeMap().firstKey(), processQueue.getMsgTreeMap().lastKey(), size, pullRequest, flowControlTimes1);
            }
            return;
        }

  由于拉取的消息,会放到本地队列ProcessQueue进行处理,当发现本地队列大小超过1000,就延迟50ms再拉取。
 if (!this.consumeOrderly) {
            if (processQueue.getMaxSpan() > this.defaultMQPushConsumer.getConsumeConcurrentlyMaxSpan()) {
                this.executePullRequestLater(pullRequest, PullTimeDelayMillsWhenFlowControl);
                if ((flowControlTimes2++ % 1000) == 0) {
                    log.warn(
                            "the queue's messages, span too long, so do flow control, minOffset={}, maxOffset={}, maxSpan={}, pullRequest={}, flowControlTimes={}",
                            processQueue.getMsgTreeMap().firstKey(), processQueue.getMsgTreeMap().lastKey(), processQueue.getMaxSpan(),
                            pullRequest, flowControlTimes2);
                }
                return;
            }
        }

  由于消息以offset为key,放入本地队列ProcessQueue的TreeMap中,所以这里有一步span检查。当span值(即this.msgTreeMap.lastKey() - this.msgTreeMap.firstKey())大于2000时,延迟拉取。 由于业务关系,消息消费快慢无法保证,如果offset大的消息处理的快,本地队列就会积压offset小的消息,所以span的值可能会越来越大。
  由于是异步拉取消息,所以这里需要构造一个PullCallback对象。onSuccess方法内:
if (pullResult != null) {
                    pullResult = DefaultMQPushConsumerImpl.this.pullAPIWrapper.processPullResult(pullRequest.getMessageQueue(), pullResult,
                            subscriptionData);

  对拉取结果进行处理,如果有消息,反序列化,再进行一步tag的比较去重。前面章节,有提到过,broker的ConsumeQueue中保存tag的hashcode值,所以consumer的此步去重是保证消息的准确性。
boolean dispathToConsume = processQueue.putMessage(pullResult.getMsgFoundList());
DefaultMQPushConsumerImpl.this.consumeMessageService.submitConsumeRequest(//
                                        pullResult.getMsgFoundList(), //
                                        processQueue, //
                                        pullRequest.getMessageQueue(), //
                                        dispathToConsume);

  然后将消息放入本地队列,并通过submitConsumeRequest方法构造ConsumeRequest,由于consumeBatchSize为1,提交任务到consumeExecutor线程池(20个线程),每线程每消息并发处理,ConsumeRequest会调用consumeMessageService触发MessageListener#consumeMessage,执行业务处理。
ConsumeMessageConcurrentlyService.this.processConsumeResult(status, context, this);

  在ConsumeRequest#run业务处理完后,执行processConsumeResult方法:
switch (this.defaultMQPushConsumer.getMessageModel()) {
            case BROADCASTING:
                for (int i = ackIndex + 1; i < consumeRequest.getMsgs().size(); i++) {
                    MessageExt msg = consumeRequest.getMsgs().get(i);
                    log.warn("BROADCASTING, the message consume failed, drop it, {}", msg.toString());
                }
                break;
            case CLUSTERING:
                List<MessageExt> msgBackFailed = new ArrayList<MessageExt>(consumeRequest.getMsgs().size());
                for (int i = ackIndex + 1; i < consumeRequest.getMsgs().size(); i++) {
                    MessageExt msg = consumeRequest.getMsgs().get(i);
                    boolean result = this.sendMessageBack(msg, context);
                    if (!result) {
                        msg.setReconsumeTimes(msg.getReconsumeTimes() + 1);
                        msgBackFailed.add(msg);
                    }
                }

                if (!msgBackFailed.isEmpty()) {
                    consumeRequest.getMsgs().removeAll(msgBackFailed);

                    this.submitConsumeRequestLater(msgBackFailed, consumeRequest.getProcessQueue(), consumeRequest.getMessageQueue());
                }
                break;
            default:
                break;
        }

  当业务处理返回RECONSUME_LATER后,ackIndex为-1,返回CONSUME_SUCCESS,ackIndex为0,。如果consumer为广播模式,消息消费失败后,直接打印log。如果consumer为集群模式,消息会通过this.sendMessageBack(msg, context)发回broker,consumer会重新收到消息。如果发回broker失败,consumer会尝试5s后重新消费。
  发回broker的这些消费失败消息会根据消费失败的次数设置不同的delayLevel。SendMessageProcessor#consumerSendMsgBack:
if (msgExt.getReconsumeTimes() >= maxReconsumeTimes//
                || delayLevel < 0) {
            newTopic = MixAll.getDLQTopic(requestHeader.getGroup());
            queueIdInt = Math.abs(this.random.nextInt() % 99999999) % DLQ_NUMS_PER_GROUP;

            topicConfig = this.brokerController.getTopicConfigManager().createTopicInSendMessageBackMethod(newTopic, //
                    DLQ_NUMS_PER_GROUP, //
                    PermName.PERM_WRITE, 0
            );
            if (null == topicConfig) {
                response.setCode(ResponseCode.SYSTEM_ERROR);
                response.setRemark("topic[" + newTopic + "] not exist");
                return response;
            }
        }

        else {
            if (0 == delayLevel) {
                delayLevel = 3 + msgExt.getReconsumeTimes();
            }

            msgExt.setDelayTimeLevel(delayLevel);
        }

  第一次消费失败,msgExt.getReconsumeTimes()为0,由于原始messageDelayLevel为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”,当delayLevel为3的情况下,就对应10s,也就是说,第一次消费失败的消息,会在10s后重新消费,依次类推。消息自第一次消费失败后,由原先的topic转入%RETRY%队列,如果消息消费失败次数大于maxReconsumeTimes(16次),消息会进入DLQ队列。
 
long offset = consumeRequest.getProcessQueue().removeMessage(consumeRequest.getMsgs());
if (offset >= 0 && !consumeRequest.getProcessQueue().isDropped()) {
          this.defaultMQPushConsumerImpl.getOffsetStore().updateOffset(consumeRequest.getMessageQueue(), offset, true);
        }

  然后删除本地处理队列ProcessQueue中数据,注意这个removeMessage方法内部,永远返回的是msgTreeMap.firstKey(),所以更新消费的offset永远为最小值,这也正是MQ官方文档中说,MQ的重复消息需要让业务端过滤或采用幂等操作。
 
5. 长轮询
  前面提到,consumer是长轮询拉消息,当consumer拉消息时,broker端如果没有新消息,broker会通过PullRequestHoldService服务hold住这个请求:
if (brokerAllowSuspend && hasSuspendFlag) {
                        long pollingTimeMills = suspendTimeoutMillisLong;
                        if (!this.brokerController.getBrokerConfig().isLongPollingEnable()) {
                            pollingTimeMills = this.brokerController.getBrokerConfig().getShortPollingTimeMills();
                        }

                        String topic = requestHeader.getTopic();
                        long offset = requestHeader.getQueueOffset();
                        int queueId = requestHeader.getQueueId();
                        PullRequest pullRequest = new PullRequest(request, channel, pollingTimeMills,
                                this.brokerController.getMessageStore().now(), offset, subscriptionData);
                        this.brokerController.getPullRequestHoldService().suspendPullRequest(topic, queueId, pullRequest);
                        response = null;
                        break;
                    }

  Broker通过ReputMessageService异步构建ConsumeQueue并通过注册的MessageArrivingListener通知PullRequestHoldService#notifyMessageArriving达到有消息,立即推送给consumer。ReputMessageService#doReput:
if (BrokerRole.SLAVE != DefaultMessageStore.this.getMessageStoreConfig().getBrokerRole()
                                            && DefaultMessageStore.this.brokerConfig.isLongPollingEnable()) {
                                        DefaultMessageStore.this.messageArrivingListener.arriving(dispatchRequest.getTopic(),
                                                dispatchRequest.getQueueId(), dispatchRequest.getConsumeQueueOffset() + 1,
                                                dispatchRequest.getTagsCode());
                                    }

public void arriving(String topic, int queueId, long logicOffset, long tagsCode) {
        this.pullRequestHoldService.notifyMessageArriving(topic, queueId, logicOffset, tagsCode);
    }
  • 大小: 72.7 KB
分享到:
评论

相关推荐

    rocketmq-externals-master.zip

    "rocketmq-externals-master.zip"是一个包含RocketMQ源码的压缩包,对于深入理解RocketMQ的工作原理、性能优化以及进行二次开发非常有帮助。下面将详细阐述RocketMQ的核心概念、架构、工作流程以及源码解析的关键点...

    消息中间件rocketmq原理解析

    以下将基于给定内容详细解析RocketMQ的原理解析。 ### RocketMQ概述 RocketMQ是由阿里巴巴开源的一款分布式消息中间件。它提供了分布式系统之间的异步消息通信能力,广泛应用于各种业务场景中,如订单处理、任务...

    RocketMQ原理详解

    ### RocketMQ原理详解 #### 一、RocketMQ概述 RocketMQ是一款由阿里巴巴开源的消息中间件,主要用于异步处理、解耦、削峰等场景。它提供了高性能、高可靠性的消息服务,支持点对点消息、发布/订阅模式、事务消息等...

    消息中间件 rocketmq原理解析

    本文将从以下几个方面对RocketMQ的原理进行解析。 ### 一、Producer #### 1. Producer启动流程 Producer是消息的发送者,它的启动流程如下: - 在发送消息时,如果Producer集合中没有对应topic的信息,则会向...

    rocketmq相关jar包.zip

    2. `rocketmq-common-4.7.0.jar`:这个jar包包含了RocketMQ的通用模块,提供了一些基础工具类和常量,如NameServer地址解析、配置管理、时间戳处理、线程池管理等。同时,它也包含了一些核心的数据结构,如Message...

    RocketMQ实战与原理

    Producer: 生产者,负责生产消息并发送到消息引擎。测评开始时,测评程序会启动10~20...对于被多个Consumer订阅的某个Topic,这些Consumer直接的消费应该是独立的,也就是每个Consumer都应该全量消费这个Topic的消息。

    Rocketmq核心源码剖析-图灵杨过老师1

    在深入探讨RocketMQ核心源码之前,...通过对RocketMQ的CommitLog和ConsumeQueue的理解,以及NameServer和Broker架构的解析,我们可以更深入地掌握RocketMQ的工作原理,这对于优化系统性能和解决实际问题具有重要意义。

    RocketMQ实战与原理解析.zip

    《RocketMQ实战与原理解析》是一本专为IT专业人士准备的深度学习Apache RocketMQ的指南。这本书分为两大部分:基础入门和源码分析,旨在帮助读者从零开始熟悉RocketMQ,并逐步深入到其核心机制的理解。 在基础入门...

    阿里RocketMQ_用户指南_V3.2.4 & RocketMQ-原理简介

    在《RocketMQ-原理简介.pdf》中,可能会深入解析RocketMQ的工作原理: 1. **消息存储机制**:RocketMQ采用日志文件存储消息,通过CommitLog和IndexFile配合,实现高效的消息查询和检索。 2. **消息传输机制**:...

    rocketmq-4.9.2版本

    以下是对RocketMQ核心知识点的详细解析: 1. **消息模型** - **点对点(P2P)**:消费者可以从队列中拉取消息,每个消息只会被一个消费者消费,适合一对多的发布/订阅场景。 - **发布/订阅(Pub/Sub)**:主题下...

    RocketMQ原理分析.rar

    本压缩包“RocketMQ原理分析.rar”包含了对RocketMQ核心机制的深入解析,旨在帮助用户理解其工作原理。 RocketMQ的核心组件包括Producer、Consumer、NameServer和Broker四个部分: 1. **Producer**: 生产者是消息...

    RocketMQ实战与原理解析

    ### RocketMQ实战与原理解析 #### 一、RocketMQ简介 Apache RocketMQ是一个分布式消息中间件,由阿里巴巴捐赠并成为Apache顶级项目。RocketMQ具备高性能、低延迟、高可靠等特性,支持发布/订阅模式、消息过滤、...

    rocketmq-原理简析(适合初级使用者)

    本篇文章主要针对初级使用者,解析RocketMQ的基本概念和工作原理。 1. **ProducerGroup** ProducerGroup 是一组具有相同属性的Producer的集合,这些属性包括处理的消息类型(Topic)以及处理逻辑。在事务消息机制...

    全面解剖RocketMQ和项目实战-day4-part2.7z

    【全面解剖RocketMQ与项目实战-day4-part2】是一个深入学习Apache RocketMQ的课程资料压缩包,包含多个视频教程,旨在帮助用户深入了解RocketMQ的工作原理及实际应用。RocketMQ是一个开源的消息中间件,广泛应用于...

    全面解剖RocketMQ和项目实战-day4-part5.7z

    在"全面解剖RocketMQ和项目实战-day4-part5.7z"这个压缩包中,包含了一系列视频教程,详细讲解了RocketMQ的关键特性和实战技巧,下面将对这些知识点进行深入解析。 1. **拉取消息长轮询机制(54.拉取消息长轮询机制...

    RocketMQ-master.rar

    在Java编程环境中,RocketMQ的源码解析可以帮助我们理解其内部工作原理,包括消息的生产、消费、存储和调度机制。以下是一些可能涉及的知识点: 1. **消息模型**:RocketMQ支持两种消息模型,发布/订阅(Publish/...

    RocketMQ入门实战及源码解析.7z

    本知识点将深入探讨RocketMQ的基础概念、工作原理、实战应用以及源码解析。 一、RocketMQ基础 1. 概念:RocketMQ是一个基于发布/订阅模式的消息队列,支持事务消息、定时/延时消息、顺序消息等多种特性,广泛应用...

    全面解剖RocketMQ和项目实战-day4-part4.7z

    在这个“全面解剖RocketMQ和项目实战-day4-part4.7z”资料包中,包含了一系列视频教程,详细讲解了RocketMQ的关键特性和工作流程,下面将对这些知识点进行深入解析。 1. **实时更新消息消费队列与索引文件流程说明*...

    RocketMQ最全介绍与实战.pdf

    RocketMQ 的架构主要包括 Producer、Consumer、Broker、NameServer、Topic、Message Queue 等角色。Producer 是消息的发送者,Consumer 是消息接收者,Broker 是暂存和传输消息的中间件,NameServer 是管理 Broker ...

Global site tag (gtag.js) - Google Analytics