3. 读写分离架构概述：读写分离的定义、为什么需要读写分离、读写分离带来的挑战

在消息队列系统中，随着业务规模的增长，单一节点或单一集群往往难以同时承受高吞吐写入与大量消费者读取的压力。读写分离架构正是为了解决这一矛盾而设计的经典架构模式。本节将系统阐述读写分离的核心定义、引入动机以及落地过程中必须正视的技术挑战。

3.1 读写分离的定义

读写分离（Read-Write Splitting / CQRS 简化模式）是指将消息队列集群中的写入操作（Produce / Publish）与读取操作（Consume / Subscribe）分别路由到不同的物理节点或逻辑分组上执行，使写入流量与读取流量不再共享同一组 Broker 实例。

在典型实现中，集群被划分为两类角色：

写入节点与读取节点之间通过同步复制或异步复制机制保持数据最终一致。消费者默认从读取节点消费，生产者始终向写入节点发送。

3.2 为什么需要读写分离

在单体 Broker 或未做读写分离的集群中，写入与读取共享同一组线程池、磁盘 I/O 和内存缓存。当业务出现以下场景时，这种混合模式会迅速成为瓶颈：

1. 读写比例严重失衡：典型消息队列场景中，读取量往往是写入量的 5~20 倍。一个消息被写入后，可能被多个消费者组、多个分区并发拉取。共享节点下，读取请求会抢占写入所需的 CPU 和磁盘资源。
2. 写入延迟敏感：金融交易、订单状态变更等场景要求毫秒级写入确认。如果读取流量突发（如消费者批量拉取），会导致写入线程饥饿，延迟抖动加剧。
3. 消费者数量膨胀：当消费者组数量从几十个增长到上千个时，每个消费者都会定期拉取消息。未分离的集群中，Broker 需要为每个拉取请求遍历索引、读取磁盘，严重拖慢写入吞吐。
4. 故障隔离需求：读取节点出现慢查询或 Full GC 时，不应影响写入节点的可用性。读写分离天然提供了故障域隔离。

3.3 读写分离带来的挑战

读写分离并非银弹。引入该架构后，系统复杂度显著上升，主要面临以下四大挑战：

3.4 挑战的应对思路

针对上述挑战，业界已形成成熟的应对策略，这些策略也是后续章节中插件扩展与集群部署的核心内容：

• 一致性：采用半同步复制（写入节点等待至少一个读取节点确认后再返回成功），或引入读取节点延迟阈值，消费者只从复制延迟小于 100ms 的节点拉取。
• 路由：通过客户端插件或透明 Proxy 封装路由逻辑，对业务代码无侵入。插件内部维护写入节点列表与读取节点列表，支持定时探活与拓扑刷新。
• 故障切换：基于 Raft 共识算法或 ZooKeeper 临时节点实现自动选主。切换后，新的写入节点会从旧节点补拉未同步的消息，保证至少一次语义。
• 监控：在 Prometheus 中暴露每个节点的角色标签（role="write" / role="read"），并记录 replication_lag_seconds 指标。当滞后超过 5 秒时自动告警并摘除该读取节点。