Celery: 동일한 작업이 한 번에 여러 번 실행됩니까?

아마도 이것은 가시성 시간 초과 와 관련이 있습니까?

@georgepsarakis 의혹에 대해 자세히 설명해 주시겠습니까?

내가 아는 한 이것은 AMQP의 기본 제공 승인 특성 이 없는 브로커 전송에 대해 알려진 문제입니다. 작업 완료 시간이 가시성 제한 시간을 초과하면 작업이 새 작업자에게 할당되므로 작업이 병렬로 실행되는 것을 볼 수 있습니다.

@georgepsarakis 작업이 훨씬 더 먼 미래에 예정되어 있다면 위의 내용을 볼 수 있을까요? "가시성 시간 초과"가 이를 해결합니까? 링크 한 문서에서 :

Redis의 기본 가시성 제한 시간은 1시간입니다.

한 시간 내에 작업자가 작업을 승인하지 않으면(즉, 실행합니까?) 해당 작업은 승인하지 않을 다른 작업자에게 전송되는 식입니다... 실제로 이것은 다음의 경고 섹션을 보는 경우인 것 같습니다. 문서; 이 관련 문제 https://github.com/celery/kombu/issues/337; 또는 이 블로그 에서 인용:

그러나 개발자가 막 사용하기 시작하면 정기적으로 작업자의 비정상적인 동작, 특히 여러 작업자가 동일한 작업을 여러 번 실행하는 문제에 직면하게 됩니다. 그 원인은 가시성 시간 초과 설정입니다.

visibility_timeout 를 31,540,000초(1년)로 설정하는 것이 빠른 수정일 수 있습니다.

가시성 제한 시간을 2시간으로 늘리면 작업이 한 번만 실행됩니다.

따라서 다음을 결합하면:

• 레디스 브로커
• 늦은 확인
• 가시성 시간 초과와 동일하거나 초과하는 ETA
  작업에 대해 여러 번 실행됩니다.

나는 무슨 일이 일어나는지 생각한다:

• 한 시간이 지나면 한 작업자 프로세스가 작업 처리를 시작합니다.
• 두 번째 작업자는 이 메시지가 표시 제한 시간보다 오래 대기열에 있었고 다른 작업자가 처리하고 있음을 알 수 있습니다.
• 메시지가 대기열에서 복원됩니다.
• 다른 작업자가 동일한 메시지 처리를 시작합니다.
• 위의 작업은 모든 작업자 프로세스에 대해 발생합니다.

Redis 전송 구현을 살펴보면 Sorted Sets를 사용하여 대기 시간을 zadd 에 점수로 전달한다는 것을 알 수 있습니다. 메시지는 해당 타임스탬프를 기반으로 복원되며 가시성 타임아웃 과 동일한 간격과 비교됩니다.

이것이 Redis 전송의 내부를 약간 설명하기를 바랍니다.

@georgepsarakis , 나는 이제 완전히 혼란스러워합니다. 작업의 ETA가 지금부터 2개월로 설정되어 있는 경우 작업자가 작업이 예약된 후 1시간 후에 이를 픽업하는 이유는 무엇입니까? 내가 뭔가를 놓치고 있습니까?

내 (잘못된?) 가정은 다음과 같습니다.

• 나는 미래의 언제든지 ETA로 작업을 예약합니다. 그 다음에
• 작업(즉, 정렬된 인수)과 ETA는 ETA가 도착할 때까지 대기열에 있습니다. 그 다음에
• 작업자는 ETA에서 작업 처리를 시작합니다.

위의 "_나는 무슨 일이 일어나는지 생각합니다:_"는 내 가정과 상당히 다릅니다.

저도 같은 문제가 발생했는데 해결하셨나요? @jenstroeger

감사 해요!

@jenstroeger 는 실현 가능한 흐름이 아닌 것처럼 들리는데 ETA 조건이 충족될 때까지 실행을 연기하기 위해 작업자가 계속 메시지를 requeue하는 것 같습니다. 대기열의 개념은 메시지가 도착하는 즉시 배포하는 것이므로 작업자는 메시지를 검사하고 대기열에 추가합니다.

이것은 내 추측이며 ETA 구현의 내부를 실제로 알지 못합니다.

@zivsu , 위에서 언급했듯이 visibility_timeout 을 _매우_ 큰 숫자로 설정했는데 증상이 해결된 것 같습니다. 그러나 @georgepsarakis가 지적했듯이 이는 좋지 않은 접근 방식인 것 같습니다.

원래 문제의 원인도 모르고, 어떻게 제대로 대처해야 하는지도 모릅니다.

@jenstroeger 블로그를 읽고 visibility_timeout 를 변경해도 문제를 완전히 해결할 수 없으므로 보커를 rabbitmq 로 변경합니다.

@zivsu , 블로그 링크를 공유할 수 있습니까? 이전에 Redis를 사용하셨습니까?

@jenstroeger 블로그를 찾을 수 없습니다. 이전에 Redis를 브로커로 사용했습니다. 일정 작업의 경우 오류가 다시 발생하지 않도록 rebbitmq를 선택합니다.

정확히 같은 문제가 있습니다. 내 구성은 다음과 같습니다.
장고==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 를 비활성화하면 주기적 작업을 여러 번 실행하기 시작합니다.

세이브 문제가 있습니다. eta 작업은 redis를 브로커로 사용할 때 곱하기 시간을 실행합니다.
이거 해결 방법좀..
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> 을 실행하는 습관을 들였습니다.

제가 드릴 수 있는 가장 좋은 조언은 기기에서 연결을 끊기 전에 항상 "다시 시작 완료" 메시지가 표시되는지 확인하는 것입니다.

{"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"}
...

Received task timestamps를 확인하면 매시간 동일한 ID로 새 작업을 가져옵니다. 결과는 모든 ETA 메시지가 10번 이상 전송된다는 것입니다. ETA를 사용하려는 경우에만 rabbitmq가 옵션인 것 같습니다.

최근에 비슷한 버그를 만났습니다. 또한 ps aux | grep celery 는 작업자가 시작한 것보다 두 배 더 많은 프로세스를 보여주었습니다. 셀러리 작업자 실행 명령에 매개변수 --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
셀러리 = 셀러리('작업', 브로커='pyamqp://nosd:sdsd@rabbit//', 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 -- 험담 없이 -- 섞이지 않고 -- 심장 박동 없이

celery==4.4.0rc4를 사용해 볼 수 있습니까?

Celery는 동시에 동일한 작업 ID로 동일한 작업을 두 번 수신 합니다.
다음은 로그입니다.

[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

둘 다 동시에 실행 중이며,

파이썬 플라스크에서 SQS와 함께 celery==4.4.0rc4 , boto3==1.9.232, kombu==4.6.6 사용.
SQS에서 기본 가시성 제한 시간은 30분이며 내 작업에는 ETA가 없고 ack이 없습니다.

달리는 작업자,
셀러리 작업자 -A app.jobs.run -l 정보 --pidfile=/var/run/celery/celery.pid --logfile=/var/log/celery/celery.log --time-limit=7200 --concurrency =8

@auvipy , 어떤 도움이 될 것입니다.

어떤 브로커와 결과 백엔드를 사용하고 있습니까? 다른 백엔드로 전환해 볼 수 있습니까?

어떤 브로커와 결과 백엔드를 사용하고 있습니까? 다른 백엔드로 전환해 볼 수 있습니까?

SQS를 사용하면 결과 백엔드는 sqlalchemy가 있는 MYSQL입니다.
자세한 내용은 여기 SO, https://stackoverflow.com/questions/59123536/celery-is-receiving-same-task-twice-with-same-task-id-at-same-time
@auvipy 좀 봐주세요.

@thedrow 당신은 블룸버그에서 이 문제에 직면하고 있습니까?

@nitish-itilite : 셀러리의 시간대는 무엇입니까?

@nitish-itilite : 셀러리의 시간대는 무엇입니까?

기본 UTC입니다. sqs 에서 지역은 이 미국 동부(버지니아 북부)입니다.

SQS와 함께 셀러리를 실행하는 비슷한 경우가 있었습니다. countdown=60 으로 더미 작업을 실행했지만 SQS의 가시성 제한 시간은 30초입니다. 내가 얻는 것은 다음과 같습니다.

참고: 저는 --concurrency=1 로 셀러리를 시작했으므로 두 개의 스레드가 있습니다. 맞나요?

[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가 30초 동안 inflight 모드로 설정했습니다.
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]

(공개 게시를 위해 로그에서 작업 이름을 수정했습니다.)

고유성 제약으로 인해 작업자 중 한 명이 작업 도중에 오류를 발생시키고 다른 작업자는 성공합니다.

설정을 시도했습니다
CELERY_WORKER_PREFETCH_MULTIPLIER = 1
도움이 되지 않는 것으로 나타났습니다.

나는 사용하고있다
셀러리==4.4.1
장고-셀러리-결과==1.2.1

그리고 대기열에 AWS SQS를 사용하고 있습니다.

나에게는 이론이 있다. 분명히 내 대기열의 "기본 표시 시간 초과" 설정은 5초로 설정되었습니다. 첫 번째 작업자가 작업하는 동안 두 번째 작업자가 작업을 빼냈을 수 있습니다. 첫 번째 작업자가 사망했다고 가정했기 때문일 수 있습니다. 가시성 제한 시간을 2분으로 올렸더니 더 잘 되는 것 같습니다. 8-12초가 걸리는 작업이 많았기 때문에 2분이 과도할 수 있습니다. 하지만 해결되기를 바랍니다.

첫 번째 작업자가 작업하는 동안 두 번째 작업자가 작업을 빼냈을 수 있습니다. 첫 번째 작업자가 사망했다고 가정했기 때문일 수 있습니다.

@JulieGoldberg , Celery가 작업을 처리하는 것은 형편없는 방법이 될 것입니다. Celery 작업자는 다른 작업자가 대기열에서 제거하고 적극적으로 처리 중인 작업을 시작해서는 안 됩니다. 심각하게 깨질 것이라고 생각합니다. (근데 샐러리야 이젠 아무것도 안들어가서 놀람😒)

Kubernetes에서 실행 중인 애플리케이션에 비슷한 문제가 있습니다. Kubernetes 인스턴스에는 Redis의 작업을 사용하는 10명의 작업자(셀러리 앱 인스턴스)가 있습니다.

증상:
셀러리 작업자는 30분 후에 계획될 ETA 작업을 예약합니다. Kubernetes 포드가 회전되거나(Kubernetes에 의해 작업자가 종료됨) 애플리케이션의 최신 버전이 배포되면(모든 작업자가 종료되고 새 작업자가 생성됨) 모든 작업자가 예약된 작업을 수행하고 정의된 시간에 실행을 시작합니다.
작업자의 경우 몇 시간에서 최대 1년까지 visibility_timeout 값을 다르게 설정해 보았지만 결과는 여전히 동일했습니다. enable_utc = True 설정 또는 worker_prefetch_multiplier = 1 감소로 동일한 동작에 도달했습니다.

이것이 누군가에게 도움이 될지 모르겠지만 이것이 내 문제였습니다.

페이지가 GET을 통해 로드될 때 실행되는 작업(보고서 생성)이 있었습니다. 어떤 이유로(파비콘과 관련이 있음) Chrome은 모든 페이지 로드에 대해 2개의 GET 요청을 보내 작업을 두 번 트리거합니다.
GET 요청은 부작용이 없어야 하므로 귀하가 제출한 양식으로 모두 변환하여 문제가 해결되었습니다.

첫 번째 작업자가 작업하는 동안 두 번째 작업자가 작업을 빼냈을 수 있습니다. 첫 번째 작업자가 사망했다고 가정했기 때문일 수 있습니다.

@JulieGoldberg , Celery가 작업을 처리하는 것은 형편없는 방법이 될 것입니다. Celery 작업자는 다른 작업자가 대기열에서 제거하고 적극적으로 처리 중인 작업을 시작해서는 안 됩니다. 심각하게 깨질 것이라고 생각합니다. (근데 샐러리야 이젠 아무것도 안들어가서 놀람😒)

불만을 제기하는 대신 솔루션과 PR을 제시하여 문제를 해결하는 데 도움을 줄 수 있습니다.

Kubernetes에서 실행 중인 애플리케이션에 비슷한 문제가 있습니다. Kubernetes 인스턴스에는 Redis의 작업을 사용하는 10명의 작업자(셀러리 앱 인스턴스)가 있습니다.

증상:
셀러리 작업자는 30분 후에 계획될 ETA 작업을 예약합니다. Kubernetes 포드가 회전되거나(Kubernetes에 의해 작업자가 종료됨) 애플리케이션의 최신 버전이 배포되면(모든 작업자가 종료되고 새 작업자가 생성됨) 모든 작업자가 예약된 작업을 수행하고 정의된 시간에 실행을 시작합니다.

@elMateso k8(포드의 소비자 및 대기열로 redis)의 Airflow 배포와 유사한 문제에 직면했습니다. 하지만 배포를 안정적으로 만들고 예상대로 작동할 수 있었습니다. 다음 팁이 도움이 될 것입니다.
https://www.polidea.com/blog/application-scalability-kubernetes/#tips -for-hpa

여기에서 같은 얼굴을 하고 있습니다.

적어도 저에게는 어떤 타이밍 구성(가시성 시간 초과, ETA 등)에도 문제가 없는 것 같습니다. 내 경우에는 실행 사이에 마이크로초가 발생합니다. 셀러리가 실제로 메시지 ACK를 수행하는 방법을 찾지 못했지만 RabbitMQ에서 완벽하게 작동하는 경우 Redis의 동시성 및 ACK에 문제가 있는 것 같습니다.

동일한 문제가 발생하고 Redis도 브로커로 사용하고 있습니다. RabbitMQ로 변경하는 것은 우리에게 선택 사항이 아닙니다.

작업이 한 번만 실행되도록 잠금을 사용해 본 사람이 있습니까? 그게 효과가 있을까요?

예: 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를 가져오고 캐시를 설정하기만 하면 됩니다. 지금까지는 잘 작동하고 있습니다.

누군가이 홍보를 확인할 수 있습니까? https://github.com/vinayinvicible/kombu/commit/a755ba14def558f2983b3ff3358086ba55521dcc