4、读写分离架构设计：读写分离概念、MQ中读写分离的实现方式（主从、Proxy层）、读写分离的优缺点

4.1 读写分离核心概念

读写分离（Read/Write Splitting）是一种将系统的写入操作与读取操作分散到不同节点或不同路径上的架构设计模式。在消息中间件领域，读写分离的核心目标是：让写入流量不阻塞读取流量，让读取流量不抢占写入资源。

在未做读写分离的架构中，Broker 节点同时承担消息生产（写）和消息消费（读）两类负载。当消费端出现积压、重试或慢消费时，会直接拖慢生产端的写入性能，甚至引发 Broker 整体抖动。读写分离通过物理或逻辑隔离，将读写路径解耦，从而提升集群的吞吐能力和稳定性。

4.2 MQ 中读写分离的实现方式

业界主流消息中间件（Kafka、RocketMQ、Pulsar）实现读写分离主要有两种架构模式：主从模式和Proxy 代理层模式。两种模式在隔离粒度、运维复杂度、延迟特性上存在显著差异。

4.2.1 主从模式（Leader-Follower）

主从模式是最经典的读写分离实现方式。在 Kafka 中，每个 Partition 有 1 个 Leader 和多个 Follower。Leader 负责处理所有生产请求（写）和消费请求（读），Follower 只从 Leader 同步数据，不对外提供服务。这种模式下，读写并未真正分离——Leader 节点仍然同时承担读写。

真正的主从读写分离需要将消费请求路由到 Follower 节点。Kafka 从 2.4 版本开始支持 Follower 消费（Follower Fetching），允许消费者从 Follower 副本拉取消息，从而将读流量卸载到 Follower 节点上。

4.2.2 Proxy 代理层模式

Proxy 代理层模式在客户端与 Broker 集群之间引入一层独立的代理节点（Proxy），由 Proxy 负责请求路由、读写分离、流量控制和协议转换。这种模式在 RocketMQ 5.x 的 Proxy 模式和 Pulsar 的 Broker 中均有体现。

在 Proxy 模式下，客户端不再直接感知 Broker 拓扑，而是统一连接到 Proxy 层。Proxy 根据请求类型（生产/消费）和集群负载情况，将请求分发到不同的 Broker 节点或节点组。写请求路由到写节点组，读请求路由到读节点组，实现物理层面的读写隔离。

4.3 读写分离的优缺点

4.3.1 优点

1. 提升整体吞吐能力：写节点专注处理生产请求，读节点专注处理消费请求，避免读写争抢同一份 CPU、内存和网络带宽资源。实测表明，读写分离后集群整体吞吐可提升 2~3 倍。
2. 读能力可水平扩展：读节点组可以独立增加副本或节点数量，轻松应对消费端流量突增（如大促、数据回溯）。
3. 写路径稳定性增强：消费积压、慢消费、重试等异常不会影响生产端的写入延迟，保障消息生产的实时性。
4. 故障隔离：读节点故障不影响写节点，写节点故障不影响已同步的读节点，集群整体可用性提升。
5. 资源利用率优化：可以为读节点配置不同的硬件规格（如高磁盘、低 CPU），为写节点配置高 CPU、高内存，实现成本最优。

4.3.2 缺点

1. 数据一致性延迟：读节点从写节点同步数据存在延迟（通常为毫秒级到秒级），消费者可能读取到稍旧的数据。对于严格顺序消费或强一致性场景，读写分离可能不适用。
2. 架构复杂度增加：Proxy 模式需要额外部署和维护代理层；主从模式需要配置副本选择策略和消费者路由规则。
3. 运维成本上升：需要监控写节点组和读节点组的健康状态、同步延迟、流量比例等指标，告警和故障处理更复杂。
4. 延迟略有增加：Proxy 模式引入了一跳网络转发，主从模式中 Follower 消费可能因同步滞后导致读取延迟略高于直接读 Leader。
5. 资源冗余：读节点组需要维护完整的数据副本，增加了存储成本和网络同步开销。

4.4 读写分离选型决策矩阵