RocketMQ小记

Rocketmq

https://rocketmq.apache.org/docs/quick-start/

github： https://github.com/apache/rocketmq

Apache RocketMQ 架构

• Name Server :是一个无状态节点，可集群部署，在消息队列 MQ 中提供命名服务，更新和发现 Broker 服务
• Broker ： 消息中转角色，负责存储、转发消息。 分为 Master Broker 和 Slave Broker ，一个 Master Broker 可以对应多个 Slave Broker 。Broker 启动后将自己注册到 Name Server 。随后每30秒定期向 Name Server 上报 Topic 路由信息。
• 生产者： 与 Name Server 集群中的其中一个节点（随机）建立长连 。 定期从Name Server 读取 Topic 路由。并向提供 Topic 服务的 Master Broker 建立长链接 。 定时向Master Broker 发送心跳
• 消费者： 与 Name Server 集群中的其中一个节点建立长链接。定期中Name Server 拉去Topic 路由信息。 并向提供 Topic 的Master Broker、slave Broker 建立长连。且定时向 Master Broker 、Slave Broker 发送心跳。 消费者即可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 决定。

功能

发布/订阅消息传递模型

财务级交易消息

各种跨语言客户端，例如Java，C / C ++，Python，Go

可插拔的传输协议，例如TCP，SSL，AIO

内置的消息跟踪功能，还支持开放式跟踪

多功能的大数据和流生态系统集成

按时间或偏移量追溯消息

可靠的FIFO和严格的有序消息传递在同一队列中

高效的推拉消费模型

单个队列中的百万级消息累积容量

多种消息传递协议，例如JMS和OpenMessaging

灵活的分布式横向扩展部署架构

快如闪电的批量消息交换系统

各种消息过滤器机制，例如SQL和Tag

用于隔离测试和云隔离群集的Docker映像

功能丰富的管理仪表板，用于配置，指标和监视

认证与授权

核心模块

rocketmq-broker：接受生产者发来的消息并存储（通过调用rocketmq-store），消费者从这里取得消息

rocketmq-client：提供发送、接受消息的客户端API。

rocketmq-namesrv：NameServer，类似于Zookeeper，这里保存着消息的TopicName，队列等运行时的元信息。

rocketmq-common：通用的一些类，方法，数据结构等。

rocketmq-remoting：基于Netty4的client/server + fastjson序列化 + 自定义二进制协议。

rocketmq-store：消息、索引存储等。

rocketmq-filtersrv：消息过滤器Server，需要注意的是，要实现这种过滤，需要上传代码到MQ！（一般而言，我们利用Tag足以满足大部分的过滤需求，如果更灵活更复杂的过滤需求，可以考虑filtersrv组件）。

rocketmq-tools：命令行工具。

消息模型

Message

Message（消息）就是要传输的信息。

一条消息必须有一个主题（Topic），主题可以看做是你的信件要邮寄的地址。

一条消息也可以拥有一个可选的标签（Tag）和额处的键值对，它们可以用于设置一个业务 Key 并在 Broker 上查找此消息以便在开发期间查找问题。

Topic

Topic（主题）可以看做消息的规类，它是消息的第一级类型。比如一个电商系统可以分为：交易消息、物流消息等，一条消息必须有一个 Topic 。

Topic 与生产者和消费者的关系非常松散，一个 Topic 可以有0个、1个、多个生产者向其发送消息，一个生产者也可以同时向不同的 Topic 发送消息。

一个 Topic 也可以被 0个、1个、多个消费者订阅。

Tag

Tag（标签）可以看作子主题，它是消息的第二级类型，用于为用户提供额外的灵活性。使用标签，同一业务模块不同目的的消息就可以用相同 Topic 而不同的 Tag 来标识。比如交易消息又可以分为：交易创建消息、交易完成消息等，一条消息可以没有 Tag 。

标签有助于保持您的代码干净和连贯，并且还可以为 RocketMQ 提供的查询系统提供帮助。

Group

分组，一个组可以订阅多个Topic。

分为ProducerGroup，ConsumerGroup，代表某一类的生产者和消费者，一般来说同一个服务可以作为Group，同一个Group一般来说发送和消费的消息都是一样的

Queue

在Kafka中叫Partition，每个Queue内部是有序的，在RocketMQ中分为读和写两种队列，一般来说读写队列数量一致，如果不一致就会出现很多问题。

Message Queue

Message Queue（消息队列），主题被划分为一个或多个子主题，即消息队列。

一个 Topic 下可以设置多个消息队列，发送消息时执行该消息的 Topic ，RocketMQ 会轮询该 Topic 下的所有队列将消息发出去。

消息的物理管理单位。一个Topic下可以有多个Queue，Queue的引入使得消息的存储可以分布式集群化，具有了水平扩展能力。

Offset

在RocketMQ 中，所有消息队列都是持久化，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset 来访问，Offset 为 java long 类型，64 位，理论上在 100年内不会溢出，所以认为是长度无限。

也可以认为 Message Queue 是一个长度无限的数组，Offset 就是下标。

消息消费模式

消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）。

默认情况下就是集群消费，该模式下一个消费者集群共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。

而广播消费消息会发给消费者组中的每一个消费者进行消费。

Message Order

Message Order（消息顺序）有两种：Orderly（顺序消费）和Concurrently（并行消费）。

顺序消费表示消息消费的顺序同生产者为每个消息队列发送的顺序一致，所以如果正在处理全局顺序是强制性的场景，需要确保使用的主题只有一个消息队列。

并行消费不再保证消息顺序，消费的最大并行数量受每个消费者客户端指定的线程池限制。