集翔网大网站建设,景观设计公司名字,建筑培训网安全员,泰安哪里有做网站app的Cluster简介
默认情况下#xff0c;Node.js不会利用所有的CPU#xff0c;即使机器有多个CPU。一旦这个进程崩掉#xff0c;那么整个 web 服务就崩掉了。
应用部署到多核服务器时#xff0c;为了充分利用多核 CPU 资源一般启动多个 NodeJS 进程提供服务#xff0c;这时就…Cluster简介
默认情况下Node.js不会利用所有的CPU即使机器有多个CPU。一旦这个进程崩掉那么整个 web 服务就崩掉了。
应用部署到多核服务器时为了充分利用多核 CPU 资源一般启动多个 NodeJS 进程提供服务这时就会使用到 NodeJS 内置的 Cluster 模块了。Cluster模块可以创建同时运行的子进程Worker进程同时共享同一个端口。每个子进程都有自己的事件循环、内存和V8实例。
NodeJS Cluster是基于Master-Worker模型的Master负责监控Worker的状态并分配工作任务Worker则负责执行具体的任务。Master和Worker之间通过IPC进程间通信传递消息进程之间没有共享内存。 主进程也做叫Master进程子进程也叫做Worker进程下面会混用这两种叫法 HTTP服务器和Cluster
使用NodeJS构建http服务器非常简单代码如下
//app.js
const http require(http);
const pid process.pid;
http.createServer((req, res) {for (let i 1e7; i 0; i--) {}console.log(Handling request from ${pid});res.end(Hello from ${pid}\n);}).listen(8081, () {console.log(Started ${pid});});
****为了模拟一些实际的CPU工作我们执行了1000万次空循环启动服务之后可以使用浏览 器或curl向http://localhost:8080发送请求
curl localhost:8081
返回如下
Hello from 33720
使用autocannon压测服务器
安装autocannon
npm i -g autocannon
使用autocannon
autocannon -c 200 -d 10 http://localhost:8081
上面的命令将在10秒内为服务器发起200个并发连接
运行结果如下
┌─────────┬────────┬────────┬─────────┬─────────┬───────────┬───────────┬─────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼────────┼────────┼─────────┼─────────┼───────────┼───────────┼─────────┤
│ Latency │ 453 ms │ 651 ms │ 1003 ms │ 1829 ms │ 750.95 ms │ 208.08 ms │ 1968 ms │
└─────────┴────────┴────────┴─────────┴─────────┴───────────┴───────────┴─────────┘3k requests in 10.02s
Latency表示延迟可以看到平均延迟是750ms最慢的响应延迟接近2S在10S服务器一共接受了3000请求
使用Cluster模块进行扩展
const cluster require(node:cluster);
const http require(node:http);
const numCPUs require(node:os).cpus().length;
const process require(node:process);
if (cluster.isMaster) {//处理主进程逻辑masterProcess();
} else {//处理子进程逻辑childProcess();
}
function masterProcess() {console.log(Master ${process.pid} is running);for (let i 0; i numCPUs; i) {cluster.fork();}
}
function childProcess() {http.createServer((req, res) {for (let i 1e7; i 0; i--) {}console.log(Handling request from ${pid});res.end(Hello from ${pid}\n);}).listen(8081, () {console.log(Started ${pid});});
}将代码保存在 app.js 文件中并运行执行 $node app.js 。输出类似于下面这样
Master 33931 is running
Worker Started 33932
Worker Started 33935
Worker Started 33936
Worker Started 33934
Worker Started 33939
Worker Started 33933
Worker Started 33937
Worker Started 33938通过 isMaster 属性可以判断是否为 Master 进程Master进程中执行 cluster.fork()创建与CPU核心数相同的子进程。
fork() 是创建一个新的NodeJS进程就像通过命令行使用 $node app.js 运行一样会有很多进程运行 app.js 程序。
子进程创建和执行时和master一样导入cluster模块执行 if 语句。但子进程的 cluster.isMaster的值为 false
fork的过程如下 压测Cluster
autocannon -c 200 -d 10 [http://localhost:8081](http://localhost:8081/)
输出结果如下
┌─────────┬────────┬────────┬────────┬────────┬───────────┬──────────┬────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼────────┼────────┼────────┼────────┼───────────┼──────────┼────────┤
│ Latency │ 109 ms │ 136 ms │ 260 ms │ 282 ms │ 142.75 ms │ 32.09 ms │ 397 ms │
└─────────┴────────┴────────┴────────┴────────┴───────────┴──────────┴────────┘14k requests in 10.02s可以看到平均延迟为142ms最大的延迟为397ms服务器在10S内一共处理了14000个请求
使用Cluster之后性能提升大约4倍 14000次/10s 对比 3000次/10s
测试Cluster模块的可用性
为了测试服务的可用性我们会在子进程中使用setTimeout抛出一些错误
对masterProcess方法和childProcess进行修改
function masterProcess() {//...//监听子进程的退出事件cluster.on(exit, (worker, code) {//子进程异常退出if (code ! 0 !worker.exitedAfterDisconnect) {console.log(Worker ${worker.process.pid} crashed. Starting a new worker);cluster.fork();}});
}
function childProcess() {// 随机的1到3秒内等待一段时间然后抛出一个名为Ooops的错误setTimeout(() {throw new Error(Ooops);}, Math.ceil(Math.random() * 3) * 1000);//...
}在这段代码中一旦主进程接收到“退出”事件。我们检查code状态码和 worker.exitedAfterDisconnect标记来判断进程是否为异常退出然后启动一个新的Worker进程。当终止的Worker进程重新启动时其他工作进程仍然可以服务请求从而不会影响应用程序的可用性。
code是用于检查进程的退出码code为 0则表示正常退出如果不是则表示进程非正常退出。
worker.exitedAfterDisconnect是NodeJS中cluster模块Worker对象的一个属性用于指示工作进程是否在主进程调用其disconnect()方法后退出。
如果Worker进程成功地完成了disconnect过程并正常退出则worker.exitedAfterDisconnect将被设置为true。否则该属性将保持为false表示该进程已经以其他方式退出。
使用autocannon进行压测autocannon -c 200 -d 10 [http://localhost:8081](http://localhost:8081/)
结果如下
┌─────────┬────────┬────────┬─────────┬─────────┬───────────┬───────────┬─────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼────────┼────────┼─────────┼─────────┼───────────┼───────────┼─────────┤
│ Latency │ 101 ms │ 398 ms │ 1301 ms │ 1498 ms │ 466.99 ms │ 301.07 ms │ 2405 ms │
└─────────┴────────┴────────┴─────────┴─────────┴───────────┴───────────┴─────────┘14k requests in 10.03s
1k errors (0 timeouts)在14000个请求中有1000个出现错误服务的可用性大约为92%对于一个经常崩溃的应用程序来说它的可用性也不差
主进程和子进程通信
稍微更新一下之前的代码就能允许Master进程向Worker进程发送和接收消息Wordker进程也可以从Master进程接收和发送消息
function childProcess() {console.log(Worker ${process.pid} started);//监听主进程的消息process.on(message, function (message) {console.log(Worker ${process.pid} recevies message ${JSON.stringify(message)});});console.log(Worker ${process.pid} sends message to master...);//给主进程发消息process.send({ msg: Message from worker ${process.pid} });
}在子进程中使用 process.on(message, handler)方法注册一个监听器当主进程给这个子进程发送消息的时候会执行handler回调然后使用 process.send()向主进程发送消息
function masterProcess() {console.log(Master ${process.pid} is running);let workers [];// fork 子进程for (let i 0; i numCPUs; i) {const worker cluster.fork();workers.push(worker);// 监听子进程的消息worker.on(message, function (message) {console.log(Master ${process.pid} recevies message ${JSON.stringify(message)} from worker ${worker.process.pid});});}// 给每个子进程发送消息workers.forEach(function (worker) {console.log(Master ${process.pid} sends message to worker ${worker.process.pid}...);worker.send({ msg: Message from master ${process.pid} });}, this);}我们先监听子进程的message事件最后在Master进程给每个 Worker进程发送消息
输出会类似于下面这样
Master 88498 is running
Master 88498 sends message to worker 88500...
Master 88498 sends message to worker 88501...
Worker 88501 started
Worker 88501 sends message to master...
Master 88498 recevies message {msg:Message from worker 88501} from worker 88501
Worker 88501 recevies message {msg:Message from master 88498}
Worker 88500 started
Worker 88500 sends message to master...
Master 88498 recevies message {msg:Message from worker 88500} from worker 88500
Worker 88500 recevies message {msg:Message from master 88498}使用Cluster进行优雅的重启
当我们更新代码的时候可能需要重新启动NodeJS。重新启动应用程序时会出现一个小的空窗期在我们重启单进程的NodeJS过程中服务器会无法处理用户的请求
使用Cluster可以解决这个问题具体做法如下一次重新启动一个Worker剩下的Worker可以继续运行处理用户的请求。
在上面代码的基础上对masterProcess和childProcess进行修改
function masterProcess() {console.log(Master ${process.pid} is running);let workers [];// fork 子进程for (let i 0; i numCPUs; i) {const worker cluster.fork();workers.push(worker);}process.on(SIGUSR2, async () {restartWorker(0);function restartWorker(i) {if (i workers.length) return;const worker workers[i];console.log(Stopping worker: ${worker.process.pid});worker.disconnect(); //监听子进程的退出事件worker.on(exit, () {//判断子进程是否完成disconnect过程并正常退出if (!worker.exitedAfterDisconnect) return;const newWorker cluster.fork(); //[4]newWorker.on(listening, () {//当新的子进程开始监听端口//重启下一个子进程restartWorker(i 1);});});}});
}
function childProcess() {http.createServer((req, res) {console.log(Worker : , Worker ${process.pid});res.writeHead(200);res.end(hello world\n);}).listen(8000);console.log(Worker ${process.pid} started);
}masterProcess方法新增了process.on(SIGUSR2, callback), SIGUSR2是一种信号通常用于向一个进程发送自定义的指令比如要求应用程序执行某些操作如重启、重新加载配置文件等。
当主进程接收到SIGUSR2信号时它会遍历所有Workder进程并调用disconnect方法然后监听子进程的退出事件。
Workder进程退出之后Master进程就会重新创建新的Workder进程并等待其开始监听端口。然后重启下一个Workder进程。
childProcess 方法则是启动了一个Http服务器。
通过这种方式整个应用程序可以在不中断服务的情况下进行平滑重启从而实现无缝升级和维护。
在生产环境中我们一般会使用PM2来进行进程管理PM2基于cluster提供负载均衡、过程监控、零停机重启和其他功能。
总结
本文介绍了使用NodeJS Cluster模块进行多进程处理的方法包括如何创建子进程、压测Cluster、主进程和子进程通信、以及如何使用Cluster进行优雅的重启。
在生产环境中我们一般会使用PM2来进行进程管理PM2基于cluster提供负载均衡、过程监控、零停机重启和其他功能。下篇文章会介绍一下PM2敬请期待吧
