本篇文章帶大家詳細(xì)了解一下Node.js中的集群，介紹一下cluster 事件，希望對大家有所幫助！

一、介紹

Node 在 v0.8 時直接引入了 cluster 模塊，用以解決多核 CPU 的利用率問題，同時也提供了較完善的 API，用以處理進(jìn)程的健壯性問題。

cluster 模塊調(diào)用 fork 方法來創(chuàng)建子進(jìn)程，該方法與 child_process 中的 fork 是同一個方法。 cluster 模塊采用的是經(jīng)典的主從模型，cluster 會創(chuàng)建一個 master，然后根據(jù)你指定的數(shù)量復(fù)制出多個子進(jìn)程，可以使用cluster.isMaster 屬性判斷當(dāng)前進(jìn)程是 master 還是 worker (工作進(jìn)程)。由 master 進(jìn)程來管理所有的子進(jìn)程，主進(jìn)程不負(fù)責(zé)具體的任務(wù)處理，主要工作是負(fù)責(zé)調(diào)度和管理。

cluster 模塊使用內(nèi)置的負(fù)載均衡來更好地處理線程之間的壓力，該負(fù)載均衡使用了 Round-robin 算法（也被稱之為循環(huán)算法）。當(dāng)使用 Round-robin 調(diào)度策略時，master accepts() 所有傳入的連接請求，然后將相應(yīng)的TCP請求處理發(fā)送給選中的工作進(jìn)程（該方式仍然通過 IPC 來進(jìn)行通信）。 官方使用實例如下所示

const cluster = require('cluster'); const cpuNums = require('os').cpus().length; const http = require('http');  if (cluster.isMaster) {   for (let i = 0; i < cpuNums; i++){     cluster.fork();   }   // 子進(jìn)程退出監(jiān)聽   cluster.on('exit', (worker,code,signal) => {     console.log('worker process died,id',worker.process.pid)   }) } else {   // 給子進(jìn)程標(biāo)注進(jìn)程名   process.title = `cluster 子進(jìn)程 ${process.pid}`;   // Worker可以共享同一個 TCP 連接，這里是一個 http 服務(wù)器   http.createServer((req, res)=> {     res.end(`response from worker ${process.pid}`);   }).listen(3000);   console.log(`Worker ${process.pid} started`); }

其實，cluster 模塊由 child_process 和 net 模塊的組合應(yīng)用，cluster 啟動時，會在內(nèi)部啟動 TCP 服務(wù)器，在 cluster.fork() 子進(jìn)程時，將這個 TCP 服務(wù)器端 socket 的文件描述符發(fā)送給工作進(jìn)程。如果工作進(jìn)程是通過 cluster.fork() 復(fù)制出來的，那么它的環(huán)境變量里就存在 NODE_UNIQUE_ID，如果工作進(jìn)程中存在 listen() 偵聽網(wǎng)絡(luò)端口的調(diào)用，它將拿到文件描述符，通過 SO_REUSEADDR 端口重用，從而實現(xiàn)多個子進(jìn)程共享端口。

二、cluster 事件

• fork：復(fù)制一個工作進(jìn)程后觸發(fā)該事件；

• online：復(fù)制好一個工作進(jìn)程后，工作進(jìn)程主動發(fā)送一條 online 消息給主進(jìn)程，主進(jìn)程收到消息后，觸發(fā)該事件；

• listening：工作進(jìn)程中調(diào)用 listen() （共享了服務(wù)器端 Socket）后，發(fā)送一條 listening 消息給主進(jìn)程，主進(jìn)程收到消息后，觸發(fā)該事件；

• disconnect：主進(jìn)程和工作進(jìn)程之間 IPC 通道斷開后會觸發(fā)該事件；

• exit：有工作進(jìn)程退出時會觸發(fā)該事件；

• setup：cluster.setupMaster() 執(zhí)行完后觸發(fā)該事件；

這些事件大多跟 child_process 模塊的事件相關(guān)，在進(jìn)程間消息傳遞的基礎(chǔ)上完成的封裝。

cluster.on('fork', ()=> {   console.log('fork 事件... '); })  cluster.on('online', ()=> {   console.log('online 事件... '); })  cluster.on('listening', ()=> {   console.log('listening 事件... '); })  cluster.on('disconnect', ()=> {   console.log('disconnect 事件... '); })  cluster.on('exit', ()=> {   console.log('exit 事件... '); })  cluster.on('setup', ()=> {   console.log('setup 事件... '); })

三、master 與 worker 通信

由以上可知，master 進(jìn)程通過 cluster.fork() 來創(chuàng)建 worker 進(jìn)程，其實，cluster.fork() 內(nèi)部是通過 child_process.fork() 來創(chuàng)建子進(jìn)程。也就是說：master 與 worker 進(jìn)程是父、子進(jìn)程的關(guān)系；其跟 child_process 創(chuàng)建的父子進(jìn)程一樣是通過 IPC 通道進(jìn)行通信的。

IPC 的全稱是 Inter-Process Communication，即進(jìn)程間通信，進(jìn)程間通信的目的是為了讓不同的進(jìn)程能夠互相訪問資源并進(jìn)行協(xié)調(diào)工作。Node 中實現(xiàn) IPC 通道的是管道（pipe）技術(shù)，具體實現(xiàn)由 libuv 提供，在 Windows 下由命名管道（named pipe）實現(xiàn)，*nix 系統(tǒng)則采用 Unix Domain Socket 實現(xiàn)。其變現(xiàn)在應(yīng)用層上的進(jìn)程間通信只有簡單的 message 事件和 send 方法，使用十分簡單。

父進(jìn)程在實際創(chuàng)建子進(jìn)程之前，會創(chuàng)建 IPC 通道并監(jiān)聽它，然后才真正創(chuàng)建出子進(jìn)程，并通過環(huán)境變量（NODE_CHANNEL_FD）告訴子進(jìn)程這個 IPC 通道的文件描述符。子進(jìn)程在啟動過程中，根據(jù)文件描述符去連接這個已存在的 IPC 通道，從而完成父子進(jìn)程之間的連接。

建立連接之后的父子進(jìn)程就可以進(jìn)行自由通信了。由于 IPC 通道是用命名管道或 Domain Socket 創(chuàng)建的，它們與網(wǎng)絡(luò) socket 的行為比較類似，屬于雙向通信。不同的是它們在系統(tǒng)內(nèi)核中就完成了進(jìn)程間的通信，而不用經(jīng)過實際的網(wǎng)絡(luò)層，非常高效。在 Node 中，IPC 通道被抽象為 Stream 對象，在調(diào)用 send 時發(fā)送數(shù)據(jù)（類似于 write ），接收到的消息會通過 message 事件（類似于 data）觸發(fā)給應(yīng)用層。

master 和 worker 進(jìn)程在 server 實例的創(chuàng)建過程中，是通過 IPC 通道進(jìn)行通信的，那會不會對我們的開發(fā)造成干擾呢？比如，收到一堆其實并不需要關(guān)心的消息？答案肯定是不會？那么是怎么做到的呢？

Node 引入進(jìn)程間發(fā)送句柄的功能，send 方法除了能通過 IPC 發(fā)送數(shù)據(jù)外，還能發(fā)送句柄，第二個參數(shù)為句柄，如下所示

child.send(meeage, [sendHandle])

句柄是一種可以用來標(biāo)識資源的引用，它的內(nèi)部包含了指向?qū)ο蟮奈募枋龇＠缇浔梢杂脕順?biāo)識一個服務(wù)器端 socket 對象、一個客戶端 socket 對象、一個 UDP 套接字、一個管道等。 那么句柄發(fā)送跟我們直接將服務(wù)器對象發(fā)送給子進(jìn)程有沒有什么差別？它是否真的將服務(wù)器對象發(fā)送給子進(jìn)程？

其實 send() 方法在將消息發(fā)送到 IPC 管道前，將消息組裝成兩個對象，一個參數(shù)是 handle，另一個是 message，message 參數(shù)如下所示

{   cmd: 'NODE_HANDLE',   type: 'net.Server',   msg: message }

發(fā)送到 IPC 管道中的實際上是要發(fā)送的句柄文件描述符，其為一個整數(shù)值。這個 message 對象在寫入到 IPC 管道時會通過 JSON.stringify 進(jìn)行序列化，轉(zhuǎn)化為字符串。子進(jìn)程通過連接 IPC 通道讀取父進(jìn)程發(fā)送來的消息，將字符串通過 JSON.parse 解析還原為對象后，才觸發(fā) message 事件將消息體傳遞給應(yīng)用層使用。在這個過程中，消息對象還要被進(jìn)行過濾處理，message.cmd 的值如果以 NODE_ 為前綴，它將響應(yīng)一個內(nèi)部事件 internalMessage ，如果 message.cmd 值為 NODE_HANDLE，它將取出 message.type 值和得到的文件描述符一起還原出一個對應(yīng)的對象。這個過程的示意圖如下所示

在 cluster 中，以 worker 進(jìn)程通知 master 進(jìn)程創(chuàng)建 server 實例為例子。worker 偽代碼如下：

// woker進(jìn)程 const message = {   cmd: 'NODE_CLUSTER',   type: 'net.Server',   msg: message }; process.send(message);

master 偽代碼如下：

worker.process.on('internalMessage', fn);

四、如何實現(xiàn)端口共享

在前面的例子中，多個 woker 中創(chuàng)建的 server 監(jiān)聽了同個端口 3000，通常來說，多個進(jìn)程監(jiān)聽同個端口，系統(tǒng)會報 EADDRINUSE 異常。為什么 cluster 沒問題呢？

因為獨立啟動的進(jìn)程中，TCP 服務(wù)器端 socket 套接字的文件描述符并不相同，導(dǎo)致監(jiān)聽到相同的端口時會拋出異常。但對于 send() 發(fā)送的句柄還原出來的服務(wù)而言，它們的文件描述符是相同的，所以監(jiān)聽相同端口不會引起異常。

這里需要注意的是，多個應(yīng)用監(jiān)聽相同端口時，文件描述符同一時間只能被某個進(jìn)程所用，換言之就是網(wǎng)絡(luò)請求向服務(wù)器端發(fā)送時，只有一個幸運的進(jìn)程能夠搶到連接，也就是說只有它能為這個請求進(jìn)行服務(wù)，這些進(jìn)程服務(wù)是搶占式的。

五、如何將請求分發(fā)到多個worker

• 每當(dāng) worker 進(jìn)程創(chuàng)建 server 實例來監(jiān)聽請求，都會通過 IPC 通道，在 master 上進(jìn)行注冊。當(dāng)客戶端請求到達(dá)，master 會負(fù)責(zé)將請求轉(zhuǎn)發(fā)給對應(yīng)的 worker；
• 具體轉(zhuǎn)發(fā)給哪個 worker？這是由轉(zhuǎn)發(fā)策略決定的，可以通過環(huán)境變量 NODE_CLUSTER_SCHED_POLICY 設(shè)置，也可以在 cluster.setupMaster(options) 時傳入，默認(rèn)的轉(zhuǎn)發(fā)策略是輪詢（SCHED_RR）；
• 當(dāng)有客戶請求到達(dá)，master 會輪詢一遍 worker 列表，找到第一個空閑的 worker，然后將該請求轉(zhuǎn)發(fā)給該worker；

六、pm2 工作原理

pm2 是 node 進(jìn)程管理工具，可以利用它來簡化很多 node 應(yīng)用管理的繁瑣任務(wù)，如性能監(jiān)控、自動重啟、負(fù)載均衡等。

pm2 自身是基于 cluster 模塊進(jìn)行封裝的， 本節(jié)我們主要 pm2 的 Satan 進(jìn)程、God Daemon 守護(hù)進(jìn)程 以及兩者之間的進(jìn)程間遠(yuǎn)程調(diào)用 RPC。

撒旦（Satan），主要指《圣經(jīng)》中的墮天使（也稱墮天使撒旦），被看作與上帝的力量相對的邪惡、黑暗之源，是God 的對立面。

其中 Satan.js 提供程序的退出、殺死等方法，God.js 負(fù)責(zé)維持進(jìn)程的正常運行，God 進(jìn)程啟動后一直運行，相當(dāng)于 cluster 中的 Master進(jìn)程，維持 worker 進(jìn)程的正常運行。

RPC（Remote Procedure Call Protocol）是指遠(yuǎn)程過程調(diào)用，也就是說兩臺服務(wù)器A，B，一個應(yīng)用部署在A 服務(wù)器上，想要調(diào)用 B 服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。同一機器不同進(jìn)程間的方法調(diào)用也屬于 rpc 的作用范疇。 執(zhí)行流程如下所示

每次命令行的輸入都會執(zhí)行一次 satan 程序，如果 God 進(jìn)程不在運行，首先需要啟動 God 進(jìn)程。然后根據(jù)指令，Satan 通過 rpc 調(diào)用 God 中對應(yīng)的方法執(zhí)行相應(yīng)的邏輯。

以 pm2 start app.js -i 4 為例，God 在初次執(zhí)行時會配置 cluster，同時監(jiān)聽 cluster 中的事件：

// 配置cluster cluster.setupMaster({   exec : path.resolve(path.dirname(module.filename), 'ProcessContainer.js') });  // 監(jiān)聽cluster事件 (function initEngine() {   cluster.on('online', function(clu) {     // worker進(jìn)程在執(zhí)行     God.clusters_db[clu.pm_id].status = 'online';   });      // 命令行中 kill pid 會觸發(fā)exit事件，process.kill不會觸發(fā)exit   cluster.on('exit', function(clu, code, signal) {     // 重啟進(jìn)程 如果重啟次數(shù)過于頻繁直接標(biāo)注為stopped     God.clusters_db[clu.pm_id].status = 'starting';     // 邏輯     // ...   }); })();

在 God 啟動后， 會建立 Satan 和 God 的rpc鏈接，然后調(diào)用 prepare 方法，prepare 方法會調(diào)用 cluster.fork 來完成集群的啟動

God.prepare = function(opts, cb) {   // ...   return execute(opts, cb); };  function execute(env, cb) {   // ...   var clu = cluster.fork(env);   // ...   God.clusters_db[id] = clu;      clu.once('online', function() {     God.clusters_db[id].status = 'online';     if (cb) return cb(null, clu);     return true;   });   return clu; }

七、總結(jié)

本文從 cluster 的基本使用、事件，到 cluster 的基本實現(xiàn)原理，再到 pm2 如何基于 cluster 進(jìn)行進(jìn)程管理，帶你從入門到深入原理以及了解其高階應(yīng)用，希望對你有幫助。