啟動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的發布訂閱模塊，可用於實現及時性，且可靠性低的功能。