DOCSEARCHbyAlgolia
Submit Docs

RocketMQ-Rust Documentation

website·Indexed 31 days ago

https://rocketmqrust.com

Documentation for RocketMQ-Rust version 1.0.0 (development), featuring guides on the Rust API, system architecture, and producer implementation. Includes technical reference for service configuration, protocol compatibility, and the rocketmq-admin-cli tool, as well as operational guidance for monitoring, backup recovery, and capacity performance.

Tokens
97.8K
Snippets
211
Records
677
Agent score
53%

What's inside RocketMQ-Rust

  1. Overview of RocketMQ Rust observability export paths

    Activating a signal requires two conditions: the binary must be compiled with the corresponding Cargo feature, and the runtime configuration must select an active exporter.

    Available export paths include:

    • Local console/file logging: Used for inspecting startup, errors, and lifecycle diagnostics. This is separate from OTLP log export.
    • OTLP gRPC to a collector: Used to centralize metrics, traces, and logs. Requires a collector to verify the pipeline.
    • Direct Prometheus: Available for services built with the Prometheus exporter (currently Broker or Controller). Requires a deliberately exposed metrics listener.
    • Log exporter: Used for local inspection of selected telemetry; not intended as a durable remote monitoring system.

    Note: Selecting an exporter that was not compiled into the binary will result in a typed feature-disabled error.

  2. Overview of RocketMQ-Rust components

    RocketMQ-Rust provides a modular implementation of message services. The core components and their responsibilities are:

    • NameServer: Handles Broker registration, liveness checks, and topic-route lookups. Required for standard client discovery.
    • Broker: Manages request processing, topic/group metadata, message storage, and delivery. Required for every message path.
    • Rust Client: Provides Producer and consumption models (Push, LitePull, POP) and administration tools for Rust applications.
    • Proxy: Handles protocol ingress with cluster or embedded-local backend adaptation.
    • Controller: Manages coordination for selected High Availability (HA) topologies.
    • Admin CLI & Storage Inspection: Used for cluster administration, diagnosis, and offline operations.
    • Dashboards: Provides web or native interfaces for interactive administration.
    • MCP, MCP Control, SRE: Optional operations products for read-only diagnostics and SRE workflows.

  3. Overview of rocketmq-mcp-control mutation tools

    rocketmq-mcp-control is an independent HTTPS MCP server that provides five specific typed mutations for RocketMQ. It is distinct from the read-only MCP and requires the write-tools feature to be enabled during build to provide mutation capabilities.

  4. Overview of rocketmq-mcp

    rocketmq-mcp is a standalone Model Context Protocol (MCP) server designed for RocketMQ queries, diagnosis, and runbook prompts. It operates independently of Broker, NameServer, and Dashboard processes, utilizing Admin Core's read-client-adapter. By default, its tools are read-only and do not open mutation sessions; the optional planning feature generates proposals but does not apply them.

  5. Overview of RocketMQ-Rust

    RocketMQ-Rust is a high-performance messaging middleware implemented in Rust. It reimplements the architecture of Apache RocketMQ to leverage Rust's memory safety, zero-cost abstractions, and modern async programming patterns. It is designed for enterprise-grade use and provides cross-platform compatibility across Linux, Windows, and macOS.

  6. Use the rocketmq-tools crate for administration

    v0.4.0
    A new rocketmq-tools crate has been introduced to provide administrative capabilities. This includes the MQAdminExt for extended administration and AdminToolResult for handling tool outputs.

  7. Understand NameServer route management and publication

    The NameServer acts as a discovery service where Brokers register their identity and Topic metadata, and clients query these routes to locate where Topics can be read or written.

    Key architectural details:

    • RouteInfoManager maintains source tables for Topic queues, Broker addresses, cluster membership, and queue mapping.
    • To ensure high-performance reads, the NameServer uses a snapshot mechanism: mutations are serialized via a coordinator, and immutable snapshots are published for affected Topics. Clients load a complete Topic snapshot rather than joining tables.
    • KVConfigManager handles namespace/key configuration and persistence separately from route state.
    • Route state is volatile; it is repopulated from Broker registrations after a NameServer restart rather than being loaded from a durable registry.

  8. Implement a TransactionMQProducer for coordinated events

    Transaction messages coordinate the visibility of an event with a producer-side business transaction. The process involves the Broker storing a 'half-message' (prepared), followed by the producer reporting a commit, rollback, or unknown outcome. This is not a distributed ACID transaction but a coordination mechanism. To use this, you must use a TransactionMQProducer with a registered TransactionListener and an injected ClientRuntime.

  9. RemotingCommand batch sending and serialization optimization

    v0.7.0
    Batch sending for RemotingCommand is now implemented to optimize throughput and reduce latency in client-server communication. Additionally, remoting command serialization, deserialization, and header encoding/decoding efficiency have been optimized.

  10. Understand throughput and performance factors in RocketMQ Rust

    Throughput is workload-dependent and cannot be represented by a single figure. To accurately measure or report throughput, you must account for the following variables: hardware specifications, storage type, software versions/features, message sizes, queue layout, client mode, flush/replication policies, test duration, error rates, and completed consumption. Note that short producer bursts do not represent sustainable end-to-end throughput.

  11. RouteInfoManager V2 features and concurrency

    v0.7.0
    RouteInfoManager V2 has been implemented using DashMap to improve concurrency. It includes functionality to register and delete topics, along with updated configuration options and integration tests.

  12. Understand RocketMQ Proxy operational modes

    RocketMQ Proxy translates gRPC MessagingService and remoting ingress requests into backend-neutral services. It operates in two primary modes:

    1. Cluster Mode: Uses NameServer discovery and cached route/metadata information to make bounded client/transport calls to an existing cluster. Note that inbound request authentication does not automatically authenticate the Proxy's separate connection to the Broker.
    2. Local Mode: Uses an embedded Broker facade via a bounded command queue. This mode requires its own Broker identity and a unique store root. It has separate limits for queue count, retained bytes, age, I/O concurrency, control reserve, and long-poll tracking.