Redis中連接錯誤的示例分析

這篇文章主要介紹Redis中連接錯誤的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

前言

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

• 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 在啟動時發現有個 dump.rdb，然后就去加載它，導致服務器里的服務都報錯，然后就退出了，并且 redis 加載這個要好久（不知道為什么），supervisord 自動重啟了新的服務后依然報錯。

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

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

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

其他3種錯誤

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

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

這樣來來回回折騰了大概一周，終于從 pool.Active 和 pool.MaxActive 中發現了貓膩。

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

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

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

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

Redis 用于高并發服務的配置

Redis 客戶端（即 golang 代碼）

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

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

Redis 服務器（即 redis-server）

maxclients 要設置得比 MaxActive 大

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

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 內存，那么打開文件數最大可以設置為：4 * 1024 * 100 = 409600

以上是“Redis中連接錯誤的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！