为什么会有 RobustMQ
起源
2023 年 10 月，写下第一行代码。
最初的动机很简单：学习 Rust。Rust 是一门门槛很高的语言，必须在实战中才能真正掌握。找来找去，没有找到合适的项目，于是决定自己写一个消息队列。
选消息队列，是因为它足够复杂——网络、并发、存储、协议，每一块都是 Rust 最适合发力的地方。这个项目从一开始就不是为了商业化，而是想做一件技术上值得做的事。
看到的问题
在消息队列领域深耕多年，对这个领域的现状看得很清楚：确实有一些结构性的问题长期没有被解决。
历史包袱太重。 Kafka 诞生于 2011 年，架构基于文件系统，Topic 数量受文件句柄限制，万级 Topic 就是天花板。RabbitMQ 用 Erlang 写的，并发模型很特别但性能上限有限。这些系统在设计之初就没有考虑过 AI 时代的需求，后来的改造都是在原有架构上打补丁，改造复杂度高、收益低、还容易和社区脱节。
场景割裂。 IoT 用 MQTT，大数据用 Kafka，企业用 AMQP——三套协议，三套系统，三套运维。数据要在不同系统之间流转，中间需要各种桥接层，每一层都是延迟和故障点。没有一个系统真正把这些场景统一起来。
AI 时代没有对应的基础设施。 Kafka 的 Topic 上限是 AI Agent 场景的硬伤——10 万个 Agent 各需要几个通信通道，就需要几十万个 Topic，Kafka 直接崩溃。GPU 训练需要从 S3 读取 TB 级数据，现有系统都要先把数据导入，既慢又浪费存储。这些新场景，现有系统都没有从根本上解决。
这些问题不是小问题，是架构层面的缺陷。修补没有意义，需要从头设计。
我们想做什么
一个从一开始就为 AI、IoT、大数据统一设计的通信基础设施，而不是在老架构上凑合。
具体来说，RobustMQ 想做到：
极简架构，固定边界。 三个组件：Meta Service 管元数据、Broker 处理协议、Storage Engine 存数据。组件边界清晰，不会因为支持新协议或新存储而变形。加一个新协议只需要实现 Broker 层的解析逻辑，加一个新存储只需要实现 Storage Engine 的接口。核心架构不动。
多协议统一。 MQTT 和 Kafka 跑在同一套存储上，数据只存一份，两个协议提供不同的访问视角。IoT 设备用 MQTT 写入，大数据平台用 Kafka 消费，不需要中间的桥接层。
百万级 Topic。 基于 RocksDB 的 KV 存储，Topic 数量不受文件系统限制。每个 AI Agent 有自己独立的通信通道，百万个 Agent 也能承载。
AI 原生。 Topic 直连对象存储（S3/MinIO），RobustMQ 作为智能缓存层，GPU 训练不再等数据。共享订阅打破并发度和 Partition 数量的绑定，弹性训练集群可以随时扩缩。
用 Rust 做。 零成本抽象、内存安全、无 GC 停顿。通信基础设施对延迟稳定性要求极高，Rust 是这个领域最合适的语言选择。
这是什么样的项目
非商业化项目。 没有商业公司背景，没有付费版本，所有核心功能完全开源。
技术信仰驱动。 相信用 Rust 重新设计通信基础设施是正确的方向，相信 AI 时代需要一套真正为新场景设计的消息系统，相信优秀的基础软件应该属于整个社区。不是因为有商业回报才做，是因为觉得这件事值得做。
目标是 Apache 顶级项目。 不是为了名声，是因为 Apache 基金会的治理模式代表了开源社区最好的运作方式——开放、透明、中立、可持续。这是我们希望 RobustMQ 长期存在的方式。
做这个项目没有捷径，一步一步来。抬头看天，低头走路。
现在到哪了
从 2023 年 10 月第一行代码，到现在的 0.3.0 版本：架构重新设计了，MQTT 核心功能趋于完整，监控、CLI、Dashboard 等工具配套齐全。还有很多没有做好的地方，Kafka 协议还在开发中，AI 数据缓存还没有完成，性能和稳定性还有很大优化空间。
但方向是清晰的，架构是稳的，初心没有变。