建站
咨詢
售后
建站咨詢
新聞中心
一、關(guān)于連接池
公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站建設(shè)、網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。創(chuàng)新互聯(lián)公司推出天河免費(fèi)做網(wǎng)站回饋大家。
一個(gè)數(shù)據(jù)庫(kù)服務(wù)器只擁有有限的資源，并且如果你沒(méi)有充分使用這些資源，你可以通過(guò)使用更多的連接來(lái)提高吞吐量。一旦所有的資源都在使用，那么你就不 能通過(guò)增加更多的連接來(lái)提高吞吐量。事實(shí)上，吞吐量在連接負(fù)載較大時(shí)就開始下降了。通常可以通過(guò)限制與可用的資源相匹配的數(shù)據(jù)庫(kù)連接的數(shù)量來(lái)提高延遲和吞 吐量。
如果不使用連接池，那么，每次傳輸數(shù)據(jù)，我們都需要進(jìn)行創(chuàng)建連接，收發(fā)數(shù)據(jù)，關(guān)閉連接。在并發(fā)量不高的場(chǎng)景，基本上不會(huì)有什么問(wèn)題，一旦并發(fā)量上去了，那么，一般就會(huì)遇到下面幾個(gè)常見問(wèn)題：
-
性能普遍上不去
-
CPU 大量資源被系統(tǒng)消耗
-
網(wǎng)絡(luò)一旦抖動(dòng)，會(huì)有大量 TIME_WAIT 產(chǎn)生，不得不定期重啟服務(wù)或定期重啟機(jī)器
-
服務(wù)器工作不穩(wěn)定，QPS 忽高忽低
要想解決這些問(wèn)題，我們就要用到連接池了。連接池的思路很簡(jiǎn)單，在初始化時(shí)，創(chuàng)建一定數(shù)量的連接，先把所有長(zhǎng)連接存起來(lái)，然后，誰(shuí)需要使用，從這里取走，干完活立馬放回來(lái)。 如果請(qǐng)求數(shù)超出連接池容量，那么就排隊(duì)等待、退化成短連接或者直接丟棄掉。
二、使用連接池遇到的坑
最近在一個(gè)項(xiàng)目中，需要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 Web Server 提供 Redis 的 HTTP interface，提供 JSON 形式的返回結(jié)果?？紤]用 Go 來(lái)實(shí)現(xiàn)。
首先，去看一下 Redis 官方推薦的 Go Redis driver。官方 Star 的項(xiàng)目有兩個(gè)：Radix.v2 和 Redigo。經(jīng)過(guò)簡(jiǎn)單的比較后，選擇了更加輕量級(jí)和實(shí)現(xiàn)更加優(yōu)雅的 Radix.v2。
Radix.v2 包是根據(jù)功能劃分成一個(gè)個(gè)的 sub package，每一個(gè) sub package 在一個(gè)獨(dú)立的子目錄中，結(jié)構(gòu)非常清晰。我的項(xiàng)目中會(huì)用到的 sub package 有 redis 和 pool。
由于我想讓這種被 fork 的進(jìn)程***簡(jiǎn)單點(diǎn)，做的事情單一一些，所以，在沒(méi)有深入去看 Radix.v2 的 pool 的實(shí)現(xiàn)之前，我選擇了自己實(shí)現(xiàn)一個(gè) Redis pool。(這里，就不貼代碼了。后來(lái)發(fā)現(xiàn)自己實(shí)現(xiàn)的 Redis pool 與 Radix.v2 實(shí)現(xiàn)的 Redis pool 的原理是一樣的，都是基于 channel 實(shí)現(xiàn)的, 遇到的問(wèn)題也是一樣的。)
不過(guò)在測(cè)試過(guò)程中，發(fā)現(xiàn)了一個(gè)詭異的問(wèn)題。在請(qǐng)求過(guò)程中經(jīng)常會(huì)報(bào) EOF 錯(cuò)誤。而且是概率性出現(xiàn)，一會(huì)有問(wèn)題，一會(huì)又好了。通過(guò)反復(fù)的測(cè)試，發(fā)現(xiàn) bug 是有規(guī)律的，當(dāng)程序空閑一會(huì)后，再進(jìn)行連續(xù)請(qǐng)求，會(huì)發(fā)生3次失敗，然后之后的請(qǐng)求都能成功，而我的連接池大小設(shè)置的是3。再進(jìn)一步分析，程序空閑300秒 后，再請(qǐng)求就會(huì)失敗，發(fā)現(xiàn)我的 Redis server 配置了 timeout 300，至此，問(wèn)題就清楚了。是連接超時(shí) Redis server 主動(dòng)斷開了連接?？蛻舳诉@邊從一個(gè)超時(shí)的連接請(qǐng)求就會(huì)得到 EOF 錯(cuò)誤。
然后我看了一下 Radix.v2 的 pool 包的源碼，發(fā)現(xiàn)這個(gè)庫(kù)本身并沒(méi)有檢測(cè)壞的連接，并替換為新的連接的機(jī)制。也就是說(shuō)我每次從連接池里面 Get 的連接有可能是壞的連接。所以，我當(dāng)時(shí)臨時(shí)的解決方案是通過(guò)增加失敗后自動(dòng)重試來(lái)解決了。不過(guò)，這樣的處理方案，連接池的作用好像就沒(méi)有了。技術(shù)債能早點(diǎn) 還的還是早點(diǎn)還上。
三、使用連接池的正確姿勢(shì)
想到我們的 ngx_lua 項(xiàng)目里面也大量使用 redis 連接池，他們?cè)趺礇](méi)有遇到這個(gè)問(wèn)題呢。只能去看看源碼了。
經(jīng)過(guò)抽象分離， ngx_lua 里面使用 redis 連接池部分的代碼大致是這樣的：
- server {
- location /pool {
- 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
- ok, err = red:set("hello", "world")
- if not ok then
- return
- end
- red:set_keepalive(10000, 100)
- }
- }
- }
發(fā)現(xiàn)有個(gè) set_keepalive 的方法，查了一下官方文檔，方法的原型是 syntax: ok, err = red:set_keepalive(max_idle_timeout, pool_size) 貌似 max_idle_timeout 這個(gè)參數(shù)，就是我們所缺少的東西，然后進(jìn)一步跟蹤源碼，看看里面是怎么保證連接有效的。
- function _M.set_keepalive(self, ...)
- local sock = self.sock
- if not sock then
- return nil, "not initialized"
- end
- if self.subscribed then
- return nil, "subscribed state"
- end
- return sock:setkeepalive(...)
- end
至此，已經(jīng)清楚了，使用了 tcp 的 keepalive 心跳機(jī)制。
于是，通過(guò)與 Radix.v2 的作者一些討論，選擇自己在 redis 這層使用心跳機(jī)制，來(lái)解決這個(gè)問(wèn)題。
四、***的解決方案
在創(chuàng)建連接池之后，起一個(gè) goroutine，每隔一段 idleTime 發(fā)送一個(gè) PING 到 Redis server。其中，idleTime 略小于 Redis server 的 timeout 配置。
連接池初始化部分代碼如下：
- p, err := pool.New("tcp", u.Host, concurrency)
- errHndlr(err)
- go func() {
- for {
- p.Cmd("PING")
- time.Sleep(idelTime * time.Second)
- }
- }()
使用 redis 傳輸數(shù)據(jù)部分代碼如下：
- func redisDo(p *pool.Pool, cmd string, args ...interface{}) (reply *redis.Resp, err error) {
- reply = p.Cmd(cmd, args...)
- if err = reply.Err; err != nil {
- if err != io.EOF {
- Fatal.Println("redis", cmd, args, "err is", err)
- }
- }
- return
- }
其中，Radix.v2 連接池內(nèi)部進(jìn)行了連接池內(nèi)連接的獲取和放回，代碼如下：
- // Cmd automatically gets one client from the pool, executes the given command
- // (returning its result), and puts the client back in the pool
- func (p *Pool) Cmd(cmd string, args ...interface{}) *redis.Resp {
- c, err := p.Get()
- if err != nil {
- return redis.NewResp(err)
- }
- defer p.Put(c)
- return c.Cmd(cmd, args...)
- }
這樣，我們就有了 keepalive 的機(jī)制，不會(huì)出現(xiàn) timeout 的連接了，從 redis 連接池里面取出的連接都是可用的連接了。看似簡(jiǎn)單的代碼，卻***的解決了連接池里面超時(shí)連接的問(wèn)題。同時(shí)，就算 Redis server 重啟等情況，也能保證連接自動(dòng)重連。
當(dāng)前文章：如何在Go語(yǔ)言中使用Redis連接池
網(wǎng)頁(yè)鏈接：http://m.5511xx.com/article/coshdjs.html
