如何在Linux上配置Node.js的集群模式

在Linux上配置Node.js的集群模式，说白了就是要把服务器的多核CPU充分调动起来。单进程跑Node虽然省心，但遇到高并发场景就容易捉襟见肘。还好Node.js内置了cluster模块，能帮你把进程“分身”成多个工人，每个工人负责处理一部分请求。下面咱们就一步步把这个流程走通。

1. 安装Node.js

先确认你的Linux系统里有没有Node.js。如果没有，走一遍这两行命令就好——这里用的是Node 14.x LTS版本，稳定可靠：

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt-get install -y nodejs

装完之后可以跑个node -v看看版本号，心里踏实。

2. 创建一个简单的Node.js应用

接下来写一个集群模式的样板。新建一个app.js，内容如下——别被代码吓到，核心逻辑很清晰：主进程（Master）根据CPU核心数fork出多个工作进程（Worker），每个工作进程都启动一个HTTP服务器，共享同一个端口（8000）。

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

这段代码的精妙之处在于：你不用手动管理端口冲突，Node.js的集群模块会自动把请求分发到各个Worker。当然，生产环境里还得考虑更复杂的负载均衡策略，但作为入门演示，这已经足够用了。

3. 运行应用

在终端中直接执行：

node app.js

如果一切顺利，你会看到类似这样的输出：

Master 1234 is running
Worker 1235 started
Worker 1236 started
Worker 1237 started
...

注意看，Worker的数量取决于你的CPU核心数。双核就两个，四核就四个，一个萝卜一个坑。

4. 验证集群模式

开浏览器或者用curl发几个请求试试：

curl http://localhost:8000

每次请求都应该返回“hello world”。你可以连续刷几次，然后观察终端日志——注意看每次请求是由哪个Worker响应的（虽然代码里没打印，但你可以自己加个console.log验证）。集群模式确实在工作，而且你基本感觉不到中断。

5. 监控和管理集群

手写集群代码做demo还行，真正上线跑的时候，你总不希望进程挂了还要手动重启。这时候就需要上工具了。最推荐的是pm2，它可以说集群管理的标配。

使用pm2管理集群

安装pm2：

npm install pm2 -g

然后启动应用，参数-i max表示按CPU核心数自动启动对应数量的实例：

pm2 start app.js -i max

接下来可以用pm2 status查看进程健康状态，用pm2 logs看实时日志。更贴心的是，如果某个Worker意外退出，pm2会自动再拉一个起来，省心不少。

另外还有个nodemon，主要用来开发时自动重启，跟集群模式搭配也挺好用，不过生产环境还是pm2更靠谱。

总结

到此为止，我们在Linux上完成了Node.js集群模式的实战配置。核心思路就三步：装好Node、写好集群代码、用pm2来托管。这样你的应用就能真正利用多核CPU的优势，并发能力直接翻倍。

当然，现实中的调优远不止这些——比如要小心内存泄漏、合理设置worker数、做好平滑重启等。但至少你现在已经有了一个牢固的起点。剩下的，就是多跑几轮压测，找到最适合你业务的那组参数。