前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >RocketMq的基本概念

RocketMq的基本概念

作者头像
木字楠
发布2023-10-17 10:46:17
1710
发布2023-10-17 10:46:17
举报
文章被收录于专栏:木字楠の空间
在这里插入图片描述
在这里插入图片描述

🎶 文章简介:RocketMq的基本概念 💡 创作目的:关于RocketMq的基本概念的大致介绍 ☀️ 今日天气:阳光明媚。 📝 每日一言:冬有冬的来意,雪有雪的秘密。


🐶 1、Rocket四大部分

RocketMQ主要有四大核心组成部分:NameServerBrokerProducer以及Consumer四部分。

image-20220620160416671
image-20220620160416671

🐺 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客户端选择策略

这里所指的客户端是指 ProducerConsumer

客户端在配置时必须要写上一个NameServer集群的地址,那么客户端到底连接的是哪个NameServer的节点呢?客户端首先会首选一个随机数,然后再与NameServer的节点数取模,此时得到的就是他连接的节点的索引,然后就回去连接对应节点。如果说该节点出现异常无法连接,那么就会采用round-robin策略,逐个去连接其他的节点。

首先采用的是随机策略,连接失败之后采用的是轮询策略

🐔 1.2、Broker (消息存储中心)

消息服务器(Broker)充当着消息中转角色,负责消息存储、转发。

消息服务器(Broker)是消息存储中心,主要作用是接收来自 Producer 的消息并存储,Consumer 从这里取得消息。它还存储与消息相关的元数据,包括用户组、消费进度偏移量、队列信息等。从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型,Master 既可以写又可以读,Slave不可以写只可以读。

🐲 1.2.1、模块构成
image-20220621134629168
image-20220621134629168

Remoting Moudle:整个Broker的实体,负责处理来自clients端的请求。而Borker实体则由以下模块构成。

Client Manager:客户端管理器。负责接受、解析客户端(Producter/Consumer)请求,管理客户端。例如,维护Consumer的Topic订阅信息。

Store Service:存储服务。提供方便简单的API接口,处理消息存储到物理硬盘消息查询功能。

HA Service:高可用服务,提供 Master BrokerSlave Borker 之间的数据同步功能。

Index Service:索引服务。根据特定的Message Key,对投递到Borker的消息进行索引,同时也提供了快速查询的方式。

🐸 1.3、Producer(生产者/发布者)

也称为消息发布者,负责生产并发送消息至 Topic。 生产者向brokers发送由业务应用程序系统生成的消息。RocketMQ提供了发送:同步、异步和单向(one-way)的多种范例。

🐼 1.4、Consumer(消费者/订阅者)

也称为消息订阅者,负责从 Topic 接收并消费消息。 消费者从brokers那里拉取信息并将其输入应用程序。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-04-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 🐶 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(消费者/订阅者)
      相关产品与服务
      对象存储
      对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档