Producer
-
Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。
-
RocketMQ 提供了三种方式发送消息：同步、异步和单向
-
同步发送：同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。
-
异步发送：异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。（一般使用这个，考虑到消息积压的风险）
-
单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。
Broker
消息中转角色，负责存储消息，转发消息。
- Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer。
- Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型。
- 官网上有数据显示：具有上亿级消息堆积能力，同时可严格保证消息的有序性。
Consumer
消息消费者，负责消费消息，一般是后台系统负责异步消费。
- Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费(
一般使用这个)和广播消息，提供实时的消息订阅机制。 - Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。
- Push：
（一般使用这个）推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息。
消息消费模式
消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）。
默认情况下就是集群消费，该模式下一个消费者集群共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。
而广播消费消息会发给消费者组中的每一个消费者进行消费。
队列分配：主题的队列会按一定策略（例如，轮询或范围分配）分配给集群中的消费者实例。
• 例如，假设一个主题有 8 个队列，消费者组中有 4 个实例，则每个消费者实例通常会分配 2 个队列
一个队列只能被一个消费者实例消费，避免重复消费。
消息回溯的实现机制
RocketMQ 的消息回溯是基于消息存储的时间戳和偏移量（Offset）来实现的。其主要原理是：
• 每条消息都有一个唯一的 偏移量（Offset） 和 时间戳（Timestamp） 。
• 当需要回溯时，消费者组可以通过指定时间戳，让 Broker 根据时间查找起始偏移量，重新分配消费位置。
RocketMQ优点
- 单机吞吐量：十万级
- 可用性：非常高，分布式架构
- 消息可靠性：经过参数优化配置，消息可以做到0丢失
- 功能支持：MQ功能较为完善，还是分布式的，扩展性好
- 支持10亿级别的消息堆积，不会因为堆积导致性能下降
- RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ
消息队列应用场景
- 应用解耦：消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节。
- 异步处理：消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息。
- 流量削锋：当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的”载体”，在下游有能力处理的时候，再进行分发与处理。
- 日志处理：日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。
- 消息通讯：消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯，比如实现点对点消息队列，或者聊天室等。
- 消息广播：如果没有消息队列，每当一个新的业务方接入，我们都要接入一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。
与kafka对比/选型考虑
核心功能对比
| 功能 | Kafka | RocketMQ |
|---|---|---|
| 消息模型 | 发布/订阅（Pub/Sub） | 发布/订阅（Pub/Sub）和点对点（P2P） |
| 存储方式 | 分区顺序存储 | 基于文件系统 + 可用索引 |
| 消息顺序 | 支持分区级顺序（全局需特殊处理） | 支持严格的全局顺序 |
| 事务消息 | 不支持事务消息（需幂等实现） | 原生支持事务消息 |
| 延迟消息 | 不支持延迟消息（需第三方实现） | 原生支持延迟消息 |
| 消息重试 | 手动控制 Offset 实现重试 | 内置重试机制，支持延迟与定时 |
| 消息回溯 | 通过 Offset 手动调整实现回溯 | 支持基于时间或 Offset 的回溯 |
| 吞吐量 | 高吞吐，适合实时日志流 | 吞吐略低，但延迟更小 |
| 跨数据中心支持 | 支持（需额外配置） | 原生支持 |
一般选型场景
-
选择 Kafka
- 高吞吐量需求，例如日志流处理、实时数据分析。
- 注重分布式架构和生态集成（如 Hadoop、Spark）。
- 对延迟消息或事务消息要求不高。
-
选择 RocketMQ
-
强事务保证，例如支付、订单等场景。
-
需要延迟消息或定时消息功能。
-
需要严格的全局消息顺序。
-
跨数据中心消息可靠性要求高。
-
