Celery:

Celery是基于Python開發(fā)的分布式任務(wù)隊列囊卜。它支持使用任務(wù)隊列的方式在分布的機(jī)器／進(jìn)程／線程上執(zhí)行任務(wù)調(diào)度。

1越妈、celery工作流程：

image

消息中間件（message broker）：Celery本身不提供消息服務(wù)季俩，但是可以方便的和第三方提供的消息中間件集成。包括梅掠，RabbitMQ, Redis, MongoDB 酌住，SQLAlchemy等，其中rabbitm與redis比較穩(wěn)定阎抒，其他處于測試階段酪我。

任務(wù)執(zhí)行單元（worker）：Worker是Celery提供的任務(wù)執(zhí)行的單元，worker并發(fā)的運行在分布式的系統(tǒng)節(jié)點中且叁。

任務(wù)結(jié)果存儲（result store）：result store用來存儲Worker執(zhí)行的任務(wù)的結(jié)果都哭，支持AMQP，redis逞带，mongodb欺矫，mysql等主流數(shù)據(jù)庫。

2展氓、并發(fā)穆趴、序列化、壓縮:
celery任務(wù)并發(fā)執(zhí)行支持prefork带饱、eventlet、gevent阅羹、threads的方式勺疼；

序列化支持pickle,json,yaml,msgpack等；

壓縮支持zlib, bzip2 捏鱼。
3执庐、celery使用中的一些建議和優(yōu)化

（1）、如果你的broker使用的是rabbitmq导梆，可安裝一個C語言版的客戶端librabbitmq來提升性能轨淌， pip install librabbitmq迂烁；

（2）、通過 BROKER_POOL_LIMIT 參數(shù)配置消息中間件的連接池递鹉；

（3）盟步、通過CELERYD_PREFETCH_MULTIPLIER 參數(shù)配置消息預(yù)取的數(shù)量，如果消息隊列中有很多消息躏结，這個值建議設(shè)為1却盘，以達(dá)到各個worker的最大化利用；

（4）媳拴、指定worker消費的隊列黄橘，如果你根據(jù)業(yè)務(wù)配置了多個不同的消息隊列，各個隊列的任務(wù)量大小不同屈溉，可以在worker啟動時指定消費隊列 celery -A app_name -l INFO -Q queue1,queue2

（5）塞关、worke（prefork）默認(rèn)啟動cpu核數(shù)個子進(jìn)程，進(jìn)程管理可以使用supervisor子巾，supervisor是用Python開發(fā)的一套通用的進(jìn)程管理程序帆赢，能將一個普通的命令行進(jìn)程變?yōu)楹笈_daemon，并監(jiān)控進(jìn)程狀態(tài)砰左，異常退出時能自動重啟

rabbitmq：

• AMQP匿醒，即AdvancedMessage Queuing Protocol，高級消息隊列協(xié)議缠导，是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn)廉羔，為面向消息的中間件設(shè)計。消息中間件主要用于組件之間的解耦僻造，消息的發(fā)送者無需知道消息使用者的存在憋他，反之亦然。
• AMQP的主要特征是面向消息髓削、隊列竹挡、路由（包括點對點和發(fā)布/訂閱）、可靠性立膛、安全揪罕。
• RabbitMQ是一個開源的AMQP實現(xiàn)，服務(wù)器端用Erlang語言編寫宝泵，支持多種客戶端好啰，如：Python、Ruby儿奶、.NET框往、Java、JMS闯捎、C椰弊、PHP许溅、ActionScript、XMPP秉版、STOMP等贤重，支持AJAX。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息沐飘，在易用性游桩、擴(kuò)展性、高可用性等方面表現(xiàn)不俗

1、queue、channel

• Queue（隊列）是RabbitMQ的內(nèi)部對象保檐，用于存儲消息。
• Channel是我們與RabbitMQ打交道的最重要的一個接口铐刘，我們大部分的業(yè)務(wù)操作是在Channel這個接口中完成的，包括定義Queue影晓、定義Exchange镰吵、綁定Queue與Exchange、發(fā)布消息等挂签。

2疤祭、exchange

• 生產(chǎn)者不是將消息直接放到queue（隊列）中，而是先到exchange中饵婆，exchange主要用于控制消息到隊列的路由,根據(jù)具體的exchange type將消息傳給需要的隊列或者直接廢棄勺馆，exchange可以通過參數(shù) routing_key 指定消息發(fā)送到哪個隊列。
• RabbitMQ常用的ExchangeType有fanout侨核、direct草穆、topic、headers這四種搓译，不同的類型有著不同的路由策略悲柱。

（1）fanout-exchange: fanout類型的Exchange路由規(guī)則非常簡單，它會把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中些己；

（2）direct-exchange：direct類型的Exchange路由規(guī)則也很簡單豌鸡，它會把消息路由到那些bindingkey與routingkey完全匹配的Queue中；

image

（3）topic-exchange：前面講到direct類型的Exchange路由規(guī)則是完全匹配bindingkey與routingkey段标，但這種嚴(yán)格的匹配方式在很多情況下不能滿足實際業(yè)務(wù)需求涯冠。topic類型的Exchange在匹配規(guī)則上進(jìn)行了擴(kuò)展，它與direct類型的Exchage相似怀樟，也是將消息路由到bindingkey與routingkey相匹配的Queue中功偿，但這里的匹配規(guī)則有些不同盆佣，它約定：
a.routing key為一個句點號“.”分隔的字符串（我們將被句點號 “. ”分隔開的每一段獨立的字符串稱為一個單詞）往堡，如“stock.usd.nyse”械荷、“nyse.vmw”、“quick.orange.rabbit”

b.binding key與routingkey一樣也是句點號“.”分隔的字符串

c.binding key中可以存在兩種特殊字符“*”與“#”虑灰，用于做模糊匹配吨瞎，    其中“*”用于匹配一個單詞，“#”用于匹配多個單詞（可以是零個）

image

rabbitMQ和redis用作消息隊列的區(qū)別:

可靠性:

• redis ：沒有相應(yīng)的機(jī)制保證消息的可靠消費穆咐，如果發(fā)布者發(fā)布一條消息颤诀，而沒有對應(yīng)的訂閱者的話，這條消息將丟失对湃，不會存在內(nèi)存中崖叫；
• rabbitMQ：具有消息消費確認(rèn)機(jī)制，如果發(fā)布一條消息拍柒，還沒有消費者消費該隊列心傀，那么這條消息將一直存放在隊列中，直到有消費者消費了該條消息拆讯，以此可以保證消息的可靠消費脂男。如果有多個消費者，RabbitMQ會按順序得把消息發(fā)送給每個消費者（consumer）种呐。平均每個消費者都會收到同等數(shù)量得消息宰翅。這種發(fā)送消息得方式叫做——輪詢（round-robin）

實時性:

• redis:實時性高，redis作為高效的緩存服務(wù)器爽室，所有數(shù)據(jù)都存在在服務(wù)器中汁讼，所以它具有更高的實時性

消費者負(fù)載均衡：

• redis發(fā)布訂閱模式，一個隊列可以被多個消費者同時訂閱肮之，當(dāng)有消息到達(dá)時掉缺，會將該消息依次發(fā)送給每個訂閱者；
• rabbitMQ隊列可以被多個消費者同時監(jiān)控消費戈擒，但是每一條消息只能被消費一次眶明，由于rabbitMQ的消費確認(rèn)機(jī)制，因此它能夠根據(jù)消費者的消費能力而調(diào)整它的負(fù)載筐高；

持久性:

• redis：redis的持久化是針對于整個redis緩存的內(nèi)容搜囱，它有RDB和AOF兩種持久化方式（redis持久化方式，后續(xù)更新）柑土，可以將整個redis實例持久化到磁盤蜀肘，以此來做數(shù)據(jù)備份，防止異常情況下導(dǎo)致數(shù)據(jù)丟失稽屏。
• rabbitMQ：隊列扮宠，消息都可以選擇性持久化，持久化粒度更小狐榔，更靈活坛增；

隊列監(jiān)控:

• rabbitMQ實現(xiàn)了后臺監(jiān)控平臺获雕，可以在該平臺上看到所有創(chuàng)建的隊列的詳細(xì)情況，良好的后臺管理平臺可以方便我們更好的使用收捣；
• redis沒有所謂的監(jiān)控平臺届案。

總結(jié):

• redis： 輕量級，低延遲罢艾，高并發(fā)楣颠，低可靠性；
• rabbitMQ：重量級咐蚯，高可靠童漩，異步，不保證實時春锋；
• rabbitMQ是一個專門的AMQP協(xié)議隊列睁冬，他的優(yōu)勢就在于提供可靠的隊列服務(wù)，并且可做到異步看疙，而redis主要是用于緩存的豆拨，redis的發(fā)布訂閱模塊，可用于實現(xiàn)及時性能庆，且可靠性低的功能施禾。

RabbitMQ與Redis隊列對比(轉(zhuǎn)載):

RabbitMQ

RabbitMQ是實現(xiàn)AMQP（高級消息隊列協(xié)議）的消息中間件的一種，最初起源于金融系統(tǒng)搁胆，用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息弥搞，在易用性、擴(kuò)展性渠旁、高可用性等方面表現(xiàn)不俗攀例。消息中間件主要用于組件之間的解耦，消息的發(fā)送者無需知道消息使用者的存在顾腊，反之亦然粤铭。

Redis

是一個Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護(hù)很活躍杂靶，雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)梆惯，但它本身支持MQ功能，所以完全可以當(dāng)做一個輕量級的隊列服務(wù)來使用吗垮。

具體對比

可靠消費

Redis：沒有相應(yīng)的機(jī)制保證消息的消費垛吗，當(dāng)消費者消費失敗的時候，消息體丟失烁登，需要手動處理
RabbitMQ：具有消息消費確認(rèn)怯屉，即使消費者消費失敗，也會自動使消息體返回原隊列，同時可全程持久化锨络，保證消息體被正確消費

可靠發(fā)布

Reids：不提供蝗敢，需自行實現(xiàn)
RabbitMQ：具有發(fā)布確認(rèn)功能，保證消息被發(fā)布到服務(wù)器

高可用

Redis：采用主從模式足删，讀寫分離，但是故障轉(zhuǎn)移還沒有非常完善的官方解決方案
RabbitMQ：集群采用磁盤锁右、內(nèi)存節(jié)點失受，任意單點故障都不會影響整個隊列的操作

持久化

Redis：將整個Redis實例持久化到磁盤
RabbitMQ：隊列，消息咏瑟，都可以選擇是否持久化

消費者負(fù)載均衡

Redis：不提供拂到，需自行實現(xiàn)
RabbitMQ：根據(jù)消費者情況，進(jìn)行消息的均衡分發(fā)

隊列監(jiān)控

Redis：不提供码泞，需自行實現(xiàn)
RabbitMQ：后臺可以監(jiān)控某個隊列的所有信息兄旬，（內(nèi)存，磁盤余寥，消費者领铐，生產(chǎn)者，速率等）

流量控制

Redis：不提供宋舷，需自行實現(xiàn)
RabbitMQ：服務(wù)器過載的情況绪撵，對生產(chǎn)者速率會進(jìn)行限制，保證服務(wù)可靠性

出入隊性能

對于RabbitMQ和Redis的入隊和出隊操作祝蝠，各執(zhí)行100萬次音诈，每10萬次記錄一次執(zhí)行時間。
測試數(shù)據(jù)分為128Bytes绎狭、512Bytes细溅、1K和10K四個不同大小的數(shù)據(jù)。

應(yīng)用場景分析

Redis：輕量級儡嘶，高并發(fā)喇聊，延遲敏感
即時數(shù)據(jù)分析、秒殺計數(shù)器蹦狂、緩存等

RabbitMQ：重量級承疲，高并發(fā)，異步
批量數(shù)據(jù)異步處理鸥咖、并行任務(wù)串行化燕鸽，高負(fù)載任務(wù)的負(fù)載均衡等

轉(zhuǎn)載鏈接：http://www.cnblogs.com/chinaboard/p/3819533.html