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

一、介紹

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

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

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

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();   }   // 子進程退出監(jiān)聽   cluster.on('exit', (worker,code,signal) => {     console.log('worker process died,id',worker.process.pid)   }) } else {   // 給子進程標注進程名   process.title = `cluster 子進程 ${process.pid}`;   // Worker可以共享同一個 TCP 連接，這里是一個 http 服務器   http.createServer((req, res)=> {     res.end(`response from worker ${process.pid}`);   }).listen(3000);   console.log(`Worker ${process.pid} started`); }

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

二、cluster 事件

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

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

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

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

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

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

這些事件大多跟 child_process 模塊的事件相關，在進程間消息傳遞的基礎上完成的封裝。

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 進程通過 cluster.fork() 來創(chuàng)建 worker 進程，其實，cluster.fork() 內(nèi)部是通過 child_process.fork() 來創(chuàng)建子進程。也就是說：master 與 worker 進程是父、子進程的關系；其跟 child_process 創(chuàng)建的父子進程一樣是通過 IPC 通道進行通信的。

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

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

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

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

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

child.send(meeage, [sendHandle])

句柄是一種可以用來標識資源的引用，它的內(nèi)部包含了指向對象的文件描述符。例如句柄可以用來標識一個服務器端 socket 對象、一個客戶端 socket 對象、一個 UDP 套接字、一個管道等。 那么句柄發(fā)送跟我們直接將服務器對象發(fā)送給子進程有沒有什么差別？它是否真的將服務器對象發(fā)送給子進程？

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

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

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

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

// woker進程 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，通常來說，多個進程監(jiān)聽同個端口，系統(tǒng)會報 EADDRINUSE 異常。為什么 cluster 沒問題呢？

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

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

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

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

六、pm2 工作原理

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

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

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

其中 Satan.js 提供程序的退出、殺死等方法，God.js 負責維持進程的正常運行，God 進程啟動后一直運行，相當于 cluster 中的 Master進程，維持 worker 進程的正常運行。

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

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

以 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進程在執(zhí)行     God.clusters_db[clu.pm_id].status = 'online';   });      // 命令行中 kill pid 會觸發(fā)exit事件，process.kill不會觸發(fā)exit   cluster.on('exit', function(clu, code, signal) {     // 重啟進程 如果重啟次數(shù)過于頻繁直接標注為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; }

七、總結

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