前言

最近由于流量增大，redis 出現(xiàn)了一連串錯(cuò)誤，比如：

• LOADING Redis is loading the dataset in memory
• use of closed network connection
• connection pool exhausted
• connection refuse by peer

一個(gè)個(gè)來分析。

LOADING Redis is loading the dataset in memory

這里至少有2種可能

• 可用內(nèi)存太小，修改 redis.conf 中的 maxmemory 即可解決
• redis 在啟動(dòng)時(shí)正在加載 dump.rdb 文件，由于加載比較慢導(dǎo)致 redis 在啟動(dòng)時(shí)不可用

我遇到的就是第2種情況，AWS在自動(dòng)擴(kuò)容的時(shí)候，每個(gè)新產(chǎn)生的 EC2 實(shí)例都報(bào)錯(cuò)，原因就是 redis 在啟動(dòng)時(shí)發(fā)現(xiàn)有個(gè) dump.rdb，然后就去加載它，導(dǎo)致服務(wù)器里的服務(wù)都報(bào)錯(cuò)，然后就退出了，并且 redis 加載這個(gè)要好久（不知道為什么），supervisord 自動(dòng)重啟了新的服務(wù)后依然報(bào)錯(cuò)。

后來把鏡像中的 dump.rdb 文件刪了，服務(wù)才能正常啟動(dòng)。

dump.rdb 文件產(chǎn)生的原因可能是之前 redis 出現(xiàn)了某種錯(cuò)誤，然后在制作鏡像時(shí)也做進(jìn)去了，導(dǎo)致新生成的實(shí)例個(gè)個(gè)都報(bào)錯(cuò)。

這次吸取了教訓(xùn)，下次制作鏡像之前都要先 stop 掉 redis 然后刪掉 dump.rdb 。

其他3種錯(cuò)誤

一開始也是各種找資料，然后各種改配置，導(dǎo)致這3種錯(cuò)誤都先后出現(xiàn)。

一開始我認(rèn)為是 golang 代碼沒有正確處理 redis 連接異常的情況，于是各種升級(jí) redigo，改 golang 中的 timeout 、max_active、wait 等的配置，發(fā)現(xiàn)都沒有用。

這樣來來回回折騰了大概一周，終于從 pool.Active 和 pool.MaxActive 中發(fā)現(xiàn)了貓膩。

因?yàn)槲?MaxActive 設(shè)置的是 10000，于是我開了 10000 個(gè) go runtine 去測試它，發(fā)現(xiàn)當(dāng)前連接數(shù) pool.Active 老是才 4000 左右，然后就各種報(bào)錯(cuò)。

那段時(shí)間也是腦子短路了，老是認(rèn)為 redigo 沒有正確處理 redis 的連接才導(dǎo)致 pool.Active 不能上到最大。老是想著改 redigo 的代碼……

后來實(shí)在沒辦法，想著去改一改 ulimit，舊的是 500000，改到 990000，發(fā)現(xiàn)還是報(bào)連接錯(cuò)誤，pool.Active 還是上不去，我想這不可能啊，這才想到會(huì)不會(huì)是 redis 本身有最大連接數(shù)的配置。上網(wǎng)一查，果然，redis-server 有一個(gè) maxclients 的配置……默認(rèn)是 4000 多，改到 10000 后，整個(gè)世界都清靜了……

其實(shí)也不能怪我，因?yàn)?redigo 也有個(gè) max_active 參數(shù)，鬼知道 redis-server 還要設(shè)置呢 [笑哭]？

Redis 用于高并發(fā)服務(wù)的配置

Redis 客戶端（即 golang 代碼）

Wait: true 如果連接池滿了，就等待， Redis 處理很快的，等個(gè)幾微秒用戶也感覺不出來什么
IdleTimeout: 5s 一個(gè)業(yè)務(wù)邏輯5s都處理不完，那你應(yīng)該優(yōu)化你的代碼了。如果設(shè)置為0，萬一這個(gè)連接失蹤了服務(wù)端就收回不了了，會(huì)產(chǎn)生僵尸連接的。

MaxActive: 10000 相當(dāng)于這個(gè)服務(wù)器能處理每秒 10000 并發(fā)了。

Redis 服務(wù)器（即 redis-server）

maxclients 要設(shè)置得比 MaxActive 大

附加題：一臺(tái)服務(wù)器的最大文件數(shù)怎么算？

linux kernel - Need to “calculate” optimum ulimit and fs.file-max values according to my own server needs - Stack Overflow

this ends up being about 100 for every 1MB of ram.

例，如果是 4G 內(nèi)存，那么打開文件數(shù)最大可以設(shè)置為：4 * 1024 * 100 = 409600

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)腳本之家的支持。