最近由于流量增大，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è)來(lái)分析。
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ò)术吗。
后來(lái)把鏡像中的 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 。（注意：如果你不是制作新的鏡像襟企，或者你是在生產(chǎn)環(huán)境的服務(wù)器上嘱么，那么不要隨便刪 dump.rdb，否則會(huì)導(dǎo)致數(shù)據(jù)丟失）
其他3種錯(cuò)誤
一開(kāi)始也是各種找資料顽悼，然后各種改配置曼振，導(dǎo)致這3種錯(cuò)誤都先后出現(xiàn)。
一開(kāi)始我認(rèn)為是 golang 代碼沒(méi)有正確處理 redis 連接異常的情況蔚龙，于是各種升級(jí) redigo冰评，改 golang 中的 timeout 、max_active木羹、wait 等的配置甲雅，發(fā)現(xiàn)都沒(méi)有用。
這樣來(lái)來(lái)回回折騰了大概一周坑填，終于從 pool.Active 和 pool.MaxActive 中發(fā)現(xiàn)了貓膩抛人。
因?yàn)槲?MaxActive 設(shè)置的是 10000，于是我開(kāi)了 10000 個(gè) go runtine 去測(cè)試它脐瑰，發(fā)現(xiàn)當(dāng)前連接數(shù) pool.Active 老是才 4000 左右函匕，然后就各種報(bào)錯(cuò)。
那段時(shí)間也是腦子短路了蚪黑，老是認(rèn)為 redigo 沒(méi)有正確處理 redis 的連接才導(dǎo)致 pool.Active 不能上到最大盅惜。老是想著改 redigo 的代碼……
后來(lái)實(shí)在沒(méi)辦法，想著去改一改 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 客戶(hù)端（即 golang 代碼）
Wait: true 如果連接池滿(mǎn)了例嘱，就等待， Redis 處理很快的宁舰，等個(gè)幾微秒用戶(hù)也感覺(jué)不出來(lái)什么
IdleTimeout: 5s 一個(gè)業(yè)務(wù)邏輯5s都處理不完拼卵，那你應(yīng)該優(yōu)化你的代碼了。如果設(shè)置為0蛮艰，萬(wàn)一這個(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)存仍律，那么打開(kāi)文件數(shù)最大可以設(shè)置為：4 * 1024 * 100 = 409600
