Delayed Message Queue Implementation: Use Cases, Comparison, and NetEase Open Course Practice
The article explains how delayed message queues replace inefficient scheduled‑task scans in distributed systems, outlines common use cases such as order timeouts and retries, compares RabbitMQ, RocketMQ, Kafka, ActiveMQ and Redis implementations, and details NetEase’s ActiveMQ‑based solution with idempotent processing and traceability.
This article discusses the implementation of delayed message queues in distributed systems. In early systems, delayed processing was handled by scheduled tasks scanning databases, which had drawbacks of high frequency, low hit rate, and significant resource consumption. With the popularity of message middleware, delayed messages provide a better solution.
Use Cases:
1. Validity period: Limited-time activities, group buying
2. Timeout processing: Cancel unpaid orders, auto-confirm receipt
3. Delayed processing: Robot likes, view counts, comments, following
4. Retry: Network exception retry, taxi dispatching
5. Scheduled tasks: Smart device timed startup
Comparison of Message Queues:
RabbitMQ: Implements delayed queues using TTL (Time To Live) and Dead Letter Exchanges (DLE). Drawbacks include complex configuration and fragility.
RocketMQ: Stores delayed messages in specific queues based on delay time periods, using a timer to poll and deliver messages when expired. Drawback is limited time granularity (1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h).
Kafka: Implements delayed operations using TimingWheel and JDK DelayQueue. Drawbacks include precision dependent on time grid settings and potential external event triggers.
ActiveMQ: Stores delayed messages in JobStore, using JobScheduler to deliver messages when delivery time is reached. Drawback is potential message delivery time multiplication on failure.
Redis: Implements delayed queues using sorted sets with score as execution timestamp. Drawbacks include complex implementation and memory-based storage.
NetEase Open Course Practice:
Selected ActiveMQ for their delayed queue implementation based on: controllable data volume, reliability requirements, existing middleware infrastructure, and flexible delay time requirements. Business scenarios include closing unpaid orders (WeChat: 2h delay, iOS: 4h delay) and discount activity management.
The implementation includes: DelayMessage class for message definition, JmsDelayEnum for business type enumeration, JmsDelayTemplate for message sending, and database redundancy for traceability. Optimizations include idempotent processing in consumers to ensure delay time accuracy.
NetEase Media Technology Team
NetEase Media Technology Team
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.