weixin_39313241的博客

前提介绍：一定要先看前面的几篇文章，了解rocketmq的基本概念和架构设计之后再看本篇消费模式消费者以消费者组的模式开展。消费者组之间有集群模式和广播模式两种消费模式。然后消费模式有推模式和拉模式。推模式是由拉模式封装组成。集群模式下，消费队列负载均衡的通用原理：一个消费队列同一时间只能被一个消费者消费，而一个消费者可以同时消费多个队列。消息顺序：RocketMQ只支持一个队列上的局部消息顺序，不保证全局消息顺序。 要实现顺序消息，可以把有序的消息指定为一个queue，或者给Topic只指定

前提介绍：一定要先看前面的几篇文章，了解rocketmq的基本概念和架构设计之后再看本篇Producer 分类Producer有两种。 一个是普通发送者DefaultMQProducer。这个只需要构建一个Netty客户端。还一个是事务消息发送者： TransactionMQProducer。这个需要构建一个Netty客户端同时也要构建Netty服务端（用于接受broker的回查）。DefaultMQProducer 启动官方提供的Producer例子/* * Licensed to

启动加载配置创建关键组件BrokerControllerorg.apache.rocketmq.broker.BrokerStartup#createBrokerController通过读取配置 包括BrokerConfig、NettyServerConfig、 《Netty服务端占用了10911端口。》NettyClientConfig、MessageStoreConfig等等配置后封装了BrokerController 。BrokerController 代表了整个brokerBro

前提请大家先浏览我前面转载的官网的一些rocketmq的基本概念和架构设计之后再阅读本文。NameServer 是什么官网解释：NameServer 充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。白话文：生产者和消费者怎么知道每个broker的地址以及broker上消息分别存放在集群中的那台机器上？NameServer就是为了解决这个，可以理解为就是一个数据库。NameServe

设计(design)1 消息存储消息存储是RocketMQ中最为复杂和最为重要的一部分，本节将分别从RocketMQ的消息存储整体架构、PageCache与Mmap内存映射以及RocketMQ中两种不同的刷盘方式三方面来分别展开叙述。1.1 消息存储整体架构消息存储架构图中主要有下面三个跟消息存储相关的文件构成。(1) CommitLog：消息主体以及元数据的存储主体，存储Producer端写入的消息主体内容,消息内容不是定长的。单个文件大小默认1G ，文件名长度为20位，左边补零，剩余为起始

架构设计1 技术架构RocketMQ架构上主要分为四部分，如上图所示:Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。NameServer：NameServer是一

特性(features)1 订阅与发布消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。2 消息顺序消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个Topic下的所有消

基本概念1 消息模型（Message Model）RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中