RocketMQ的“三高”架构设计
RocketMQ的“三高”架构设计主要围绕高可用、高吞吐、高扩展三个维度展开分别解决服务不中断、性能不瓶颈、规模不设限的核心问题。1 高可用High Availability高可用的目标是确保部分组件故障时消息服务依然可用数据不丢失。1.1 服务高可用NameServer 集群化至少2个NameServer节点组成无状态集群节点间不通信无依赖关系任意节点故障不影响整体。Broker 多主架构所有节点对等均可读写Broker故障 → NameServer心跳超时 → 从路由表剔除客户端定时拉取路由表 → 感知到Broker下线自动切换到其他健康Broker → 业务无感知。1.2 数据高可用主从同步复制SYNC_FLUSH消息写入Master后同步复制到Slave返回成功前确保至少一个副本已落盘。1.3 DLedgerRaft协议RocketMQ 4.5引入DLedger基于Raft协议实现自动主从切换同时保证了服务高可用和数据高可用。Leader故障时集群中自动选举Leader切换时间秒级无需人工干预。数据同步复制到多数节点多数派确认机制节点宕机后数据不丢失保证消息强一致性。2 高吞吐High Throughput高吞吐的目标是在有限硬件资源下处理尽可能多的消息。2.1 存储层优化1. 顺序写入CommitLog所有消息按到达顺序追加写入CommitLog文件默认1GB/个充分利用磁盘顺序写的高性能接近内存随机写。2. 内存映射MappedByteBufferCommitLog通过mmap映射到进程虚拟内存写入操作直接写内存PageCache由OS异步刷盘减少内核态/用户态切换开销3. 零拷贝读取消费消息时使用sendfile系统调用数据从内核缓冲区直接拷贝到Socket缓冲区跳过用户态拷贝减少2次上下文切换4. 分离式索引结构组件作用特点CommitLog存储原始消息顺序写全局唯一ConsumeQueue按Topic-Queue的索引定长20字节/条可内存映射IndexFile按消息Key的哈希索引支持快速检索2.2 并发层优化1. 读写分离写入只写CommitLog顺序IO索引构建异步线程将CommitLog分发到ConsumeQueue读取从ConsumeQueue定位后再读CommitLog2. 批量处理消息批量发送/消费PageCache批量刷盘3. 队列级并行一个Topic对应多个MessageQueue防止消费者实例产生资源竞争不同MessageQueue可分布在不同的Broker并发读写天然负载均衡3 高扩展High Scalability高扩展的目标是系统能够通过增加节点线性提升容量。3.1 无状态组件水平扩展NameServer完全无状态节点间不通信增加节点即可扩展服务能力Proxy5.0无状态计算层不存储任何数据可独立弹性伸缩应对连接数波动3.2 Broker存储扩展Topic级分片一个Topic包含多个MessageQueueQueue分布在不同的Broker上增加Broker → 迁移Queue → 容量线性提升扩容流程新Broker启动注册到NameServer创建新Queue或将现有Queue迁移到新Broker客户端自动发现新路由开始写入新节点3.3 存储计算分离5.0传统架构计算存储耦合 → 扩容需同时扩展5.0架构Proxy计算 Broker存储分离- 计算层无状态按需弹性应对突发流量- 存储层有状态按容量弹性应对数据增长3.4 平滑扩缩容扩容新节点加入自动负载均衡缩容节点下线前先禁写开读待存量消息消费完再下线4 三高架构总结维度核心目标关键设计应对问题高可用服务不中断数据不丢NameServer集群、多主架构、多副本、DLedger节点/机房故障高吞吐海量消息快速处理顺序写CommitLog、mmap、零拷贝、索引分离性能瓶颈高扩展容量线性提升无状态组件、Topic分片、存算分离业务增长RocketMQ通过NameServer集群保障服务发现高可用多主架构多副本保障数据不丢顺序写零拷贝保障高吞吐存算分离分片机制保障水平扩展共同构成“三高”架构的基石。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2478917.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!