6

认识RocketMQ4.x架构设计 - peachyy

 2 years ago
source link: https://www.cnblogs.com/peachyy/p/16723113.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

认识RocketMQ4.x架构设计

单体的消息模型

RocketMQ消息模型跟其他的消息队列一样 都是 producer - > topic->consumer

producer 生产消息 也就是发送者

topic 消息主题 按topic发送消息 以后消息的存储 分片等都是基于topic做业务处理的

consumer 消息消费者 也是基于topic来进行消息的消费 支持推和拉模式(其实内部都是pull模式的变种)。

526778-20220923160930458-1300430579.png

扩展集群消息模型

为了支持高并发、提高可扩展性、提高消息堆积能力。

一个topic可以有多个队列 而且还可以在不同的物理机器，这就为高吞吐、水平扩展支持打了基础。

在消费端consumer支持组(group)概念。一组consumer里面有多个消费者实例，一组consumer来消费某个topic 这样消费能力就得到了水平扩展

526778-20220923160938917-1585071943.png

consumer组支持集群消费模式、广播消费模式

  • 集群消费下同组consumer实例会去拉取对应topic的不同队列上数据进行消费。‘

  • 广播模式是每个消费者都会拉取对应topic中所有队列的消息来消费。

RocketMQ总体最组件分为 NameServer Broker Porducer Consumer

526778-20220923160948163-1839933850.png
NameServer 名称服务

NameServer类似于Zookeeper这种角色 负责管理集群组件，简单来说NameServer可以查询到Broker有哪些、Topic在哪些Broker机器上 队列是如何分布的，它就像一颗大脑 管理者 收集者。相当于是一个topic路由管理中心，NameServer可以多实例分别独立部署、相互之间不产出数据交换，每个Broker在启动的时候会向所有的NameServer上报信息，所以他们之间可以相互独立，完全无状态。就算挂掉1个也不影响集群。

Broker 消息存储代理服务

Broker才是真正托管消费存储、投递查询的服务，这个是非常核心的服务，大部分的性能优化都是针对这个服务进行。Broker分为master slave角色 在配置文件中brokerId=0表示Master 不为0表示slave。

broker启动后和NameServer建立了长连接 定期向NameServer上报Topic信息自身信息。

producer 生产者

生产/发送消息服务，一般是程序自己编写的业务发送消息端，启动后首先会和NameServer建立连接，定时从NameServer获取Topic路由信息，定时查询Broker服务信息 同时会和Broker master角色建立长连接。producer 也是无状态的。

consumer 消费者

消费者服务 一般是由自己业务程序编写实现。启动后和NameServer建立连接 定时从NameServer获取topic信息和Broker信息，获取到Broker的信息后会和broker中的master salve角色也建立长连接 所有consumer中可以订阅master和slave。

只有非常懂IO的人 才能写得出来这么优秀的框架 里面有太多值的学习和借鉴的设计和思想 后面再慢慢精研。

相关链接 https://www.cnblogs.com/peachyy/p/9406526.html


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK