nodejs + redis/mysql 连接池问题

NodeJS

上图中，nodejs共有俩连接，分别发送查询请求到redis服务器上。因为redis是单线程作业，不管两个查询任务是由一个连接发来还是多个连接发来，也不管任务是串行一前一后先后发送到服务器，还是并行的同时发送到服务器上，redis都将他们一个个按顺序执行，并通过当前连接返回给客户端(这里是nodejs)。nodejs接受到redis的返回后，也管不了并行不并行，都得等他nodejs的主线程空闲的时候才能来一个个处理服务器返回的数据。

所以单从上面结论来看，nodejs + redis只需要公用一个连接就可以了，所以是不需要用连接池的。

再来看看nodejs + mysql下的情况

不同的是mysql不是单线程服务的，也就是它可以并行处理多个查询请求。

如上图所示，mysql会为每个连接创建一个单独的线程来查询。不同于redis数据基本都在内存中，因为mysql会有大量的读取磁盘的IO操作，所以多个线程一起工作会比一个个查询要快。

但是nodejs又是单线程的，它能不能同时发送多个请求到mysql服务器上呢？

这里要理解nodejs的运作，虽然nodejs是一个主线程，但是它调用的IO指令等是通过另外的线程去做的，IO指令完成后就给主线程一个小任务片，也就是回调函数了。

这里有个很关键的点就是，nodejs主线程一个，但是IO线程会有多个。

因此如果用nodejs + mysql只用单个连接的话那么就利用不到mysql能同时服务多个查询的优势了。应该使用类似下图的运作方式，nodejs 使用多个连接来连接mysql。多连接是需要连接池的，有连接池就避免了每次连接都要去创建销毁的消耗了。

所以我们第一步的感觉认为Nodejs是单线程而不是需要连接池是错误的，使用不使用连接池，不光看客户端，还要看数据库服务器等。要全盘理解整个系统的运作模式才能下结论。了解服务器的运作模式，有没有阻塞操作，是否是多线程等。我想redis设计成单线程主要原因在于它的数据基本都在内存中，查询数据过程总不会产生阻塞过程，cpu也不会处于空闲状态。

全局连接断开重连问题

到这里还没完。综上面的分析，nodejs + mysql用线程池是没什么问题的。nodejs + redis只用单个连接就够。不过也还是有人建议需要连接池。为了说明问题得从代码着手。我们使用node-redis这个包来做例子。

例如新建了一个db.js

var redis = require("redis"),client = redis.createClient(6379, "127.0.0.1");module.exports = client;

上面的连接会在程序启动载入完后就连接上了。使用它的时候引入它就可以使用全局唯一的连接。

var db = require("db.js");exports.add = function(req, res, next) { db.get("keyName", function() {res.send("ok");});}

这里于是有这样的问题存在。

但此处全局只有一个连接，并且这个连接是程序启动的时候创建的。它不同于连接池中的连接那样运行时候动态创建。如果某个时候唯一的连接断掉了，程序又不会动态去创建连接，岂不是需要重新启动服务器才行。

看是来挺可怕，但好在这个问题是不存在的。因为redis的客户端会自动重新连接，所以不需要重新启动服务器。

但是因为连接断开那一小段时间，应用服务器不能正常对外服务，但是连接自动重连是需要一定的时间间隔的。例如一秒之后，所以这一秒之内系统是处在不能服务状态。

也正是基于上面这样的原因，于是就有连接redis使用连接池的做法。如果使用连接池来管理，当连接不可用的时候立即手动去创建新连接。和自动重连相比，一个是手动立即重连，一个是等到一定间隔重连。相对来说手动重连的时间更短，也就是说系统那1秒中不能服务的状态或许可以缩短成0.5秒。于是就有了使用连接池管理redis连接的做法。严格来说这个不能算是连接池，而是一个连接管理模块。

到这里最后的结论nodejs + mysql使用连接池更好， nodejs + redis可以使用也可以不用。