linux--解决celery消息中间件带来的一系列问题

启动celery定时任务

1、celery -A OpsManage beat -l info -S django

2、celery -A OpsManage  worker -l info

此时消息中间件为rabbitmq

# BROKER_URL = 'amqp://guest:guest@localhost:5672//'

参考博客：https://blog.csdn.net/setlilei/article/details/102927015在linux安装rabbitmq，但无奈网络太慢，在执行第二条数次之后决定暂时放弃

将celery中间件更换为redis

# BROKER_URL = 'redis://localhost:6379'

在启动定时任务后得到反馈：

kombu.exceptions.VersionMismatch: Redis transport requires redis-py versions 3.2.0 or later. You have 2.10.6

由报错得知，需要升级redis为3.2.0版本,查看redis版本得知此时redis已是3.2.8

经过查询，了解到此时kombu(4.6.4)版本过高，使用4.2.0版本即可

# pip3 install kombu==4.2.0

此时问题又指向kombu模块

File "/usr/local/python3/lib/python3.6/site-packages/celery/app/control.py", line 12, in <module>

    from kombu.matcher import match

ModuleNotFoundError: No module named 'kombu.matcher'

好悲催！！

最终找到正解，需要将celery4.3.0降成4.1.1

# pip3 install celery==4.1.1

至此，终于解决了由消息中间件导致celery定时任务执行失败的问题

那么，话说回来，redis和rabbitmq到底有什么差别呢？

rabbitMQ和redis用作消息队列的区别:

可靠性:

redis ：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；
rabbitMQ：具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费

实时性:

redis:实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性

消费者负载均衡：

redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订阅者；
rabbitMQ队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitMQ的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载；

持久性:

redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（redis持久化方式，后续更新），可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。
rabbitMQ：队列，消息都可以选择性持久化，持久化粒度更小，更灵活；

队列监控:

rabbitMQ实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方便我们更好的使用；
redis没有所谓的监控平台。

总结:

redis：轻量级，低延迟，高并发，低可靠性；
rabbitMQ：重量级，高可靠，异步，不保证实时；
rabbitMQ是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，
而redis主要是用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。

巴特西

linux--解决celery消息中间件带来的一系列问题

rabbitMQ和redis用作消息队列的区别:

最新文章

热门文章