Message Queue Explained

JNDI

JNDI stands for Java Naming and Directory Interface, in short, it provides

bind, that binds a name to an object or object reference
lookup that looks up an object or object reference by its name

Message Queue

Message queue is a mechanism for async communication that allows avoiding direct interaction between producers and consumers. Instead, relying on an intermediate message queue. A message can be a segment of data (or JSON, binary).

Message queue is helpful in terms of 3 aspects:

Decoupling. Producers and consumers don’t know each other, only following the format of the message queue
Async.
Buffering.

Two Models for MQ

End-to-End Model. (Queue). One message can only be received by 1 consumer.
Publisher-Subscriber Model (Topic). One message can be received by multiple consumers.

Example: Message Queue and Real-Time Leaderboard

For example, let’s implement a leaderboard. It requires

real-time score update
leaderboard consulting
ability for high concurrency

We may use MessageQueue to handle this. The architecture is to

When players get score, clients send ScoreUpdate message to MQ.
Leaderboard service (on server) reads ScoreUpdate message from MQ and updates SortedSet in Redis
After update, server puts ScoreChange event to some Topic that all clients subscribes to. Upon receiving ScoreChange, clients update the client-side leaderboard for rendering.

Example: MQ and Game Room

In game rooms, MQ is often served as a coordinator for state sync. For example, we can treat Topic as game room.

When some player joins a room, their client is connected to the specific Topic
Any operation will be capsuled as event, which will be sent to Topic by client as producer.
All other clients in the same room are consumers that receives event from Topic and consume it.

Based on this, we may also implement match-making mechanism. We simply maintain a “waiting room” (e.g. Redis pool), and a MQ to buffer requests from clients. A processor consumes requests from the MQ that puts clients into some Redis pool.

When players look for matches, their clients send MatchMakeRequest to MQ.
A processor consumes requests from MQ and put clients into Redis pool.
A server-side match-maker tries to consume data from Redis pool.
- Internally, it maintains a waiting list. Upon enough players, the match-maker creates the room ID, and send MatchFound send to another Topic, and inform all players to join.
Clients subscribes resulting Topic and enters the room.