• 连接池

    连接池

    作为一个专业的服务端开发工程师，我们必须要对连接池、线程池、内存池等有较深理解，并且有自己熟悉的库函数可以让我们轻松驾驭这些不同的 池子。既然他们都叫某某池，那么他们从基础概念上讲，原理和目的几乎是一样的，那就是 复用。

    以连接池做引子，我们说说服务端工程师基础必修课。

    从我们应用最多的 HTTP 连接、数据库连接、消息推送、日志存储等，所有点到点之间，都需要花样繁多的各色连接。为了传输数据，我们需要完成创建连接、收发数据、拆除连接。对并发量不高的场景，我们为每个请求都完整走这三步（短连接），开发工作基本只考虑业务即可，基本上也不会有什么问题。一旦挪到高并发应用场景，那么可能我们就要郁闷了。

    你将会碰到下面几个常见问题：

    • 性能普遍上不去
    • CPU 大量资源被系统消耗
    • 网络一旦抖动，会有大量 TIME_WAIT 产生，不得不定期重启服务或定期重启机器
    • 服务器工作不稳定，QPS 忽高忽低

    这时候我们可以优化的第一件事情就是把短链接改成长连接。也就是改成创建连接、收发数据、收发数据… 拆除连接，这样我们就可以减少大量创建连接、拆除连接的时间。从性能上来说肯定要比短连接好很多。但这里还是有比较大的浪费。

    举例：请求进入时，直接分配数据库长连接资源，假设有 80% 时间在与关系型数据库通讯，20% 时间是在与 Nosql 数据库通讯。当有 50K 个并行请求时，后端要分配 50K*2=100K 的长连接支撑请求。无疑这时候系统压力是非常大的。数据库再牛也抵不住滥用不是？

    连接池终于要出场了，它的解决思路是先把所有长连接存起来，谁需要使用，从这里取走，干完活立马放回来。那么按照这个思路，刚刚的 50K 的并发请求，最多占用后端 50K 的长连接就够了。省了一半啊有木有？

    在 OpenResty 中，所有具备 set_keepalive 的类、库函数，说明他都是支持连接池的。

    来点代码，给大家提提神，看看连接池使用时的一些注意点，麻雀虽小，五脏俱全。

    1. server {
    2.     location /test {
    3.         content_by_lua_block {
    4.             local redis = require "resty.redis"
    5.             local red = redis:new()
    7.             local ok, err = red:connect("127.0.0.1", 6379)
    8.             if not ok then
    9.                 ngx.say("failed to connect: ", err)
    10.                 return
    11.             end
    13.             -- red:set_keepalive(10000, 100)       -- 坑①
    15.             ok, err = red:set("dog", "an animal")
    16.             if not ok then
    17.                 -- red:set_keepalive(10000, 100)   -- 坑②
    18.                 return
    19.             end
    21.             -- 坑③
    22.             red:set_keepalive(10000, 100)
    23.         }
    24.     }
    25. }
    • 坑①：只有数据传输完毕了，才能放到池子里，系统无法帮你自动做这个事情
    • 坑②：不能把状态未知的连接放回池子里，设想另一个请求如果获取到一个不能用的连接，他不得哭死啊
    • 坑③：逗你玩，这个不是坑，是正确的

    尤其是掉进了第二个坑，你一定会莫名抓狂。不信的话，你就自己模拟试试，老带劲了。

    理解了连接池，那么线程池、内存池，就应该都明白了，只是存放的东西不一样，思想没有任何区别。