分佈式任務框架之celery

架構

• Broker

  消息代理，做爲臨時儲存任務的中間媒介，爲 Celery 提供了隊列服務。生產者將任務發送到 Broker，消費者再從 Broker 獲取任務。

Celery目前支持RabbitMQ、Redis、MongoDB、Beanstalk、SQLAlchemy、Zookeeper等 做爲消息代理，但適用於生產環境的只有RabbitMQ和Redis，至於其餘的方式，一是支持有限， 二是可能得不到更好的技術支持。
Celery官方推薦的是RabbitMQ，Celery的做者Ask Solem Hoel最初在VMware就是爲RabbitMQ工做的，Celer最初的設計就是基於RabbitMQ，因此使用 RabbitMQ會很是穩定，成功案例不少。若是使用Redis，則有可能發生忽然斷電之類的問題 形成Redis忽然終止後的數據丟失等後果。

• Beat

  任務調度器，負責調度並觸發 Celery 定時週期任務。Beat 進程讀取 CeleryConfig 中自定義的定時週期任務列表，將到期須要執行的定時任務發送到任務隊列中。

• Worker

  任務執行單元，實際負責執行任務的服務進程，每個 Worker 都有一個併發池（Prefork/Eventlet/Gevent/Thread）來支持多併發。Worker 會監聽訂閱的任務隊列，當隊列中有任務時，就會獲取任務並執行。

• Result Backend/Store

  任務執行狀態和結果存儲，Celery 支持任務實時處理，也就是說 Celery 能夠把任務執行的實時狀態和最終結果回傳生產者。這種回傳也須要經過中間存儲媒介。

web監控管理

添加管理任務

任務的監控

celery的魅力

• 高可用

1. 對於celery worker來講，其實部署在多個節點上，就是高可用的。
2. 對於borker來講，咱們使用了rabbitmq集羣來保證高可用（咱們線上同時也有其餘celery服務使用了AWS的SQS做爲borker，其自己就是保證高可用的）。
3. 對於celerybeat（就是啓動定時任務的程序）來講，只能使用單節點啓動，很難保證高可用，可是咱們這邊線上，並無使用celerybeat來啓動celery定時任務，而是使用了第三方服務（AWS lambda）來發送定時任務到celery borker中（至關於實現了celerybeat功能），這樣就用第三方的這個服務保證高可用。
   其實除了使用AWS lambda的這種方案，咱們還使用了在docker集羣中部署celerybeat的方案，這種其實也是能保證celerybeat的高可用的

參考文獻：

1. Celery+RabbitMQ的多機器worker節點介紹
2. celery有什麼難理解的