1.RocketMQ 介绍及术语

1. 介绍

2. 集群架构

• NameServer互相独立，彼此没有通信关系，单台NameServer挂掉，不影响其他NameServer。NameServer不去连接别的机器，不会主动推消息。

• 单个broker（Master、Slave）与所有NameServer进行定时注册，以便告知NameServer自己还活着。Broker每隔30秒向所有NameServer发送心跳，心跳包含了自身的topic配置信息。NameServer每隔10秒，扫描所有还存活的broker连接，如果某个连接的最后更新时间与当前时间差值超过2分钟，则断开此连接。此外，NameServer也会断开此broker下所有与slave的连接。同时更新topic与队列的对应关系，但不会通知生产者和消费者。
  Broker slave 同步或者异步从Broker master 上拷贝数据。

• consumer随机与一个NameServer建立长连接，如果该NameServer断开，则从NameServer列表中查找下一个进行连接。
  consumer主要从NameServer中根据topic查询broker的地址，查到就会缓存到客户端，并向提供topic服务的master、slave建立长连接，且定时向master、slave发送心跳。如果broker宕机，则NameServer会将其剔除，而consumer端的定时任务MQClientInstance.this.updateTopicRouteInfoFromNameServer每30秒执行一次，会将topic对应的broker地址拉取下来，此地址已经为slave地址了，故此时consumer会从slave上消费。 消费者与master和slave都建有连接，在不同场景有不同的消费规则。

• Producer随机与一个NameServer建立长连接，每隔30秒（此处时间可配置）从NameServer获取topic的最新队列情况，这就表示如果某个broker master宕机，producer最多30秒才能感知，在这个期间，发往该broker master的消息将会失败。Producer会向提供topic服务的master建立长连接，且定时向master发送心跳。生产者与所有的master连接，但不能向slave写入。
  客户端是先从NameServer寻址的，得到可用Broker的IP和端口信息，然后自己去连接broker。
  （ps：我们在设计系统的时候，有一些全局使用的公用信息，可以单独独立一个模块进行专门的管理；各个子模块只需要定时向该模块更新信息即可。）

综上所述，我们可以得出NameServer在RocketMQ中所扮演的角色：

• NameServer 用来保存活跃的 broker 列表，包括 Master 和 Slave 。

• NameServer 用来保存所有 topic 和该 topic 所有队列的列表。

• NameServer 用来保存所有 broker 的 Filter 列表。

3. 术语及说明

3.1. Server Name

NameServer的作用是注册中心，类似于Zookeeper，但又有区别于它的地方。每个NameServer节点互相之间是独立的，没有任何信息交互，也就不存在任何的选主或者主从切换之类的问题，因此NameServer与Zookeeper相比更轻量级。
单个NameServer节点中存储了活跃的Broker列表（包括master和slave），这里活跃的定义是与NameServer保持有心跳。

nameserver接收broker的请求，注册broker的路由信息。
nameserver接收client（producer/consumer）的请求，根据消息的topic获取相应的broker路由信息。
（手动创建的topic可以指定broker，自动创建的topic会随机指定broker，也许指定单个或全部，topic的概念在后面。）
集群部署后，节点之间无任何信息同步。

3.2. Broker

rocketmq的核心组件，负责消息的接收、存储（持久化到磁盘）、被消费者拉取消息等功能。
broker也存储消息相关的元数据，包括：消费者组、消费进度、topic&queue信息等。
broker是个逻辑概念，1个broker = 1个master + 0至n个slave，
具有同1个broker name的master和slave进行配对。

3.3. Topic

一种消息的逻辑分类（消息的类型），比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类存储。

生产者方面：发消息时需指定topic，可以有1-n个生产者发布1个topic的消息，也1个生产者可以发布不同topic的消息。

消费者方面：收消息时需订阅topic，可以有1-n个消费者组订阅1个topic的消息，1个消费者组可以订阅不同topic的消息。

1个消息必须指定1个topic，topic允许自动创建与手工创建，topic创建时需要指定broker，可以指定1个或多个，name server就是通过broker与topic的映射关系来做路由。

producer和consumer在生产和消费消息时，都需要指定消息的 topic，当topic匹配时，consumer 才会消费到producer发送的消息。

topic与broker是多对多的关系，一个topic分布在多个broker上，一个broker可以配置多个topic。

一个topic下可以有多个queue，默认自动创建是4个，手动创建是8个。

3.4. Message

message是消息的载体。每个message必须指定一个topic，相当于寄信的地址。

message还有一个可选的tag设置，以便消费端可以基于tag进行过滤消息。

message还有扩展的kv结构，例如你可以设置一个业务key到你的消息中，在broker上查找消息并诊断问题。

注意：msgId与msgKey。

3.5. Tag

Tags是Topic下的次级消息类型，一般在相同业务模块中通过引入标签来标记不同用途的消息，可以在同一个Topic下基于Tags进行消息过滤

（注：Tags也支持TagA || TagB这样的表达式）

Tags的过滤需要经过两次比对，首先会在Broker端通过Tag hashcode进行一次比对过滤，匹配成功传到consumer端后再对具体Tags进行比对，以防止Tag hashcode重复的情况。

3.7. Queue

queue是消息的物理管理单位，而topic是逻辑管理单位。一个topic下可以有多个queue，默认自动创建是4个，手动创建是8个。

1个message只能属于1个queue、1个topic。

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

另外队列中只保存最近几天的数据，之前的数据会按照过期时间来删除。

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

3.8. Offset

理解成消费进度，可自增。

3.9. CommitLog

虽然每个topic下面有很多message queue，但是message queue本身并不存储消息。

真正的消息存储会写在CommitLog的文件，message queue只是存储CommitLog中对应的位置信息，方便通过message queue找到对应存储在CommitLog的消息。

不同的topic，message queue都是写到相同的CommitLog 文件，也就是说CommitLog完全的顺序写。

3.10. Producer

消息的生产者，负责发送消息，将消息推送给broker。
消息有3种发送方式：同步、异步、单向

3.11. ProducerGroup

具有同样逻辑消费同样消息的consumer，可以归并为一个group。同一个group内的消费者，
可以共同消费（集群消费模式）对应topic的消息，达到分布式并行处理（负载均衡）的功能。

集群模式下，同一条消息只会被同一个 consumer group 中的一个消费者消费，不同 consumer group 的 consumer 可以消费同一条消息

广播模式下，多个 consumer 都会消费到同一条消息。

3.12. Consumer

消息的消费者，从broker上拉取消息从而进行消费。

rocketmq提供两种消费者。

• 主动消费者
  DefaultMQPullConsumer，从broker中拉取一批消息并消费，主动权由消费者控制。
• 被动消费者
  DefaultMQPushConsumer，消费者实现回调接口，一旦有消息，broker回调接口，消费者被动响应。

3.13. ConsumerGroup

通常具有同样作用（同样topic）的一些producer可以归为同一个group。

在事务消息机制中，如果发送某条事务消息后的producer-A宕机，使得事务消息一直处于PREPARED状态并超时，
则broker会回查同一个group的其他producer，确认这条消息应该commit还是rollback。

3.14. Clustering

在 Clustering 模式下，同一个 ConsumerGroup（GroupName 相同）里的每个 Consumer 只消费所订阅消息的一部分内容，同一个 ConsumerGroup 里所有的 Consumer 消费的内容合起来才是所订阅 Topic 内容的整体，从而达到负载均衡的目的。

3.15. Broadcasting

在 Broadcasting 模式下，同一个 ConsumerGroup 里的每个 Consumer 都能消费到所订阅 Topic 的全部消息，也就是一个消息会被多次分发，被多个 Consumer 消费。