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的发布订阅模块,可用于实现及时性,且可靠性低的功能。

猜你喜欢

转载自www.cnblogs.com/lutt/p/12372033.html