CODEWITHSUNDEEP
node.jsmongodbbackbone.jssocket.iopublish-subscribe
Guy Korland
Guy Korland

Reputation: 9568

Using Backbone.iobind (socket.io) with a cluster of node.js servers

I'm using Backbone.iobind to bind my client Backbone models over socket.io to the back-end server which in turn store it all to MongoDB. I'm using socket.io so I can synchronize changes back to other clients Backbone models.

The problems starts when I try to run the same thing over a cluster of node.js servers. Setting a session store was easy using connect-mongo which stores the session to MongoDB. But now I can't inform all the clients on every change, since the clients are distributed between the different node.js servers.

The only solution I found is to set a pub/sub queue between the different node.js servers (e.g. mubsub), which seems like a very heavy weight solution that will trigger an event on all the servers for every change.

Upvotes: 1

Views: 202

Answers (1)

samhain1138
samhain1138

Reputation: 1035

How did you reach the conclusion that pub/sub is a "very heavy weight solution"?
Sounds like you got it right up until that part :-)
Oh, and pub/sub is not a queue.

Let's examine that claim:
The nice thing about pub/sub is that you publish and subscribe to channels/topics.
So, using the classic chat server example, let's say you have a million users connected in total, but #myroom only has 50 users in it.
When a message is sent to #myroom, it's being published once. No duplication whatsoever.
In most use-cases you won't even need to store it on disk/RAM, so we're mostly looking at network/bandwidth here. And, I mean, you're probably throwing more data (probably over the wire?) to MongoDB already, so I assume that's not your bottleneck.

If you also use socket.io's rooms features (which is basically its own pub/sub mechanism), that means only 5 users will have that message emitted to them over the websocket.
And no, socket.io won't iterate over 1M clients to find out which of them are in room #myroom ;-)
So the message is published once, each subscriber (node.js instance) will get notified once, and only the relevant clients -- socket.io won't waste CPU cycles in order to find them as it keeps track of them when they join() or leave() a room -- will receive the message.
Doesn't that sound pretty efficient and light-weight?

Give Redis a shot.
It's really simple to set-up, runs entirely in memory, blazing-fast, replication is extremely simple, etc.

That's the way socket.io recommends passing events between nodes.
You can find more information/code here.

Additionally, if MongoDB can't handle the load at any point, you can use Redis as your session-store as well.

Hope this helps!

Upvotes: 1

Related Questions