注意，這篇 Blog 嚴重參考了這兩篇文章：
- Using Celery With Flask: 寫了一個完整而且有意義的例子來展示如何在 Flask 中使用 Celery.
- Celery and the Flask Application Factory Pattern: 是上文的姊妹篇，描述的是更為真實的場景下，Celery 與 Flask Application Factory的結合使用。
Minimum Example
Celery 的一些設計和概念，與 Flask 很像，在 Flask 項目中集成 Celery 也很簡單，不像 Django 或其他框架需要擴展插件。首先來看個最簡單的例子 example.py：
import uuid
from flask import Flask, request, jsonify
from celery import Celery
app = Flask(__name__)
app.config['CELERY_BROKER_URL'] = 'redis://localhost:6379/0'
app.config['CELERY_RESULT_BACKEND'] = 'redis://localhost:6379/0'
celery = Celery(app.name,broker=app.config['CELERY_BROKER_URL'])
celery.conf.update(app.config)
@celery.task
def send_email(to, subject, content):
return do_send_email(to, subject, content)
@app.route('/password/forgot/', methods=['POST'])
def reset_password():
email = request.form['email']
token = str(uuid.uuid4())
content = u'請點擊鏈接重置密碼：http://example.com/password/reset/?token=%s' % token
send_email.delay(email, content)
return jsonify(code=0, message=u'發送成功')
if __name__ == '__main__': app.run()
啟動 Celery worker:
$ celery worker -A example.celery -l INFO
啟動 Web server:
$ python example.py
當然，實際應用在生產環境下，不能直接用 Flask 自帶的 server，需要使用 Gunicorn 這樣的 WSGI 容器，或 uWSGI. 而且 Celery worker 進程和 Web server 進程應該用 supervisord 管理起來。
Becoming Bigger
這是個最簡單的例子，實際應用會比這個復雜很多：有很多模塊，更復雜的配置，更多的 task 等。在這種情況下，Flask 推薦使用 Application Factory Pattern，也就是定義一個 function，在這里創建 Flask app 對象，并且處理注冊路由（blueprints）、配置 logging 等一系列初始化操作。
下面我們看看在更大的 Flask 項目里，應該如何使用 Celery.
項目結構
首先來看一下整個項目的結構：
├── README.md
├── app
│ ├── __init__.py
│ ├── config.py
│ ├── forms
│ ├── models
│ ├── tasks
│ │ ├── __init__.py
│ │ └── email.py
│ └── views
│ │ ├── __init__.py
│ │ └── account.py
├── celery_worker.py
├── manage.py└── wsgi.py
這個圖里省略了很多細節，簡單解釋一下：
項目的根目錄下，有個celery_worker.py的文件，這個文件的作用類似于wsgi.py，是啟動 Celery worker 的入口。
app 包里是主要業務代碼，其中 tasks 里定義里一系列的 task，提供給其他模塊調用。
主要代碼。
- app/config.py
class BaseConfig(object):
CELERY_BROKER_URL = 'redis://localhost:6379/2'
CELERY_RESULT_BACKEND = 'redis://localhost:6379/2'
CELERY_TASK_SERIALIZER = 'json'
BaseConfig是整個項目用到的配置的基類，實際上還會派生出DevelopmentConfig,StagingConfig和ProductionConfig
等類。這里不討論配置的細節，也只關心和 Celery 相關的配置項。
- app/init.py
from celery import Celery
from flask import Flask
from app.config import BaseConfig
celery = Celery(__name__,broker=BaseConfig.CELERY_BROKER_URL)
def create_app():
app = Flask(__name__)
celery.conf.update(app.config) # 更新 celery 的配置
return app
- app/tasks/email.py
from flask import current_app
from celery.util.log import get_task_logger
from app import celery
logger = get_task_logger(__name__)
@celery.task
def send_email(to, subject, content):
app = current_app._get_current_object()
subject = app.config['EMAIL_SUBJECT_PREFIX'] + subject
logger.info('send message "%s" to %s', content, to)
return do_send_email(to, subject, content)
- app/views/account.py
import uuid
from flask import Blueprint, request,jsonify
from app.tasks.email import send_email
bp_account = Blueprint('account', __name__)
@bp_account.route('/password/forgot/', methods=['POST'])
def reset_password():
email = request.form['email']
token = str(uuid.uuid4())
content = u'請點擊鏈接重置密碼：http://example.com/password/reset/?token=%s' % token
send_email.delay(email, content)
return jsonify(code=0, message=u'發送成功')
- ceelry_worker.py
from app import create_app, celery
app = create_app()
app.app_context().push()
這個celery_worker.py文件有兩個操作：創建一個 Flask 實例推入 Flask application context
第一個操作很簡單，其實也是初始化了 celery 實例。
第二個操作看起來有些奇怪，實際上也很好理解。如果用過 Flask 就應該知道 Flask 的 Application Context和 Request Context. Flask 一個很重要的設計理念是：在一個 Python 進程里可以運行多個應用（application），當存在多個 application 時可以通過current_app獲取當前請求所對應的 application.current_app綁定的是當前 request 的 application 的引用，在非 request-response 環境里，是沒有request context 的，所以調用current_app就會拋出異常（RuntimeError: working outside of application context）。創建一個 request context 沒有必要，而且消耗資源，所以就引入了 application context.app.app_context().push()會推入一個 application context，后續所有操作都會在這個環境里執行，直到進程退出。因此，如果在 tasks 里用到了current_app或其它需要 application context 的東西，就一定需要這樣做。（默認情況下 Celery 的 pool 是 prefork，也就是多進程，現在這種寫法沒有問題；但是如果指定使用 gevent，是沒用的。這種情況下有別的解決方案，以后會寫文章討論。）
運行
在項目的根路徑下啟動 Celery worker:
$ celery worker -A celery_worker.celery -l INFO
總結
上面兩個例子，實際上主要的差別就是初始化方式和模塊化，還有需要注意 Flask 的 application context 問題。文章內容比較簡單，文中的一些鏈接是很好的擴展和補充，值得一看
。
