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 消费。