Should I share Redis connection between files/modules?

Question

I'm developing a node.js app and I am in need of heavy Redis usage. The app will be clustered across 8 CPU cores.

Right now I have 100 concurrent connections to Redis because every worker per CPU has several modules running require('redis').createClient().

Scenario A:

file1.js:

var redis = require('redis').createClient();

file2.js

var redis = require('redis').createClient();

SCENARIO B:

redis.js

var redis = require('redis').createClient();

module.exports = redis;

file1.js

var redis = require('./redis');

file2.js

var redis = require('./redis');

Which approach is better: creating new Redis instance in every new file I introduce (scenario A) or creating one Redis connection globally (scenario B) and sharing this connection across all modules I have. What are drawbacks/benefits of each solution?

Thanks in advance!

Sweepstakes

maybe a connection pool would give you both of the two scenarios? – Settlement

@Settlement can you kindly give an example of that connection pool – Susurrant

Answer 1

When I face a question such as this I generally think about three basic questions.

1. Which is more readable?
2. Which allows better code reuse?
3. Which is more efficient?

Not necessarily in this order as it depends on the scenario, but I believe in this case all three of these questions are in favor of option B. If you ever needed to modify options for createClient, you would then need to edit them in every file which uses it. Which in option A is every file which uses redis, and option B is just redis.js. Also if a newer or different product comes out and you want to replace redis It would be feasible to make redis.js a wrapper for a different package or even a newer redis client substantially cutting down conversion time.

Globals are generally a bad thing, but in this example redis.js should not be storing mutable state, so there is no problem having a global/singleton in this context.

Lesialesion

Answer 2

Both Node and Redis can handle lots of connections pretty well, so that's not a problem.

In your situation, you're creating Redis connections at the startup of your application, so the number of connections you're setting up is limited (in the sense that after your application is started, the number of connections will be constant).

Situations where you'd want to reuse the same connection is in highly dynamic situations, for instance with an HTTP-server where you need to query Redis for every request. Creating a new connection for each request would be a waste of resources (creating and destroying connections all the time) and reusing one connection for each request would be preferable.

As for which of the two scenario's I'd prefer, I'm leaning towards Scenario A myself.

Assimilable

thats a good point but if you are scaling your node instance to 10 instances running and each instance has 2 connections, you are creating 20 connections, the approach A will be inefficient while scaling – Susurrant

@Susurrant assuming that all those connections will be used, why would it be inefficient? :) – Assimilable

this is why :) medium.com/@stockholmux/… – Susurrant

@Susurrant opening a connection is expensive, sure, but maintaining an open connection isn't. I also concur that it's silly to open 20 connections per process, but I don't see the issue of opening 2. In fact, there can be good reasons to open multiple connections, for instance if your app needs to be able to switch databases or if its using blocking operations. – Assimilable

Answer 3

You can create file to handle connection and functions with redis redis-con.js

const redis = require('redis');
let redisClient;
(async () => {
    redisClient = redis.createClient();

    redisClient.on("error", (error) => console.error(`Error Redis: ${error}`));

    await redisClient.connect();
})();

module.exports = redisClient;

Then you need to create function to handle set, get and del.

now, just import the connection

Biotechnology