Nodejs + Redis/mysql Connection pooling issues

Nodejs + Redis/mysql Connection pooling issues

Requires no connection pooling

The purpose of connection pooling is to reduce the overhead associated with each temporary connection. Initially, Nodejs runs on a single thread, it cannot use multiple connections at the same time, at first glance it does not require a connection pool. But this is just our initial subconscious feeling, below our detailed analysis to see this conclusion is wrong.

Start with a simple redis first. The Redis server is also running on a single thread. Both are single threaded and look firmer without the need to connect the pool to the conclusion. From the detailed image to see Nodejs connection to Redis with connection pooling has no meaning. In  , Nodejs has two connections, sending query requests to the REDIS server separately. Because Redis is a single-threaded job, regardless of whether two query tasks are sent from a single connection or multiple connections, and whether the task is delivered to the server sequentially or in parallel, Redis executes them one by one and returns it to the client via the current connection ( This is Nodejs). Nodejs accept the return of Redis, also can not control parallel, all have to wait for his Nodejs the main thread idle time to deal with the data returned by the server.   So single from the above conclusion, Nodejs + Redis only need a common connection, so it is not necessary to use the connection pool.   Look at the situation under Nodejs + MySQL   The difference is that MySQL is not a single-threaded service, that is, it can process multiple query requests in parallel. As shown, MySQL creates a separate thread query for each connection. Unlike Redis data, which is basically in memory, because MySQL has a large number of IO operations that read the disk, multiple threads work together faster than queries.   But Nodejs is single-threaded, can it send multiple requests to the MySQL server at the same time? Here to understand the operation of the Nodejs, although Nodejs is a main thread, but it calls the IO instructions and so on by another thread to do, the IO command after the completion of the main thread a small task piece, that is, the callback function. One of the key points here is that the Nodejs main thread is one, but the IO thread will have multiple. So if you use Nodejs + MySQL only with a single connection then you can not use MySQL to serve multiple queries at the same time advantage. You should use a similar mode of operation, NODEJS using multiple connections to connect to MySQL. Multiple connections are required to connect pools, and there is a connection pool that avoids every connection to create the destruction consumed.   So our first step of feeling that Nodejs is single-threaded instead of needing connection pooling is wrong, using no connection pooling, not just looking at the client, but also looking at the database server. It is necessary to understand the whole system operation mode to conclude. Understand the operating mode of the server, there is no blocking operation, whether it is multithreading, etc. I think the main reason for Redis to be single-threaded is that its data is basically in memory, and the process of querying data does not always create a blocking process and the CPU is not idle.   Global Connection Disconnect reconnection questionThe question is not over yet. The above analysis, Nodejs + MySQL with the thread pool is no problem. Nodejs + Redis is sufficient only with a single connection. However, it is also recommended that you need a connection pool. To illustrate the problem, start with the code. We use the Node-redis package to do an example.   For example, a new db.js

var redis = require ("Redis"),    = redis.createclient (6379, "127.0.0.1"= client;

The connection above will be connected when the program starts loading. When you use it, you can use a globally unique connection when you introduce it.

var db = require ("db.js"function(req, res, next) {       db.get (function () {        res.send ("OK");     });}

So there is such a problem here. But there is only one connection globally, and this connection is created when the program starts. It is created dynamically, unlike connections in connection pooling. If the only connection is broken at some point, and the program does not dynamically create the connection, it is not necessary to restart the server.   looks scary, but fortunately the problem is not there. Because Redis clients are automatically reconnected, there is no need to restart the server. However, because the connection is disconnected for a short period of time, the application server will not be able to serve the external, but the connection automatic reconnection requires a certain time interval. For example, after one second, the system is in a state of no service within this second.   is based on the above reasons, so there is the practice of connecting redis using connection pooling. If you use connection pooling to manage, manually create a new connection immediately when the connection is unavailable. Compared to automatic re-interconnection, one is a manual immediate re-connection, and one is to wait for a certain interval to re-connect. A relatively short time to manually re-connect, which means that the system's inability to service in 1 seconds may be shortened to 0.5 seconds. Then there is the practice of using connection pooling to manage redis connections. Strictly speaking, this is not a connection pool, but a connection management module.    Here's the final conclusion Nodejs + MySQL uses connection pooling better, Nodejs + Redis can be used or not.