这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 掌握 RocketMQ 不止是记住 API，而是能在业务、架构、存储、内核、云原生和团队协作之间做出可验证的取舍。本章给出继续精进的路线。
31.1 能力模型
| 阶段 | 核心能力 |
|---|---|
| 入门 | 部署、收发、Topic、消费组 |
| 熟练 | 事务、顺序、延迟、幂等、监控 |
| 高级 | 存储、高可用、容量、故障演练 |
| 专家 | 架构选型、平台治理、源码贡献 |
| 大师 | 在复杂业务和组织中落地可靠消息体系 |
大师级能力的标志是：能把不确定性显式化，用数据、演练和治理承接风险。
31.2 深入源码
推荐阅读路径：
client send
-> broker request handler
-> message store
-> commitlog append
-> reput dispatch
-> consume queue
-> pull message
-> offset commit
重点模块：
- remoting 协议；
- producer 发送与重试；
- consumer 重平衡；
- topic 路由；
- MappedFileQueue；
- CommitLog；
- ConsumeQueue；
- IndexFile；
- 刷盘线程；
- 复制与 Controller；
- 事务回查；
- 定时消息；
- Proxy 转发。
读源码时先跑单测，再打断点跟一条消息。
31.3 建立实验环境
实验清单：
- 单机部署；
- 双主双从；
- Controller 集群；
- Proxy 集群；
- 混合版本迁移；
- 磁盘故障注入；
- 网络分区；
- 断电恢复；
- 负载压测；
- 冷读压测。
记录每次实验：
version
configuration
input load
observed metrics
failure injection
recovery behavior
conclusion
31.4 平台化建设
消息平台应提供：
- Topic 生命周期管理；
- 权限申请与审计；
- 事件契约管理；
- SDK 规范；
- 监控模板；
- 死信治理台；
- 消息查询和轨迹；
- 容量看板；
- 成本看板；
- 故障 Runbook；
- 混沌演练；
- 自动巡检。
平台的目标不是减少所有手工操作，而是让高风险操作有流程、有校验、有证据。
31.5 业务架构能力
继续学习：
- DDD 聚合与事件边界；
- Event Sourcing；
- CQRS 投影；
- Saga 与补偿；
- 数据一致性；
- 工作流引擎与消息协作；
- 数据治理；
- 安全合规；
- 成本治理；
- 混沌工程。
技术方案必须回答：
business invariant
failure mode
recovery path
observability
cost
rollback
31.6 版本追踪
关注：
- 5.x 新特性；
- Proxy 演进；
- Controller 与高可用；
- 定时消息；
- 多语言客户端；
- 性能优化；
- 安全增强；
- 云原生部署；
- 社区 RFC；
- 兼容性说明。
学习新版本时保持“当前版本文档优先”，不要把旧博客结论当成事实。
31.7 个人知识库
建议沉淀：
- 架构图；
- 参数表；
- 故障案例；
- 压测报告；
- 演练记录；
- 容量模型；
- Topic 命名规范；
- 事件 schema 规范；
- 面试复盘；
- 源码笔记。
每个案例都记录时间线、根因、修复、验证和长期预防。
31.8 协作与领导
高级工程师要推动：
- 事件契约评审；
- 消息可靠性分级；
- 故障演练常态化；
- 死信治理值班；
- 容量评审机制；
- 变更审批和自动化；
- 多团队 Topic 归属；
- 事故复盘无责文化。
好的消息体系是团队工程能力的体现，不是某个人的经验判断。
本章小结
大师之路从跑通一条消息开始，经过存储与高可用源码、真实故障演练、平台化治理，最终沉淀为组织级工程能力。保持对版本、数据和业务边界的敬畏，持续记录实验与事故，才能在复杂系统中做出可靠决策。
思考题
- 你所在团队的消息可靠性如何分级？
- 下一个最值得做的故障演练是什么？
- 如何把死信治理变成日常流程？
- 哪些 Topic 契约缺少版本治理？
- 你的容量模型多久校准一次？