worker与redis网络中断后，worker不再接受任务的异常问题
最近生产遇到一个诡异的问题，celery使用redis作为任务调度存贮，worker从redis拿数据，问题就处在worker和redis，worker和redis中间的网络中断了十几分钟，然后用户就反馈业务有问题。
果断上机器看，worker进程ok，redis也ok，看不出问题，那就去看日志吧。发现没有异常日志，同时也发现，没有正常业务日志，什么鬼，没业务过来？
去redis看下任务队列（redis-cli -h 192.168.1.1 -n 0 llen {{queue_name}}）,发现有任务啊，但为啥不消费嘞？
业务催的急啊，怎么办？那就动用终极大杀器（重启大法），重启worker进程后，发现任务开始正常消费了，为啥我会知道嘞，因为业务开始打印日志了。
剩下来的就是开始排查原因，首先去celery官网看文档看参数，发现了一个参数CELERY_BROKER_CONNECTION_MAX_RETRIES = None
这个参数是开启一直重试的参数，测试发现不行，找了好多个参数，最终发现之前都找错方向了。因为在官网文档的开头突然看到官网的参数是分类的，之前一直找了的worker和broken相关的参数，其实还有一部分是redis的
于是找到并添加，如下参数
CELERY_REDIS_SOCKET_CONNECT_TIMEOUT = 5
CELERY_REDIS_RETRY_ON_TIMEOUT = True
测试，关闭网卡20分钟，启动网卡，worker进程会在几秒内就开始重连redis，并开始消费挤压的任务，至此这个问题就解决了。
感想：
之前出现这个问题的时候，检查了redis的tcp连接，发现不管是redis还是worker机器上的tcp连接都是正常的，猜测应该是worker启动的时候就已经吧redis池创建好了，创建完了即使redis连接超时了也不会尝试重新建立连接，就造成了，我们看到了情况，操作系统层的tcp连接是好的，但是应用层就是死活连不上redis的情况，其实这个时候worker的redis连接池已经全部异常了。
