RocketMQ

数据流图

组件解释

Producer

消息的生产者，Producer通过MQ 的负载均衡模块选择相应的Broker集群队列进行消息投递，比如电商系统产生的订单消息。

Consumer

消息的消费者，消费者会从Broker中获取数据，进行后续的消息处理，比如从Broker中获取到订单信息，之后库存业务系统会根据订单中的商品进行对应的库存减少。

Name Server

路由中心，主要保存的是Broker和Topic的关系，支持Broker的动态注册和发现

• Broker 管理

  • 受Broker集群的注册信息并且保存下来作为路由信息的基本数据

  • 心跳检测 机制，检查Broker是否还存活

• 路由信息管理

每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。

路由注册

Name Server 集群中每个节点是不互相通信的，每个节点都保存了全部的Broker集群的信息。

Broker 在启动的时候会轮询Name Server集群列表，与每个Name Server进行长连接建立，发起注册请求，在Name Server 内部维护着一个Broker 列表，用来动态存储Broker信息【内存存储】

心跳机制

Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以心跳包的方式上报给NameServer，每30秒发送一次心跳。

路由剔除

由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。

路由发现

RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。

订阅模型：

• Push模型：推送模型。其实时性较好，是一个“发布-订阅”模型，需要维护一个长连接。而长连接的维护是需要资源成本的，使用场景：Client数量不多，Server数据变化较频繁

• Pull模型：拉取模型。存在的问题是，实时性较差

• Long Polling模型：长轮询模型。其是对Push与Pull模型的整合，充分利用了这两种模型的优势，屏蔽了它们的劣势。

选择策略

客户端选择策略【生产者和消费者】客户端首先会生产一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后就会进行连接。

Broker

消息中转站，负责存储消息和转发消息，Broker 在RocketMQ 中负责接收并存储从生产者发来的消息，同时为消费者的拉取做准备，Broker 同时也存储消息相关的元数据，包括消费者组的消费进度偏移offset【集群消费的场景下】、主题、队列等等。

模块

• Remoting Module：整个Broker的实体，负责来自客户端的请求

• Client Manager：客户端管理器，负责接收和解析客户端的请求，管理客户端。例如维护消费者与订阅的主题之间的关系

• Store Service：存储服务。消息存储以及消息查询

• HA Service：高可用服务，提供 M - S 之间的数据同步

• Index Service：索引服务，根据Message Key 查询消息

复制策略

a) 同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ack。

b) 异步复制：消息写入master后，master立即向producer返回成功ack，无需等待slave同步数据成功。

工作流程

发送消息

Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址（IP+Port）的映射关系。然后根据算法策略从队选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。

消费消息

Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。

获取消息方式：

• 拉取式：Consumer主动从broker中拉去消息，这种方式实时性较弱。

• 推送式：Broker收到数据后主动推送给Consumer，该方式一般实时性较高。该方式是经典的发布-订阅模式。

消费消息方式：

• 广播消费：即每条消息都会发送到消费者组里的每个Consumer。消费进度保存在consumer端，因为每个Consumer都会收到消息，它们的消费进度是不同的，所以consumer各自保存各自的消费进度。

• 集群消费：组内的每个Consumer实例平均分摊同一个Topic的消息，即每条消息只会发送到组内某个Consumer。消费进度保存在Broker中，同一条消息只会被消费一次，消费进度会参与到消费的负载均衡中，所以消费进度是需要共享的。