RocketMQ思维导图

2024-03-15 11:15:29   0  举报





AI智能生成

RocketMQ是一个高性能、高可靠的消息中间件，它支持队列模型、主题模型等多种消息模式。具有低延迟、高吞吐量的特性，适合处理海量数据。文件类型为Java和Scala。RocketMQ是由阿里巴巴开发的，基于Apache 2.0许可证，支持分布式事务、消息过滤、死信队列等多种功能。适用于高并发、高可用、高性能的场景，如互联网金融、电子商务、IoT等。

RocketMQ

作者其他创作

大纲/内容

基本概念

生产者Producer

负责生产消息，将消息发送到broker服务器

Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态

消息发送方式

普通消息发送

同步发送

消息发送方发出一条消息后，在收到服务端同步响应之后才发下一条消息

SendResult send(final Message msg)

异步发送

消息发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息，通过设置回调函数来判断服务端接收情况

void send(final Message msg, final SendCallback sendCallback)

单向发送

消息发送方发出一条消息后，不管服务端的响应，接着发送下一条消息，没有回调。即只发送请求不等待应答

void sendOneway(final Message msg)

顺序消息发送

消息的消费顺序和发送顺序一致

分类

全局顺序消息

某个Topic下的所有消息都要保证顺序（比如要保证所有的订单消息的有序性）

单一的生产者，所有消息串行的发送，对系统的吞吐量影响很大，一般很少用

部分顺序消息

只要保证每一组消息的有序性即可（比如保证同一笔订单的消息被顺序发送和消费即可）

只要让同一组的消息被发送到同一个队列即可，因为一个队列的消息是先进先出，同一个队列里的消息是有序的 SendResult send(final Message msg, final MessageQueueSelector selector, final Object arg)

在消费端要使用顺序消费方式，void registerMessageListener(MessageListenerOrderly messageListener)

延迟消息发送

消息发送到Broker后不立即投递该消息，而是延迟一段时间后消费者才能消费该消息

Message message = new Message(); message.setDelayTimeLevel(3);

应用

订单超过30分钟没有支付则关闭订单，则可以发送一条消息，延迟30分钟投递，消费者判断订单状态，如果没有支付则关闭订单

批量消息发送

在对吞吐率有一定要求的情况下，Apache RocketMQ可以将一些消息聚成一批以后进行发送，可以增加吞吐率，并减少API和网络调用次数。

List<Message> messages = new ArrayList<>(); messages.add(new Message(topic, "Tag", "OrderID001", "Hello world 0".getBytes())); messages.add(new Message(topic, "Tag", "OrderID002", "Hello world 1".getBytes())); producer.send(messages);

事务消息发送

事务消息是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。它基于两阶段提交和定时事务状态回查来决定消息最终是提交还是回滚

步骤

1、生产者向broker发送一个半事务消息

2、半事务消息发送成功后，执行本地事务，提交本地事务

3、根据本地事务的执行情况，向broker提交commit或rollback

4、如果没收到第3步的确认，定时向生产者回查本地事务知否执行成功

5、broker根据本地事务执行情况来判断是否向消费者投递消息

消费者Consumer

负责消费消息，从broker服务器拉取消息消费

消费组

如果多个消费者设置了相同的Consumer Group，则这些消费者在同一个消费组内

消费模式

集群消费模式

一条消息只会被消费组内的一个消费者消费

消息分配策略

平均分配策略（默认策略）

机房优先分配策略

一致性hash分配策略

广播消费模式

一条消息会被消费组内的所有消费者消费

消费位点

消费位点是指消费者启动后从哪个位置开始消费消息

方式

CONSUME_FROM_LAST_OFFSET

CONSUME_FROM_FIRST_OFFSET

CONSUME_FROM_TIMESTAMP

消费者获取消息方式

拉取式pull

消费者自己到broker队列中拉取消息，并自己维护消费位点

推送式push

消费者订阅topic，由broker向消费者推送消息

并发消费

顺序消费

消息过滤

消息重试

死信队列

Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。

主题Topic

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题

命名服务器NameServer

topic路由注册中心，支持topic和broker的动态注册和发现

功能

broker管理

Name Server接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。 然后提供心跳检查机制，检查Broker是否还存活

路由信息管理

每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。 Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费

NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息

代理服务器Broker

主要负责消息的存储、投递和查询

Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个

每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer

消息

topic

消息主题，通过 Topic 对不同的业务消息进行分类

body

消息的实际内容