IBM 收购 Confluent，聊聊 RobustMQ

今天看到 IBM 以 110 亿美元收购 Confluent 的新闻，说实话，第一反应是有点意外的。就在想原来消息队列这种基础技术还有人愿意投入这么大精力。在做这个 RobustMQ 的事情过程中，最大的质疑是消息队列这个方向已经饱和，没空间了。在这个 AI 概念满天飞的时代，消息队列这种传统的基础软件，既没有大模型的性感，也没有应用软件的即时反馈，似乎早就不是聚光灯下的主角了。

但今天这个新闻让我想：也许我们在做可能有价值的事情。在想，如果我们技术路线没问题，做的好的话，应该会很酷。也想顺便聊一聊自己开发 RobustMQ 过程中的一些思考。

过去几个月，确实有很多人问：现在已经有 Kafka、EMQX、RabbitMQ 这些成熟的产品，市场格局基本定了，为什么还要做 RobustMQ？你们凭什么认为能做得更好？

我们的答案很简单：要超越，必须从头开始。

现在很多项目都在做优化：Redpanda 用 C++ 重写 Kafka，追求更好的性能；一些项目在 Kafka 基础上加功能，扩展使用场景。这些都是有价值的改进。但我们坚信，真正的差异性和竞争力，必须从最底层、最内核的地方开始构建。只有从头设计，才能做出真正不一样的东西。

Kafka 是十几年前设计的，那时候还没有云原生的概念，还没有 Rust 这样的系统语言，还没有存算分离的架构思想。EMQX 用 Erlang 实现，虽然在 IoT 场景表现很好，但架构上已经很难支持多协议统一。这些产品都很优秀，都在它们的时代解决了关键问题。但时代在变，技术在进步，需求在演化。

所以我们选择从内核开始，完全重新构建。用 Rust 而不是 Java 或 Erlang，因为我们需要零 GC 的性能和内存安全的保障。用存算分离而不是传统的一体化架构，因为云原生时代需要真正的弹性伸缩。设计协议无关的统一内核，而不是为单一协议优化，因为我们相信未来需要的是统一的消息平台。

这条路很难，也很慢。从零开始意味着每一行代码都要自己写，每一个坑都要自己踩，每一个细节都要反复打磨。但我们相信，只有这样，才能在最底层、最核心的地方建立真正的差异性。

RobustMQ 的核心设计理念是"统一内核，多协议适配"。我们在内核层实现了高性能的消息路由引擎、存算分离的架构、插件化的存储抽象、弹性的调度机制。这些能力是协议无关的、场景无关的。在这个强大内核之上，MQTT、Kafka、AMQP 都只是不同的协议适配层。

这种设计让我们可以"一次构建，多次复用"。我们给自己定的标准是：一个协议做到100%，才启动下一个。MQTT 是我们选择的第一个协议，不是因为 MQTT 市场最大，而是因为 MQTT 能够充分验证内核的各项能力。发布订阅模型、QoS 保障、会话管理、海量连接处理，这些都需要内核提供强大的支持。

我们不追求短期的便利，而是追求长期的正确。选择 Rust，是因为它提供了接近 C++ 的性能，同时保证了内存安全。选择存算分离，是因为云原生时代需要真正的弹性。选择多协议统一，是因为我们相信这是未来的方向。

看 Confluent 的发展历程，11 年从创立到被收购，验证了一个道理：优秀的基础软件需要时间。我们给自己 10 年的时间，一个协议一个协议地做到极致，一个场景一个场景地深入验证。

有人说我们的愿景太大——"下一代统一消息平台"，要支持所有协议、所有场景。但我们也很清醒。愿景归愿景，执行要脚踏实地。当下我们的重点很明确：把 MQTT 做到 100%，用 MQTT 验证内核的稳定性和可靠性。同时探索 AI 场景，验证内核的通用性和性能。

抬头看天，知道自己要去哪里；低头走路，知道脚下的每一步怎么走。这是我们的节奏。

今天的这个新闻，让我更加确信我们在做对的事情。AI 时代对数据基础设施的需求，正在快速增长。从内核开始构建差异性，是真正能够超越现有产品的路径。

当然，路还很长。但我们不着急。我们想做一件有技术追求的事情，一件能够长期影响技术发展的事情。Confluent 用 了 11 年，Linux 用 了 30 年，我们也给自己足够的时间来打磨技术。

技术本身就是最好的答案。如果这件事有价值，技术会说话。