189 8069 5689
查看redis监控的时候看到redis的graph出现不正常的情况，截图如下：
10年积累的成都做网站、网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计制作后付款的网站建设流程，更有文水免费网站建设让你可以放心的选择与我们合作。
如上面截图所展示的样子，可以看到redis 的客户端连接数很突兀的上升到10K，又突然下降到0.排除了监控本身的原因，很明显是因为redis本身出了问题。
进入redis服务器，连接上去
/usr/bin/redis-cli -p 6399 -h 127.0.0.1
>127.0.0.1:6399>> info
ERR max number of clients reached
无论执行命令，显示的都是上面的那个错误。这个时候唯一想到的就是redis的客户端已经达到了最大的连接数，无法创建连接了。即redis client可以打开的文件描述符不足
1.获取得到redis:6399这个服务的PID信息
netstat -tunlp | grep 6399
2.获取redis的能够打开的最大文件描述符
cat /proc/PID/limints
可以看上述截图中Max open file这行参数可以看得到进程能够打开的最大文件描述符
3.查看进程打开的文件描述符
方法一：ll /proc/6677/fd | wc -l
方法二：lsof | grep 6399 | wc -l
通过上述方法获取得到的值是10015和10007,可以看得到redis的文件描述符已经使用完毕了。
4.因为redis-cli连接上redis之后无论如何更改出现上面的报错，但是redis server因为是作为缓存使用，不能够随随便便的重启，所以只能在客户端想办法，只能主动让客户端断开连接。所以获取得到6399端口的连接信息：
netstat -tun | grep 6399 | awk '{print $5}' | awk -F':' '{print $1}' | sort | uniq -c
8 10.143.106.95
8 10.143.90.216
5433 10.207.169.67
4788 10.221.236.76
1 10.221.244.39
6 10.225.36.189
在上面的命令可以很明显的获取得到那个IP地址连接redis服务的连接很多
5.进入连接最多的服务器，获得连接redis的客户端信息
netstat -tun | grep 6399
lsof -i:Port
根据上面俩个命令可以获得客户端的应用服务信息
6.获取得到应用服务信息之后，我们和开发商量之后，只能重启才能让客户端主动断开连接。所以直接重启了应用服务。
7.更改redis配置信息。
重启客户端之后，redis的connect也减少了一部分，这个时候可以连接上redis了。
a)获取redis的状态信息
>127.0.0.1:6399>>info
b)获取redis本地配置文件信息，最大连接数，timeout，tcp-keepalive
>127.0.0.1:6399>> config *
>127.0.0.1:6399>> config get maxclients
"10000"
>127.0.0.1:6399>> config get timeout
0
>127.0.0.1:6399>> config get tcp-keepalive
0
c)从上面命令可以看得出，最大连接数是10000，timeout和tcp-keepalive并没有开启，但是又不能重启redis-server，所以只能在线修改配置信息。
>127.0.0.1:6399>> config set maxclients=100000
OK
>127.0.0.1:6399>> config set timeout = 300
OK
做完上面措施之后，客户端连接数也已经断开。
问题产生的原因：
1.zabbix监控获取得到的值为什么是0
zabbix server上面执行
zabbix_get -s 0.0.0.0 -k 'redis[connect client,6399]'
0
原因是因为在agent段redis脚本抓取info信息的时候，对于不是数字类型的数据替换成0，所以导致zabbix 监控获取得到的数值是0
2.为什么有这么多的连接
线上的架构是
client ->VIP->server #VIP指的是负载均衡
客户端和服务的连接的中间是通过VIP进行转发的，他们直接的通信是TCP/IP四层的通信，在VIP上面本身自己是有做timeout设置的，默认20min ，它会主动的断开连接，但是却没有通知client和server端，导致client和server端并不清楚自己已经断开了连接。但是由于client的代码并没有设置主动断开连接，所以client会认为自己是一直连接的状态，等到下一次它发起请求的时候，VIP会告诉client连接已经断开，client会重新在创建一个新的连接；对于server端来说即redis它本身也没有开启timeout和tcp-keepalive的，所以server端也不会主动的断开连接，所以连接会越来越多，导致连接数完全被使用完。