1. 课程导学与架构总览：消息队列读写分离架构的演进历史、核心价值与适用场景
1.1 从单体到读写分离：消息队列架构的演进脉络
消息队列（Message Queue, MQ）作为分布式系统的核心中间件，其架构演进经历了三个主要阶段。早期单体架构中，Broker 同时承担消息写入、存储、分发和消费的全部职责，节点间无角色区分。随着业务流量增长，单体 Broker 在吞吐量、可用性和资源利用率上的瓶颈逐渐暴露，催生了读写分离架构。
| 阶段 | 架构特征 | 典型代表 | 核心瓶颈 |
|---|---|---|---|
| 单体架构 | 单节点或主从复制，读写路径不分离 | 早期 RabbitMQ、ActiveMQ | 写入瓶颈、单点故障、扩展性差 |
| 主从/分区架构 | 数据分片 + 主从复制，读写仍共用主节点 | Kafka 0.8~2.x、RocketMQ 4.x | 主节点写入压力大、从节点资源闲置 |
| 读写分离架构 | 写入节点与读取节点物理分离，独立扩缩容 | Pulsar、Kafka 3.x+、RocketMQ 5.x | 数据一致性、延迟敏感场景适配 |
演进驱动力： 当单集群写入吞吐超过 10 万条/秒，或消费组数量超过 50 个时，单体架构的 CPU 中断、磁盘 I/O 争抢和网络带宽瓶颈会急剧放大。读写分离通过解耦写入与读取路径，使两者可以独立水平扩展。
1.2 读写分离架构的核心价值
读写分离架构并非简单的"把读和写放在不同节点"，而是围绕以下四个核心价值进行系统设计：
- 吞吐量解耦： 写入节点专注处理生产者的消息追加请求，读取节点专注处理消费者的拉取请求，两者互不抢占 CPU 和磁盘 I/O 资源。实测表明，在相同硬件条件下，读写分离可使整体吞吐量提升 2~4 倍。
- 资源利用率优化： 写入节点通常需要高性能磁盘（如 NVMe SSD）和充足内存用于 Page Cache；读取节点可以使用普通 HDD 或更低配置的实例，降低硬件成本。
- 弹性扩缩容： 当消费流量突增时，只需增加读取节点副本，无需调整写入节点；反之，写入压力增大时，可独立扩展写入节点数量。
- 故障隔离： 读取节点故障不影响消息写入，生产者仍可正常发送消息；写入节点故障时，读取节点仍可服务已存储的消息，提升系统整体可用性。
适用场景判断： 读写分离最适合"写少读多"或"写多读多但读写负载不均衡"的场景。如果系统写入和读取负载基本对称且总量不大（< 5 万 TPS），单体架构可能更简单高效。
1.3 读写分离架构的典型拓扑
下图展示了消息队列读写分离架构的核心组件与数据流关系。写入节点（Producer-Facing Broker）接收生产者消息，完成持久化后异步复制到读取节点（Consumer-Facing Broker）；消费者从读取节点拉取消息，实现读写路径的物理分离。
1.4 适用场景与选型决策
读写分离架构并非银弹，其适用性取决于业务对一致性、延迟和成本的综合要求。以下表格总结了典型场景的匹配度：
| 场景 | 读写分离推荐度 | 关键考量 |
|---|---|---|
| 日志采集与流处理 | ★★★★★ | 写多读多，吞吐要求高，可接受秒级延迟 |
| 异步任务/事件驱动 | ★★★★☆ | 写少读多，消费组数量大，需要独立扩缩容 |
| 金融交易/订单系统 | ★★☆☆☆ | 强一致性要求，读写分离可能引入复制延迟风险 |
| 实时监控与告警 | ★★★★☆ | 数据量大，消费延迟敏感，需读写路径隔离 |
| 物联网设备数据采集 | ★★★★★ | 海量写入，少量消费，写入节点需高性能存储 |
避坑提示： 读写分离架构在以下场景中需要谨慎评估：① 要求严格顺序消费且不允许乱序；② 要求毫秒级强一致性读；③ 写入流量极小（< 1000 TPS）且消费组数量少。这些场景下，单体架构或主从架构可能更合适。
1.5 课程实验环境概览
本课程后续章节将基于 Docker Compose 搭建一套完整的读写分离消息队列集群，包含以下组件：
- 写入节点（2 个）： 负责接收生产者消息，使用 NVMe 模拟磁盘，配置高水位 Page Cache
- 读取节点（3 个）： 负责服务消费者拉取请求，配置普通 HDD 模拟磁盘
- 元数据服务（1 个）： 管理节点注册、主题路由和配置中心
- 监控与告警： Prometheus + Grafana 采集写入/读取节点性能指标
实验环境将模拟生产级流量，通过压测工具验证读写分离架构在吞吐量、延迟和资源利用率上的实际收益。