关于socket.io服务器集群

基本环境介绍

由于每个socket.io服务器上限就是保持5000个连接数，考虑到大用户量的情况，需要用到一定数量的socket.io服务器，专门用来保持和用户的持久化连接，以便以后可以满足消息的推送功能。服务器数量多了起来，由于socket.io的特殊性，需要考虑到在用户和socket.io服务器建立TCP连接前的http请求，为此，在socket.io服务器和用户中间使用了nginx做了代理转发以及均衡负载作用。

---

socket.io具体机制

socket.io在建立连接之前，会经过3次http请求，叫做3次握手，当3次握手成功之后，才会建立TCP连接。socket.io底层是建立在engine.io之上，而非完全建立在websocket之上。engine.io使用了XMLHttpRequest(或JSON)和websocket封装了自己的一套socket协议。在低版本浏览器里面使用长轮询替代 WebSocket。一个完整的 EIO Socket 包括多个 XHR 和 WebSocket 连接。

首先，前端，也可以理解为客户端，EIO socket通过长轮询，也就是一个XHR请求握手，告诉socket.io端，我要进行XHR长轮询了。后端返回的数据，包括open(数字代表为0)，以及一个sid(可以理解为session.id)和upgrades字段。由于一个EIO socket包含了多个请求，而后端又会同时连接多个EIO socket，此时sid就可以理解为session.id。

另一个字段upgrades，表示可以将连接方式从长轮训升级到websocket。
前端在发送第一个XHR时候就开始了长轮询，所谓长轮询，就是前端在发送一个请求的时候，服务端会等到有数据来到时候发送一个response，前端收到response之后再发送下一个request，实现双向通信。

前端收到握手的 upgrades 后，EIO 会检测浏览器是否支持 WebSocket，如果支持，就会启动一个 WebSocket 连接，然后通过这个 WebSocket 往服务器发一条内容为 probe, 类型为 ping 的数据。如果这时服务器返回了内容为 probe, 类型为 pong 的数据，前端就会把前面建立的 HTTP 长轮询停掉，后面只使用 WebSocket 通道进行收发数据。

---

socket.io服务器集群基本思路

开始的思路，在集群方面，利用cluster的方式来生成socket.io服务器群，具体代码如下

var cluster = require('cluster');
var os = require('os');

if (cluster.isMaster) {
  var server = require('http').createServer();
  for (var i = 0; i < os.cpus().length; i++) {
    cluster.fork();
  }

  cluster.on('exit', function(worker, code, signal) {
    console.log('worker ' + worker.process.pid + ' died');
  }); 
}

if (cluster.isWorker) {
  var express = require('express');
  var app = express();

  var http = require('http');
  var server = http.createServer(app);
  var io = require('socket.io').listen(server);
  var redis = require('socket.io-redis');

  io.adapter(redis({ host: 'localhost', port: 6379 }));
  io.on('connection', function(socket) {
    socket.emit('data', 'connected to worker: ' + cluster.worker.id);
  });

  app.listen(80);
}

cluster支持两种分发模式，第一是由主进程负责监听端口，接收新连接后再将连接循环分发给工作进程。在分发中使用了一些内置技巧防止工作进程任务过载。子进程无法去监听端口，不能最大化去设定每个子进程的任务。

第二是主进程创建监听socket后发送给感兴趣的工作进程，由工作进程负责直接接收连接。

理论上第二种方法应该是效率最佳的，但在实际情况下，由于操作系统调度机制的难以捉摸，会使分发变得不稳定。我们遇到过这种情况：8个进程中的2个，分担了70%的负载。

所以在下面例子中直接不采用cluster方式，而直接粗暴的创建socket.io服务器。

由于利用到多个socket.io服务器，为了能够将整个socket.io服务器群对于用户而言等同于一个大的服务器，在socket.io和用户之间用Nginx来做请求转发。基本思路图如下

image.png

首先用户将请求发送到Nginx，Nginx在此基础上做请求转发，将请求根据相关配置发送到4个服务器中的一个。假设socket.io服务器分别占用端口3001、3002、3003、3004的话，在Nginx中的相关配置nginx.conf如下：
在http模块下有

http{
    #在upstream配置socket.io服务器，可以理解为上游部分
    upstream my_servers{
        server 127.0.0.1:3001
        server 127.0.0.1:3002
        server 127.0.0.1:3003
        server 127.0.0.1:3004
    }
    server{
        listen 8080;
        server_name localhost;
        location / {
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $host;
          proxy_http_version 1.1;
          proxy_pass http://my_servers;
        }
    }
}

这样就可以将Client的请求转发到这4个服务器中的任何一个，此时socket.io代码如下，仅仅将socket.io2作为实例，其余socket.io服务器代码完全一致，除了各自编号

const express = require('express');
const http = require('http');
const app = express();

const server = http.Server(app)
const io = require('socket.io')(server);

io.on('connection',(socket)=>{
    console.log('Server No.2 is connected');
    socket.emit('message', {message: 'Here is the message coming from the server 2'});
})

server.listen(3002, ()=>{
    console.log('hey there')
})

客户端服务器代码如下，主要是为了加载静态页，

const path = require('path');
const app = require('express')();
const server = require('http').createServer(app);
const io = require('socket.io')(server);

app.get('/',(req, res)=>{
    res.sendFile(path.join(__dirname, './index.html'));
})

server.listen(3000)

index.html代码如下

此时将4个socket.io服务器同时运行，模拟一个最小的集群样例，开启客户端服务器，打开网页localhost:3000，此时页面上有一个连接的按钮，点击之后，打开浏览器控制台可以看到

image.png

由于socket.io服务器要和用户建立TCP的连接的前提在于三次握手成功，但是目前存在的问题是，比如，第一次用户的请求分发给socket.io No.1，然后第二次请求分发给socket.io No.2，用户所携带的sid无法被No.2所识别，所以导致失败，也许前面3次都成功握手了，负责监听update事件的server也不是那个server也会导致失败。

基本原理基本清楚了之后，重点是解决用户的一次建立tcp之前的http请求，必须固定分发给一个服务器，在socket.io官方文档给出的解决方案是利用sticky session，而Nginx本身也提供了这一策略，即ip_hash。

将ip_hash添加到http部分的upstream部分中，放置在首位。然后重启nginx，运行客户端，点击连接按钮，连接成功。当模拟一个socket.io挂掉的时候，用户请求仍然可以转发至其他正常运行的服务器，针对sticky session策略目前是可行的。

---

模拟大量用户并发访问

单个用户访问建立TCP连接在上述是可行的，但是如果大量用户并发访问呢？目前用到apache ab工具来进行高并发访问实验。

命令如下

ab -n 10000 -c 100 -r 127.0.0.1:8080

模拟总量10000次，每次同时请求100。

此时socket.io服务器只有一个接受请求，其余3个都是处于空闲状态，而接受请求的那个负载很高，并且经常以外拒绝请求，导致失败。

原因分析应该在于ip_hash策略，导致所有的请求都自动绑定到某一个服务器上，而无法实现分摊到其他服务器上。Nginx还有提供一个策略就是least_conn，即根据最小连接数来选择相应的服务器进行连接，当在upstream中加入least_conn策略的时候，运行的时候提示least_conn把ip_hash覆盖掉了，看来策略只能存在一个。但是least_conn可以将请求均摊到4个服务器上，看来还是在一定情况下满足我们的需求。

在每个server 127.0.0.1:300x 后面加上权重的话，可以将服务器的访问分流到我们想要的服务器上，但是缺点在于，目前只会手动处理，不现实。因此这个方案也pass掉。

---

新解决方案1(代码部分还未实现)

由于least_conn方案可以将用户的请求均摊到4个服务器上，如果用户只通过nginx请求一次，分发到空闲的服务器上，然后再由服务器本身去与客户直接连接tcp，将websocket连接绕开Nginx

image.png

白色箭头表示普通的http的请求，也仅仅是单次请求，只请求一次，通俗而言就是客户端通过Nginx，告诉4个socket.io服务器中的某一个，我要开始进行连接了，得到服务器端的通过之后，服务器端会绕开nginx，主动与client建立websocket连接，目前方法是可行的，只是代码部分还未实现。

---

新解决方案2

可以定制nginx的策略，来完成相关的均衡负载，但是不知道可行与否

---