RobustMQ：基于 Rust 的新一代云原生消息队列
RobustMQ 是基于 Rust 构建的新一代高性能多协议消息队列，愿景是成为新一代云原生与 AI 原生消息基础设施。它不是简单的"又一个消息队列"，而是面向 AI 时代和云原生需求，对消息队列进行的一次重新思考和设计。
传统消息队列面临的挑战
协议生态割裂
在实际的架构设计和系统运维中，不同业务场景往往需要不同的消息协议。IoT 场景需要 MQTT 协议，大数据处理依赖 Kafka，微服务通信使用 AMQP/RabbitMQ，金融交易场景选择 RocketMQ。这种现状导致企业需要维护多套消息系统，每套系统都有独立的部署方式、监控体系、运维流程和学习成本。协议割裂不仅增加了技术栈的复杂度，也显著提升了团队的运维负担，造成了资源的重复投入和效率损失。
存算一体架构的局限性
传统消息队列采用存算一体的架构设计，在云原生环境下暴露出明显的适配问题。弹性扩缩容方面，以 Kafka 为例，扩容时需要进行 Partition Rebalance，这个过程可能持续数小时，期间会影响业务性能。存储与计算的紧耦合使得每个 Broker 节点都需维护本地存储，难以实现 Serverless 所需的按需计算和秒级冷启动能力。此外，计算密集型和存储密集型负载无法独立调度，容易出现资源不均衡的情况。当节点发生故障时，需要同时处理计算和存储的恢复，数据迁移和负载均衡相互影响，大大增加了运维的复杂度。
存储引擎的单一化
传统消息队列通常只支持单一的存储引擎，无法灵活适配不同业务场景的差异化需求。实时交易、IoT 数据采集等高性能场景需要极低延迟但数据量相对较小，适合使用内存或 SSD 存储。而日志收集、数据分析等大数据场景对性能要求不高，但数据量巨大，需要低成本的对象存储。许多业务系统中既有热数据需要高性能访问，又有冷数据需要长期低成本存储，但传统消息队列无法根据数据访问模式自动选择合适的存储介质，导致整体成本居高不下。
性能稳定性问题
基于 Java 的传统消息队列在高并发场景下存在性能稳定性问题。高负载下消息处理延迟极不稳定，可能从毫秒级突然跳跃到秒级。垃圾回收机制导致周期性的服务暂停，影响系统可用性。随着连接数和消息量增长，系统性能呈现明显的退化趋势，这些问题在对延迟敏感的业务场景中尤为突出。
AI 时代的新需求
随着 AI 技术的快速发展，消息队列面临新的挑战。AI 训练数据、多模态数据（文本、图像、视频、音频）让数据量从 TB 级增长到 PB 级，传统消息队列的存储架构难以承载。从数据采集到模型训练再到推理服务，每个环节对消息队列的延迟、吞吐量、持久性要求各不相同。GPU 算力昂贵，训练数据存储成本高，需要灵活的存储方案和弹性调度来降本增效。同时，不同 AI 团队需要资源隔离和细粒度权限控制，这些都对消息队列系统提出了新的要求。
RobustMQ 的解决方案
基于对传统消息队列问题的深入分析，RobustMQ 从架构设计上提出了新的思路。
技术选型：Rust 语言
选择 Rust 作为开发语言是经过深思熟虑的技术决策。Rust 在编译期就能消除悬空指针、缓冲区溢出等安全隐患，提供了内存安全保障。它的零成本抽象特性使得高级语言特性不会损失运行时性能，同时避免了垃圾回收导致的服务暂停问题。Rust 原生的 async/await 机制天然支持高并发场景，配合 Tokio、Serde、RocksDB 等成熟的基础库，能够快速构建高性能系统。从业界实践来看，基于 Rust 构建的消息流引擎 Iggy 已经展示出纳秒级的延迟表现，证明了这一技术路线的可行性。
多协议统一架构
RobustMQ 不设计新的通信协议，而是兼容主流的消息队列协议。通过统一的内核，一个集群可以同时支持多种消息协议：
┌─────────────────────────────────────────────┐
│ RobustMQ Cluster │
├─────────────┬─────────────┬─────────────────┤
│ MQTT │ Kafka │ AMQP │
│ Port: 1883 │ Port: 9092 │ Port: 5672 │
│ ├─ IoT │ ├─ 大数据 │ ├─ 企业集成 │
│ ├─ 移动应用 │ ├─ 流处理 │ ├─ 微服务 │
│ └─ 实时通信 │ └─ 日志收集 │ └─ 事务消息 │
└─────────────┴─────────────┴─────────────────┘这种设计带来了显著的价值。企业可以从维护多套消息系统整合为一套系统，大幅降低运维成本。业务可以专注于内核功能，不需要构建生态，客户端可以直接使用现有的 MQTT、Kafka 等客户端 SDK，实现零成本迁移。统一的资源池避免了资源孤岛现象，提升了整体资源利用率。
插件化存储引擎
RobustMQ 将存储层设计为可插拔的架构，内置了多种存储引擎以满足不同场景的需求。内存存储适用于对延迟极度敏感的场景，可以实现微秒级的读写延迟。本地分段多副本存储基于 Raft 协议实现数据可靠性，适合对性能和可靠性都有要求的场景。远程对象存储兼容 S3、HDFS 等分布式存储系统，适合大数据量、成本敏感的场景。业务可以根据实际需求在集群或 Topic 维度灵活选择存储引擎，既能满足金融交易等高性能场景的需求，也能满足日志收集等大数据场景的成本优化需求，还能支持本地化部署等特殊场景。
计算、存储、调度三层分离
RobustMQ 从架构设计之初就采用计算、存储、调度三层完全分离的架构。计算层（Broker）完全无状态，只负责协议解析和消息处理。存储层支持插件化设计，内置了内存存储、本地分段多副本存储、远程对象存储（兼容 S3、HDFS 等）。调度层（Meta Service）基于 Raft 实现，负责集群协调和管理。三层架构完全解耦，任何一层都可以独立弹性扩缩容而不影响其他层，真正实现了 Serverless 能力。业务可以在集群或 Topic 维度选择存储引擎，既能满足高性能场景的需求，也能满足成本优化的需求。
技术架构
RobustMQ 采用存算分离架构，由三个核心组件构成。Broker Server 作为无状态协议处理层，负责多协议解析和连接管理，单机可支持百万级连接。Meta Service 基于 Raft 协议构建，作为集群的调度层，负责集群管理和服务发现。Journal Server 是插件化的存储层，支持内存、本地分段存储、远程对象存储等多种存储引擎。三层架构相互独立，可以根据业务需求独立扩缩容。
核心特性
RobustMQ 的核心特性体现在多个方面。在协议支持上，一个集群可以同时支持 MQTT、Kafka、AMQP 等多种协议，解决了协议割裂的问题。性能方面，基于 Rust 的零成本抽象实现了单机百万连接和微秒级延迟。存储层采用插件化设计，业务可以在集群或 Topic 维度选择存储引擎，既能满足高性能场景对内存和本地存储的需求，也能满足大数据场景对低成本对象存储的需求。架构上支持 Serverless，计算节点无状态设计实现了弹性扩缩容和秒级冷启动。安全性方面提供了多种认证方式和细粒度权限控制，满足企业级需求。系统内置了监控告警、性能分析、链路追踪等可观测性功能，方便运维管理。
开发与运维
RobustMQ 提供了完善的工具链支持。部署方式上支持源码编译、预编译二进制、Docker、Kubernetes 等多种方式，适配不同的环境需求。Web 管理界面提供了集群监控、用户管理、配置管理等功能，可视化程度高。CLI 工具覆盖了用户管理、权限控制、实时监控、消息测试等常用操作，方便日常运维。
发展现状
从 GitHub 数据来看，RobustMQ 已经获得了 1400+ Stars、200+ Forks，拥有 70+ 贡献者，累计提交超过 2100 次，形成了活跃的开发者社区。技术成熟度方面，MQTT 协议已经完整支持并可用于生产环境，Kafka 协议正在开发中，AMQP 和 RocketMQ 协议已纳入规划。部署方式上支持单机、集群、Docker、Kubernetes 等多种模式，满足不同场景的需求。
发展路线
2025 年的主要目标是在第四季度实现 MQTT 协议的生产可用，并发布 0.2.0 第一个正式版本。2026 年的核心任务是完善 Kafka 能力，提升协议兼容性和性能表现。长期来看，RobustMQ 的目标是成为 Apache 顶级项目，与 Kafka、Pulsar 等项目并列，获得全球开源社区的认可。
开源理念
RobustMQ 采用 Apache 2.0 开源协议，核心代码完全开源，无商业限制。项目致力于与全球开发者共建，让技术创新惠及每个人。项目决策、技术路线、代码审查全程公开透明。长期目标是成为 Apache 顶级项目，与 Kafka、Pulsar 等项目并列，获得全球开源社区的认可。
快速开始
RobustMQ 采用单二进制设计，无需任何外部依赖。下载预编译包后，只需执行 robust-server start 命令即可一键启动集群。启动后可以创建用户、发布订阅消息进行测试，也可以访问 Web 控制台体验可视化管理功能。详细的使用教程和文档可以访问官网 robustmq.com 查看。
加入社区
RobustMQ 欢迎各种形式的参与，包括代码贡献、文档完善、测试反馈、社区推广等。可以通过 GitHub (github.com/robustmq/robustmq) 参与项目开发，访问官网 (robustmq.com) 了解更多信息，或者扫描下方二维码加入微信技术交流群。
RobustMQ 致力于通过 Rust 重写、存算分离、多协议统一、插件化存储等技术创新，成为 AI 时代云原生消息队列的新选择。