[rabbitmq-discuss] How to sanely bind one queue to many exchanges?
n8gray at n8gray.org
Fri Aug 14 19:17:50 BST 2009
On Fri, Aug 14, 2009 at 10:53 AM, Paul Jones<pauljones23 at gmail.com> wrote:
> Hi Nathan,
> On Fri, Aug 14, 2009 at 6:29 PM, Nathan Gray <n8gray at n8gray.org> wrote:
>> Maybe, maybe not. I've written a multiplayer boardgame. I used
>> Google App Engine for the server, which works fine but requires that
>> the client poll the server to detect when someone has made a move,
>> sent a chat, or otherwise generated an event. (GAE doesn't allow
>> long-lived connections or raw socket access.) I'm hoping to use
>> rabbitmq as an "event server" to get real-time updates to clients
>> without pounding GAE with HTTP requests. When an event is generated
>> for a game, GAE publishes to the event server, which tells any
>> connected clients of the game to ask GAE for an update.
>> There will be many games running, and each game has 2-4 players. The
>> natural mapping (IMHO) to AMQP is to have one fanout exchange per
>> game. The server on GAE creates this (durable) exchange when a new
>> game starts. When the game ends there will be no more events from it,
>> so the exchange is deleted. It's possible for a game to end before
>> the client connects (the last player can play while the client is
>> offline). Each player can play multiple games, thus the requirement
>> to connect to multiple exchanges. Clients connect with auto-delete
>> queues, since message content is uninteresting -- it's only the timing
>> they care about.
>> If there's a better way to do this I'm happy to hear it. I could use
>> one big direct exchange with player names as routing keys, but that
>> would require my publisher to send multiple messages for each game
>> event, one for each player in the game. I could use one big topic
>> exchange with routing keys like "joe.sally.bob" and subscribe with
>> patterns like "#.bob.#", but putting all the messages through one
>> topic exchange doesn't seem like it would scale well.
> Assuming that there is a known identifier for each game (database id, guid,
> or equivalent), what about using a single direct exchange, with the routing
> key being set to the game id each time. When a player connects, they
> subscribe to the exchange with all of the routing keys for the games that
> they are interested in.
Can you subscribe one queue to one exchange with multiple keys, or is
the idea that each player would use one queue per game?
> As far as scalability is concerned, using a direct exchange with many
> routing keys should hopefully be no worse than many fanout exchanges with no
> routing keys. If you're considering the clustering scenario, exchange
> information is replicated to all nodes - so it isn't like there is a single
> point that all messages need to go through.
Good to know. I wasn't too worried about using one direct exchange,
but using one topic exchange seemed like a bad idea.
More information about the rabbitmq-discuss