Rabbitmq 和 Celery 是怎樣工作的?

01-11

Rabbitmq 作為消息管理系統已經可以實現非同步的發送消息.
為什麼還要使用celery呢?
Rabbitmq和Celery一起使用的時候還是用來存儲消息,和Redis一樣?為什麼要一起用呢?

Celery相當於給你包裝了一個現成的系統，讓你更加方便的在自己的項目中操作RabbitMQ這個消息隊列介質。不然你什麼都要自己在RabbitMQ上重新寫。最直接的例子就是在Celery Python里，你只需要config一下settings，然後就可以用decorator來輕鬆使用消息隊列了，而不用重新在RabbitMQ上寫自己的腳本。

首先，RabbitMQ是個消息隊列的實現。

將消息隊列應用到何種場景，得看自己需求。

你可以拿它自己實現任務分發（自己實現一個Celery），也可以拿它實現消息推送，甚至只是用它解耦應用的物理結構，等等等等...

其次，Celery是一個任務分發系統。

任務分發系統目的很明確，就是利用後端待命的無數worker實現一系列任務的快速處理。

它跟消息隊列的關係不過是利用其在分發者和執行者之間進行任務的發布/訂閱。

所以RabbitMQ和redis等具有發布/訂閱能力的工具，理論上都能為其所用。

拋磚引玉，在看 celery 的文檔，貌似不長，寫得也蠻好的，奈何閱讀理解不過關，一邊啃一邊答～

celery 文檔： Celery - Distributed Task Queue

首先對 celery 進行一下簡單介紹：celery 是一種分散式任務調度框架（類似的產品，如 Gearman），特點是支持非同步化處理。語言方面目前已支持 python，ruby，node-js，php，還支持 web 調用。

celery 非同步處理需要傳遞消息和存儲結果，傳遞消息的叫 Broker（消息中間件），存儲結果的叫 backend。

celery 中 Broker 和 backend 都是通過對消息的發送、接收、存儲實現的。celery 消息的解決方案默認使用 amqp 協議（即 RabbitMQ），可以在配置中指定其他的消息解決方案。目前對 RabbitMQ、Redis 支持比較好，其他如 BeanStalk，ZeroMQ，MongoDB等僅有實驗性支持，見 Brokers — broker-overview