Express.js多核心机器（PM2部署）下全局变量方案对比咨询

Great question—this is a super common point of confusion when scaling Node.js apps with cluster mode (like PM2’s cluster setup). Let’s break down both approaches, their pros and cons specifically in a multi-core environment:

This is the "quick and dirty" way to share your Sequelize instance, but it comes with some critical caveats in a clustered setup:

Pros #

• Simplicity: No need to require the DB file in every module that needs it—just reference global.db directly. It’s minimal code upfront.
• Low barrier to entry: If you’re new to Node.js modules, this feels intuitive at first glance.

Cons #

• Process-isolated globals = redundant DB connections: PM2’s cluster mode spawns separate worker processes (one per core typically), each with its own V8 runtime. The global object is not shared across these processes—each worker will initialize its own Sequelize instance. If you have 4 cores, that’s 4 separate DB connections (or connection pools) by default. Scale up to 8 cores, and you’re doubling that load on your database, which can lead to connection pool exhaustion and performance hits.
• Hidden dependencies: Global variables create "magic" dependencies—other modules use global.db without explicitly declaring where it comes from. This makes debugging a nightmare when something breaks, and tracking down which code modifies the global instance is nearly impossible in large codebases.
• Testing headaches: Isolating the DB instance for unit tests becomes tricky. You can’t easily swap the global db with a test-specific instance without messing with the global namespace, leading to flaky tests.
• Namespace pollution: If any other module (third-party or internal) also uses a global.db variable, you’ll get silent conflicts that are hard to diagnose.

This follows Node.js’s native module system, which is the community-recommended way to manage dependencies. Let’s clarify first: Node.js caches modules per process, so within a single worker, calling require('./db.js') multiple times will return the same Sequelize instance. But just like the global approach, each PM2 worker will still initialize its own instance when it loads the module.

Pros #

• Explicit dependencies: Every module that needs the DB explicitly requires it, making your code self-documenting. Anyone reading the code can immediately see where the DB instance comes from, which simplifies maintenance and onboarding.
• No global pollution: The DB instance lives within the module’s scope, so you don’t have to worry about naming conflicts with other code.
• Test-friendly: Mocking or replacing the DB instance for tests is straightforward. You can use tools like sinon or just override the module export in your test setup to use a test database.
• Follows best practices: This is the standard way to share state in Node.js. Most teams and open-source projects use this pattern, so it’s familiar to other developers you might collaborate with.

Cons #

• Still has redundant connections (by default): Just like the global approach, each worker gets its own Sequelize instance. However, this is easier to mitigate—you can configure Sequelize’s built-in connection pool (e.g., pool: { max: 3, min: 0, idle: 10000 }) to limit how many connections each worker opens, preventing database overload.
• Minor boilerplate: You have to add a require statement in every module that needs the DB, which is a small tradeoff for the benefits of explicit dependencies.

Quick Bonus Tip #

If you want to avoid per-worker DB instances entirely, you’d need to move the DB connection to the PM2 master process and have workers communicate with it via IPC (inter-process communication). This adds complexity, but it’s an option for apps where database connection limits are a strict constraint. For most apps though, configuring Sequelize’s connection pool per worker is a simpler, more practical solution.

内容的提问来源于stack exchange，提问作者shamon shamsudeen