当前位置：首页 > web >正文

【Java面试】RocketMQ的设计原理

web 2025/7/3 21:13:31

NameServer轻量级无状态
- 问题：传统注册中心（如ZooKeeper）强一致性（CP）设计复杂，且在高并发场景下性能瓶颈明显。
- 解决：NameServer采用无状态+最终一致性（AP），节点间不通信，仅通过Broker心跳（30s/次）更新路由，降低复杂度并提升吞吐量。容忍分钟级不一致（如Broker宕机需120s剔除），适合消息路由这种非强一致场景。
Broker主从架构与文件设计
- 问题：单节点故障导致消息丢失，且随机磁盘I/O性能差。
- 解决：
  - Master-Slave：同步复制（SYNC_MASTER）确保数据强一致，异步复制（ASYNC_MASTER）提升性能，主宕机时Slave自动切换。
  - CommitLog顺序写：所有消息顺序追加写入1GB固定文件，避免磁盘寻道（性能提升10倍+），文件名用20位偏移量命名（如00000000000000000000）快速定位。
  - ConsumeQueue索引：固定20字节/条目（8B偏移量+4B消息大小+8B Tag哈希），解决CommitLog混合存储导致消费效率低的问题。

顺序写入+页缓存优化
- 问题：传统消息队列（如RabbitMQ）随机写入导致磁盘I/O成为瓶颈。
- 解决：
  - 顺序写入：CommitLog仅追加写入，利用磁盘顺序I/O特性（吞吐可达600K+ TPS）。
  - PageCache：消息先写入OS缓存，由异步线程刷盘，读取时命中缓存则免磁盘I/O（接近内存速度）。
同步/异步刷盘策略
- 问题：金融场景需强持久化，而电商大促需高吞吐。
- 解决：
  - 同步刷盘（SYNC_FLUSH）：消息写入内存后立即调用fsync刷盘，确保宕机不丢失（如支付场景）。
  - 异步刷盘：依赖OS的pdflush机制批量刷盘，牺牲少量可靠性换取性能（默认配置）。

主从同步与DLedger
- 问题：传统主从切换依赖人工，恢复时间长（分钟级）。
- 解决：
  - Raft协议（DLedger）：自动选主+日志强一致，故障切换秒级完成，解决脑裂问题。
  - Slave只读：消费者可从Slave消费，缓解Master压力。
消息重试与死信队列
- 问题：网络抖动或消费逻辑异常导致消息处理失败。
- 解决：
  - 重试队列：默认16次重试（间隔1s→2h），避免无效消息阻塞队列。
  - 死信队列（DLQ）：超过重试次数转人工处理，防止无限重试占用资源。

顺序消息
- 问题：订单状态变更等业务需严格保序（如先支付后发货）。
- 解决：通过ShardingKey哈希将同一业务ID消息路由到同一Queue，消费者单线程顺序处理（牺牲并发性保序）。
事务消息
- 问题：分布式事务需保证本地DB操作与消息发送原子性。
- 解决：
  - 两阶段提交：半消息（HALF）试探Broker可用性，本地事务成功则提交消息，失败则回滚。
  - 定时回查：未决事务每60s回查生产者，避免长时间阻塞。

Netty多线程模型
- 问题：传统BIO模型无法支撑高并发（如双十一百万级TPS）。
- 解决：
  - Reactor线程池：Boss线程处理连接，IO线程处理网络事件，业务线程解耦逻辑，避免阻塞。
  - 零拷贝：通过MappedByteBuffer直接映射文件到内存，减少内核态-用户态拷贝。
消费端限流
- 问题：消费者处理能力不足导致消息堆积（如突发流量）。
- 解决：堆积超1000条或100MB时暂停拉取，结合长轮询（Push模式基于Pull实现）平衡实时性与背压。