欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

socket.io與pm2(cluster)集群搭配的解決方案

 更新時間:2017年06月02日 10:55:08   作者:RoyalRover  
這篇文章主要給大家介紹了關(guān)于socket.io與pm2(cluster)集群搭配的解決方案,文中介紹的非常詳細,對大家具有一定的參考學習價值,需要的朋友們下面跟著小編一起來看看吧。

socket.io與cluster

在線上系統(tǒng)中,需要使用node的多進程模型,我們可以自己實現(xiàn)簡易的基于cluster模式的socket分發(fā)模型,也可以使用比較穩(wěn)定的pm2這樣進程管理工具。在常規(guī)的http服務(wù)中,這套模式一切正常,可是一旦server中集成了socket.io服務(wù)就會導致ws通道建立失敗,即使通過backup的polling方式仍會出現(xiàn)時斷時連的現(xiàn)象,因此我們需要解決這種問題,讓socket.io充分利用多核。

在這里之所以提到socket.io而未說websocket服務(wù),是因為socket.io在封裝websocket基礎(chǔ)上又保證了可用性。在客戶端未提供websocket功能的基礎(chǔ)上使用xhr polling、jsonp或forever iframe的方式進行兼容,同時在建立ws連接前往往通過幾次http輪訓確保ws服務(wù)可用,因此socket.io并不等于websocket。再往底層深入研究,socket.io其實并沒有做真正的websocket兼容,而是提供了上層的接口以及namespace服務(wù),真正的邏輯則是在“engine.io”模塊。該模塊實現(xiàn)握手的http代理、連接升級、心跳、傳輸方式等,因此研究engine.io模塊才能清楚的了解socket.io實現(xiàn)機制。

場景重現(xiàn)

服務(wù)端采用express+socket.io的組合方案,搭配pm2的cluster模式,實現(xiàn)一個簡易的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(){
    // 發(fā)起“腳手架安裝”請求
    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
 }
 ]
}

這樣,執(zhí)行命令pm2 start pm2.json即可開啟服務(wù),訪問127.0.0.1:8080/page,點擊按鈕發(fā)起ws連接,觀察控制臺即可。

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


可見在websocket連接建立之前多出了3個xhr請求,而websocket連接建立失敗后又多出了幾個xhr請求,同時最后兩個xhr請求失敗了。

socket.io沒有采用直接建立websocket連接的粗暴方式,而是首先通過http請求(xhr)訪問服務(wù)端的相關(guān)輪訓配置信息以及sid。此處sid類似sessionID,但是它唯一標識連接,可理解為socketId,以后每次http請求cookie中都必須攜帶sid(httponly);

第二、三個請求用于確認連接,在socket.io中,post請求是客戶端發(fā)送消息給服務(wù)端的唯一形式,而且post響應(yīng)一定是“ok”,它的“content-length”一定為2;而get請求主要用于輪訓,同時獲取服務(wù)端的相關(guān)消息,這會在下文中有體現(xiàn);

第四個websocket連接請求失敗,這主要是由于與后端http握手失敗造成的;

第五個請求為xhr方式的post請求,它是作為websocket通道建立失敗后的一種兼容性處理,上文講述了socket.io的post請求只在客戶端需要發(fā)送消息給服務(wù)端時才會使用,因此,為了證實我們查看消息體:

可見,它攜帶了客戶端發(fā)出的消息類型b:message,同時包含消息體{}空對象。對應(yīng)的,服務(wù)端返回“OK”;

第六個請求為xhr方式的get請求,用來獲取服務(wù)端對第五個請求的響應(yīng)。

至此,大致分析了socket.io建立連接的大致過程以及連接建立失敗后如何兜底的方案,下面分析為何出現(xiàn)握手失敗的問題。

原因何在

實例中pm2主進程開啟了4個工作進程,由主進程偵聽8080端口并分發(fā)請求給工作進程。pm2進程在分發(fā)請求的階段采用了某種算法的均衡,如round-robin或者其他hash方式(但不是iphash),因此在socket.io客戶端連接建立階段發(fā)送的多個xhr請求,會被pm2定位到不同的worker進程中。前文中提到每個xhr請求都會攜帶sid字段標識當前連接,因此當一個攜帶sid字段的請求被pm2定位到另一個與該連接無關(guān)的worker時,就會造成請求失敗,返回{"code":1,"message":"Session ID unknown"}錯誤;即使前三次xhr握手成功,進入websocket連接升級階段,負責偵聽update事件的worker也往往不是之前的那個worder,因此導致websocket連接建立失敗。

一言以蔽之,客戶端多次請求的服務(wù)端進程不是同一個進程才導致的ws連接無法成功建立。那么如何才能解決呢?最簡單的方案就是確??蛻舳说拿看握埱蠖伎梢远ㄎ坏酵粋€服務(wù)進程即可。當然,分布式session同樣可以解決問題,依托第三方緩存類似redis并配合一致性hash算法,確保所有服務(wù)進程都可以獲取到連接信息,相互配合完成連接建立。但這也僅僅是作者在理論上分析的一種實現(xiàn)方式,并沒有測試通過,因為這種分布式架構(gòu)不僅實現(xiàn)繁雜而且引入了相關(guān)依賴redis,不太可取。

那么下文主要針對確??蛻舳说拿看握埱蠖伎梢远ㄎ坏酵粋€服務(wù)進程這一點實現(xiàn)解決方案。

多種實現(xiàn)

官方實現(xiàn)

官方提供了一種比較輕便的架構(gòu):nginx反向代理+iphash

我們的示例demo中的http服務(wù)器只偵聽8080端口,因此必須由pm2分發(fā)請求,否則會出現(xiàn)端口占用的錯誤發(fā)生。但是,官方的解決方案是每個進程的socket.io服務(wù)器創(chuàng)建不同端口的http服務(wù)器,專注用于http握手和升級,由nginx做握手請求的代理。而且針對nginx必須設(shè)置iphash,保證同一個客戶端的多次請求定位到后端同一個服務(wù)進程。

這樣,示例demo中會占用5個端口,其中8080端口為公用的http服務(wù)器使用,其他四個端口則只用于ws連接握手。但是這四個端口卻如何選取呢?為了保證擴展性以及順序性,采用與pm2相兼容的方案。pm2會為每個worker進程分配一個id,并且將該id綁定到進程的環(huán)境變量中,那么我們就可以利用該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(){
    // 發(fā)起“腳手架安裝”請求
    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服務(wù),同時開啟服務(wù)器,點擊按鈕建立ws連接成功。

服務(wù)端路由

服務(wù)端路由,意義在于“服務(wù)端做worker的負載均衡,并將選擇的worker ip和端口渲染在頁面,之后瀏覽器的所有ws連接默認連接到對應(yīng) ip:port的服務(wù)器中”。這樣只要是服務(wù)端渲染的頁面都可以采用這種方式實現(xiàn)。

如果頁面采用前端異步渲染,仍可以采用這種方式,不過首先通過xhr請求向服務(wù)端獲取需要握手的http服務(wù)器的ip和端口,然后在進行ws連接。

服務(wù)端路由的前提仍然是需要針對每個ws服務(wù)器分配一個端口,只不過去掉nginx由服務(wù)端做ip hash。采用服務(wù)端路由架構(gòu)清晰,而且實現(xiàn)容易,兼容性好。

上帝進程路由

此處的上帝進程即為主進程,類似pm2進程。上帝進程路由則是在上帝進程層面上做請求的定向分發(fā),保證請求主機和進程的一致性。在上帝進程中,針對每個請求的ip做hash,并對每一個ws服務(wù)器創(chuàng)建單獨的http服務(wù)器用于握手升級。

簡易代碼:

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();
 });
}

總結(jié)

本文實現(xiàn)了三種解決方案,歸根到底就是“ip hash”,不同點在于在請求處理的不同階段做ip hash。

可以在請求處理最前端做iphash,即nginx方式,這也就是第一種方案;

可以在請求處理的第二層分發(fā)處做iphash,即上帝進程路由的方式,即第三種;

也可以在請求處理的終端做iphash,即服務(wù)端路由的方式,也就是第二種;

同時共享session也同樣可以實現(xiàn),借助socket.io-redis模塊也可以實現(xiàn)。

好了,以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作能帶來一定的幫助,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

相關(guān)文章

  • Nodejs對postgresql基本操作的封裝方法

    Nodejs對postgresql基本操作的封裝方法

    今天小編就為大家分享一篇Nodejs對postgresql基本操作的封裝方法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2019-02-02
  • node.js操作mongoDB數(shù)據(jù)庫示例分享

    node.js操作mongoDB數(shù)據(jù)庫示例分享

    這里給大家分享的是node.js操作mongoDB數(shù)據(jù)庫的示例,包括連接數(shù)據(jù)庫、插入數(shù)據(jù)、關(guān)閉數(shù)據(jù)庫、讀取數(shù)據(jù)、插入數(shù)據(jù)等方面,十分的全面,這里推薦給需要的小伙伴們。
    2014-11-11
  • node.js實現(xiàn)簡單登錄注冊功能

    node.js實現(xiàn)簡單登錄注冊功能

    這篇文章主要為大家詳細介紹了node.js實現(xiàn)簡單登錄注冊功能,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2022-04-04
  • Node.js設(shè)置CORS跨域請求中多域名白名單的方法

    Node.js設(shè)置CORS跨域請求中多域名白名單的方法

    這篇文章主要介紹了Node.js設(shè)置CORS跨域請求中多域名白名單的方法,文中通過示例代碼介紹的非常詳細,相信對大家具有一定的參考價值,需要的朋友們下面來一起看看吧。
    2017-03-03
  • 教你如何使用node.js制作代理服務(wù)器

    教你如何使用node.js制作代理服務(wù)器

    本文介紹了如何使用node.js制作代理服務(wù)器,圖文并茂,十分的詳細,代碼很簡潔易懂,這里推薦給大家。
    2014-11-11
  • NVM切換不同版本node的實現(xiàn)步驟

    NVM切換不同版本node的實現(xiàn)步驟

    nvm是Node.js的版本管理器,可以讓我們輕松地在不同的Node.js版本之間進行切換,本文就來介紹一下NVM切換不同版本node的實現(xiàn)步驟,感興趣的可以了解一下
    2023-12-12
  • 深入理解 Koa 框架中間件原理

    深入理解 Koa 框架中間件原理

    koa是目前node里最流行的web框架。這篇文章主要介紹了理解 Koa 框架中間件原理,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2018-10-10
  • Node.js 利用cheerio制作簡單的網(wǎng)頁爬蟲示例

    Node.js 利用cheerio制作簡單的網(wǎng)頁爬蟲示例

    本篇文章主要介紹了Node.js 利用cheerio制作簡單的網(wǎng)頁爬蟲示例,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2018-03-03
  • nodejs實現(xiàn)UDP組播示例方法

    nodejs實現(xiàn)UDP組播示例方法

    這篇文章主要介紹了nodejs實現(xiàn)UDP組播示例方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2019-11-11
  • Node.js模擬發(fā)起http請求從異步轉(zhuǎn)同步的5種用法

    Node.js模擬發(fā)起http請求從異步轉(zhuǎn)同步的5種用法

    這篇文章主要介紹了Node.js模擬發(fā)起http請求從異步轉(zhuǎn)同步的5種方法,下面總結(jié)了幾個常見的庫 API 從異步轉(zhuǎn)同步的幾種方法。需要的朋友可以參考下
    2018-09-09

最新評論