请说明 RocketMQ 中主从节点架构的具体实现方式，包括主从同步机制、故障切换处理以及读写路径上主从各自承担的角色。

回答思路

1. 【回答框架 1】RocketMQ 主从架构基于 Broker 角色划分，Master 负责读写请求，Slave 负责从 Master 同步消息并承担读请求的负载均衡。同步方式支持同步复制和异步复制，通过配置 brokerId 和 brokerRole 来决定主从关系。
2. 【回答框架 2】同步复制时，消息在 Master 和 Slave 都写入成功后才返回客户端确认，保证强一致性但延迟较高；异步复制时 Master 写入即返回，Slave 异步拉取，吞吐高但存在消息丢失风险。生产环境通常结合使用，如采用异步复制加同步刷盘。
3. 【回答框架 3】主从切换方面，RocketMQ 不自动进行主从选举，当 Master 宕机时，消费者仍可从 Slave 读取消息，但生产者无法写入，需人工或通过 NameServer 感知后手动切换。其实现依赖 Broker 心跳上报和 NameServer 的路由表更新。
4. 【回答框架 4】在消息消费场景，Slave 提供只读服务，消费者从 Slave 拉取消息时走与 Master 类似的流程，但消息会标记为 slave 读取。消息存储采用 CommitLog 统一存储，主从同步通过偏移量推进实现，Slave 定期从 Master 拉取新消息并追加到本地 CommitLog。
5. 【回答框架 5】整体架构中，主从节点通过 brokerName 标识同一组，brokerId 为 0 表示 Master，非 0 表示 Slave。NameServer 维护路由信息，客户端根据 topic 路由选择 Broker，实现读写分离和基本的高可用。
6. 【关键点 1】同步复制保证消息可靠性但延迟高，异步复制提升吞吐但可能丢消息，需按场景配置。
7. 【关键点 2】主从切换不自动执行，依赖人工或额外机制，Master 故障时只能读不能写。
8. 【关键点 3】消息存储统一在 CommitLog，Slave 通过拉取偏移量同步消息，支持消费端从 Slave 读取。
9. 【易错点 1】易误以为 RocketMQ 支持自动故障转移，实际上没有内置自动选举机制。
10. 【易错点 2】将同步复制与同步刷盘混淆，两者是不同维度，同步复制指主从复制策略，刷盘指落盘策略。
11. 【易错点 3】忽视异步复制下的消息丢失风险，在金融等强一致场景需采用同步复制或半同步方案。