输入“/”快速插入内容

RocketMQ

1.
RocketMQ架构图​

common.docs_name - LarkCCM_Docs_Menu_Image

RocketMQ技术架构中有四大角色，分别是：NameServer、Broker、Producer、Consumer​

•
NameServer：注册中心，主要提供Broker管理和路由信息管理。Broker会将自己的信息注册到NameServer中，生产者和消费者会从NameServer中获取路由表然后按照路由表信息和对应的Broker进行通信​

•
Broker：主要负责的存储、投递、查询以及服务高可用的保证。一个Topic分布在多个Broker上，一个Broker可以配置多个Topic，多对多的关系。​

•
Producer：消息发布的角色，支持分布式集群部署​

•
Consumer：消息消费的角色，支持分布式集群部署。支持以 push 推，pull 拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制。​

官网的架构图如下

1.
Broker做了集群部署并且还进行了主从部署，由于消息分布在各个Broker上，一旦某个Broker宕机，则该Broker上的消息读写都会受到影响，故RocketMQ提供了master/slave的结构，slave定时从master同步数据，若master宕机，则slave提供消费服务，但是不能写入消息​

2.
为了保证HA，NameServer也做了集群部署，去中心化，单个Broker和所有NameServer保持长连接，并且在每隔30秒Broker会向所有NameServer发送心跳，心跳包含了自身的Topic配置信息​

3.
生产者需要向Broker发送消息时，需要先从NameServer获取关于Broker的路由信息，然后通过轮询的方法去向每个队列中生产数据以达到负载均衡的效果​

4.
消费者通过NameServer获取所有Broker的路由信息后，向Broker发送Pull请求来获取消息数据。Consumer可以两种模式启动 - 广播和集群。​
a.
广播：一条消息会发送同一个消费组中的所有消费者​
b.
集群：只会发送一个消费者​

2.
RocketMQ功能特性​

2.1
普通消息​

普通消息一般应用于微服务解耦，事件驱动、数据集成等场景，这些场景大多数要求数据传输通道具有可靠传输的能力，且对消息的处理时机、处理顺序等没有特别要求。​

以在线的电商交易场景为例，上游订单系统将用户下单支付这一业务事件封装成独立的普通消息并发送至 RocketMQ 服务端，下游按需从服务端订阅消息并按照本地消费逻辑处理下游任务。每个消息之间都是相互独立的，且不需要产生关联。另外还有日志系统，以离线的日志收集场景为例，通过埋点组件收集前端应用的相关操作日志，并转发到 RocketMQ 。​

•
初始化（Initialized）：消息被生产者构建并完成初始化，待发送到服务端的状态​

•
待消费（Ready）：消息被发送到服务端，对消费者可见，等待消费者消费的状态​

•
消费中（Inflight）：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程，此时服务端会等待消费者完成消费并提交消费结构，若一定时间后没有收到消费者的响应，会对消息进行重试处理​

RocketMQ​

RocketMQ