Celery:
Celery是基於Python開發的分布式任務隊列。它支持使用任務隊列的方式在分布的機器／進程／線程上執行任務調度。
1、 celery工作流程：
消息中間件（message broker）：Celery本身不提供消息服務，但是可以方便的和第三方提供的消息中間件集成。包括，RabbitMQ, Redis, MongoDB ，SQLAlchemy等，其中rabbitm與redis比較穩定，其他處於測試階段。
任務執行單元（worker）：Worker是Celery提供的任務執行的單元，worker並發的運行在分布式的系統節點中。
任務結果存儲（result store）：result store用來存儲Worker執行的任務的結果，支持AMQP，redis，mongodb，mysql等主流數據庫。
2、並發、序列化、壓縮:
celery任務並發執行支持prefork、eventlet、gevent、threads的方式；
序列化支持pickle,json,yaml,msgpack等；
壓縮支持zlib, bzip2 。
3、celery使用中的一些建議和優化
（1）、如果你的broker使用的是rabbitmq，可安裝一個C語言版的客戶端librabbitmq來提升性能， pip install librabbitmq；
（2）、通過 BROKER_POOL_LIMIT 參數配置消息中間件的連接池；
（3）、通過CELERYD_PREFETCH_MULTIPLIER 參數配置消息預取的數量，如果消息隊列中有很多消息，這個值建議設為1，以達到各個worker的最大化利用；
（4）、指定worker消費的隊列，如果你根據業務配置了多個不同的消息隊列，各個隊列的任務量大小不同，可以在worker啟動時指定消費隊列 celery -A app_name -l INFO -Q queue1,queue2
（5）、worke（prefork）默認啟動cpu核數個子進程，進程管理可以使用supervisor，supervisor是用Python開發的一套通用的進程管理程序，能將一個普通的命令行進程變為后台daemon，並監控進程狀態，異常退出時能自動重啟
rabbitmq：
- AMQP，即AdvancedMessage Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標准，為面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
- AMQP的主要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。
- RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗
1、queue、channel
- Queue（隊列）是RabbitMQ的內部對象，用於存儲消息。
- Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。
2、exchange
- 生產者不是將消息直接放到queue（隊列）中，而是先到exchange中，exchange主要用於控制消息到隊列的路由,根據具體的exchange type將消息傳給需要的隊列或者直接廢棄。
- RabbitMQ常用的ExchangeType有fanout、direct、topic、headers這四種，不同的類型有着不同的路由策略。
（1）fanout-exchange: fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中；
（2）direct-exchange：direct類型的Exchange路由規則也很簡單，它會把消息路由到那些bindingkey與routingkey完全匹配的Queue中；
（3）topic-exchange：前面講到direct類型的Exchange路由規則是完全匹配bindingkey與routingkey，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到bindingkey與routingkey相匹配的Queue中，但這里的匹配規則有些不同，它約定：
a.routing key為一個句點號“.”分隔的字符串（我們將被句點號 “. ”分隔開的每一段獨立的字符串稱為一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
b.binding key與routingkey一樣也是句點號“.”分隔的字符串
c.binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配， 其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
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的發布訂閱模塊，可用於實現及時性，且可靠性低的功能。
RabbitMQ與Redis隊列對比(轉載):
RabbitMQ
RabbitMQ是實現AMQP（高級消息隊列協議）的消息中間件的一種，最初起源於金融系統，用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
Redis
是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。
具體對比
可靠消費
Redis：沒有相應的機制保證消息的消費，當消費者消費失敗的時候，消息體丟失，需要手動處理
RabbitMQ：具有消息消費確認，即使消費者消費失敗，也會自動使消息體返回原隊列，同時可全程持久化，保證消息體被正確消費
可靠發布
Reids：不提供，需自行實現
RabbitMQ：具有發布確認功能，保證消息被發布到服務器
高可用
Redis：采用主從模式，讀寫分離，但是故障轉移還沒有非常完善的官方解決方案
RabbitMQ：集群采用磁盤、內存節點，任意單點故障都不會影響整個隊列的操作
持久化
Redis：將整個Redis實例持久化到磁盤
RabbitMQ：隊列，消息，都可以選擇是否持久化
消費者負載均衡
Redis：不提供，需自行實現
RabbitMQ：根據消費者情況，進行消息的均衡分發
隊列監控
Redis：不提供，需自行實現
RabbitMQ：后台可以監控某個隊列的所有信息，（內存，磁盤，消費者，生產者，速率等）
流量控制
Redis：不提供，需自行實現
RabbitMQ：服務器過載的情況，對生產者速率會進行限制，保證服務可靠性
出入隊性能
對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。
測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。
應用場景分析
Redis：輕量級，高並發，延遲敏感
即時數據分析、秒殺計數器、緩存等
RabbitMQ：重量級，高並發，異步
批量數據異步處理、並行任務串行化，高負載任務的負載均衡等