RocketMQ-Rust: a Rust reimplementation of Apache RocketMQ, crate by crate

What RocketMQ-Rust is for, and who should care

Apache RocketMQ is a Java message middleware with a name server, brokers, producers and consumers. RocketMQ-Rust reimplements that system in Rust and describes itself as an unofficial implementation, so it is not governed by the Apache project. The README frames the goal as bringing enterprise-grade message middleware to the Rust ecosystem while keeping compatibility with the RocketMQ protocol.

The audience is narrow and specific. If your services are already Rust and you want a broker you can build from the same toolchain, with a client crate you can add to Cargo.toml, this is aimed at you. If you run RocketMQ on the JVM today and are happy with it, the project offers no migration story in the README. There is no section on importing existing commitlog data or on running mixed Java and Rust brokers in one cluster, so treat the two as separate deployments until you find evidence otherwise.

The crate split: nameserver, broker, store, proxy, client

The architecture is not a single binary. The README lists core components: a Name Server for service discovery and routing, a Broker for storage and delivery, a Producer Client, a Consumer Client, a Store, and a Controller for failover. The workspace Cargo.toml makes that concrete, with members such as rocketmq-namesrv, rocketmq-broker, rocketmq-controller, rocketmq-proxy, rocketmq-client, rocketmq-store, rocketmq-store-local and rocketmq-store-rocksdb.

That last pair is the most interesting detail in the repository layout. Having both a local store and a RocksDB-backed store as separate crates implies the storage engine is meant to be swappable, which the README does not explain further. The store-api crate suggests a trait boundary, but the documentation does not state which engine is the default for a broker started with the quickstart commands.

The proxy layer is similarly split: rocketmq-proxy, rocketmq-proxy-core, rocketmq-proxy-cluster and rocketmq-proxy-local. The README describes proxy-core as stable contracts and use cases, and proxy-cluster as the cluster-mode adapter with keyed execution and remote broker access. A local variant exists alongside them. Which one a given deployment should run is not answered in the README.

Build the workspace and start a nameserver

The README pins Rust toolchain 1.95.0 and assumes cargo on the path. It also points to a toolchain and dependency policy document under rocketmq-doc for the pinned toolchain and dependency admission rules. Clone and build the whole workspace first:

git clone https://github.com/mxsm/rocketmq-rust.git
cd rocketmq-rust
cargo build --workspace

If you only need the client from your own application, the README shows adding the release to Cargo.toml. Note the crate names here differ from the repository directory names:

[dependencies]
rocketmq-client-rust = "1.0.0"
rocketmq-model = "1.0.0"
rocketmq-protocol = "1.0.0"

The nameserver runs as its own binary. The default endpoint is 127.0.0.1:9876, and the README shows binding it explicitly:

cargo run --bin rocketmq-namesrv-rust -- --ip 127.0.0.1 --port 9876

Expect a process that stays in the foreground and logs broker registrations. Nothing is registered yet, so the routing table starts empty.

Starting the broker requires ROCKETMQ_HOME

This is the first real constraint a new user hits. The broker will not start without the ROCKETMQ_HOME environment variable, which the README says can point at an existing RocketMQ home or at a local runtime directory created for testing. On Linux or macOS:

export ROCKETMQ_HOME="$(pwd)/.rocketmq"
mkdir -p "$ROCKETMQ_HOME/conf"
cargo run --bin rocketmq-broker-rust -- -n 127.0.0.1:9876

Windows PowerShell uses the same variable with different syntax:

$env:ROCKETMQ_HOME = "$PWD\.rocketmq"
New-Item -ItemType Directory -Force "$env:ROCKETMQ_HOME\conf" | Out-Null
cargo run --bin rocketmq-broker-rust -- -n 127.0.0.1:9876

The -n flag carries the nameserver address. The README also mentions --configFile and --namesrvAddr, and suggests running the binary with --help to inspect configuration flags and config printing options. It does not publish a sample broker configuration file, so if you need non-default behaviour you are reading the flag list rather than a documented config reference.

Once the broker registers, start the consumer example first, then the producer in another terminal:

cargo run -p rocketmq-client-rust --example consumer

cargo run -p rocketmq-client-rust --example producer

The examples default to 127.0.0.1:9876 and a topic named TopicTest. The README links separate client documentation for single messages, batch messages and RPC messaging.

Where the README stops short

The documentation gap is the main cost of adopting this project. There is no operations section covering topic creation, retention, disk-full behaviour, or what happens when a broker restarts with an existing store. The store crate split suggests pluggable persistence, but neither the README nor the component table says which engine is used by default or how to switch it.

The compatibility claim is also underspecified. The README says the project maintains full compatibility with the RocketMQ protocol, but it does not say which protocol version, which client versions can talk to the Rust broker, or whether the Rust client works against a Java broker. Those are exactly the questions a team asks before putting a message broker in front of production traffic, and the README answers none of them.

The component tables are deliberately framed around responsibility rather than maturity, and the README says so explicitly. That is an honest choice, but it means you cannot tell from the README which crates are ready for production and which are scaffolding. The presence of a fuzz directory and a deny.toml suggests the project cares about dependency and input hygiene, though the README does not describe what either covers.

RocketMQ-Rust against the Java broker and against Kafka

The obvious alternative is Apache RocketMQ itself, in Java. That is the reference implementation, it is what the RocketMQ documentation describes, and it has the operational tooling and release history that come with an Apache project. RocketMQ-Rust is a reimplementation of the same design, so the difference is not architectural: it is the implementation language, the build toolchain, and the fact that the Rust version is unofficial. If your team is JVM-based and you want the protocol's behaviour defined by the original, the Java broker is the safer default.

Kafka is the other comparison people reach for, and the difference is in the model rather than the language. RocketMQ's design centres on a lightweight name server for routing plus brokers, with the client resolving routes through the name server; Kafka relies on its own controller and metadata quorum. RocketMQ-Rust reproduces the RocketMQ side of that split, including a controller crate for failover. Choosing between them is a choice about which operational model you already know, not about which one this project improves on. The README makes no performance comparison against either, and no benchmark numbers appear in it.

Licence and the cost of tracking a fast-moving workspace

RocketMQ-Rust is Apache-2.0, matching the upstream project, with LICENSE-APACHE and NOTICE at the repository root and the same identifier in the workspace manifest. Apache-2.0 is permissive and includes a patent grant, but the NOTICE file matters: if you redistribute the software you need to carry the notices with it. That is a packaging question for your legal team, not something this article can settle.

The upgrade cost is real. Three releases landed between December 2025 and June 2026, and the workspace spans dozens of crates including storage engines, a proxy and an admin tool. The last push to the repository was on 2026-06-14, so the project is not dormant, but a workspace of this size means a version bump can move protocol types, client APIs and store behaviour at once. The CHANGELOG.md at the root is where the project records those changes; the README does not describe a compatibility policy between releases. Pin exact versions of the client crates and read the changelog before bumping, because the README gives no rollback procedure.

Editorial conclusion

Adopt RocketMQ-Rust if you want a RocketMQ-compatible broker and client you can read and extend in Rust, and you are willing to run it from source while the documentation catches up. Do not adopt it if you need a documented upgrade path, a supported operations manual, or a protocol guarantee beyond what the client and broker crates implement today; the README does not document rollback or version compatibility. Verify two things before committing: that the client crates at the version you pin (the README shows 1.0.0) match the broker you intend to run, and that ROCKETMQ_HOME is populated with the configuration your deployment needs, since the broker refuses to start without it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes