3. 读写分离架构：主从复制、读写分离模式、适用场景与优缺点
读写分离是消息队列集群中提升吞吐能力与可用性的经典架构模式。其核心思想是将写请求（消息生产）与读请求（消息消费）分散到不同的节点上，通过主从复制机制保证数据一致性，从而突破单节点瓶颈。
3.1 主从复制机制
主从复制是读写分离的基础。在消息队列中，主节点（Leader/Broker Master）负责处理写入请求，从节点（Follower/Slave）通过复制协议同步主节点的数据。常见的复制模式包括：
| 复制模式 | 同步方式 | 数据一致性 | 典型场景 |
|---|---|---|---|
| 同步复制 | 主节点等待所有从节点确认写入后才返回成功 | 强一致性 | 金融交易、订单系统 |
| 异步复制 | 主节点写入本地后立即返回，后台异步同步到从节点 | 最终一致性 | 日志收集、监控数据 |
| 半同步复制 | 主节点等待至少一个从节点确认后返回 | 介于强一致与最终一致之间 | 高可用消息队列（如Kafka ISR） |
性能提示：在读写分离测试中，异步复制通常能获得更高的写入吞吐，但会引入数据丢失风险。基准测试时应分别测量同步与异步模式下的吞吐与延迟差异。
3.2 读写分离模式
读写分离在消息队列中的实现通常分为两种模式：代理层路由模式和客户端感知模式。
- 代理层路由模式：客户端不感知主从关系，所有请求发送到代理层（Proxy/Load Balancer），代理根据请求类型（生产/消费）将流量分发到主节点或从节点。
- 客户端感知模式：客户端通过元数据服务获取主从拓扑信息，生产请求直接发送到主节点，消费请求从从节点拉取。
架构对比：代理层路由模式对客户端透明，但引入额外网络跳转，增加延迟；客户端感知模式延迟更低，但客户端逻辑更复杂，需要处理主从切换。
3.3 适用场景
读写分离架构并非万能，其适用性取决于业务对一致性、延迟和吞吐的权衡：
- 高吞吐写入场景：写多读少的系统（如日志采集、IoT数据上报），主节点专注写入，从节点分担读取压力。
- 读写负载不均衡场景：消费端数量远大于生产端，或消费请求频繁（如实时推荐、消息推送）。
- 地理分布式部署：主节点部署在中心机房，从节点部署在边缘节点，降低消费端的跨区域读取延迟。
- 读多写少且允许最终一致性：如缓存刷新、配置同步，从节点读取旧数据可接受。
3.4 优缺点分析
| 维度 | 优点 | 缺点 |
|---|---|---|
| 吞吐能力 | 写节点与读节点并行工作，整体吞吐可线性扩展 | 从节点数量增加时，主节点复制压力上升，可能成为新瓶颈 |
| 延迟 | 消费端从就近从节点读取，网络延迟降低 | 写入延迟受复制模式影响，同步复制下写入延迟增加 |
| 可用性 | 主节点故障时，从节点可快速提升为主，减少停机时间 | 主从切换期间可能出现数据不一致或短暂不可用 |
| 数据一致性 | 同步复制可保证强一致性，适合金融级场景 | 异步复制下，从节点读取可能滞后，出现“脏读” |
| 运维复杂度 | 架构清晰，主从角色明确，便于监控 | 需要管理复制链路、主从切换策略、数据校验等 |
测试注意：在基准测试中，读写分离架构的吞吐瓶颈往往不在主节点，而在复制链路的带宽与从节点的消费能力。务必在测试报告中记录复制延迟（Replication Lag）指标。
3.5 基准测试关注点
在读写分离架构的基准测试中，除了常规的吞吐与延迟指标，还需额外关注以下参数：
- 复制延迟（Replication Lag）：主节点写入时间与从节点可见时间之差，单位毫秒。
- 读写比例（Read/Write Ratio）：测试中应覆盖 1:1、3:1、10:1 等典型比例。
- 从节点数量扩展性：测试 1主1从、1主2从、1主3从下的吞吐变化曲线。
- 主节点故障恢复时间：从节点提升为主节点所需时间，影响可用性指标。
测试建议：使用分布式压测工具（如 JMeter、Locust）分别向主节点和从节点发送请求，同时监控复制链路状态。推荐在测试报告中绘制“复制延迟 vs 写入吞吐”的散点图，直观展示拐点位置。