タスクの大部分は個々のワーカーに向けられます（たとえば、「get_status」ジョブを「system51」に送信します）—これは問題になりますか？
全くない。ワーカーごとにキューを作成するだけです。たとえば、default各ノードが呼び出されたラウンドロビンキューをリッスンし、各ノードにノード名にちなんで名付けられた独自のキューがあるとします。
(a)$ celeryd -n a.example.com -Q default,a.example.com
(b)$ celeryd -n b.example.com -Q default,b.example.com
(c)$ celeryd -n c.example.com -Q default,c.example.com
タスクをノードに直接ルーティングするのは簡単です。
$ get_status.apply_async(args, kwargs, queue="a.example.com")
またはRouter：を使用した構成
# Always route "app.get_status" to "a.example.com"
CELERY_ROUTES = {"app.get_status": {"queue": "a.example.com"}}
不利なネットワーク状態（接続の切断など）を適切に処理しますか？
ワーカーは、ブローカー接続の障害から正常に回復します。（少なくともRabbitMQからは、他のすべてのバックエンドについてはわかりませんが、これはテストと修正が簡単です（関連する例外をリストに追加するだけで済みます）
クライアントの場合、接続がダウンしている場合はいつでもタスクの送信を再試行できます。または、RabbitMQを使用してHAを設定できます：http ：//www.rabbitmq.com/pacemaker.html
RabbitMQがバックエンドとして使用されている場合にのみ使用できる機能は何ですか？（フィールドシステムでRabbitMQを実行したくない）
リモートコントロールコマンド、および「直接」交換のみがサポートされています（「トピック」または「ファンアウト」はサポートされていません）。ただし、これは昆布（http://github.com/ask/kombu）でサポートされます。
RabbitMQの使用を真剣に再考します。なぜそれがうまく合わないと思いますか？私見私はこのようなシステムを他の場所で探すことはありません（システムが一時的でメッセージの永続性を必要としない場合はZeroMQを除いて）。
私が説明したようにセロリを使用した場合、セロリが私の人生を困難にする可能性がある他の理由はありますか？
あなたが上で述べたことから私は何も考えられません。同時実行モデルはマルチプロセッシングであるため、ある程度のメモリが必要です（スレッドプールとイベントレットプールのサポートの追加に取り組んでいます。これは場合によっては役立つ可能性があります）。
セロリがやり過ぎだと示唆するのは妥当ですが、それが私の人生を楽にする他の理由があるので、それを検討したいと思います）
その場合、あなたは「やり過ぎ」という言葉を軽く使うと思います。それは本当にあなたがそれなしで書く必要があるコードとテストの量に依存します。既存の一般的なソリューションを改善する方が良いと思います。理論的には、アプリケーションでうまく機能するはずです。