一、RocketMQ 核心架构概述

​1. 主要组件

​Name Server： 集群的「中枢神经」，负责 Topic 元数据管理（如 Topic 分区分布、Broker 节点状态监控）。
​Broker： 消息存储与流转的核心节点，负责消息的持久化、读写请求处理。
​Producer： 消息生产者，负责将消息投递到指定的 Topic。
​Consumer： 消息消费者，从 Broker 拉取消息并处理。

​2. 集群部署模式

​Name Server 集群： 通常部署 2-3 个节点，通过 ​Raft 协议实现高可用，保障元数据一致性。
​Broker 集群： 至少部署 2 个 Broker（主从或异步复制），支持横向扩展，每个 Broker 可管理多个 Partition。

​二、Partition 分区机制

​1. 设计目的

​水平扩展： 通过增加 Partition 数量提升并行处理能力。
​负载均衡： 消费者可以分散到不同 Partition 消费，避免单点瓶颈。
​顺序性保障： 单个 Partition 内的消息按生产顺序严格递增，满足事务性场景需求。

​2. 实现细节

​Topic 与 Partition：
每个 Topic 可划分为多个 ​Ordered Partition​（顺序分区）和 ​Unordered Partition​（无序分区）。
默认情况下为 Ordered Partition，需显式配置 unordered=true 启用无序模式。
​分区分配策略：
​Hash 分布：根据 Message Key 的哈希值均匀分配到各个 Partition。
​Round Robin：无 Key 时轮询分配，适用于广播场景。
​数据存储：
每个 Partition 对应一个 ​CommitLog​（提交日志），所有消息按顺序追加写入。
​IndexFile：索引文件，记录消息在 CommitLog 中的物理偏移量，加速随机读取。

​3. 示例场景

Topic: ORDER_EVENT (4 Partitions)
Partition 0: 消息 1,3,5,7...
Partition 1: 消息 2,4,6,8...
Partition 2: 消息 9,11,13...
Partition 3: 消息 10,12,14...

三、不丢消息的实现机制

1. 持久化保障

​CommitLog 设计：
所有消息先写入 CommitLog，顺序追加保证原子性。
​刷盘策略： 支持同步刷盘（SyncFlush）和异步刷盘（AsyncFlush）。
​同步刷盘： 写入 CommitLog 后立即刷盘到磁盘（默认），牺牲性能换取零数据丢失。
​异步刷盘： 周期性批量刷盘，提升吞吐但存在极小丢数据风险（可配置 flushDiskType）。
​多副本机制：
​同步复制（SyncReplicate）​： 主 Broker 写入成功后，至少等待一个从 Broker 复制确认才返回生产者（default）。
​异步复制（AsyncReplicate）​： 主 Broker 立即返回，从 Broker 异步同步（适用于对一致性要求低的场景）。

2. 生产者端可靠性

​重试与幂等性：
生产者发送消息失败后自动重试（maxRetryTimes 配置）。
支持幂等消息（通过 MessageId 或 SequenceId 避免重复消费）。
​事务消息：
通过 ​本地事务 + RocketMQ 事务消息 实现最终一致性（如订单扣减与消息发送原子性）。

​3. 消费者端可靠性

​ACK 机制：
消费者拉取消息后需手动提交 Offset（enableAutoCommit=false 关闭自动提交）。
​消费失败重试：结合 RetryPolicy 实现自动重试或死信队列处理。
​Exactly-Once 语义：
通过 ​事务消息 + 消费者 Offset 管理 实现精确一次消费（如支付成功后消息不重复）。

4. 监控与告警

​Broker 监控： 监控磁盘使用率、网络延迟、请求堆积等指标，触发异常告警。
​SLA 策略： 配置副本同步超时时间（replicaSyncTimeoutMs），超时节点自动隔离。

​四、读写性能优化

​1. 写入性能优化

​批量压缩：
启用 compressEnable=true 和 compressAlgorithm=lz4，减少网络传输和磁盘占用。
​适用场景：文本类消息（如 JSON）压缩率可达 50%+。
​零拷贝技术：
​Netty 零拷贝：直接操作 ByteBuf，避免数据在 Java 内存与 Native 内存间多次拷贝。
​文件通道：通过 MappedByteBuffer 直接映射磁盘文件，提升 IO 效率。
​多线程写入：
Broker 使用 ​多线程模型​（默认 16 个线程）处理生产者请求，充分利用 CPU 资源。

​2. 读取性能优化

​批量拉取：
消费者单次拉取消息数量可配置（pullBatchSize），减少网络 round trip。
​多消费者并行消费：
同一 Partition 的多个消费者实例通过 ​Consumer Group 并行消费，提升吞吐量。
​索引加速：
​IndexFile 二分查找消息 Offset，将随机读取复杂度从 O(n) 降至 O(log n)。

3. 网络与存储优化

​TCP 协议优化：
使用 ​长连接 减少握手开销，启用 tcpNoDelay=true 禁用 Nagle 算法。
​SSD 存储：
Broker 数据盘部署 SSD，对比 HDD，IO 延迟降低 5-10 倍。
​分区策略优化：
根据负载动态扩容 Partition（需结合客户端版本支持）。