Other Message Queue Technologies (e.g., RocketMQ, AWS SQS)

In distributed system architecture, selecting the appropriate high-performance message queue is key to implementing peak shaving and decoupling business logic. Apache RocketMQ, as a leading open-source solution in the domestic domain, excels in its pursuit of extreme data throughput capabilities and strict guarantees on transactional consistency. Unlike other lightweight queues, RocketMQ was designed from the ground up with reliability requirements for financial-grade scenarios in mind, featuring unique implementation paths particularly regarding message persistence strategies.

RocketMQ's message storage architecture adopts a "write sequentially, read in batches" strategy. To address disk I/O bottlenecks caused by high-concurrency writes, it introduces a multi-queue replica mechanism across multiple physical machines. When producers send messages, data is directly flushed to local SSDs or high-performance disk arrays without first being staged in memory and asynchronously written back—a behavior seen in some other systems. While this design incurs a slight initial latency, it significantly enhances stability under extreme traffic surges.

In practical development, RocketMQ offers rich persistence configuration options to adapt to various scenarios:

  • Sequential Message Control: By setting orderly=true, ensure messages within the same business thread are processed in order, which is critical for strong consistency requirements in payments and logistics.
  • Transaction Message Support: Utilize the "half-message" mechanism to coordinate local transactions with distributed transactions, ensuring data integrity and eventual consistency without loss.

The following code snippet demonstrates a simple producer example based on Spring Boot and RocketMQ 5.x, showing how to configure persistence parameters:

import org.apache.rocketmq.client.producer.SendMessageResult;
import org.apache.rocketmq.common.message.MessageExt;

public class RocketMqProducerExample {
    private static final String NAME_SERVER = "localhost:9876";
    
    public void sendOrderMsg(String orderId) throws Exception {
        DefaultMQPushConsumerImpl consumer = new DefaultMQPushConsumerImpl();
        consumer.setNamesrvAddr(NAME_SERVER);
        
        // Enable sequential message mode to ensure ordered execution of updates for the same order
        SendMessageBuilder builder = new SendMessageBuilder()
            .setTopic("ORDER_TOPIC")
            .setMessageBody(orderId.getBytes())
            .putUserProperty("order_id", orderId)
            .enableOrderly(true); // Key configuration: Enable sequential messages
        
        SendResult result = producer.send(builder.build());
        
        if (result.getSendStatus() == SendStatus.SEND_SUCCESS) {
            System.out.println("Order " + orderId + " sent successfully, persisted");
        } else {
            throw new RuntimeException("Send failed: " + result.toString());
        }
    }

    public static void main(String[] args) throws Exception {
        RocketMqProducerExample producer = new RocketMqProducerExample();
        // Simulate high-concurrency order placement scenario to test persistence capabilities
        for (int i = 0; i < 1000; i++) {
            Thread t = new Thread(() -> producer.sendOrderMsg("ORD-" + System.currentTimeMillis()));
            t.start();
        }
    }
}

With the above configuration, RocketMQ ensures that critical business messages are reliably saved and waiting for recovery even in cases of network jitter or temporary disk failures. This is an indispensable technical foundation for building systems with extremely high data integrity requirements, such as financial transactions and e-commerce orders.
If RocketMQ represents the exploration results of the open-source community in the high-performance domain, then Amazon Simple Queue Service (SQS) demonstrates how cloud vendors integrate message queues deeply into their full-stack service ecosystems. As a fully managed service, AWS SQS provides developers with the ability to achieve reliable message delivery without maintaining underlying infrastructure, making it particularly suitable for asynchronous communication scenarios within microservice architectures.

Compared to traditional self-built MQ solutions, the core characteristics of SQS lie in its seamless integration with other AWS services and built-in reliability assurance mechanisms:

  • High Availability Design: Deployed across multiple Availability Zones (Multi-AZ) to ensure messages remain accessible even if a single zone fails.
  • Delayed Delivery Feature: Supports setting fixed delays such as 5 seconds or 15 seconds, suitable for scenarios requiring waiting for external system responses.
  • Dead Letter Queue Management: Automatically moves repeatedly failed messages into the Dead Letter Queue (DLQ) to facilitate subsequent issue troubleshooting.

In microservice architectures, SQS is often used as an event-driven middleware. For example, after a user completes registration, tasks such as "sending welcome emails" and "creating new user profiles" can be asynchronously offloaded to SQS queues, avoiding blocking of the main process. This design not only improves system throughput but also enhances fault tolerance—temporary unavailability of downstream services will not affect the execution of core business logic.

The following is a simplified example of sending messages to SQS using AWS SDK for Java v2:

import software.amazon.awssdk.services.sqs.model.SendMessageRequest;
import software.amazon.awssdk.services.sqs.SqsClient;

public class AwsSqSender {
    private final SqsClient sqs = SqsClient.create();

    public void sendMessage(String queueUrl, String messageBody) throws Exception {
        SendMessageRequest request = SendMessageRequest.builder()
            .queueUrl(queueUrl)
            .messageBody(messageBody) // Supports multiple formats including JSON, XML, and plain text
            .build();

        sqs.sendMessage(request);
        System.out.println("Message sent to queue: " + queueUrl);
    }
}

In actual production environments, developers can also combine SQS's FIFO (First-In-First-Out) mode to guarantee message ordering. This is particularly important for scenarios requiring strict sequential processing, such as order processing and invoice generation. By enabling the FifoQueue URL suffix and configuring corresponding producer attributes, SQS ensures that messages within the same transaction are delivered in strict sending-time order.

Technical Selection Recommendations and Future Trend Comparison

When facing two mainstream solutions like RocketMQ and AWS SQS, enterprises should comprehensively evaluate their business needs, team skill reserves, and cost structures when making a selection. RocketMQ is more suitable for enterprises that desire full control, pursue extreme performance, and possess strong operations capabilities; whereas AWS SQS is better suited for scenarios involving rapid deployment, reliance on cloud-native ecosystems, or requiring elastic scaling.

From the perspective of technical evolution, both solutions are continuously integrating new features:

  • RocketMQ is accelerating its transformation towards Serverless mode, launching serverless components like MRPC (Message Router for Cloud) to reduce resource idle costs.
  • AWS SQS is also introducing LocalSQS, allowing direct access to queue data stored on local disks within EC2, ECS, or Lambda environments, thereby improving low-latency read/write performance.

In the future, with the proliferation of edge computing and IoT devices, distributed message systems will face more complex network environments and heterogeneous hardware challenges. Whether open-source or cloud-native solutions, they will place greater emphasis on cross-platform compatibility and intelligent routing capabilities. For technical teams, mastering the underlying principles and best practices of both solutions will be essential preparation for building modern highly-available systems.