m0_37604110的博客

1.顺序消息 1.1消息队列负载 RocketMQ 首先需要通过 RebalanceService 线程实现消息队列的负载， 集群模式下同一个消 费组 内的消 费者共同承担其订阅主题下消息队列的消费， 同一个消息消费队列在同一时刻只会被消费组内一个消费者消费， 一个消费者同一时刻可以分配多个消费队列 List<PullRequest> pullRequestList = new ArrayList<PullRequest>(); for (MessageQueue mq : mqSe

1.消息消费过程 PullMessageService 负责对消息队列进行消息拉取，从远端服务器拉取消息后将消息存入 ProcessQueue 消息队列处理队列中，然后调用 Consum Message Ser vice#submitConsumeRequest 方法进行消息消费，使用线程池来消费消息，确保了消息拉取与消息消费的解祸 1.1消息消费 消费者消息消费服务 ConsumeMessageConcurrentlyService 的主要方法是 submitConsumeRequest提交消费请求，具

1.消息拉取流程 1.PullMessageService 实现机制 @Override public void run() { log.info(this.getServiceName() + " service started"); while (!this.isStopped()) { try { PullRequest pullRequest = this.pullRequestQueue.take(); this.p

1.消费者启动流程 @Override public void start() throws MQClientException { setConsumerGroup(NamespaceUtil.wrapNamespace(this.getNamespace(), this.consumerGroup)); this.defaultMQPushConsumerImpl.start(); } public synchronized void start() throws MQClientEx

1.RocketMQ实时更新消息消费队列 索引文件 当消息生产者提交的消息存储在CommitLog文件中,ConsumeQueue,IndexFile需要及时更新,RocketMQ通过开启一个线程ReputMessageServcie来准实时转发CommitLog文件更新事件,相应的任务处理器根据转发的消息及时更新ConsumeQueue,IndexFile文件 if (this.getMessageStoreConfig().isDuplicationEnable()) { this.reputMes

RocketMQ消息刷盘 流程图 1.源码分析 RocketMQ 存储与读写是基于 JDK NIO 的内存映射机制（ MappedByteBuffer ）的，消息存储时首先将消息追加到内存，再根据配 的刷盘 略在不同时间进行刷写磁盘 ,如果是同步刷盘，消息追加到内存后，将同步调用 MappedByteBuffer的force()方法；；如果是异步刷盘，在消息追加到内存后立刻返回给消息发送端 RocketMQ 使用 一个单独的线程按照某一个设定的频率执行刷盘操作.通过在 broker 配置文件中配置 flu

RocketMQ的消息存储 RocketMQ 会创建多个MappedFile用来存储文件，每个MappedFile大小固定，有自己的内存缓冲区和对应的系统文件，所有的MappedFile由CommitLog中的MappedFileQueue统一维护 每个Broker都对应有一个MessageStore，专门用来存储发送到它的消息，不过MessageStore本身不是文件，只是存储的一个抽象，MessageStore 中保存着一个 CommitLog，CommitLog 维护了一个 MappedFileQue

RocketMq消费发送 流程图 1.生产者启动流程 public void start(final boolean startFactory) throws MQClientException { //1.检查 productGroup 是否符合要求； this.checkConfig(); //2. 并改变生产者 instanceName 为进程 ID if (!this.defaultMQProducer.getProdu

NameServer 源码分析 流程图 1.NameServer 架构设计 Broker 消息服务器在启动时向所有 Name Server 注册，消息生产者（Producer）在发送消息之前先从 Name Server 获取 Broker 服务器地址列表，然后根据负载算法从列表中选择一台消息服务器进行消息发送 NameServer 与每台 Broker 服务器保持长连接，并间隔 30sBroker 是否存活，如果检测到 Broker 从路由注册表中将其移除 但是路由变化不会马上通知消息生产者，为什么要这样