🎶 文章简介:RocketMq的基本概念
💡 创作目的:关于RocketMq的基本概念的大致介绍
☀️ 今日天气:阳光明媚。
📝 每日一言:冬有冬的来意,雪有雪的秘密。
文章目录
- 🐶 1、Rocket四大部分
- 🐺 1.1、NameServer (核心部分)
- 🐱 1.1.1、NameServer路由注册
- 🐯 1.1.2、NameServer路由剔除
- 🦒 1.1.3、NameServer路由发现
- 🦊 1.1.4、NameServer客户端选择策略
- 🐔 1.2、Broker (消息存储中心)
- 🐲 1.2.1、模块构成
- 🐸 1.3、Producer(生产者/发布者)
- 🐼 1.4、Consumer(消费者/订阅者)
🐶 1、Rocket四大部分
RocketMQ主要有四大核心组成部分:NameServer、Broker、Producer以及Consumer四部分。
🐺 1.1、NameServer (核心部分)
Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。
NameServer 是整个 RocketMQ 的“大脑” ,它是 RocketMQ 的服务注册中心,所以 RocketMQ 需要先启动 NameServer 再启动 Rocket 中的 Broker。
🐱 1.1.1、NameServer路由注册
NameServer通常来说也是以集群的形式来进行部署。但是NameServer是无状态的,也就是说NameServer的集群中各个部分是无差异的,各个节点之间不进行相互通信。
那么集群中各个节点是如何进行同步的呢?
在Borker节点启动之后,它会对NameServer列表进行轮训,与每一个NameServer节点建立连接,发起注册请求,而在NameServer内部也维护着一个Borker列表,用来动态存储Borker的信息。
这样做的优点
NameServer集群搭建很简单!
这样做的缺点
对于Borker必须明确指出所有NameServer地址,否者未指出的将不会进行注册!因此NameServer不能随便扩容!
🐯 1.1.2、NameServer路由剔除
如果Borker关机、宕机或网络抖动原因,NameServer没有收到Borker的心跳,NameServer就可能会将其从Borker列表中进行剔除!
NameServer中有一个定时任务,会每隔十秒扫描一次Borker列表,查看每一个Broker的最新心跳时间戳距离当前时间是否超过120s,如果超过则会剔除该borker。
🦒 1.1.3、NameServer路由发现
RocketMq默认使用的是Pull模型。当Topic信息发生变化时,NameServer不会主动推送给客户端,而客户端定时拉取主题最新的路由。默认客户端会每隔30s去拉取一次。
Push模式:推送模型。 实时性比较好,是一个“发布-订阅”模型,需要维护一个长连接。而长链接会需要消耗大量资源。
Pull模型:拉取模型。存在的问题是 实时性比较差!
Long Polling模型:长轮询模型。其是对Push 和 Pull 的整合,充分利用了两种模型的优势,屏蔽了她们的劣势。
长链接:一般用于 实时性要求很高的场景 或者 Client不多,Server数据变化比较频繁的场景
🦊 1.1.4、NameServer客户端选择策略
这里所指的客户端是指 Producer 和 Consumer
客户端在配置时必须要写上一个NameServer集群的地址,那么客户端到底连接的是哪个NameServer的节点呢?客户端首先会首选一个随机数,然后再与NameServer的节点数取模,此时得到的就是他连接的节点的索引,然后就回去连接对应节点。如果说该节点出现异常无法连接,那么就会采用round-robin策略,逐个去连接其他的节点。
首先采用的是随机策略,连接失败之后采用的是轮询策略。
🐔 1.2、Broker (消息存储中心)
消息服务器(Broker)充当着消息中转角色,负责消息存储、转发。
消息服务器(Broker)是消息存储中心,主要作用是接收来自 Producer 的消息并存储,Consumer 从这里取得消息。它还存储与消息相关的元数据,包括用户组、消费进度偏移量、队列信息等。从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型,Master 既可以写又可以读,Slave不可以写只可以读。
🐲 1.2.1、模块构成
Remoting Moudle:整个Broker的实体,负责处理来自clients端的请求。而Borker实体则由以下模块构成。
Client Manager:客户端管理器。负责接受、解析客户端(Producter/Consumer)请求,管理客户端。例如,维护Consumer的Topic订阅信息。
Store Service:存储服务。提供方便简单的API接口,处理消息存储到物理硬盘和消息查询功能。
HA Service:高可用服务,提供 Master Broker 和 Slave Borker 之间的数据同步功能。
Index Service:索引服务。根据特定的Message Key,对投递到Borker的消息进行索引,同时也提供了快速查询的方式。
🐸 1.3、Producer(生产者/发布者)
也称为消息发布者,负责生产并发送消息至 Topic。
生产者向brokers发送由业务应用程序系统生成的消息。RocketMQ提供了发送:同步、异步和单向(one-way)的多种范例。
🐼 1.4、Consumer(消费者/订阅者)
也称为消息订阅者,负责从 Topic 接收并消费消息。
消费者从brokers那里拉取信息并将其输入应用程序。