過去に、送信者と受信者の両方がCelery経由で処理するためにRabbitMQに送信されるタスクを理解するCelery async pythonおよびDjangoアプリケーションを使用しました(クラスター内の同じアプリなど)。
現在、.NET サービスがメッセージを JSON の形式で RabbitMQ に発行しているユース ケースがあります。キューごとに 1 つのメッセージ タイプです。.NET アプリはメッセージを発行するだけで、Rabbit が適切に受信したことを確認してから立ち去ります。次に、メッセージを消費するために Django アプリケーションを実行します。したがって、これらの JSON メッセージを消費する適切な方法がわからないため、この Django アプリはモデルを介してデータを単純に保存し、メッセージが処理されたことを確認できます。
Celery/Kombu を使用する キューにアクセスするための最良の方法がわからないため、キューごとに直接消費者がいます。Celery は内部で Kombu を使用していることを理解しているので、そこでコンシューマーを作成できると思いますが、Celery と Flower のようにプロセスを管理することは不可能であり、アプリの開始時に不正なスレッド コンシューマーを作成するのは不安定に思えます。せいぜい。