# 連接池 作為一個專業的服務端開發工程師，我們必須要對連接池、線程池、內存池等有較深理解，并且有自己熟悉的庫函數可以讓我們輕松駕馭這些不同的`池子`。既然他們都叫某某池，那么他們從基礎概念上講，原理和目的幾乎是一樣的，那就是`復用`。 以連接池做引子，我們說說服務端工程師基礎必修課。 從我們應用最多的HTTP連接、數據庫連接、消息推送、日志存儲等，所有點到點之間，都需要花樣繁多的各色連接。為了傳輸數據，我們需要完成創建連接、收發數據、拆除連接。對并發量不高的場景，我們為每個請求都完整走這三步（短連接），開發工作基本只考慮業務即可，基本上也不會有什么問題。一旦挪到高并發應用場景，那么可能我們就要郁悶了。 你將會碰到下面幾個常見問題： - 性能普遍上不去 - CPU大量資源被系統消耗 - 網絡一旦抖動，會有大量TIME_WAIT產生，不得不定期重啟服務或定期重啟機器 - 服務器工作不穩定，QPS忽高忽低 這時候我們可以優化的第一件事情就是把短鏈接改成長連接。也就是改成創建連接、收發數據、收發數據...拆除連接，這樣我們就可以減少大量創建連接、拆除連接的時間。從性能上來說肯定要比短鏈接好很多。但這里還是有比較大的浪費。 舉例：請求進入時，直接分配數據庫長連接資源，假設有80%時間在與關系型數據庫通訊，20%時間是在與Nosql數據庫通訊。當有50K個并行請求時，后端要分配50K*2=100K的長連接支撐請求。無疑這時候系統壓力是非常大的。數據庫在牛逼也抵不住濫用不是？ 連接池終于要出廠了，它的解決思路是先把所有長連接存起來，誰需要使用，從這里取走，干完活立馬放回來。那么按照這個思路，剛剛的50K的并發請求，最多占用后端50K的長連接就夠了。省了一半啊有木有？ 在OpenResty中，所有具備set_keepalive的類、庫函數，說明他都是支持連接池的。 來點代碼，給大家提提神，看看連接池使用時的一些注意點，麻雀雖小，五臟俱全。 ~~~ server { location /test { content_by_lua ' 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) '; } } ~~~ - 坑①：只有數據傳輸完畢了，才能放到池子里，系統無法幫你自動做這個事情 - 坑②：不能把狀態位置的連接放回池子里，你不知道這個連接后面會觸發什么錯誤 - 坑③：逗你玩，這個不是坑，是正確的 尤其是掉進了第二個坑，你一定會莫名抓狂。不信的話，你就自己模擬試試，老帶勁了。 理解了連接池，那么線程池、內存池，就應該都明白了，只是存放的東西不一樣，思想沒有任何區別。