Celery: 同じタスクが一度に複数回実行されますか？

多分これは可視性タイムアウトに関連していますか？

@georgepsarakis疑惑について詳しく教えていただけますか？

私の知る限り、これはAMQPの確認応答特性が組み込まれていないブローカートランスポートの既知の問題です。 タスクの完了時間が可視性タイムアウトを超えると、タスクは新しいワーカーに割り当てられるため、タスクが並行して実行されていることがわかります。

@georgepsarakisそれで、タスクがはるかに先にスケジュールされている場合、私は上記を見るかもしれませんか？ 「可視性タイムアウト」はそれに対処しますか？ リンクしたドキュメントから：

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

つまり、1時間以内にワーカーがタスクを確認しなかった場合（つまり、実行しなかった場合）、そのタスクは確認しなかった別のワーカーに送信されます。ドキュメント; この関連する問題https://github.com/celery/kombu/issues/337; またはこのブログからの引用：

しかし、開発者がそれを使い始めたばかりのとき、彼らは定期的に労働者の異常な振る舞い、特に複数の労働者による同じタスクの複数の実行に直面します。 それを引き起こす理由は、可視性タイムアウト設定です。

visibility_timeoutを31,540,000秒（1年）に設定すると、簡単に修正できる可能性があります。

可視性のタイムアウトを2時間に増やすと、タスクは1回だけ実行されます。

したがって、組み合わせると：

• Redisブローカー
• 遅い承認
• ETAが可視性タイムアウト以上
  タスクに対して複数の実行があります。

私は何が起こるかと思います：

• 1時間が経過すると、1つのワーカープロセスがタスクの処理を開始します。
• 2番目のワーカーは、このメッセージが可視性タイムアウトより長くキューにあり、別のワーカーによって処理されていることを確認します。
• メッセージはキューに復元されます。
• 別のワーカーが同じメッセージの処理を開始します。
• 上記はすべてのワーカープロセスで発生します。

Redisトランスポートの実装を調べると、ソートされたセットを使用しており、キューに入れられた時間をスコアとしてzaddに渡していることがわかります。 メッセージはそのタイムスタンプに基づいて復元され、可視性タイムアウトに等しい間隔と比較されます。

これがRedisトランスポートの内部を少し説明することを願っています。

@georgepsarakis 、私は今完全に混乱しています。 タスクのETAが今から2か月後に設定されている場合、タスクがスケジュールされてから1時間後にワーカーがそれを受け取るのはなぜですか？ 私は何かが足りないのですか？

私の（間違った？）仮定は次のとおりです：

• 私は将来いつでもETAでタスクをスケジュールします。 それから
• タスク（つまり、マーシャリングされた引数）とETAは、ETAが到着するまでキューに残ります。 それから
• ワーカーはETAでタスクの処理を開始します。

上記の「_私は何が起こるか：_」は私の仮定とはかなり異なります。

私も同じ問題に遭遇しました、あなたはそれを解決しましたか？ @jenstroeger

ありがとう！

@jenstroegerは実行可能なフローのようには聞こえませんが、ETA条件が最終的に満たされるまで実行を延期するために、ワーカーはメッセージを継続的に再キューイングするだけだと思います。 キューの概念は、メッセージが到着するとすぐに配信することです。そのため、ワーカーはメッセージを調べて、再キューイングするだけです。

これは私の推測であることに注意してください。私はETA実装の内部を実際には認識していません。

@zivsu 、上記のように、 visibility_timeoutを_非常に_大きな数値に設定しましたが、これで症状は解決したようです。 ただし、 @ georgepsarakisが指摘しているように、これは不適切なアプローチのようです。

元の問題の原因も、適切に対処する方法もわかりません。

@jenstroegerブログを読んだのですが、 visibility_timeoutを変更しても問題を完全に解決できないため、ボーカーをrabbitmqに変更します。

@zivsu 、ブログへのリンクを教えていただけますか？ 以前にRedisを使用しましたか？

@jenstroegerブログが見つかりません。以前、Redisをブローカーとして使用していました。 スケジュールタスクでは、エラーが再発しないようにrebbitmqを選択します。

私はまったく同じ問題を抱えています、私の設定は次のとおりです：
django == 1.11.6
セロリ==4.2rc2
django-celery-beat == 1.0.1

設定：

CELERY_ENABLE_UTC = True
# CELERY_TIMEZONE = 'America/Los_Angeles'

そして、それがこの設定の唯一の有効な組み合わせです。 また、UTCタイムゾーンで定期的なタスクをスケジュールする必要があります。
CELERY_TIMEZONEを有効にするか、 CELERY_ENABLE_UTCを無効にすると、定期的なタスクの実行が複数回開始されます。

保存に問題があります。 redisをブローカーとして使用する場合、etaタスクは複数回実行します。
これを解決する方法。
ブローカーをredisからrabbitmqに変更すると、この問題が解決するように見えます。

redisを使用すると、UTC以外のタイムゾーンを指定するときによく知られている問題があります。 この問題を回避するには、デフォルトアプリをサブクラス化し、独自のタイムゾーン処理関数を追加します。

from celery import Celery


class MyAppCelery(Celery):
    def now(self):
        """Return the current time and date as a datetime."""
        from datetime import datetime
        return datetime.now(self.timezone)

この問題に直面している他の人の助けになることを願っています。

マルチコアマシンでビートを使用してセロリジョブを頻繁に再起動すると、この問題が発生することがあります。 私はそれを解決するためにps aux | grep celery 、次にkill <each_pid>を実行する習慣を身につけました。

私が持っている最善のアドバイスは、マシンから切断する前に、常に「restartDONE」メッセージが表示されることを確認することです。

{"log":"INFO 2018-10-09 17:41:08,468 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T17:41:08.468912644Z"}
{"log":"INFO 2018-10-09 17:41:08,468 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T17:41:08.468955918Z"}
{"log":"INFO 2018-10-09 19:46:04,293 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T19:46:04.293780045Z"}
{"log":"INFO 2018-10-09 19:46:04,293 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T19:46:04.293953621Z"}
{"log":"INFO 2018-10-09 20:46:04,802 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T20:46:04.802819711Z"}
{"log":"INFO 2018-10-09 20:46:04,802 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T20:46:04.802974829Z"}
{"log":"INFO 2018-10-09 21:46:05,335 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T21:46:05.336081133Z"}
{"log":"INFO 2018-10-09 21:46:05,335 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T21:46:05.336107517Z"}
{"log":"INFO 2018-10-09 22:46:05,900 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T22:46:05.901078395Z"}
{"log":"INFO 2018-10-09 22:46:05,900 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T22:46:05.901173663Z"}
{"log":"INFO 2018-10-09 23:46:06,484 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T23:46:06.485276904Z"}
{"log":"INFO 2018-10-09 23:46:06,484 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-09T23:46:06.485415253Z"}
{"log":"INFO 2018-10-10 00:46:07,072 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T00:46:07.072529828Z"}
{"log":"INFO 2018-10-10 00:46:07,072 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T00:46:07.072587887Z"}
{"log":"INFO 2018-10-10 01:46:07,602 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T01:46:07.60325321Z"}
{"log":"INFO 2018-10-10 01:46:07,602 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T01:46:07.603327426Z"}
{"log":"INFO 2018-10-10 02:46:08,155 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T02:46:08.155868992Z"}
{"log":"INFO 2018-10-10 02:46:08,155 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T02:46:08.155921893Z"}
{"log":"INFO 2018-10-10 03:46:08,753 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T03:46:08.75401387Z"}
{"log":"INFO 2018-10-10 03:46:08,753 strategy celery.worker.strategy 1 140031597243208 Received task: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f]  ETA:[2018-10-10 04:00:00+00:00] \n","stream":"stderr","time":"2018-10-10T03:46:08.754056891Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.013548928Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.013592318Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:71\n","stream":"stderr","time":"2018-10-10T04:00:00.014000106Z"}
{"log":"DEBUG 2018-10-10 04:00:00,013 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:71\n","stream":"stderr","time":"2018-10-10T04:00:00.014167558Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:64\n","stream":"stderr","time":"2018-10-10T04:00:00.014661348Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:64\n","stream":"stderr","time":"2018-10-10T04:00:00.014684354Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.01514884Z"}
{"log":"DEBUG 2018-10-10 04:00:00,014 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.015249646Z"}
{"log":"DEBUG 2018-10-10 04:00:00,015 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:66\n","stream":"stderr","time":"2018-10-10T04:00:00.01571124Z"}
{"log":"DEBUG 2018-10-10 04:00:00,015 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:66\n","stream":"stderr","time":"2018-10-10T04:00:00.01580249Z"}
{"log":"DEBUG 2018-10-10 04:00:00,019 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:68\n","stream":"stderr","time":"2018-10-10T04:00:00.019260948Z"}
{"log":"DEBUG 2018-10-10 04:00:00,019 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:68\n","stream":"stderr","time":"2018-10-10T04:00:00.019322151Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.245159563Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:70\n","stream":"stderr","time":"2018-10-10T04:00:00.245177267Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:67\n","stream":"stderr","time":"2018-10-10T04:00:00.245338722Z"}
{"log":"DEBUG 2018-10-10 04:00:00,245 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:67\n","stream":"stderr","time":"2018-10-10T04:00:00.245351289Z"}
{"log":"DEBUG 2018-10-10 04:00:00,256 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.256770035Z"}
{"log":"DEBUG 2018-10-10 04:00:00,256 request celery.worker.request 1 140031597243208 Task accepted: main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] pid:65\n","stream":"stderr","time":"2018-10-10T04:00:00.256788689Z"}
{"log":"INFO 2018-10-10 04:00:00,371 trace celery.app.trace 68 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.35710329699213617s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.371967002Z"}
{"log":"INFO 2018-10-10 04:00:00,371 trace celery.app.trace 68 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.35710329699213617s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.371983293Z"}
{"log":"INFO 2018-10-10 04:00:00,387 trace celery.app.trace 69 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.10637873200175818s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.388119538Z"}
{"log":"INFO 2018-10-10 04:00:00,387 trace celery.app.trace 69 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.10637873200175818s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.388166317Z"}
{"log":"INFO 2018-10-10 04:00:00,404 trace celery.app.trace 70 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.16254851799749304s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.404834545Z"}
{"log":"INFO 2018-10-10 04:00:00,404 trace celery.app.trace 70 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.16254851799749304s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.404862208Z"}
{"log":"INFO 2018-10-10 04:00:00,421 trace celery.app.trace 65 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.1654666289978195s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.421607856Z"}
{"log":"INFO 2018-10-10 04:00:00,421 trace celery.app.trace 65 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.1654666289978195s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.421674687Z"}
{"log":"INFO 2018-10-10 04:00:00,438 trace celery.app.trace 67 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.19588526099687442s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.438295459Z"}
{"log":"INFO 2018-10-10 04:00:00,438 trace celery.app.trace 67 140031597243208 Task main.batch.sendspam[2a6e5dc8-5fd2-40bd-8f65-7e7334a14b3f] succeeded in 0.19588526099687442s: None\n","stream":"stderr","time":"2018-10-10T04:00:00.438311386Z"}
...

受信したタスクのタイムスタンプを確認すると、1時間ごとに同じIDの新しいタスクが取得されます。 その結果、すべてのETAメッセージが10回以上送信されます。 ETAを使用する場合はrabbitmqが唯一のオプションのようです

最近、同様のバグに遭遇します。 またps aux | grep celeryは、ワーカーが開始したよりも2倍多いプロセスを示しました。 コマンド起動セロリワーカーにパラメーター--pool geventを追加すると、プロセス数が開始ワーカーの正確な数とセロリビートに減少しました。 そして今、私は自分のタスクの実行を無駄にしています。

別の解決策は、ackエミュレーションを完全に無効にすることでしょうか？ つまり"broker_transport_options": {"ack_emulation": False} 。 短期間のタスク/カウントダウンの欠点はありますか？

誰かが修正を取得しましたか？

同じ問題に直面しています、それに対する解決策はありますか？

バンピング、同じ問題。

ここでも同じ問題があり、Redisをブローカーとして使用しています。

$ pipenv graph --bare | grep -i "redis\|celery"                                                                                                                                                                                                                              
---
channels-redis==2.4.0
  - aioredis [required: ~=1.0, installed: 1.3.0]
    - hiredis [required: Any, installed: 1.0.0]
django-celery-beat==1.5.0
django-celery-results==1.1.2
  - celery [required: >=4.3,<5.0, installed: 4.3.0]
  - celery [required: >=3.1.0, installed: 4.3.0]
  - pylint-celery [required: ==0.3, installed: 0.3]
redis==3.2.1

ここでも同じ問題があります。 セロリバージョン4.3.0
celery = Celery（'tasks'、broker ='pyamqp：// nosd：sdsd @ rabit //'、config_from_object = {"broker_transport_options"：{'visibility_timeout'：18000}}）

ワーカーを実行するために使用するコマンド
celery-Aタスクワーカー--pidfile=/tmp/celery_worker.pid -f = /tmp/celery_worker.log -Q celery_queue --loglevel = info --pool = solo --concurrency = 1 -n worker_celery --detach - without-gossip --without-mingle --without-heartbeat

celery == 4.4.0rc4を試してみませんか？

Celeryは、同じタスクIDを同時に使用して、同じタスクを2回受信しています。
これがログです

[2019-11-29 08:07:35,464: INFO/MainProcess] Received task: app.jobs.booking.bookFlightTask[657985d5-c3a3-438d-a524-dbb129529443]  
[2019-11-29 08:07:35,465: INFO/MainProcess] Received task: app.jobs.booking.bookFlightTask[657985d5-c3a3-438d-a524-dbb129529443]  
[2019-11-29 08:07:35,471: WARNING/ForkPoolWorker-4] in booking funtion1
[2019-11-29 08:07:35,473: WARNING/ForkPoolWorker-3] in booking funtion1
[2019-11-29 08:07:35,537: WARNING/ForkPoolWorker-3] book_request_pp
[2019-11-29 08:07:35,543: WARNING/ForkPoolWorker-4] book_request_pp

両方が同時に実行されています、

celery == 4.4.0rc4、boto3 == 1.9.232、kombu == 4.6.6を使用し、PythonフラスコでSQSを使用します。
SQSでは、デフォルトの可視性タイムアウトは30分であり、私のタスクにはETAがなく、ackもありません。

のような実行中の労働者、
セロリワーカー-Aapp.jobs.run-l info --pidfile = / var / run / celery / celery.pid --logfile = / var / log / celery / celery.log --time-limit = 7200 --concurrency = 8

@auvipy 、どんな助けでも素晴らしいでしょう。

どのブローカーと結果のバックエンドを使用していますか？ 別のバックエンドに切り替えてみてください。

どのブローカーと結果のバックエンドを使用していますか？ 別のバックエンドに切り替えてみてください。

SQSを使用すると、結果のバックエンドはMYSQLであり、sqlalchemyを使用します。
詳細はSO、 https：//stackoverflow.com/questions/59123536/celery-is-receiveing-same-task-twice-with-same-task-id-at-same-timeにあります
@auvipyご覧ください。

@thedrowブルームバーグでこの問題に直面していますか？

@ nitish-itilite：セロリにどのタイムゾーンを使用していますか？

@ nitish-itilite：セロリにどのタイムゾーンを使用していますか？

デフォルトのUTCです。 平方では、地域はこの米国東部（バージニア州北部）です。

SQSでセロリを実行している同様のケースがありました。 countdown=60でダミータスクを実行しましたが、SQSの可視性タイムアウトは30秒です。 これが私が得るものです：

注：私は--concurrency=1でセロリを始めたので、2つのスレッドがありますよね？

[2020-02-18 14:46:32 +0000] [INFO] Received task: notification[b483a22f-31cc-4335-9709-86041baa8f05]  ETA:[2020-02-18 14:47:31.898563+00:00] 
[2020-02-18 14:47:02 +0000] [INFO] Received task: notification[b483a22f-31cc-4335-9709-86041baa8f05]  ETA:[2020-02-18 14:47:31.898563+00:00] 
[2020-02-18 14:47:32 +0000] [INFO] Task notification[b483a22f-31cc-4335-9709-86041baa8f05] succeeded in 0.012232275999849662s: None
[2020-02-18 14:47:32 +0000] [INFO] Task notification[b483a22f-31cc-4335-9709-86041baa8f05] succeeded in 0.012890915997559205s: None

時系列で何が起こったのか：

1. 14:46:32タスクが受信され、SQSはそれをinflightモードで30秒間置きました
2. 14:47:02可視性のタイムアウトが期限切れになったため、同じタスクを受信しました
3. 14:47:32両方のタスクが同時に実行されます

私の推測では、これはCelery（？）のバグであり、メッセージID（ b483a22f-31cc-4335-9709-86041baa8f05 ）がそのワーカーによってすでに取得されているかどうかを確認する必要があったと思います。

セロリが受信したタスクが処理に有効かどうかを判断できるように、すべてのメッセージIDを含むハッシュリストが存在する可能性があります。 セロリはそれをすることができますか？

注2：
ワーカーが実際に死亡した場合、メッセージが別のワーカーによって取得されるまでに時間がかかりすぎるため、可視性のタイムアウトを長く設定することはできません。 設定が低すぎると、この状態が発生します。

これは私にも起こっているようです。

[2020-05-11 15：31：23,673：INFO / MainProcess]受信したタスク：ee_external_attributes.tasks。 recreate_specific_values [53046bd7-2a19-4f72-808f-d712eaecb0e8]
[2020-05-11 15：31：28,673：INFO / MainProcess]受信したタスク：ee_external_attributes.tasks.recreate_specific_values [53046bd7-2a19-4f72-808f-d712eaecb0e8]

（公開投稿用にログのタスク名を微調整しました。）

一意性の制約により、1人のワーカーがタスクの途中でエラーをスローし、もう1人は成功します。

設定してみました
CELERY_WORKER_PREFETCH_MULTIPLIER = 1
それは役に立たなかったことが判明しました。

私が使用している
セロリ==4.4.1
django-celery-results == 1.2.1

そして、キューにAWSSQSを使用しています。

私には理論があります。 どうやら私のキューの「デフォルトの可視性タイムアウト」設定は5秒にしか設定されていませんでした。 最初の労働者が死亡したと想定したため、最初の労働者が作業中に2番目の労働者が仕事を引き抜いた可能性があります。 可視性のタイムアウトを2分に増やしましたが、うまくいっているようです。 8〜12秒かかるタスクがたくさんあったので、2分はやり過ぎかもしれません。 しかし、うまくいけば、それはそれを解決します。

最初の労働者が死亡したと想定したため、最初の労働者が作業中に2番目の労働者が仕事を引き抜いた可能性があります。

@JulieGoldberg 、それはセロリが仕事を処理するための厄介な方法になるでしょう。 Celeryワーカーは、別のワーカーがキューから取り出してアクティブに処理しているジョブを開始しないでください。 それはひどく壊れると思います。 （しかし、それはセロリです、私はもう何にも驚いていません😒）

Kubernetesで実行されているアプリケーションでも同様の問題が発生します。 Kubernetesインスタンスには、Redisからのタスクを消費する10人のワーカー（セロリアプリインスタンス）があります。

症状：
セロリ労働者は、30分後に計画されるETAタスクをスケジュールします。 Kubernetesポッドがローテーションされた場合（ワーカーがKubernetesによって強制終了された場合）、またはアプリケーションの新しいバージョンがデプロイされた場合（すべてのワーカーが強制終了され、新しいワーカーが作成された場合）、すべてのワーカーがスケジュールされたタスクを実行し、定義された時間に実行を開始します。
ワーカーの場合、1年までの数時間にわたってvisibility_timeoutの異なる値を設定しようとしましたが、結果は同じでした。 enable_utc = Trueの設定、またはworker_prefetch_multiplier = 1の削減でも、同じ動作が達成されました。

これが誰かに役立つかどうかはわかりませんが、これは私の問題でした：

GETを介してページがロードされたときに実行されていたタスク（レポート生成）がありました。 何らかの理由で（ファビコンと関係があります）、Chromeはページの読み込みごとに2つのGETリクエストを送信し、タスクを2回トリガーします。
GETリクエストは副作用がないはずなので、すべてフォームに変換して送信すると、問題は解決しました。

最初の労働者が死亡したと想定したため、最初の労働者が作業中に2番目の労働者が仕事を引き抜いた可能性があります。

@JulieGoldberg 、それはセロリが仕事を処理するための厄介な方法になるでしょう。 Celeryワーカーは、別のワーカーがキューから取り出してアクティブに処理しているジョブを開始しないでください。 それはひどく壊れると思います。 （しかし、それはセロリです、私はもう何にも驚いていません😒）

不平を言う代わりに、解決策とPRを考え出すことで、問題の解決に役立てることができます。

Kubernetesで実行されているアプリケーションでも同様の問題が発生します。 Kubernetesインスタンスには、Redisからのタスクを消費する10人のワーカー（セロリアプリインスタンス）があります。

症状：
セロリ労働者は、30分後に計画されるETAタスクをスケジュールします。 Kubernetesポッドがローテーションされた場合（ワーカーがKubernetesによって強制終了された場合）、またはアプリケーションの新しいバージョンがデプロイされた場合（すべてのワーカーが強制終了され、新しいワーカーが作成された場合）、すべてのワーカーがスケジュールされたタスクを実行し、定義された時間に実行を開始します。

@elMateso k8s（ポッド上のコンシューマーとキューとしてのredis）でのAirflowのデプロイで同様の問題に直面しました。 しかし、デプロイメントを安定させて期待どおりに機能させることができました。おそらく、これらのヒントが役立つでしょう。
https://www.polidea.com/blog/application-scalability-kubernetes/#tips -for-hpa

ここで同じことに直面しています。

少なくとも私にとっては、タイミング構成（可視性タイムアウト、ETAなど）に問題はないようです。 私の場合、実行の間にマイクロ秒が発生します。 セロリが実際にメッセージをACKする方法は見つかりませんでしたが、rabbitMQで完全に機能している場合は、Redisの同時実行性とACKに問題があるようです。

同じ問題が発生しており、Redisをブローカーとしても使用しています。 rabbitMQに変更することは私たちの選択肢ではありません。

タスクが1回だけ実行されるようにロックを使用しようとした人はいますか？ それはうまくいくでしょうか？

例： https ：//docs.celeryproject.org/en/latest/tutorials/task-cookbook.html#ensuring -a-task-is-only-executed-one-at-a-time

@ErikKalkoken私たちはまさにそれをすることになります。

def semaphore(fn):
    @wraps(fn)
    def wrapper(self_origin, *args, **kwargs):
        cache_name = f"{UID}-{args[0].request.id}-semaphore"
        agreement_redis = AgreementsRedis()
        if not agreement_redis.redis.set(cache_name, "", ex=30, nx=True):
          Raise Exception("...")
        try:
            return fn(self_origin, *args, **kwargs)
        finally:
            agreement_redis.redis.delete(cache_name)

    return wrapper

上記のコードはセロリには使用されていませんが、セロリの複数の実行は同じロジックであり、task_idを取得してキャッシュを設定するだけです。 これまでのところ正常に動作しています。

誰かがこのPRをチェックできますかhttps://github.com/vinayinvicible/kombu/commit/a755ba14def558f2983b3ff3358086ba55521dcc