# 连接池 作为一个专业的服务端开发工程师，我们必须要对连接池、线程池、内存池等有较深理解，并且有自己熟悉的库函数可以让我们轻松驾驭这些不同的`池子`。既然他们都叫某某池，那么他们从基础概念上讲，原理和目的几乎是一样的，那就是`复用`。 以连接池做引子，我们说说服务端工程师基础必修课。 从我们应用最多的HTTP连接、数据库连接、消息推送、日志存储等，所有点到点之间，都需要花样繁多的各色连接。为了传输数据，我们需要完成创建连接、收发数据、拆除连接。对并发量不高的场景，我们为每个请求都完整走这三步（短连接），开发工作基本只考虑业务即可，基本上也不会有什么问题。一旦挪到高并发应用场景，那么可能我们就要郁闷了。 你将会碰到下面几个常见问题： - 性能普遍上不去 - CPU大量资源被系统消耗 - 网络一旦抖动，会有大量TIME_WAIT产生，不得不定期重启服务或定期重启机器 - 服务器工作不稳定，QPS忽高忽低 这时候我们可以优化的第一件事情就是把短链接改成长连接。也就是改成创建连接、收发数据、收发数据...拆除连接，这样我们就可以减少大量创建连接、拆除连接的时间。从性能上来说肯定要比短连接好很多。但这里还是有比较大的浪费。 举例：请求进入时，直接分配数据库长连接资源，假设有80%时间在与关系型数据库通讯，20%时间是在与Nosql数据库通讯。当有50K个并行请求时，后端要分配50K*2=100K的长连接支撑请求。无疑这时候系统压力是非常大的。数据库在牛逼也抵不住滥用不是？ 连接池终于要出场了，它的解决思路是先把所有长连接存起来，谁需要使用，从这里取走，干完活立马放回来。那么按照这个思路，刚刚的50K的并发请求，最多占用后端50K的长连接就够了。省了一半啊有木有？ 在OpenResty中，所有具备set_keepalive的类、库函数，说明他都是支持连接池的。 来点代码，给大家提提神，看看连接池使用时的一些注意点，麻雀虽小，五脏俱全。 ~~~ server { location /test { content_by_lua_block { local redis = require "resty.redis" local red = redis:new() local ok, err = red:connect("127.0.0.1", 6379) if not ok then ngx.say("failed to connect: ", err) return end -- red:set_keepalive(10000, 100) -- 坑① ok, err = red:set("dog", "an animal") if not ok then -- red:set_keepalive(10000, 100) -- 坑② return end -- 坑③ red:set_keepalive(10000, 100) } } } ~~~ - 坑①：只有数据传输完毕了，才能放到池子里，系统无法帮你自动做这个事情 - 坑②：不能把状态未知的连接放回池子里，你不知道这个连接后面会触发什么错误 - 坑③：逗你玩，这个不是坑，是正确的 尤其是掉进了第二个坑，你一定会莫名抓狂。不信的话，你就自己模拟试试，老带劲了。 理解了连接池，那么线程池、内存池，就应该都明白了，只是存放的东西不一样，思想没有任何区别。