RocketMQ的各个角色

浅浅的花香味﹌ 2023-10-01 19:53 13阅读 0赞

1.  ## **broker** ##

*  broker面向producer和consumer接受和发送消息
 *  向nameserver提供自己的消息
 *  是消息中间件的消息存储，转发的服务器
 *  路由注册：每个broker节点，在启动时都会遍历nameserver列表，与每个nameserver建立长链接，注册自己的信息(例如:brokerId,broker名称，broker地址，所属集群名等)，之后每隔30s发送一次心跳，NameServer接收到心跳后会更新时间戳。

broker集群

*  broker高可用，可以配成master/slave结构，master可写可读，slave只可以读，master将写入的数据同步给slave
    
     *  一个master可以对应多个slave，但每一个slave只能对应一个master
     *  master和slave的对应关系可以通过指定的brokerName，不同的brokerId来定义。borkerId为0表示master，非0表示slave
 *  master多机负载，可以部署多个broker
    
     *  每个broker与nameserver集群中的所有节点建立长链接，定时注册topic信息到所有的nameserver

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5rWB5rWq5aSn5Lq6_size_20_color_FFFFFF_t_70_g_se_x_16][]

Remoting Module:整个broker的实体，负责处理来自clients端的请求， 整个broker实体则由一下模块构成

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

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

HA Service:高可用服务，根据master broker和slave broker之间的数据同步功能

Index Service:索引服务，根据特定的Message key,对投递到broker的消息进行索引服务， 同时也提供根据Message Key对消息进行快速查询的功能

### 2、producer ###

*  消息生产者，负责生产消息，producer通过MQ的负载均衡选择相应的broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
 *  RocketMQ中的消息生产者都是以生产者组的形式出现的，生产者组时同一类生产者的集合，这类Producer发送相同topic类型的消息。
 *  通过nameserver集群中的其中一个节点(随机选择)建立长链接，获取topic下面的路由信息，包括topic下面有哪些queue，这些queue分布在哪些broker上等等
 *  向提供topic的master建立长链接，定时向master发送心跳

### 3、consumer ###

消息的消费者，通过NameServer集群获取topic路由信息，连接到对应的broker上消费信息，consumer会与master和slave都建立信息。

消费者组中的Consumer数量应该小于等于订阅Topic的queue数量，如果超出queue数量，多出的consumer将不能消费。

一个Topic类型的消息可以被多个消费者组同时消费

### 4、**nameserver** ###

底层是Netty实现的，提供了路由管理，服务注册，服务发现的功能，是一个无状态节点

**路由剔除**：nameserver是服务发现者，集群中各个角色都需要定时向nameserver上报自己的状态，以便互相发现彼此，如果超时不上报的话，会把它从列表剔除。NameServer有一个定时任务，每隔10秒扫描一次broker列表，查看每一个broker的最新心跳时间戳距离当前时间是否超过120s，如果超过会判定失效，然后将其从broker列表中剔除

nameserver可以部署多个，当多个nameserver存在时，其他角色同时向他们上报信息，以保证高可用。

nameserver集群之间互不通信，没有主从的概念

nameserver是内存式存储，nameserver中的broker，topic等信息默认不会持久化

路由发现：RocketMQ采取的是pull模型，当Topic路由信息发生改变时，NameServer不会主动推送给客户端，而是客户端定时拉取最新的路由，默认30s拉取一次。

扩展：

pull模型：拉取模型，存在的问题：实时性较差 
    
    push模型：推送模型，实时性较好，是一个‘发布-订阅’模型，需要维护一个长链接, 
    而长链接的维护是需要资源成本的. 该模型适用的场景： 
        1）实时性要求较高 2）client数量不多，Server数据变化频繁 
    
    Long Polling模型(Nacos Server用的是该模型)：长轮询模型,pull和push模型的整合

**Producer和Consumer(简称客户端)如何选择NameServer：**

客户端首先会生成一个随机数，然后和NameServer的节点数量取模，此时得到的是所要连接的节点的索引，然后进行连接。如果连接失败，会采用round-robin(轮询)策略，尝试连接其他节点

### **5.RocketMQ的消息标识** ###

rocketMQ中每个消息拥有唯一的一个MessageId,并且可以携带具有业务标识的key，以方便对消息的查询。不过需要注意的是：MessageId有两个：在生产者发送消息时会自动生成一个MessageId(msgId)，当消息到达broker后，broker也会自动生成一个MessageId(offsetMsgId),msgId，offsetMsgId，key都称为消息标识

*  msgId:由producer端生成，生成规则：

producerIp+进程id+MessageClientIDSetter类的classLoader的hashcode+当前时间+AutomicInteger自增计数器

*  offsetMsgId：由broker端生成，其生成规则：

brokerIp+物理分区的offset

*  key：由用户指定的业务相关的唯一标识

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5rWB5rWq5aSn5Lq6_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/82004dc80baa41bc951f6c84fbc0ead4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5rWB5rWq5aSn5Lq6,size_20,color_FFFFFF,t_70,g_se,x_16