バックエンドとブローカー—Pythonドキュメント
バックエンドとブローカー
- リリース
- 日にち
- 2021年10月15日
Celeryは、いくつかのメッセージ転送の選択肢をサポートしています。
ブローカーの概要
これは、さまざまなトランスポートサポートの比較表です。詳細については、個々のトランスポートのドキュメントを参照してください（ブローカーの説明を参照）。
| 名前 | 状態 | モニタリング | リモコン |
| RabbitMQ | 安定 | はい | はい |
| Redis | 安定 | はい | はい |
| Amazon SQS | 安定 | 番号 | 番号 |
| Zookeeper | 実験的 | 番号 | 番号 |
実験的なブローカーは機能しているかもしれませんが、専任のメンテナーがいません。
モニターのサポートがないということは、トランスポートがイベントを実装していないことを意味します。そのため、Flower、セロリイベント、セロリモンおよびその他のイベントベースのモニターツールは機能しません。
リモートコントロールとは、 celery inspect および celery control コマンド（およびリモートコントロールAPIを使用するその他のツール）を使用して、実行時にワーカーを検査および管理する機能を意味します。
要約
注：このセクションは、バックエンドとブローカーを網羅していません。
Celeryには、さまざまなバックエンド（結果ストア）およびブローカー（メッセージトランスポート）と通信および保存する機能があります。
Redis
Redisは、バックエンドとブローカーの両方になることができます。
ブローカーとして： Redisは、小さなメッセージの迅速な転送に適しています。 大きなメッセージはシステムを混雑させる可能性があります。
バックエンドとして： Redisは超高速のK / Vストアであるため、タスク呼び出しの結果を取得するのに非常に効率的です。 Redisの設計と同様に、データの保存に使用できるメモリの制限と、データの永続性の処理方法を考慮する必要があります。 結果の永続性が重要な場合は、バックエンドに別のDBを使用することを検討してください。
RabbitMQ
RabbitMQはブローカーです。
ブローカーとして： RabbitMQはRedisよりも大きなメッセージをより適切に処理しますが、多くのメッセージが非常に迅速に受信される場合、スケーリングが問題になる可能性があるため、RabbitMQが非常に大規模に実行されていない限り、RedisまたはSQSを検討する必要があります。
バックエンドとして： RabbitMQは、rpc://バックエンドを介して結果を保存できます。 このバックエンドは、クライアントごとに個別の一時キューを作成します。
注：RabbitMQ（ブローカーとして）とRedis（バックエンドとして）は非常に一般的に一緒に使用されます。 結果ストアからより保証された長期永続性が必要な場合は、PostgreSQLまたはMySQL（SQLAlchemyを介して）、Cassandra、またはカスタム定義のバックエンドの使用を検討してください。
SQS
SQSはブローカーです。
すでにAWSと緊密に統合していて、SQSに精通している場合は、ブローカーとして優れたオプションを提供します。 非常にスケーラブルで完全に管理されており、RabbitMQと同様にタスクの委任を管理します。 worker remote control commandsなどのRabbitMQブローカーの機能の一部が欠けています。
SQLAlchemy
SQLAlchemyはバックエンドです。
これにより、CeleryはMySQL、PostgreSQL、SQliteなどとインターフェイスできます。 これはORMであり、Celeryが結果のバックエンドとしてSQLDBを使用する方法です。 歴史的に、SQLAlchemyは最も安定した結果バックエンドではなかったため、選択した場合は注意して続行する必要があります。
