2. 读写分离原理
2.1 生产者-消费者模型：消息队列的基石
消息队列最核心的抽象就是生产者-消费者模型。该模型将数据的产生与数据的处理解耦，通过一个中间缓冲区（即消息队列）进行交互。
- 生产者（Producer）：负责产生消息并将消息发送到队列中。生产者不关心消息最终被谁消费、何时被消费。
- 消息队列（Queue / Topic）：作为临时存储缓冲区，负责暂存生产者发送的消息，并按照特定规则（如 FIFO、优先级）进行排队。
- 消费者（Consumer）：从队列中拉取或接收消息，并进行业务处理。消费者不关心消息是由哪个生产者产生的。
关键原则：生产者和消费者之间没有直接依赖关系，它们只与消息队列通信。这是实现读写分离、系统解耦的理论基础。
2.2 读写分离的三大动机：解耦、削峰、异步
在消息队列架构中，“写”通常指生产者发送消息（数据流入），“读”指消费者拉取/消费消息（数据流出）。读写分离的核心动机可以归纳为以下三点：
| 动机 | 核心问题 | 读写分离如何解决 | 典型场景 |
|---|---|---|---|
| 解耦 | 上下游系统强依赖，一方变更导致另一方需同步修改 | 生产者与消费者只依赖队列契约（Topic/Queue），不感知对方存在；写端与读端可独立演进、独立部署 | 订单系统 -> 库存系统、积分系统、物流系统 |
| 削峰填谷 | 突发流量（秒杀、大促）导致下游系统被冲垮 | 写端（生产者）将消息快速写入队列，读端（消费者）按自身处理能力拉取消息，实现流量平滑 | 秒杀抢购、日志采集、IoT 设备上报 |
| 异步处理 | 同步调用导致请求响应时间过长，用户体验差 | 写端立即返回成功，读端在后台异步处理；写操作不阻塞读操作，整体吞吐量提升 | 用户注册发送邮件/短信、视频转码、报表生成 |
性能视角：在压测中，读写分离的削峰能力直接体现为“写 TPS 远高于读 TPS”时的系统稳定性。如果读端消费速度跟不上写端生产速度，队列会持续积压，这是压测中需要重点关注的指标。
2.3 主从与读写分离的区别
在消息队列领域，主从（Master-Slave）与读写分离（Read-Write Separation）是两个容易混淆的概念。它们解决不同维度的问题，但在实际架构中常常组合使用。
| 对比维度 | 主从架构 | 读写分离架构 |
|---|---|---|
| 核心目标 | 高可用、数据冗余、故障转移 | 性能扩展、流量削峰、解耦 |
| 数据流向 | 主节点写入，从节点同步复制；读写通常都走主节点 | 写操作（生产）与读操作（消费）走不同的通道或节点 |
| 节点角色 | Master（主）可读可写；Slave（从）只读备份，主故障时切换 | Producer 节点负责写；Consumer 节点负责读；Broker 内部可再分写节点和读节点 |
| 典型实现 | Kafka 的 Leader-Follower 副本机制；RocketMQ 的 Master-Slave 模式 | Kafka 的 Consumer Group 独立消费；RocketMQ 的 Queue 级读写分离 |
| 故障影响 | 主节点故障需选举新主，期间可能短暂不可写 | 读节点故障只影响消费能力，写节点故障影响消息生产 |
常见误区：不要将“主从”等同于“读写分离”。主从主要解决数据可靠性和高可用，而读写分离主要解决性能瓶颈和系统解耦。在压测场景中，主从切换会影响写 TPS 的稳定性，而读写分离的瓶颈通常出现在消费端。
2.4 读写分离在消息队列中的实际体现
在主流消息队列产品中，读写分离的实现方式各有不同：
- Kafka：通过 Consumer Group 实现消费端的水平扩展，每个 Partition 只能被同一个 Group 内的一个 Consumer 消费，天然实现读端分离。写端由 Producer 直接写入 Leader Partition。
- RocketMQ：支持 Queue 级别的读写分离，Producer 发送消息到指定 Queue，Consumer 从 Queue 拉取消息。Broker 层面支持多 Master 多 Slave 部署，写走 Master，读可走 Slave（需配置）。
- RabbitMQ：通过 Exchange 和 Queue 绑定实现路由，Consumer 独立消费 Queue 中的消息。读写分离主要体现在 Exchange 的写入和 Queue 的消费解耦。
压测关注点：在读写分离架构下，压测需要分别测量“写路径”和“读路径”的极限性能。写路径关注 TPS、消息大小、延迟；读路径关注消费速率、积压量、重平衡时间。两者之间的平衡点决定了系统的整体吞吐能力。