一、關(guān)于連接池

一個數(shù)據(jù)庫服務(wù)器只擁有有限的資源，并且如果你沒有充分使用這些資源，你可以通過使用更多的連接來提高吞吐量。一旦所有的資源都在使用，那么你就不 能通過增加更多的連接來提高吞吐量。事實上，吞吐量在連接負載較大時就開始下降了。通常可以通過限制與可用的資源相匹配的數(shù)據(jù)庫連接的數(shù)量來提高延遲和吞 吐量。

如果不使用連接池，那么，每次傳輸數(shù)據(jù)，我們都需要進行創(chuàng)建連接，收發(fā)數(shù)據(jù)，關(guān)閉連接。在并發(fā)量不高的場景，基本上不會有什么問題，一旦并發(fā)量上去了，那么，一般就會遇到下面幾個常見問題：

• 性能普遍上不去

• CPU 大量資源被系統(tǒng)消耗

• 網(wǎng)絡(luò)一旦抖動，會有大量 TIME_WAIT 產(chǎn)生，不得不定期重啟服務(wù)或定期重啟機器

• 服務(wù)器工作不穩(wěn)定，QPS 忽高忽低

要想解決這些問題，我們就要用到連接池了。連接池的思路很簡單，在初始化時，創(chuàng)建一定數(shù)量的連接，先把所有長連接存起來，然后，誰需要使用，從這里取走，干完活立馬放回來。 如果請求數(shù)超出連接池容量，那么就排隊等待、退化成短連接或者直接丟棄掉。

二、使用連接池遇到的坑

最近在一個項目中，需要實現(xiàn)一個簡單的 Web Server 提供 Redis 的 HTTP interface，提供 JSON 形式的返回結(jié)果。考慮用 Go 來實現(xiàn)。

首先，去看一下 Redis 官方推薦的 Go Redis driver。官方 Star 的項目有兩個：Radix.v2 和 Redigo。經(jīng)過簡單的比較后，選擇了更加輕量級和實現(xiàn)更加優(yōu)雅的 Radix.v2。

Radix.v2 包是根據(jù)功能劃分成一個個的 sub package，每一個 sub package 在一個獨立的子目錄中，結(jié)構(gòu)非常清晰。我的項目中會用到的 sub package 有 redis 和 pool。

由于我想讓這種被 fork 的進程***簡單點，做的事情單一一些，所以，在沒有深入去看 Radix.v2 的 pool 的實現(xiàn)之前，我選擇了自己實現(xiàn)一個 Redis pool。(這里，就不貼代碼了。后來發(fā)現(xiàn)自己實現(xiàn)的 Redis pool 與 Radix.v2 實現(xiàn)的 Redis pool 的原理是一樣的，都是基于 channel 實現(xiàn)的, 遇到的問題也是一樣的。)

不過在測試過程中，發(fā)現(xiàn)了一個詭異的問題。在請求過程中經(jīng)常會報 EOF 錯誤。而且是概率性出現(xiàn)，一會有問題，一會又好了。通過反復(fù)的測試，發(fā)現(xiàn) bug 是有規(guī)律的，當(dāng)程序空閑一會后，再進行連續(xù)請求，會發(fā)生3次失敗，然后之后的請求都能成功，而我的連接池大小設(shè)置的是3。再進一步分析，程序空閑300秒 后，再請求就會失敗，發(fā)現(xiàn)我的 Redis server 配置了 timeout 300，至此，問題就清楚了。是連接超時 Redis server 主動斷開了連接。客戶端這邊從一個超時的連接請求就會得到 EOF 錯誤。

然后我看了一下 Radix.v2 的 pool 包的源碼，發(fā)現(xiàn)這個庫本身并沒有檢測壞的連接，并替換為新的連接的機制。也就是說我每次從連接池里面 Get 的連接有可能是壞的連接。所以，我當(dāng)時臨時的解決方案是通過增加失敗后自動重試來解決了。不過，這樣的處理方案，連接池的作用好像就沒有了。技術(shù)債能早點 還的還是早點還上。

三、使用連接池的正確姿勢

想到我們的 ngx_lua 項目里面也大量使用 redis 連接池，他們怎么沒有遇到這個問題呢。只能去看看源碼了。

經(jīng)過抽象分離， 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)有個 set_keepalive 的方法，查了一下官方文檔，方法的原型是 syntax: ok, err = red:set_keepalive(max_idle_timeout, pool_size) 貌似 max_idle_timeout 這個參數(shù)，就是我們所缺少的東西，然后進一步跟蹤源碼，看看里面是怎么保證連接有效的。

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 心跳機制。

于是，通過與 Radix.v2 的作者一些討論，選擇自己在 redis 這層使用心跳機制，來解決這個問題。

四、***的解決方案

在創(chuàng)建連接池之后，起一個 goroutine，每隔一段 idleTime 發(fā)送一個 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)部進行了連接池內(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 的機制，不會出現(xiàn) timeout 的連接了，從 redis 連接池里面取出的連接都是可用的連接了。看似簡單的代碼，卻***的解決了連接池里面超時連接的問題。同時，就算 Redis server 重啟等情況，也能保證連接自動重連。