这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Broker 是 RocketMQ 的存储与服务节点。它接收生产者请求，维护 Topic 路由和队列，写入 CommitLog，构建消费索引，向消费者提供拉取服务，并参与权限控制、延迟调度、事务回查和高可用切换。
17.1 整体组件
Broker
|-- remoting server 网络通信
|-- topic manager Topic、队列、权限
|-- message store CommitLog、ConsumeQueue、Index
|-- consumer manager 消费组、位点、订阅
|-- transaction service 半消息与回查
|-- schedule service 延迟或定时消息
|-- replication 主从复制
|-- admin service 运维接口
`-- stats / metrics 指标与审计
Broker 不是简单转发进程，大多数核心逻辑都围绕本地存储状态展开。
17.2 请求处理链路
发送：
client request
-> decode protocol
-> auth and rate limit
-> validate topic
-> append message
-> replicate / flush
-> response
消费：
consumer pull request
-> check subscription
-> read consumequeue
-> filter message
-> read commitlog
-> response
-> consumer commit offset later
理解链路有助于判断瓶颈在 CPU、内存、磁盘、网络还是下游服务。
17.3 Topic 与路由
Broker 维护：
| 对象 | 内容 |
|---|---|
| TopicConfig | 队列数、权限、类型 |
| QueueData | Broker、queueNum、权限 |
| RouteInfo | NameServer 汇总后的路由 |
NameServer 保存路由快照，不负责强一致事务。Broker 配置修改后要确认所有 NameServer 的视图一致。
17.4 消费组管理
Broker 记录：
- 消费组名称；
- 订阅关系；
- 队列位点；
- 客户端连接；
- 重试和死信配置。
订阅关系必须一致：
group: order-consumer
instance A -> OrderTopic, TagA
instance B -> OrderTopic, TagB
同一消费组订阅不同 Topic 或 Tag，会导致消费异常、队列分配混乱或位点不正确。
17.5 线程模型
常见线程类型：
| 线程 | 作用 |
|---|---|
| Accept / EventLoop | 网络连接和 IO |
| Request worker | 请求处理 |
| PutMessage | 消息写入 |
| PullMessage | 消息读取 |
| Reput | 索引分发 |
| Flush | 刷盘 |
| Clean | 文件回收 |
| Admin | 运维命令 |
线程堆积通常不是“加线程数”能解决的问题，要先看锁竞争、磁盘延迟、页缓存和下游状态。
17.6 内存与磁盘
内存主要用于：
- 网络缓冲；
- 热点队列索引；
- 消息查询；
- 线程栈；
- 页缓存。
磁盘主要用于：
- CommitLog；
- ConsumeQueue；
- IndexFile；
- 配置和 checkpoint；
- 日志。
生产建议：
- 数据盘与系统盘分离；
- 日志目录单独监控；
- 避免多个存储型服务抢盘；
- 关注 inode、文件句柄、目录项；
- 使用与集群规模匹配的磁盘类型。
17.7 限流与保护
Broker 可以从以下维度保护：
| 维度 | 示例 |
|---|---|
| Topic | 限制写入 TPS |
| 消息大小 | 拒绝超大消息 |
| 队列 | 防止单队列热点 |
| 消费拉取 | 限制空拉和过载 |
| 请求 | 限制 admin 和查询 |
| 磁盘 | 高水位拒写 |
应用侧也应设置生产并发和重试上限，避免 Broker 故障时客户端重试风暴。
17.8 安全边界
Broker 层安全包括：
- ACL 账号；
- Topic 读写权限；
- 管理接口鉴权；
- TLS 传输加密；
- IP 白名单；
- 审计日志。
最小权限示例：
order-service:
OrderTopic READ_WRITE
OrderDLQTopic READ
admin topic DENY
不要给业务应用统一管理员账号。
17.9 观测指标
broker_active_connections
broker_request_queue_size
broker_put_tps
broker_get_tps
broker_put_latency_p99
broker_pull_latency_p99
broker_thread_pool_active
commitlog_dispatch_lag
broker_disk_usage
broker_exception_total
排障时先固定一个视角：
时间线
-> 客户端现象
-> Broker 指标
-> 磁盘和网络
-> 代码或配置变更
17.10 常见故障
| 现象 | 可能原因 |
|---|---|
| Broker 退出 | OOM、磁盘损坏、系统重启、误操作 |
| 请求堆积 | 磁盘慢、热点 Topic、线程池满 |
| Topic 不存在 | 配置丢失、环境错误、权限 |
| 路由不更新 | NameServer 连接异常 |
| 消费位点丢失 | 配置损坏、异常恢复、误操作 |
| 查询慢 | 冷读、索引重、磁盘竞争 |
本章小结
Broker 的核心职责是把网络请求转换为可靠的本地存储状态，并维护 Topic、队列、消费组、事务和复制的一致性。读懂数据流和线程模型，才能判断性能瓶颈与故障根因。生产环境必须同时治理磁盘、路由、订阅、权限、限流和指标。
思考题
- Broker 与 NameServer 的职责边界是什么？
- 为什么同一消费组订阅关系必须一致？
- 哪些问题会表现为请求线程堆积？
- Broker 高磁盘水位应该如何处理？
- 为什么业务应用不应使用管理员账号？