- 浏览: 157064 次
- 性别:
- 来自: 大连
文章分类
最新评论
-
eclipseakwolf:
很棒的文章
Shiro User Manual-Authentication -
xugangqiang:
very good
Java Concurrent Programming (1) -
jlcon:
是不是AbstractShiroTest还需要继承EasyMo ...
Shiro User Manual-Testing -
jlcon:
createNiceMock这个EasyMockSupport ...
Shiro User Manual-Testing -
Technoboy:
53873039oycg 写道楼主:问下,你的那个dao接口的 ...
Shiro Example
1. 介绍
Consumer默认使用DefaultMQPushConsumerImpl长轮询拉消息的方式来消费,可以保证实时性同Push一样。还可以参考example项目,使用DefaultMQPullConsumerImpl,由业务控制如果拉消息,更新消费进度等方式。
2. 集群模式VS广播模式
集群模式:
广播模式:
3. ConsumeFromWhere
consumer可以设置消费的起始点,MQ提供了三种方式:
我们从源码的角度,理解这三种不同消费点的含义。DefaultMQPushConsumerImpl内部有一个类RebalancePushImpl,首先计算客户端需要拉取队列,然后到broker获取消费进度,获取消费offset代码在computePullFromWhere方法:
首先看CONSUME_FROM_LAST_OFFSET的逻辑,lastOffset >= 0,意味着broker端有消费进度了,说明之前已经启动且消费了一些消息,那么就从返回的offset开始消费。当-1 == lastOffset,如果为重试队列,从头消费,为普通队列则从最大offset处消费。
CONSUME_FROM_TIMESTAMP,如果为第一次启动,即-1 == lastOffset时,为普通队列的话,从设置的时间点开始消费,如果未设置时间点,默认从半小时前开始消费。
4. 拉消息
Consumer的启动源码如下:
首先就是加载消息消费进度,BROADCASTING模式实例化LocalFileOffsetStore,CLUSTERING实例化RemoteBrokerOffsetStore,加载内存,以后所有的读写都是直接操作的内存数据,由定时任务每隔5s进行落盘。
为消费消息服务,默认实现为ConsumeMessageConcurrentlyService,即并发消费。
mQClientFactory的启动会建立和broker通道,定时任务,拉消息服务,负载均衡服务。由于拉消息的请求是由负载均衡发起,所以先说负载均衡服务。
负载均衡服务由RebalanceService线程每隔20s做一次,跟踪代码最终会调用到RebalanceImpl#rebalanceByTopic方法:
广播模式,由于所有consumer都需要收到消息,所以不存在负载均衡策略。
集群模式下,首先通过topic和consumerGroup获取consumer列表,然后分配拉取消息队列,默认为平均分配策略AllocateMessageQueueAveragely。
直接mock数据,可以看到AllocateMessageQueueAveragely的allocate方法,就是以上结论。
得到当前consumer需要拉取的消息队列后,到RebalanceImpl#updateProcessQueueTableInRebalance进行拉取数据请求PullRequest构造,到DefaultMQPushConsumerImpl#pullMessage进行拉取消息前的逻辑整合,最终通过mQClientFactory内部的mQClientAPIImpl通道到broker异步拉取数据。
回到DefaultMQPushConsumerImpl#pullMessage方法,看一下内部的逻辑:
由于拉取的消息,会放到本地队列ProcessQueue进行处理,当发现本地队列大小超过1000,就延迟50ms再拉取。
由于消息以offset为key,放入本地队列ProcessQueue的TreeMap中,所以这里有一步span检查。当span值(即this.msgTreeMap.lastKey() - this.msgTreeMap.firstKey())大于2000时,延迟拉取。 由于业务关系,消息消费快慢无法保证,如果offset大的消息处理的快,本地队列就会积压offset小的消息,所以span的值可能会越来越大。
由于是异步拉取消息,所以这里需要构造一个PullCallback对象。onSuccess方法内:
对拉取结果进行处理,如果有消息,反序列化,再进行一步tag的比较去重。前面章节,有提到过,broker的ConsumeQueue中保存tag的hashcode值,所以consumer的此步去重是保证消息的准确性。
然后将消息放入本地队列,并通过submitConsumeRequest方法构造ConsumeRequest,由于consumeBatchSize为1,提交任务到consumeExecutor线程池(20个线程),每线程每消息并发处理,ConsumeRequest会调用consumeMessageService触发MessageListener#consumeMessage,执行业务处理。
在ConsumeRequest#run业务处理完后,执行processConsumeResult方法:
当业务处理返回RECONSUME_LATER后,ackIndex为-1,返回CONSUME_SUCCESS,ackIndex为0,。如果consumer为广播模式,消息消费失败后,直接打印log。如果consumer为集群模式,消息会通过this.sendMessageBack(msg, context)发回broker,consumer会重新收到消息。如果发回broker失败,consumer会尝试5s后重新消费。
发回broker的这些消费失败消息会根据消费失败的次数设置不同的delayLevel。SendMessageProcessor#consumerSendMsgBack:
第一次消费失败,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队列。
然后删除本地处理队列ProcessQueue中数据,注意这个removeMessage方法内部,永远返回的是msgTreeMap.firstKey(),所以更新消费的offset永远为最小值,这也正是MQ官方文档中说,MQ的重复消息需要让业务端过滤或采用幂等操作。
5. 长轮询
前面提到,consumer是长轮询拉消息,当consumer拉消息时,broker端如果没有新消息,broker会通过PullRequestHoldService服务hold住这个请求:
Broker通过ReputMessageService异步构建ConsumeQueue并通过注册的MessageArrivingListener通知PullRequestHoldService#notifyMessageArriving达到有消息,立即推送给consumer。ReputMessageService#doReput:
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); }
发表评论
-
RocketMQ原理解析-Broker处理发送消息
2017-04-20 10:49 26421. 简介 Producer发送一条消息到broker后, ... -
RocketMQ原理解析-HA
2017-04-13 10:01 23111. 介绍 当broker为slave且有master的情 ... -
RocketMQ原理解析-Broker
2017-04-13 10:00 30681. 部署方式 Broker ... -
RocketMQ原理解析-Name Server
2017-04-13 10:00 13541. 介绍 Namesrv的功能,就相当于RPC中的注 ... -
RocketMQ原理解析-Setup
2017-04-13 09:59 8881. 下载 https://github.com/al ... -
RocketMQ原理解析-broker清理文件
2017-04-07 16:37 01. commitlog文件删除 RocketMQ的c ... -
RocketMQ原理解析-Index
2017-04-13 09:56 15781. 介绍 索引文件指,发送一条消息后,MQ通过(topi ... -
RocketMQ原理解析-Producer
2017-04-14 13:46 25791.启动 producer通过配置的namesrv列表 ...
相关推荐
"rocketmq-externals-master.zip"是一个包含RocketMQ源码的压缩包,对于深入理解RocketMQ的工作原理、性能优化以及进行二次开发非常有帮助。下面将详细阐述RocketMQ的核心概念、架构、工作流程以及源码解析的关键点...
以下将基于给定内容详细解析RocketMQ的原理解析。 ### RocketMQ概述 RocketMQ是由阿里巴巴开源的一款分布式消息中间件。它提供了分布式系统之间的异步消息通信能力,广泛应用于各种业务场景中,如订单处理、任务...
### RocketMQ原理详解 #### 一、RocketMQ概述 RocketMQ是一款由阿里巴巴开源的消息中间件,主要用于异步处理、解耦、削峰等场景。它提供了高性能、高可靠性的消息服务,支持点对点消息、发布/订阅模式、事务消息等...
本文将从以下几个方面对RocketMQ的原理进行解析。 ### 一、Producer #### 1. Producer启动流程 Producer是消息的发送者,它的启动流程如下: - 在发送消息时,如果Producer集合中没有对应topic的信息,则会向...
2. `rocketmq-common-4.7.0.jar`:这个jar包包含了RocketMQ的通用模块,提供了一些基础工具类和常量,如NameServer地址解析、配置管理、时间戳处理、线程池管理等。同时,它也包含了一些核心的数据结构,如Message...
Producer: 生产者,负责生产消息并发送到消息引擎。测评开始时,测评程序会启动10~20...对于被多个Consumer订阅的某个Topic,这些Consumer直接的消费应该是独立的,也就是每个Consumer都应该全量消费这个Topic的消息。
在深入探讨RocketMQ核心源码之前,...通过对RocketMQ的CommitLog和ConsumeQueue的理解,以及NameServer和Broker架构的解析,我们可以更深入地掌握RocketMQ的工作原理,这对于优化系统性能和解决实际问题具有重要意义。
《RocketMQ实战与原理解析》是一本专为IT专业人士准备的深度学习Apache RocketMQ的指南。这本书分为两大部分:基础入门和源码分析,旨在帮助读者从零开始熟悉RocketMQ,并逐步深入到其核心机制的理解。 在基础入门...
在《RocketMQ-原理简介.pdf》中,可能会深入解析RocketMQ的工作原理: 1. **消息存储机制**:RocketMQ采用日志文件存储消息,通过CommitLog和IndexFile配合,实现高效的消息查询和检索。 2. **消息传输机制**:...
以下是对RocketMQ核心知识点的详细解析: 1. **消息模型** - **点对点(P2P)**:消费者可以从队列中拉取消息,每个消息只会被一个消费者消费,适合一对多的发布/订阅场景。 - **发布/订阅(Pub/Sub)**:主题下...
本压缩包“RocketMQ原理分析.rar”包含了对RocketMQ核心机制的深入解析,旨在帮助用户理解其工作原理。 RocketMQ的核心组件包括Producer、Consumer、NameServer和Broker四个部分: 1. **Producer**: 生产者是消息...
### RocketMQ实战与原理解析 #### 一、RocketMQ简介 Apache RocketMQ是一个分布式消息中间件,由阿里巴巴捐赠并成为Apache顶级项目。RocketMQ具备高性能、低延迟、高可靠等特性,支持发布/订阅模式、消息过滤、...
本篇文章主要针对初级使用者,解析RocketMQ的基本概念和工作原理。 1. **ProducerGroup** ProducerGroup 是一组具有相同属性的Producer的集合,这些属性包括处理的消息类型(Topic)以及处理逻辑。在事务消息机制...
【全面解剖RocketMQ与项目实战-day4-part2】是一个深入学习Apache RocketMQ的课程资料压缩包,包含多个视频教程,旨在帮助用户深入了解RocketMQ的工作原理及实际应用。RocketMQ是一个开源的消息中间件,广泛应用于...
在"全面解剖RocketMQ和项目实战-day4-part5.7z"这个压缩包中,包含了一系列视频教程,详细讲解了RocketMQ的关键特性和实战技巧,下面将对这些知识点进行深入解析。 1. **拉取消息长轮询机制(54.拉取消息长轮询机制...
在Java编程环境中,RocketMQ的源码解析可以帮助我们理解其内部工作原理,包括消息的生产、消费、存储和调度机制。以下是一些可能涉及的知识点: 1. **消息模型**:RocketMQ支持两种消息模型,发布/订阅(Publish/...
本知识点将深入探讨RocketMQ的基础概念、工作原理、实战应用以及源码解析。 一、RocketMQ基础 1. 概念:RocketMQ是一个基于发布/订阅模式的消息队列,支持事务消息、定时/延时消息、顺序消息等多种特性,广泛应用...
在这个“全面解剖RocketMQ和项目实战-day4-part4.7z”资料包中,包含了一系列视频教程,详细讲解了RocketMQ的关键特性和工作流程,下面将对这些知识点进行深入解析。 1. **实时更新消息消费队列与索引文件流程说明*...
RocketMQ 的架构主要包括 Producer、Consumer、Broker、NameServer、Topic、Message Queue 等角色。Producer 是消息的发送者,Consumer 是消息接收者,Broker 是暂存和传输消息的中间件,NameServer 是管理 Broker ...