基本环境介绍
由于每个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来做请求转发。基本思路图如下
首先用户将请求发送到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代码如下
<script>
var btn = document.getElementById('btn1');
btn.addEventListener('click',function(){
var socket = io.connect('https://localhost:8080',{
reconnection: false
});
socket.on('connect', ()=>{
console.log('Client has connected')
socket.on('s:message',(d)=>{
console.log(d);
});
});
socket.on('error',function(err){
console.log(err);
})
});
</script>
此时将4个socket.io服务器同时运行，模拟一个最小的集群样例，开启客户端服务器，打开网页localhost:3000，此时页面上有一个连接的按钮，点击之后，打开浏览器控制台可以看到
由于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
白色箭头表示普通的http的请求，也仅仅是单次请求，只请求一次，通俗而言就是客户端通过Nginx，告诉4个socket.io服务器中的某一个，我要开始进行连接了，得到服务器端的通过之后，服务器端会绕开nginx，主动与client建立websocket连接，目前方法是可行的，只是代码部分还未实现。
新解决方案2
可以定制nginx的策略，来完成相关的均衡负载，但是不知道可行与否
