A simple and performant way to use Socket.IO within a cluster.
Unlike other packages like sticky-session, the routing is based on the session ID (the sid
query parameter).
See also:
connection.remoteAddress
)x-forwarded-for
header)Table of contents
npm install @socket.io/sticky
const cluster = require("cluster");
const http = require("http");
const { Server } = require("socket.io");
const numCPUs = require("os").cpus().length;
const { setupMaster, setupWorker } = require("@socket.io/sticky");
const { createAdapter, setupPrimary } = require("@socket.io/cluster-adapter");
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
const httpServer = http.createServer();
setupMaster(httpServer, {
loadBalancingMethod: "least-connection", // either "random", "round-robin" or "least-connection"
});
setupPrimary();
httpServer.listen(3000);
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on("exit", (worker) => {
console.log(`Worker ${worker.process.pid} died`);
cluster.fork();
});
} else {
console.log(`Worker ${process.pid} started`);
const httpServer = http.createServer();
const io = new Server(httpServer);
io.adapter(createAdapter());
setupWorker(io);
io.on("connection", (socket) => {
/* ... */
});
}
The first HTTP request (without sid
query parameter) is forwarded to a random worker (based on the loadBalancingMethod
option).
The underlying Engine.IO server creates a new session and emits a connection
event with the session ID. The worker sends this session ID to the master, which stores the relationship between the worker ID and the session ID.
For subsequent requests, the sid
query parameter is extracted by the master process, which then forwards the handle to the right worker.
// client-side
const socket = io({
transports: ["websocket"] // HTTP long-polling is disabled
});
For more information, please see this issue.
MIT