socket.io搭配pm2（cluster）集羣解決方案

能夠收藏個人博客

socket.io與cluster

在線上系統中，須要使用node的多進程模型，咱們能夠本身實現簡易的基於cluster模式的socket分發模型，也可使用比較穩定的pm2這樣進程管理工具。在常規的http服務中，這套模式一切正常，但是一旦server中集成了socket.io服務就會致使ws通道創建失敗，即便經過backup的polling方式仍會出現時斷時連的現象，所以咱們須要解決這種問題，讓socket.io充分利用多核。

在這裏之因此提到socket.io而未說websocket服務，是由於socket.io在封裝websocket基礎上又保證了可用性。在客戶端未提供websocket功能的基礎上使用xhr polling、jsonp或forever iframe的方式進行兼容，同時在創建ws鏈接前每每經過幾回http輪訓確保ws服務可用，所以socket.io並不等於websocket。再往底層深刻研究，socket.io其實並無作真正的websocket兼容，而是提供了上層的接口以及namespace服務，真正的邏輯則是在「engine.io」模塊。該模塊實現握手的http代理、鏈接升級、心跳、傳輸方式等，所以研究engine.io模塊才能清楚的瞭解socket.io實現機制。

場景重現

服務端採用express+socket.io的組合方案，搭配pm2的cluster模式，實現一個簡易的b/s通訊demo：

app.js

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

io
  .on('connection', function(socket) {
      socket.on('disconnect', function() {
          console.log('/: disconnect-------->')
      });

      socket.on('b:message', function() {
          socket.emit('s:message', '/: '+port);
          console.log('/: '+port)
      });
  });

io.of('/ws')
  .on('connection', function(socket) {
    socket.on('disconnect', function() {
        console.log('/ws: disconnect-------->')
    });

    socket.on('b:message', function() {
        socket.emit('/ws: message', port);
    });
});

app.get('/page',function(req,res){
    res.sendFile(path.join(process.cwd(),'./index.html'));
});

server.listen(8080);

index.html

<script>
        var btn = document.getElementById('btn1');
        btn.addEventListener('click',function(){
            var socket = io.connect('http://127.0.0.1:8080/ws',{
                reconnection: false
            });
            socket.on('connect',function(){
                // 發起「腳手架安裝」請求
                socket.emit('b:message',{});

                socket.on('s:message',function(d){
                    console.log(d);
                });

            });

            socket.on('error',function(err){
                console.log(err);
            })
        });
    </script>

pm2.json

{
  "apps": [
    {
      "name": "ws",
      "script": "./app.js",
      "env": {
        "NODE_ENV": "development"
      },
      "env_production": {
        "NODE_ENV": "production"
      },
      "instances": 4,
      "exec_mode": "cluster",
      "max_restarts" : 3,
      "restart_delay" : 5000,
      "log_date_format" : "YYYY-MM-DD HH:mm Z",
      "combine_logs" : true
    }
  ]
}

這樣，執行命令pm2 start pm2.json便可開啓服務，訪問127.0.0.1:8080/page，點擊按鈕發起ws鏈接，觀察控制檯便可。

下圖清晰顯示了socket.io握手的錯誤：

可見在websocket鏈接創建以前多出了3個xhr請求，而websocket鏈接創建失敗後又多出了幾個xhr請求，同時最後兩個xhr請求失敗了。

socket.io沒有采用直接創建websocket鏈接的粗暴方式，而是首先經過http請求（xhr）訪問服務端的相關輪訓配置信息以及sid。此處sid相似sessionID，可是它惟一標識鏈接，可理解爲socketId，之後每次http請求cookie中都必須攜帶sid（httponly）；

第2、三個請求用於確認鏈接，在socket.io中，post請求是客戶端發送消息給服務端的惟一形式，並且post響應必定是「ok」，它的「content-length」必定爲2；而get請求主要用於輪訓，同時獲取服務端的相關消息，這會在下文中有體現；

第四個websocket鏈接請求失敗，這主要是因爲與後端http握手失敗形成的；

第五個請求爲xhr方式的post請求，它是做爲websocket通道創建失敗後的一種兼容性處理，上文講述了socket.io的post請求只在客戶端須要發送消息給服務端時纔會使用，所以，爲了證明咱們查看消息體：

可見，它攜帶了客戶端發出的消息類型b:message,同時包含消息體{}空對象。對應的，服務端返回「OK」；

第六個請求爲xhr方式的get請求，用來獲取服務端對第五個請求的響應。

至此，大體分析了socket.io創建鏈接的大體過程以及鏈接創建失敗後如何兜底的方案，下面分析爲什麼出現握手失敗的問題。

緣由何在

實例中pm2主進程開啓了4個工做進程，由主進程偵聽8080端口並分發請求給工做進程。pm2進程在分發請求的階段採用了某種算法的均衡，如round-robin或者其餘hash方式（但不是iphash），所以在socket.io客戶端鏈接創建階段發送的多個xhr請求，會被pm2定位到不一樣的worker進程中。前文中提到每一個xhr請求都會攜帶sid字段標識當前鏈接，所以當一個攜帶sid字段的請求被pm2定位到另外一個與該鏈接無關的worker時，就會形成請求失敗，返回{"code":1,"message":"Session ID unknown"}錯誤；即便前三次xhr握手成功，進入websocket鏈接升級階段，負責偵聽update事件的worker也每每不是以前的那個worder，所以致使websocket鏈接創建失敗。

一言以蔽之，客戶端屢次請求的服務端進程不是同一個進程才致使的ws鏈接沒法成功創建。
那麼如何才能解決呢？最簡單的方案就是確保客戶端的每次請求均可以定位到同一個服務進程便可。固然，分佈式session一樣能夠解決問題，依託第三方緩存相似redis並配合一致性hash算法，確保全部服務進程均可以獲取到鏈接信息，相互配合完成鏈接創建。但這也僅僅是做者在理論上分析的一種實現方式，並無測試經過，由於這種分佈式架構不只實現繁雜並且引入了相關依賴redis，不太可取。

那麼下文主要針對確保客戶端的每次請求均可以定位到同一個服務進程這一點實現解決方案。

多種實現

官方實現

官方提供了一種比較輕便的架構：nginx反向代理+iphash

咱們的示例demo中的http服務器只偵聽8080端口，所以必須由pm2分發請求，不然會出現端口占用的錯誤發生。可是，官方的解決方案是每一個進程的socket.io服務器建立不一樣端口的http服務器，專一用於http握手和升級，由nginx作握手請求的代理。並且針對nginx必須設置iphash，保證同一個客戶端的屢次請求定位到後端同一個服務進程。

這樣，示例demo中會佔用5個端口，其中8080端口爲公用的http服務器使用，其餘四個端口則只用於ws鏈接握手。可是這四個端口卻如何選取呢？爲了保證擴展性以及順序性，採用與pm2相兼容的方案。pm2會爲每一個worker進程分配一個id，而且將該id綁定到進程的環境變量中，那麼咱們就能夠利用該worker id生成4個不一樣的端口號。

app.js

var path = require('path');
var app = require('express')(),
    server = require('http').createServer(app),
    port = 3131 + parseInt(process.env.NODE_APP_INSTANCE),
    io = require('socket.io')(port);

io
  .on('connection', function(socket) {
      socket.on('disconnect', function() {
          console.log('/: disconnect-------->')
      });

      socket.on('b:message', function() {
          socket.emit('s:message', '/: '+port);
          console.log('/: '+port)
      });
  });

io.of('/ws')
  .on('connection', function(socket) {
    socket.on('disconnect', function() {
        console.log('disconnect-------->')
    });

    socket.on('b:message', function() {
        socket.emit('s:message', port);
    });
});

app.get('/abc',function(req,res){
    res.sendFile(path.join(process.cwd(),'./index.html'));
});

server.listen(8080);

index.html

<script>
        var btn = document.getElementById('btn1');
        btn.addEventListener('click',function(){
            var socket = io.connect('http://ws.vd.net/ws',{
                reconnection: false
            });
            socket.on('connect',function(){
                // 發起「腳手架安裝」請求
                socket.emit('b:message',{a:1});

                socket.on('s:message',function(d){
                    console.log(d);
                });

            });

            socket.on('error',function(err){
                console.log(err);
            })
        });
    </script>

nginx.conf

upstream io_nodes {
      ip_hash;
      server 127.0.0.1:3131;
      server 127.0.0.1:3132;
      server 127.0.0.1:3133;
      server 127.0.0.1:3134;
    }
    server {
        listen 80;
        server_name ws.vd.net;
        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://io_nodes;
        }
  }

在本機綁定hosts地址後開啓nginx服務，同時開啓服務器，點擊按鈕創建ws鏈接成功。

服務端路由

服務端路由，意義在於「服務端作worker的負載均衡，並將選擇的worker ip和端口渲染在頁面，以後瀏覽器的全部ws鏈接默認鏈接到對應 ip:port的服務器中」。這樣只要是服務端渲染的頁面均可以採用這種方式實現。

若是頁面採用前端異步渲染，仍能夠採用這種方式，不過首先經過xhr請求向服務端獲取須要握手的http服務器的ip和端口，而後在進行ws鏈接。

服務端路由的前提仍然是須要針對每一個ws服務器分配一個端口，只不過去掉nginx由服務端作ip hash。採用服務端路由架構清晰，並且實現容易，兼容性好。

上帝進程路由

此處的上帝進程即爲主進程，相似pm2進程。上帝進程路由則是在上帝進程層面上作請求的定向分發，保證請求主機和進程的一致性。在上帝進程中，針對每一個請求的ip作hash，並對每個ws服務器建立單獨的http服務器用於握手升級。

簡易代碼:

var express = require('express'),
    cluster = require('cluster'),
    net = require('net'),
    sio = require('socket.io');

var port = 3000,
    num_processes = require('os').cpus().length;

if (cluster.isMaster) {
    var workers = [];

    var spawn = function(i) {
        workers[i] = cluster.fork();
        workers[i].on('exit', function(code, signal) {
            console.log('respawning worker', i);
            spawn(i);
        });
    };

    for (var i = 0; i < num_processes; i++) {
        spawn(i);
    }

    // ip hash
    var worker_index = function(ip, len) {
        var s = '';
        for (var i = 0, _len = ip.length; i < _len; i++) {
            if (!isNaN(ip[i])) {
                s += ip[i];
            }
        }

        return Number(s) % len;
    };

    var server = net.createServer({ pauseOnConnect: true }, function(connection) {
        var worker = workers[worker_index(connection.remoteAddress, num_processes)];
        worker.send('sticky-session:connection', connection);
    }).listen(port);
} else {
    // worker
    var app = new express();

    // handshake server.
    var server = app.listen(0, 'localhost'),
        io = sio(server);

    process.on('message', function(message, connection) {
        if (message !== 'sticky-session:connection') {
            return;
        }

        server.emit('connection', connection);

        connection.resume();
    });
}

總結

本文實現了三種解決方案，歸根到底就是「ip hash」，不一樣點在於在請求處理的不一樣階段作ip hash。

能夠在請求處理最前端作iphash，即nginx方式，這也就是第一種方案；能夠在請求處理的第二層分發處作iphash，即上帝進程路由的方式，即第三種；也能夠在請求處理的終端作iphash，即服務端路由的方式，也就是第二種；同時共享session也一樣能夠實現，藉助socket.io-redis模塊也能夠實現。