How to scale socket.io without redis

I'm currently searching for an alternative to scale my express app with socket.io. The problem is that I don't want to use redis as socket.io store. Are there any other possibilities to cluster socket.io except with Clusterhub?

EDIT: I tried to use fakeredis as replacement for redis, but it seems like it doesn't work with socket.io. From ActionHero.js I know that faye-websocket works with fakeredis.

回答1:

This might well depends on your socket.io usage and the type of scaling you want to achieve (cluster vs scaling to multiple machines).

So, here is what I did to scale our usage of socket.io to multiples servers.

We have 3 servers behind a load balancer, when a socket connects it connect to any of the 3 servers, the three server has an in memory list of the sockets, and the three servers have an order list of internal server address e.g. [server1, server2, server3].

What I do basically is a ring (internally we call it the "ring of sockets"):

If I need to emit an event to a socket from server1, I look first if the socket is connected to that server1, if not I send an http request to the next server (server2) which will check if the socket is there, if not there it will send the same request to server3, and so on until reaching the origin in which case you might throw an error.
Its almost the same if I need to broadcast a message, I start from one server and then call an http endpoint on the others.

The algorithm I use to determine the next node (next_node.js) is:

var nodes = process.env.NODES.split(',');
//this is usually:  http://server1/,http://server2/,http://server3/

var url = require('url');
var current = require("os").hostname();

//origin is the node that started the lookup
exports.get = function (origin) {
  var next_node_i = nodes.map(function (uri) {
    return url.parse(uri).hostname;
  }).reduce(function (prev, curr, i, arr){
    return curr === current && i < arr.length - 1 ? i + 1 : prev;
  }, 0);

  var next_node = nodes[next_node_i];

  if (origin && url.parse(next_node).hostname === origin) {
    // if the next node is equal to the first node initiating the lookup
    // it means the socket we are looking for is not connect to any node.
    return null;
  }

  return next_node;
};

Caveats:

Latency is low between these server and network partitioning is unlikely, they are physically on the same datacenter. But if it were a network partitioning is not that important for us.
We always run the ring in the same direction. An improved version will be to run in both directions(?)
Servers share a secret to call these endpoints.

In my opinion this is a very easy way to achieve scaling in a lot of socket.io use cases, there might be a lot of other scenarios where this is not an option but I hope this give some ideas.

回答2:

If your comfortable with Azure services, some of the guys on the Azure team have gone to the liberty of writing a service bus store for socket.io.

Glenn Block Explains Socket.IO Scale-Out on Service Bus