当前位置：首页 > news >正文

RocketMQ简介与应用场景

news 2024/11/15 16:53:43

简介

RocketMQ是一个由阿里巴巴开源并捐献给Apache的分布式消息中间件，具有高吞吐、低延迟、海量消息堆积等特点，广泛应用于各种分布式系统和大规模数据处理场景。

核心特征

1、高吞吐与低延迟：RocketMQ支持极高的消息吞吐量和极低的消息延迟，确保在大规模数据处理和实时消息传递中表现优异。
2、海量消息堆积：支持单一队列百万级消息、亿级消息堆积，满足大规模消息存储需求。
3、顺序消息：保证消息的顺序性，适用于证券交易、航班登机消息处理等对消息顺序有严格要求的应用场景。
4、事务消息：支持分布式事务消息，确保数据在多个系统间的一致性，适用于订单支付、库存扣减等需要原子性操作的业务。
5、消息重试与死信队列：提供消息重试机制和死信队列，确保消息在消费失败时能够得到妥善处理。
6、高可用性：支持主从复制、多副本等机制，确保消息服务的高可用性。

RocketMQ的 4个核心组件 NameServer、Broker、Producer、Consumer。
在这里插入图片描述

NameServer

NameServer是 RocketMQ中的注册中心，负责维护 Broker集群的路由信息，为了高可用，NameServer可以集群部署，需要特别注意：NameServer相互之间不会通信，它们是一种Peer to Peer的对等关系，并且每个 NameServer都保存着所有 Broker的信息。

NameServer的核心功能包括路由注册、路由发现、路由更新等，具体描述如下：当 Broker启动时会向所有的 NameServer注册自身的信息，比如 IP、端口、Topic、Queue等，NameServer会将这些信息存入本地数据表中。

默认情况下，Broker每隔 30s会向 NameServer发送一次心跳包，NameServer接收到心跳包后更新 Broker状态，如果 NameServer在 120s内没有接收到心跳包，会认为 Broker异常，从而剔除该心跳异常的 Broker。

当存在 Producer和 Consumer时，它们默认会每隔 30s定时从 NameServer获取 Broker集群信息并更新本地缓存，然后对 Broker列表进行负载均衡，从而将消息发送给 Broker或者从 Broker获取消息。

Broker

Broker是 RocketMQ中的数据存储节点，负责接收、存储和转发消息。

Broker可以集群部署，每个集群下面可以有多个组（BrokerName一样），每个组还可以主从部署，BrokerId=0 代表主节点，BrokerId=1代表从节点。

Broker的主要职责包括消息接收、消息存储、消息转发、消息索引、负载均衡，具体描述如下：
当 Broker启动时会所有的 NameServer注册信息以及后期定时向 NameServer发送心跳包，当 Broker接收到 Producer发送的消息后，首先会将消息写入 CommitLog（Write ahead log，WAL），然后开启后台线程将 CommitLog上的数据索引写入 write queue，这样可以确保消息持久化到磁盘上。
另外，Broker 会根据消费者的消费模式（推模式或拉模式），主动推送消息或等待消费者拉取消息，为了提高消息的检索速度，Broker还会为消息创建索引，支持快速定位和检索消息。

Producer

Producer是 RocketMQ中的生产者，负责发送消息。

Producer 和 Broker 是通过 Topic这样一个虚拟的概念建立关系的，当创建 Topic后，其实已经建立了 Topic和 Broker的关系，而这个关系的桥梁就是 queue，在 Broker中，有 write queue 和 read queue两种类型。

Producer每隔 30s从 NameServer拉取所有的 Topic以及 Broker信息，当消息发送到 Topic之后，消息首先会被写入一个 CommitLog的日志文件中，然后有后台线程将消息在 CommitLog磁盘上的地址等索引信息写入 write queue。这样，一个 Topic的数据就可以存储在不同的 Broker上，真正达到了数据的分布式存储，即便有部分Broker异常，受影响的数据也局限在这些 Broker上。

Producer发送消息有 3种方式：同步发送、异步发送和单向发送。
1、同步发送：Producer 发送消息后需要等待 Broker的确认，这种方式保证消息可靠地发送到 Broker，适用于对消息可靠性要求较高的场景，比如金融领域。
2、异步发送：Producer 发送消息后不等待 Broker的确认，而是通过回调函数处理发送结果，该方式可以提高系统的并发性和吞吐量，适用于日志收集，监控报警等场景。
3、单向发送：Producer 仅发送消息，不关心发送结果，也不等待 Broker的确认。这种方式的性能最高，但无法保证消息一定被发送成功，适用于数据采集，实时统计等场景。
消息重试：在消息发送失败时，Producer 可以进行重试，确保消息最终被成功发送。

Consumer

Consumer是 RocketMQ中的消费者，负责消费和处理消息，通常是真实的业务系统，Consumer的整个工作流程描述如下：
当 Consumer启动后，会向 Broker订阅感兴趣的 Topic，当 Topic中的 read queue有消息时，Consumer会定时拉取，然后执行真实的业务逻辑。当 Consumer成功处理消息后，需要向 Broker发送确认信息，Broker收到确认信息标记该消息已消费，避免重复消费，另外，为了防止丢消息，Consumer一般不建议多线程处理。Consumer可以通过顺序消费和并行消费等方式去拉取信息，从而满足不同的业务需求。

因为一个 Topic可以对应不同 Broker上的 read queue，因此，一个 Consumer可以消费不同 Broker上的数据。