Message Queue Interview Questions and Technical Guide

Directory

How to use MQ in a project?

Why use a message queue?

Advantages and disadvantages of message queues?

Differences among Kafka, ActiveMQ, RabbitMQ, RocketMQ?

How to ensure high availability of MQ?

How to prevent duplicate consumption?

How to guarantee reliable transmission?

How to guarantee ordering?

Design a message‑queue architecture?

Message Queue Technology Selection

Problems solved by MQ: decoupling, asynchronous processing, and peak shaving.

Scenarios without MQ (tight coupling)

System A must directly handle requests from multiple dependent systems (B, C, D, E), leading to strong coupling and complex error handling.

Scenarios with MQ (decoupling)

Code maintenance no longer needs to consider downstream success.

New systems can simply consume from MQ; unwanted data can be ignored.

Result: Pub/Sub model fully decouples System A from others.

High‑latency synchronous request scenarios

Internet services often require sub‑200 ms response times.

Using MQ for asynchronous performance optimization

MQ helps smooth out spikes and improve latency.

Peak‑shaving scenario without MQ

During a traffic peak of 5 000 requests per second, MySQL cannot handle the load and the system collapses.

Using MQ for peak‑shaving

Requests are queued in MQ; the consumer processes them at a sustainable rate, allowing the backlog to be cleared after the peak.

At 3 000 messages per second backlog, 1 hour of peak can generate 10 million pending messages, which are drained once traffic normalizes.

Problems introduced by MQ

Reduced system availability – MQ failure can crash the whole system.

Increased complexity – duplicate messages, lost messages, out‑of‑order delivery, and cascading failures.

Consistency issues – partial success across services can leave the overall transaction incomplete.

Kafka, ActiveMQ, RabbitMQ, RocketMQ pros & cons

Recommendation: RabbitMQ for small‑to‑medium companies, RocketMQ for large enterprises, Kafka for real‑time big‑data processing.

Message Queue High Availability

RabbitMQ HA

Three modes: single‑node, classic cluster (non‑HA), and mirrored cluster (HA).

Single‑node – demo level.

Classic cluster – metadata replicated, messages not; no HA guarantee.

Mirrored cluster – both metadata and messages replicated across nodes; if one node fails, others continue serving.

Configuration: create a mirrored‑cluster policy in the admin console and apply it to queues.

Kafka HA Architecture

Each broker runs a process; topics are split into partitions distributed across brokers. Replication provides HA – each partition has a leader and followers; the leader writes to followers before acknowledging.

Since Kafka 0.8, the replica mechanism (acks=all) ensures data durability.

Message Queue Duplicate Data

MQ can guarantee no loss but cannot fully prevent duplicates.

Kafka duplicate consumption

Offsets are committed periodically; if a consumer crashes before committing, the same messages may be re‑delivered.

Ensuring idempotency

Check primary key before inserting into DB; update if exists.

Use Redis SET operations (naturally idempotent).

Producer attaches a global unique ID; consumer checks Redis for prior processing.

Leverage database unique constraints.

Ensuring No Message Loss

RabbitMQ loss scenarios

Network loss before broker receives the message.

Broker crash after message is in memory but before persistence.

Consumer crash after ack but before processing.

Solution 1 – Transaction mode (synchronous)

channel.txSelect
try {
    // send message
} catch (Exception e) {
    channel.txRollback;
    // retry sending
}
channel.txCommit;

Solution 2 – Confirm mode (asynchronous)

public void ack(String messageId) {
    // handle successful delivery
}

public void nack(String messageId) {
    // retry sending
}

Persist queues (durable) and messages (deliveryMode=2) to disk; combine with confirm mode for reliable delivery.

Disable auto‑ack; manually ack after processing to avoid loss when consumers crash.

Kafka loss scenarios

Consumer auto‑commits offset before processing; crash leads to loss.

Broker leader fails before followers sync.

Mitigations: set replication.factor > 1, configure min.insync.replicas > 1, producer acks=all, retries=MAX.

Message Queue Ordering

Use cases require strict order (e.g., MySQL binlog replication).

RabbitMQ ordering issues

Guarantee order by sending related messages to the same queue.

Kafka ordering

Messages with the same key (e.g., order ID) go to the same partition, preserving order; a single consumer per partition reads in sequence.

Message Queue Latency and Expiration

Backlogs can fill disk; setting TTL on messages can drop stale data, but may cause loss.

Rapidly drain backlog by scaling consumers or creating temporary high‑throughput topics/queues.

Designing a Message Queue Middleware Architecture

Support scalability: distributed brokers, topics, partitions; add partitions to scale out.

Persist data sequentially to disk for high throughput (Kafka’s approach).

High availability via replication, leader/follower election.

Zero data loss guarantees through proper replication and ack settings.

Author: mousycoder – segmentfault.com/a/1190000021054802 – Java知音整理，答案仅供参考，欢迎指正！