RocketMQ思维导图
2024-03-15 11:15:29 0 举报AI智能生成
登录查看完整内容
RocketMQ是一个高性能、高可靠的消息中间件，它支持队列模型、主题模型等多种消息模式。具有低延迟、高吞吐量的特性，适合处理海量数据。文件类型为Java和Scala。RocketMQ是由阿里巴巴开发的，基于Apache 2.0许可证，支持分布式事务、消息过滤、死信队列等多种功能。适用于高并发、高可用、高性能的场景，如互联网金融、电子商务、IoT等。
作者其他创作
大纲/内容
负责生产消息，将消息发送到broker服务器
Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态
消息发送方发出一条消息后，在收到服务端同步响应之后才发下一条消息
SendResult send(final Message msg)
同步发送
消息发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息，通过设置回调函数来判断服务端接收情况
异步发送
消息发送方发出一条消息后，不管服务端的响应，接着发送下一条消息，没有回调。即只发送请求不等待应答
void sendOneway(final Message msg)
单向发送
普通消息发送
消息的消费顺序和发送顺序一致
某个Topic下的所有消息都要保证顺序（比如要保证所有的订单消息的有序性）
单一的生产者，所有消息串行的发送，对系统的吞吐量影响很大，一般很少用
全局顺序消息
只要保证每一组消息的有序性即可（比如保证同一笔订单的消息被顺序发送和消费即可）
在消费端要使用顺序消费方式，void registerMessageListener(MessageListenerOrderly messageListener)
部分顺序消息
分类
顺序消息发送
消息发送到Broker后不立即投递该消息，而是延迟一段时间后消费者才能消费该消息
Message message = new Message();message.setDelayTimeLevel(3);
订单超过30分钟没有支付则关闭订单，则可以发送一条消息，延迟30分钟投递，消费者判断订单状态，如果没有支付则关闭订单
应用
延迟消息发送
在对吞吐率有一定要求的情况下，Apache RocketMQ可以将一些消息聚成一批以后进行发送，可以增加吞吐率，并减少API和网络调用次数。
批量消息发送
事务消息是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。它基于两阶段提交和定时事务状态回查来决定消息最终是提交还是回滚
1、生产者向broker发送一个半事务消息
2、半事务消息发送成功后，执行本地事务，提交本地事务
3、根据本地事务的执行情况，向broker提交commit或rollback
4、如果没收到第3步的确认，定时向生产者回查本地事务知否执行成功
5、broker根据本地事务执行情况来判断是否向消费者投递消息
步骤
事务消息发送
消息发送方式
生产者Producer
负责消费消息，从broker服务器拉取消息消费
如果多个消费者设置了相同的Consumer Group，则这些消费者在同一个消费组内
消费组
一条消息只会被消费组内的一个消费者消费
平均分配策略（默认策略）
机房优先分配策略
一致性hash分配策略
消息分配策略
集群消费模式
一条消息会被消费组内的所有消费者消费
广播消费模式
消费模式
消费位点是指消费者启动后从哪个位置开始消费消息
CONSUME_FROM_LAST_OFFSET
CONSUME_FROM_FIRST_OFFSET
CONSUME_FROM_TIMESTAMP
方式
消费位点
消费者自己到broker队列中拉取消息，并自己维护消费位点
拉取式pull
消费者订阅topic，由broker向消费者推送消息
并发消费
顺序消费
消息过滤
消息重试
死信队列
推送式push
消费者获取消息方式
Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
消费者Consumer
表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题
主题Topic
topic路由注册中心，支持topic和broker的动态注册和发现
Name Server接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检查机制，检查Broker是否还存活
broker管理
每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费
路由信息管理
功能
NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息
命名服务器NameServer
主要负责消息的存储、投递和查询
Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个
每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer
代理服务器Broker
消息主题，通过 Topic 对不同的业务消息进行分类
topic
消息的实际内容
body
消息标签，用来进一步区分某个 Topic 下的消息分类
Tags
每个消息可以在业务层面的设置唯一标识码 keys 字段，方便来查询消息
Keys
为了支持高并发和水平扩展，需要对 Topic 进行分区，在 RocketMQ 中这被称为队列。一个 Topic 可能有多个队列，并且可能分布在不同的 Broker 上。一条消息只会在一个队列里。一个队列也只会被一个消费者消费
队列
消息
基本概念
应用解耦
流量削峰
RocketMQ
0 条评论
回复 删除
下一页
