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种可能

1. 可用内存太小，修改 redis.conf 中的 maxmemory 即可解决
2. 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