实例基础信息：
redis版本：redis-cli 3.2.5
架构：传统主从架构
背景
一天开发人员通过kibana查看tomcat日志时，发现以下错误
RedisMessageListenerContainer 643 - Connection failure occurred. Restarting subscription task after 5000 ms
-问题分析
1）百度查看该报错，很多帖子解释原因如下：
client-output-buffer-limit pubsub 32mb 8mb 60 # Redis订阅客户端订阅buffer超过32M或持续60秒超过8M,订阅立即被关闭！（意思是说客户端消费速度比较慢，导致产生的消息大量堆积超过了限制客户端被关闭）
2）根据该解释查看redis服务器，通过client list查看信息如下，通过截图信息可以看出这次发现的错误于网上的描述并不符合，因为此时client-output-buffer-limit pubsub是空的说明不是这个参数限制导致的
3）为了进一步确定是否是该参数限制导致的错误，通过服务器手动设置client-output-buffer-limit参数，将其改为不受限制：
127.0.0.1:6379> config set client-output-buffer-limit "normal 0 0 0 slave 268435456 67108864 60 pubsub 0 0 0"
继续观察一段时间发现错误仍然以一定的频率出现，这充分说明了这次错误不是client-output-buffer-limit pubsub造成的；
4）通过帖子发现一个有用信息是client-output-buffer-limit pubsub如果达到限制会关闭客户端，然后客户端会报此次这个错误，那是不是有可能是其他地方将这个客户端关闭了造成这个错误；
5）仔细观察错误发生的频率，发现这应该是2组发布订阅产生的错误，第一张截图红框和绿框标出，每组发生的频率是3min钟，分析整个线路server端不会主动关闭client,jedis连接池配置的idle空闲断开是30min与报错也不符合，突然想起tomcat连接redis是通过haproxy代理的，是不是haproxy将客户端杀掉了，查看haproxy配置文件发现：
timeout client：客户端非活动状态的超时时长
timeout server：客户端与服务器端建立连接后，等待服务器端的超时时长
发现这个3分钟idle将会断开连接，很有可能是这两个参数造成的；
6）将haproxy的timeout client、timeout server改成10min reload后等待一段时间发现报错的频率成了10min钟，问题找到了，此次这个错误是由于haproxy将idle客户端杀掉了，造成程序客户端报错；
7）与开发人员沟通他们代码的逻辑是订阅时发生连接错误会继续尝试连接，也就是说消息产生端频率太低超出了haproxy设置端idel时间，haproxy将订阅客户端连接关闭了，订阅端客户端收到client被关闭后会抛出错误并重新建立连接，这就是错误产生端原因。
- 暂时解决方案
1）haproxy超时时间仍改回3min，因为后端代理了mysql等服务；
2）暂时继续沿用目前这种方案，因为程序具备断开重连机制，虽然redis发布订阅不能持久化，断开连接期间发布的消息订阅端有可能丢失，但是目前业务发布消息很少，几个月发布一次消息，在发布消息的时候连接断开的概率还是比较小的，所以暂不处理。 - 永久解决方案
1）采用Rabbit Mq取代redis
2）tomcat直连redis
3）代码处增加额外的发布信息，确保连接idle时间不会超过3min
