RocketMQ 核心概念与功能

RocketMQ 功能

消息发送方式（消息确认机制）

RocketMQ 的 Producer 支持三种发送方式：单向发送、同步发送 和 异步发送。

发送方式	描述	特点	适用场景
单向发送	Producer 只负责发送消息，不等待任何响应结果。	吞吐量最高，但无法保证消息是否成功到达 Broker。	可靠性要求极低、可容忍少量丢失的场景（如日志、统计）。
同步发送	Producer 向 Broker 发送消息后，同步等待 Broker 的返回结果（SendResult）。	可靠性最高，能明确知道消息是否发送成功；但发送耗时较长，TPS 较低。	重要业务消息（如交易、订单）、需要严格确认的场景。
异步发送	Producer 发送消息后立即返回，不阻塞；通过回调接口处理发送结果。	吞吐量高，不阻塞线程；但需处理回调逻辑，编程稍复杂。	对发送 RT 敏感、且需要保证可靠性的场景（如日志收集、监控数据）。

单向发送

同步发送

异步发送

消息确认机制

RocketMQ 的消息确认分为两个层面：Producer 端的发送确认 和 Broker 端的存储确认。

Producer 端发送确认

同步发送和异步发送均会返回 SendResult 对象，其中包含发送状态 SendStatus。状态枚举值如下：

• SEND_OK：消息发送成功，且 Broker 已按配置完成持久化（同步刷盘或异步刷盘，取决于 Broker 设置）。
• FLUSH_DISK_TIMEOUT：消息发送成功，但 Broker 刷盘超时（仅当 Broker 配置为同步刷盘时可能发生）。
• FLUSH_SLAVE_TIMEOUT：消息发送成功，但 Broker 同步到从节点超时（仅当 Broker 配置为同步复制时可能发生）。
• SLAVE_NOT_AVAILABLE：消息发送成功，但主 Broker 配置了同步复制，却没有可用的从节点。

注意：只有 SEND_OK 才表示消息被 Broker 可靠接收。其他状态虽然消息可能已写入内存，但未满足持久化要求，应用可根据业务决定是否重试。

Broker 端存储确认

Broker 收到消息后，会根据配置决定何时向 Producer 返回确认，以及如何持久化消息。

刷盘机制

刷盘方式	配置 flushDiskType	行为	可靠性	性能
同步刷盘	SYNC_FLUSH	消息写入内存后，立即将消息刷入磁盘，成功后才返回确认。	最高，消息不会丢失（单机故障时）。	较低，需等待磁盘 I/O。
异步刷盘	ASYNC_FLUSH	消息写入内存后立即返回确认，后台线程批量刷盘。	机器掉电可能丢失少量未刷盘的消息。	高，吞吐量大。

主从复制机制

复制方式	配置 brokerRole	行为	可靠性	性能
同步复制	SYNC_MASTER	Master 收到消息后，等待消息同步到至少一个 Slave 后才返回确认。	最高，主节点故障后从节点可接管，消息不丢失。	较低，需等待网络传输。
异步复制	ASYNC_MASTER	Master 收到消息后立即返回确认，异步将消息复制到 Slave。	主节点故障时可能丢失尚未复制的消息。	高，延迟低。

组合使用：刷盘与复制可以组合，例如同步刷盘 + 同步复制提供最高的可靠性，但性能最差；异步刷盘 + 异步复制提供最高吞吐，但存在数据丢失风险。

总结与选型建议

需求	推荐发送方式	Broker 推荐配置
极高可靠性（如金融交易）	同步发送	同步刷盘 + 同步复制
高可靠性，允许少量延迟	同步发送	同步刷盘 + 异步复制
高性能，允许数据丢失（如日志）	异步发送 / 单向发送	异步刷盘 + 异步复制
中等可靠性，要求高吞吐	异步发送	异步刷盘 + 同步复制

RocketMQ 的设计允许开发者在不同场景下灵活选择发送方式和 Broker 策略，以平衡性能与可靠性。