Node.js Cluster真有必要吗？集群与非集群压测异常问题问询

看起来你遇到了一个挺让人困惑的情况——明明用集群模式利用了多核CPU，结果性能和单进程没区别，还一起在800RPS时崩溃。我来帮你拆解几个最可能的核心原因：

1. 重定向逻辑让Node的多核优势无法发挥 #

你的两个服务核心逻辑都是立刻返回重定向响应，这个操作本身CPU开销极低，几乎不占用Node的处理能力。这时候系统的瓶颈根本不在Node进程的CPU处理，而是在网络层面或者系统资源限制上——比如服务器的带宽、TCP连接数上限，或者操作系统的文件描述符限制。不管你开1个还是2个worker，这些外部瓶颈都会先把性能卡住在800RPS。

你可以先修改测试逻辑验证这一点：把重定向换成返回一段简单文本，比如：

app.get('/', function (req, res) {
  res.send('Hello from Node.js');
});

再跑一次压力测试，看看集群模式的性能会不会有明显提升。如果这时候集群能处理更多请求，说明之前的重定向逻辑完全掩盖了Node的多核优势。

2. 集群模式的负载分发可能未生效 #

仔细看你的集群代码：每个worker都在监听3001端口。理论上Node的cluster模块会让master进程接管端口，把新连接分发给各个worker，但你需要确认压力测试的流量真的被分发到了两个worker。

你可以在worker的请求处理逻辑里加个日志验证：

app.get('/', function (req, res) {
  console.log(`Worker ${cluster.worker.id} handled a request`);
  res.redirect('http://www.walla.co.il');
});

跑测试的时候观察两个worker的日志，如果只有一个worker在打印日志，说明负载分发没生效——可能是master进程没有正确接管端口，或者测试工具的连接方式（比如长连接）导致流量都集中到了同一个worker。

3. 操作系统的资源限制先触达瓶颈 #

当处理大量短连接（比如重定向这种立刻关闭的请求）时，服务器会产生大量处于TIME_WAIT状态的TCP连接。默认情况下操作系统对文件描述符（每个连接对应一个文件描述符）的限制很低（比如默认1024），当连接数达到上限，就无法接受新请求，直接崩溃。

你可以先检查服务器的文件描述符限制：

# 查看当前进程的限制
ulimit -n
# 查看系统全局限制
cat /proc/sys/fs/file-max

如果数值很低，需要调整：

• 临时调整：ulimit -n 65535
• 永久调整：修改/etc/security/limits.conf，添加：

  * soft nofile 65535
  * hard nofile 65535
  

另外，还可以优化TCP参数减少TIME_WAIT连接的积累：

# 允许复用TIME_WAIT状态的连接
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
# 快速回收TIME_WAIT状态的连接
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

4. 压力测试工具本身成了瓶颈 #

有时候不是后端性能不行，是测试工具先扛不住了。比如你用的ab、wrk或其他工具，本身的并发数、线程数设置不够，导致最多只能打到800RPS。

你可以检查测试工具的参数：比如用wrk的话，是不是加了足够多的线程和连接数；或者换另一个测试工具对比结果，看看是不是工具的限制导致了性能天花板。

内容的提问来源于stack exchange，提问作者Roy Hershko