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

創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、巴彥淖爾網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5建站、商城開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為巴彥淖爾等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

前言

最近由于流量增大，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

以上是“Redis中連接錯(cuò)誤的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

當(dāng)前文章：Redis中連接錯(cuò)誤的示例分析
轉(zhuǎn)載源于：http://sd-ha.com/article10/pepido.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、網(wǎng)站改版、建站公司、手機(jī)網(wǎng)站建設(shè)、用戶體驗(yàn)、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)