1、说明

开发过程指的是： 基于channels和celery搭建websocket实时消息推送服务。

1. 以下问题出现在线上服务器，服务器版本centos。
2. celery的BROKER和RESULT_BACKEND均采用的redis
3. celery和redis运行在不同的docker中。

2、用prefork运行celery

我起初用prefork模式来运行celery，我在两台服务器上做过测试，其中一台正常，另一台上会在不确定的时间点报错：

process 'forkPoolworker-5' pid:111 exited with 'signal 9 (SIGKILL)'

我在网上查了很多，但是没有解决，可以确定一点的是signal 9 (SIGKILL)是OS引发的，OS主动杀死了worker进程。那为什么OS要这样做呢，内存不足，出发了OS的OOM机制。但是我去messages日志查看，并没有找到有关OOM的记录。

然后我去看两台服务器上所有进程占用内存的情况，发现占用的都不多。

我对比两台服务器所有的docker，报错的那一台上有一个docker的cpu使用率最好能达到600%多，一般也在几百左右；正常的那一台有一个docker的cpu使用率在100左右。两者其他的docker都比较正常。

https://github.com/celery/celery/issues/7007，这是celery库下的issue，比较类似。

3、用eventlet运行celery

这个也是离了大普，同样花费了我好多时间，但是没有解决。

version：

1. python：3.12
2. celery：5.3.6
3. eventlet：0.34.1
4. dnspython：2.6.1

celery根本没有启动起来，原因是连不上redis。connecting to redis:6379. Lookup timed out。我在stack overflow上提了问题，可以看下。

The eventlet DNS bug that could take down your production servers通过这篇文章可以得知，dnspython2.0版本以上破坏了eventlet的dns解析能力，我的服务分别运行在不同的docker，celery需要找到redis，但是由于dns解析失败导致一直连不上。

后来根据我的测试大概是因为这个问题，我将dnspython换成1.x版本，Lookup timed out这个错误不报了，但是报另外一个错误，**attributeerror: module 'collections' has no attribute 'mutablemapping'**，原因在于我的python版本过高，如果降低到一定的版本，可能会启动成功，但是我没有测试，毕竟我们后端不可能一下子将python降低好几个大版本。

我最纳闷的这个也太离谱了，这都几年前的bug了，而且github上有很多类似的issue，为什么我还会遇到？celery都5.x了，dnspython也都2.6.x了，难道其他人就没遇到？偏偏就让我遇到了？

WTF!

4、用gevent或threads运行celery

又让我窒息的问题，如果我没搞错，根据我运行时报的错误，这两种运行模式不支持revoke task！WTF!

5、？

我用哪种方式运行？你让我用哪种方式运行？啊？

经过我N天的尝试，我决定放弃用celery做消息推送任务，改用asyncio！