如何在Node.js集群间共享资源？集群Worker数据库连接复用疑问

云原生阿岚

2026-5-21

Problem Description

I'm using Node.js's cluster module for a multi-process service, but I've noticed that every worker process initializes a separate MySQL connection pool when loading db.js. Here's my code:

index.js

const cluster = require('cluster');
const database = require('./db.js');
if (cluster.isMaster) {
  cluster.fork();
  cluster.fork();
} else {
  // Worker process business logic
}

db.js

const mysql = require('mysql');
const pool = new mysql.Pool(config); // Assume `config` is pre-configured DB parameters
module.exports = function(query){
  return pool.query(query);
}

My understanding is that each worker spawns its own connection pool, which leads to excessive database connections and wasted resources. I want to know how to share a single connection pool across all cluster workers to avoid redundant pool creation.

Answer

Great question—this is a common pain point when working with Node.js clusters since worker processes have isolated memory spaces, so you can't directly share JavaScript objects like connection pools between them. Let's break down three practical solutions, each with tradeoffs depending on your use case:

1. Let the Master Process Manage the Connection Pool

The cleanest way to share a single pool is to have only the master process initialize it, then let workers send database queries to the master via inter-process communication (IPC). The master runs the query and sends the result back to the worker.

Here's how to adjust your code:

index.js

const cluster = require('cluster');
const database = require('./db.js');

if (cluster.isMaster) {
  // Master initializes the connection pool once
  const runQuery = database;

  // Listen for messages from workers
  cluster.on('fork', (worker) => {
    worker.on('message', async (msg) => {
      if (msg.type === 'db_query') {
        try {
          const result = await runQuery(msg.query);
          worker.send({ type: 'db_result', id: msg.id, result });
        } catch (err) {
          worker.send({ type: 'db_error', id: msg.id, error: err.message });
        }
      }
    });
  });

  cluster.fork();
  cluster.fork();
} else {
  // Worker-side query wrapper that uses IPC
  let queryCounter = 0;
  const dbQuery = (query) => {
    return new Promise((resolve, reject) => {
      const queryId = queryCounter++;
      // Send query request to master
      process.send({ type: 'db_query', id: queryId, query });

      // Listen for the master's response
      const handleResponse = (msg) => {
        if (msg.id === queryId) {
          process.removeListener('message', handleResponse);
          if (msg.type === 'db_result') {
            resolve(msg.result);
          } else {
            reject(new Error(msg.error));
          }
        }
      };
      process.on('message', handleResponse);
    });
  };

  // Use dbQuery in your worker logic instead of the original database export
  // Example: dbQuery('SELECT * FROM users').then(users => console.log(users))
}

db.js stays exactly as you have it—since only the master loads it, the pool is created once.

Pros: 100% connection pool sharing, no redundant connections.
Cons: Adds IPC overhead for every query, which can slow down high-throughput workloads.

2. Limit Connection Pool Size Per Worker

If you want to avoid IPC overhead, a simpler approach is to cap the number of connections per worker's pool. Calculate a reasonable limit based on your total allowed database connections and the number of workers you're running.

Modify db.js to set a smaller connectionLimit:

const mysql = require('mysql');
const pool = new mysql.Pool({
  ...config,
  connectionLimit: 3 // Adjust this based on worker count (total connections = workers * connectionLimit)
});
module.exports = function(query){
  return pool.query(query);
}

For example, if your database allows 20 concurrent connections and you run 5 workers, set connectionLimit to 4—this keeps total connections at 20, which stays within your DB's limits.

Pros: No IPC overhead, implementation is trivial.
Cons: You still have multiple pools, but you're controlling resource usage to avoid waste. This is the most common approach for production services.

3. Use an External Connection Pool Proxy

For larger distributed systems, you can offload connection management to an external proxy like ProxySQL. All workers connect to the proxy, which handles pooling and connection reuse with the database.

Pros: Complete decoupling of app processes and database connections, easy to scale workers or database instances independently.
Cons: Requires setting up and maintaining an additional service.

Final Recommendation

Go with Option 1 if you need strict resource control and don't mind minor IPC overhead.
Go with Option 2 if performance is a priority and you want a low-effort solution.
Go with Option 3 if you're building a large-scale system that needs flexible scaling.

内容的提问来源于stack exchange，提问作者d-_-b