RocketMQ 是什么?

RocketMQ 是 Alibaba 捐赠给 Apache 的一款分布式、队列模型的开源消息中间件。

• Github https://github.com/apache/rocketmq

从官网也能看出它的一些特性:

• 低延迟
• 高可用
• 万亿级的消息支持
• …

RocketMQ 基本概念

RocketMQ 是由 Producer、Broker、Consumer 三部分组成, Producer 负责生产 Message, Consumer 负责消费 Message, Broker 负责存储 Message。 每个 Broker 可以存储多个 Topic 的消息, 每个 Topic 的消息也可以分片存储在不同的 Broker 上。 Message Queue 用于存储消息的物理地址，每个 Topic 的消息地址存储于对歌 Message Queue 中。 Consumer Group 由多个 Consumer 实例组成。

• Producer 负责生产消息，同步发送、异步发送、顺序发送、单向发送。同步和异步需要 Broker 确认信息，单向发送不需要。

• Consumer 负责消费消息，一般异步消费。一个消费者会从 Broker 拉取消息。（拉取式消费、推动式消费）

• Broker Server 负责存储、转发消息。 接收 Producer 发送来的消息并存储、同时为 Consumer 拉取请求做准备。当然也存储这消息相关的元数据（消费组、消费进度偏移、主题、队列消息等）

• Name Server 为消息路由的提供者。Producer 和 Consumer 能够通过 它查找各个 Topic 相应的 Broker IP 列表，多个 Name Server 组成集群，相互独立、没有信息交换。

• Message 消息系统所传输信息的物理载体，生产和消费数据的最小单元，每条消息必须属于一个 Topic, RocketMQ 中每个消息拥有一个唯一的 MessageID，且可以携带业务标识的Key。系统提供通过 MessageId 和 Key 查询消息的功能

• Topic 表示一类消息的集合，每个 Topic 包含若干条消息，每条消息智只能属于一个 topic，是 RocketMQ 进行 消息定义的基本单位。

• Tag 为消息设置的标志，用于同一个 Topic 下区分不同类型的消息。来自同一个业务单元的消息，可以根据不同的业务在同一个主题下设置不同的标签。Tag 能够有效的保持代码清晰度和连贯性，并优化 RocketMQ 的查询系统。 Consumer 可以根据 Tag 实现不同的子主题的不同消费逻辑。

• Pull Consumer

• Push Consumer

• Producer Group

• Consumer Group

• Clustering

• Broadcasting

• Normal Ordered Message

• Strictly Ordered Message

RocketMQ 部署架构

• Producer: 消息发布决赛、支持分布式集群部署，Producer 通过MQ的负载均衡莫款选择相应的 Broker 进行消息投递。
• Consumer: 消息消费角色、支持分布式集群部署，支持Push方式、Pull方式对消息进行消费，同时也指出集群方式和广播方式进行消费。
• Name Server: NameServer 是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。

• Broker管理，NameServer 接受 Broker集群 的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
• 路由信息管理, 每个 NameServer 将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Consumer 通过 NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。 NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息

RocketMQ 网路部署特点:

• NameSever 是无状态节点，可集群部署，节点之间无任何信息同步。Broker 是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。
• Broker 部署相对复杂，Broker 分为 Master 与 Slave ，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。 注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。
• Producer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
• Consumer 与 NameServer 集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。

RocketMQ * 事务消息 *

后面专门一章讲述这个事务消息