Redisの使用

インストール

Redisをサポートするには、追加の依存関係をインストールする必要があります。 celery[redis] bundle を使用して、Celeryとこれらの依存関係の両方を一度にインストールできます。

$ pip install -U "celery[redis]"

構成

設定は簡単です。Redisデータベースの場所を設定するだけです。

app.conf.broker_url = 'redis://localhost:6379/0'

URLの形式は次のとおりです。

redis://:password@hostname:port/db_number

スキームの後のすべてのフィールドはオプションであり、データベース0を使用して、ポート6379でデフォルトでlocalhostになります。

Unixソケット接続を使用する必要がある場合は、URLを次の形式にする必要があります。

redis+socket:///path/to/redis.sock

virtual_hostパラメーターをURLに追加することにより、Unixソケットを使用するときに別のデータベース番号を指定できます。

redis+socket:///path/to/redis.sock?virtual_host=db_number

RedisSentinelのリストに直接接続することも簡単です。

app.conf.broker_url = 'sentinel://localhost:26379;sentinel://localhost:26380;sentinel://localhost:26381'
app.conf.broker_transport_options = { 'master_name': "cluster1" }

sentinel_kwargsを使用して、追加のオプションをSentinelクライアントに渡すことができます。

app.conf.broker_transport_options = { 'sentinel_kwargs': { 'password': "password" } }

可視性タイムアウト

可視性タイムアウトは、メッセージが別のワーカーに再配信される前に、ワーカーがタスクを確認するのを待機する秒数を定義します。下記の警告を必ずご覧ください。

このオプションは、：setting： `broker_transport_options` 設定を介して設定されます：

app.conf.broker_transport_options = {'visibility_timeout': 3600}  # 1 hour.

Redisのデフォルトの可視性タイムアウトは1時間です。

結果

タスクの状態と戻り値もRedisに保存する場合は、次の設定を構成する必要があります。

app.conf.result_backend = 'redis://localhost:6379/0'

Redis結果バックエンドでサポートされているオプションの完全なリストについては、 Redisバックエンド設定を参照してください。

Sentinelを使用している場合は、：setting： `result_backend_transport_options` 設定を使用してmaster_nameを指定する必要があります。

app.conf.result_backend_transport_options = {'master_name': "mymaster"}

接続タイムアウト

Redis結果バックエンドの接続タイムアウトを設定するには、：setting： `result_backend_transport_options` の下にあるretry_policyキーを使用します。

app.conf.result_backend_transport_options = {
    'retry_policy': {
       'timeout': 5.0
    }
}

可能な再試行ポリシーオプションについては、retry_over_time()を参照してください。

警告

可視性のタイムアウト

可視性タイムアウト内にタスクが確認応答されない場合、タスクは別のワーカーに再配信されて実行されます。

これにより、実行時間が可視性タイムアウトを超えるETA /カウントダウン/再試行タスクで問題が発生します。実際、それが発生した場合、それは再び実行され、ループで再び実行されます。

したがって、使用する予定の最長のETAの時間に一致するように、可視性のタイムアウトを増やす必要があります。

Celeryはワーカーのシャットダウン時にメッセージを再配信するため、可視性のタイムアウトが長いと、停電や強制終了したワーカーが発生した場合にのみ、「失われた」タスクの再配信が遅れることに注意してください。

これはETA /カウントダウンとは別の概念であるため、定期的なタスクは可視性タイムアウトの影響を受けません。

同じ名前のトランスポートオプションを設定することで、このタイムアウトを増やすことができます。

app.conf.broker_transport_options = {'visibility_timeout': 43200}

値は、秒数を表す整数である必要があります。

キーエビクション

状況によっては、Redisがデータベースからキーを削除する場合があります

次のようなエラーが発生した場合：

InconsistencyError: Probably the key ('_kombu.binding.celery') has been
removed from the Redis database.

次に、redis構成ファイルで設定して、キーを削除しないように redis-server を構成することをお勧めします。

maxmemoryオプション
maxmemory-policyオプションからnoevictionまたはallkeys-lru

詳細については、エビクションポリシーに関するRedisサーバーのドキュメントを参照してください。

https://redis.io/topics/lru-cache

グループ結果の順序

4.4.6までのバージョンのCeleryは、ソートされていないリストを使用して、グループの結果オブジェクトをRedisバックエンドに格納していました。これにより、これらの結果が、元のグループのインスタンス化で関連付けられたタスクとは異なる順序で返される可能性があります。 Celery 4.4.7では、この問題を修正し、他のバックエンドの動作と一致する、タスクが定義されたのと同じ順序でグループの結果が返されるようにするオプトイン動作が導入されました。 Celery 5.0では、この動作がオプトアウトに変更されました。動作は、次のように設定できる result_chord_ordered 構成オプションによって制御されます。

# Specifying this for workers running Celery 4.4.6 or earlier has no effect
app.conf.result_backend_transport_options = {
    'result_chord_ordered': True    # or False
}

これは、結果ストレージ用に同じRedisバックエンドを共有するワーカーのランタイム動作の互換性のない変更であるため、破損を回避するために、すべてのワーカーは新しい動作または古い動作のいずれかに従う必要があります。 Celery 4.4.6以前を実行している一部のワーカーがあるクラスターの場合、これは、4.4.7を実行しているワーカーは特別な構成を必要とせず、5.0以降を実行しているワーカーは result_chord_ordered を False に設定する必要があることを意味します。 4.4.6以前を実行しているワーカーがないが、4.4.7を実行している一部のワーカーがあるクラスターの場合、将来の移行を容易にするために、すべてのワーカーに対して result_chord_ordered を True に設定することをお勧めします。動作間の移行は、現在Redisバックエンドに保持されている結果を混乱させ、移行されたワーカーによってダウンストリームタスクが実行されると、破損を引き起こします-それに応じて計画してください。

Redisの使用—Pythonドキュメント

目次