连接池

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

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

从我们应用最多的 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)
        }
    }
}
  • 坑①:只有数据传输完毕了,才能放到池子里,系统无法帮你自动做这个事情
  • 坑②:不能把状态未知的连接放回池子里,设想另一个请求如果获取到一个不能用的连接,他不得哭死啊
  • 坑③:逗你玩,这个不是坑,是正确的

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

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

results matching ""

    No results matching ""