Redis連接錯誤的情況總結分析

更新時間：2019年02月06日 08:44:35 作者：panyanyany

這篇文章主要給大家總結介紹了關于Redis連接錯誤的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧

前言

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

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

一個個來分析。

LOADING Redis is loading the dataset in memory

這里至少有2種可能

可用內存太小，修改 redis.conf 中的 maxmemory 即可解決
redis 在啟動時正在加載 dump.rdb 文件，由于加載比較慢導致 redis 在啟動時不可用

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

后來把鏡像中的 dump.rdb 文件刪了，服務才能正常啟動。

dump.rdb 文件產生的原因可能是之前 redis 出現(xiàn)了某種錯誤，然后在制作鏡像時也做進去了，導致新生成的實例個個都報錯。

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

其他3種錯誤

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

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

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

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

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

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

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

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

Redis 客戶端（即 golang 代碼）

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

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

Redis 服務器（即 redis-server）

maxclients 要設置得比 MaxActive 大

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

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