Celery: Tugas yang sama berjalan beberapa kali sekaligus?

Mungkin ini terkait dengan batas waktu visibilitas ?

@georgepsarakis Bisakah Anda menjelaskan kecurigaan Anda?

Sejauh yang saya tahu, ini adalah masalah yang diketahui untuk transportasi broker yang tidak memiliki karakteristik pengakuan bawaan AMQP. Tugas akan ditetapkan ke pekerja baru jika waktu penyelesaian tugas melebihi batas waktu visibilitas, sehingga Anda mungkin melihat tugas dijalankan secara paralel.

@georgepsarakis Jadi jika tugas dijadwalkan jauh di masa depan, maka saya mungkin melihat di atas? "Visibilitas batas waktu" alamat itu? Dari dokumentasi yang Anda tautkan:

Batas waktu visibilitas default untuk Redis adalah 1 jam.

Artinya jika dalam satu jam pekerja tidak menyelesaikan tugas (yaitu menjalankannya?) tugas tersebut sedang dikirim ke pekerja lain yang tidak akan melakukan ack, dan seterusnya… Memang ini tampaknya menjadi kasus melihat bagian peringatan dari dokumentasi; masalah terkait ini https://github.com/celery/kombu/issues/337; atau mengutip dari blog ini :

Tetapi ketika pengembang baru mulai menggunakannya, mereka secara teratur menghadapi perilaku pekerja yang tidak normal, khususnya beberapa eksekusi tugas yang sama oleh beberapa pekerja. Alasan yang menyebabkannya adalah pengaturan batas waktu visibilitas.

Sepertinya menyetel visibility_timeout ke 31.540.000 detik (satu tahun) mungkin merupakan perbaikan cepat.

Saya akan mengatakan bahwa jika Anda meningkatkan batas waktu visibilitas menjadi 2 jam, tugas Anda hanya akan dieksekusi sekali.

Jadi jika Anda menggabungkan:

• Broker redis
• Pengakuan terlambat
• ETA sama/di atas batas waktu visibilitas
  Anda mendapatkan beberapa eksekusi pada tugas.

Menurut saya yang terjadi adalah:

• Setelah satu jam berlalu, satu proses pekerja mulai memproses tugas.
• Pekerja kedua akan melihat bahwa pesan ini telah berada dalam antrean lebih lama dari batas waktu visibilitas dan sedang diproses oleh pekerja lain.
• Pesan dipulihkan dalam antrian.
• Pekerja lain mulai memproses pesan yang sama.
• Hal di atas terjadi untuk semua proses pekerja.

Melihat ke implementasi transport Redis, Anda akan melihat bahwa ia menggunakan Sorted Sets, melewatkan waktu antrian sebagai skor ke zadd . Pesan dipulihkan berdasarkan stempel waktu itu dan membandingkannya dengan interval yang sama dengan batas waktu visibilitas .

Semoga ini menjelaskan sedikit internal transportasi Redis.

@georgepsarakis , saya sekarang benar-benar bingung. Jika ETA tugas ditetapkan untuk dua bulan dari sekarang, mengapa seorang pekerja mengambilnya satu jam setelah tugas dijadwalkan? Apakah saya melewatkan sesuatu?

Asumsi saya (salah?) adalah bahwa:

• Saya menjadwalkan tugas dengan ETA kapan saja di masa mendatang; kemudian
• tugas (yaitu argumen yang disusunnya) dan ETA akan duduk dalam antrian sampai ETA tiba; kemudian
• seorang pekerja mulai memproses tugas di ETA.

“_Saya pikir yang terjadi adalah:_” Anda di atas sangat berbeda dari asumsi saya.

Saya juga mengalami masalah yang sama, sudahkah Anda menyelesaikannya? @jenstroeger

Terima kasih!

@jenstroeger itu tidak terdengar seperti aliran yang layak, saya pikir pekerja hanya terus mengantrekan pesan untuk menunda eksekusi hingga kondisi ETA akhirnya terpenuhi. Konsep antrian adalah untuk mendistribusikan pesan segera setelah mereka tiba, sehingga pekerja memeriksa pesan dan hanya requeues.

Harap dicatat bahwa ini adalah tebakan saya, saya tidak begitu mengetahui internal implementasi ETA.

@zivsu , seperti yang disebutkan di atas , saya telah menetapkan visibility_timeout ke jumlah _very_ besar dan itu tampaknya telah menyelesaikan gejalanya. Namun, seperti yang ditunjukkan oleh @georgepsarakis , itu tampaknya merupakan pendekatan yang buruk.

Saya tidak tahu penyebab masalah asli atau cara mengatasinya dengan benar.

@jenstroeger Saya membaca beberapa blog, mengubah visibility_timeout tidak dapat menyelesaikan masalah sepenuhnya, jadi saya mengubah borker saya menjadi rabbitmq .

@zivsu , bisakah Anda membagikan tautan ke blog? Apakah Anda menggunakan Redis sebelumnya?

@jenstroeger Saya tidak dapat menemukan blog, saya menggunakan Redis sebagai broker sebelumnya. Untuk tugas jadwal, saya memilih rebbitmq untuk menghindari kesalahan terjadi lagi.

Saya memiliki masalah yang persis sama, konfigurasi saya adalah:
django==1.11.6
seledri==4.2rc2
django-seledri-beat == 1.0.1

pengaturan:

CELERY_ENABLE_UTC = True
# CELERY_TIMEZONE = 'America/Los_Angeles'

Dan itulah satu-satunya kombinasi yang berfungsi dari pengaturan ini. Saya juga harus menjadwalkan tugas berkala saya di zona waktu UTC.
Jika Anda mengaktifkan CELERY_TIMEZONE atau menonaktifkan CELERY_ENABLE_UTC itu mulai menjalankan tugas berkala beberapa kali.

Saya memiliki masalah penyimpanan. tugas eta dijalankan berkali-kali saat menggunakan redis sebagai broker.
cara apapun untuk menyelesaikan ini..
sepertinya ganti broker dari redis ke rabbitmq menyelesaikan masalah ini ..

Menggunakan redis, ada masalah umum saat Anda menentukan zona waktu selain UTC. Untuk mengatasi masalah ini, subkelas aplikasi default, dan tambahkan fungsi penanganan zona waktu Anda sendiri:

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)

Harapan yang membantu orang lain yang mengalami masalah ini.

Saya mendapatkan masalah ini kadang-kadang ketika sering memulai kembali pekerjaan seledri dengan ketukan pada mesin multicore. Saya sudah terbiasa menjalankan ps aux | grep celery lalu kill <each_pid> untuk mengatasinya.

Saran terbaik yang saya miliki adalah selalu memastikan Anda melihat pesan "restart DONE" sebelum memutuskan sambungan dari mesin.

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

jika kita memeriksa stempel waktu tugas yang diterima, setiap jam akan mendapatkan tugas baru dengan id yang sama. Hasilnya adalah semua pesan ETA dikirim lebih dari 10 kali. Sepertinya rabbitmq hanya pilihan jika kita ingin menggunakan ETA

Baru-baru ini bertemu bug serupa. Juga ps aux | grep celery menunjukkan lebih banyak proses daripada yang dimulai pekerja, dua kali lebih banyak. Menambahkan parameter --pool gevent ke perintah peluncuran pekerja seledri menurunkan jumlah proses ke jumlah pasti pekerja awal dan ketukan seledri. Dan sekarang saya sedang menunggu eksekusi tugas saya.

Mungkinkah solusi lain menonaktifkan emulasi ack sepenuhnya? yaitu "broker_transport_options": {"ack_emulation": False} . Adakah kekurangan untuk tugas/hitung mundur yang berjalan singkat?

Apakah ada yang mendapatkan perbaikannya?

Pernah mengalami masalah yang sama, Adakah solusi untuk itu?

Menabrak, masalah yang sama.

Masalah yang sama di sini, menggunakan Redis sebagai broker.

$ 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

Masalah yang sama disini. Seledri versi 4.3.0
seledri = Seledri('tasks', broker='pyamqp://nosd:sdsd@rabbit//', config_from_object={"broker_transport_options":{'visibility_timeout': 18000}})

Perintah yang saya gunakan untuk menjalankan pekerja saya
seledri -Pekerja tugas --pidfile=/tmp/celery_worker.pid -f=/tmp/celery_worker.log -Q celery_queue --loglevel=info --pool=solo --concurrency=1 -n worker_celery --detach -- tanpa-gosip --tanpa-berbaur --tanpa-detak jantung

dapatkah Anda mencoba seledri==4.4.0rc4?

Seledri menerima tugas yang sama dua kali, dengan id tugas yang sama pada waktu yang sama.
Berikut adalah lognya

[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

keduanya berjalan bersamaan,

menggunakan celery==4.4.0rc4 , boto3==1.9.232, kombu==4.6.6 dengan SQS dalam labu pyhton.
di SQS, Batas Waktu Visibilitas Default adalah 30 menit, dan tugas saya tidak memiliki ETA dan tidak ack.

menjalankan pekerja seperti,
pekerja seledri -A app.jobs.run -l info --pidfile=/var/run/celery/celery.pid --logfile=/var/log/celery/celery.log --time-limit=7200 --concurrency =8

@auvipy , bantuan apa pun akan sangat membantu.

broker dan backend hasil mana yang Anda gunakan? dapatkah Anda mencoba beralih ke ujung belakang yang lain?

broker dan backend hasil mana yang Anda gunakan? dapatkah Anda mencoba beralih ke ujung belakang yang lain?

menggunakan SQS, hasil backend adalah MYSQL, dengan sqlalchemy.
detailnya ada di sini di SO, https://stackoverflow.com/questions/59123536/celery-is-receiving-same-task-twice-with-same-task-id-at-same-time
@auvipy bisa tolong lihat.

@thedrow apakah Anda menghadapi masalah ini di bloomberg?

@nitish-itilite : zona waktu apa yang Anda gunakan untuk seledri?

@nitish-itilite : zona waktu apa yang Anda gunakan untuk seledri?

itu adalah UTC default. di sqs , wilayah ini AS Timur (Virginia Utara).

Saya memiliki kasus serupa yang menjalankan seledri dengan SQS. Saya menjalankan tugas dummy dengan countdown=60 , sementara batas waktu visibilitas di SQS adalah 30 detik. Inilah yang saya dapatkan:

CATATAN: Saya sudah memulai seledri dengan --concurrency=1 , jadi ada dua utas, bukan?

[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

Apa yang terjadi dalam urutan kronologis:

1. 14:46:32 tugas diterima, dan SQS memasukkannya ke mode inflight selama 30 detik
2. 14:47:02 tugas yang sama diterima, karena batas waktu visibilitas kedaluwarsa
3. 14:47:32 kedua tugas dijalankan secara bersamaan

Dugaan saya adalah ini adalah bug di Seledri (?), Saya pikir itu harus diperiksa apakah id pesan ( b483a22f-31cc-4335-9709-86041baa8f05 ) telah diambil oleh pekerja itu.

Mungkin ada daftar hash dengan semua id pesan, sehingga seledri dapat memutuskan apakah tugas yang diterima valid untuk diproses. Bisakah seledri melakukan itu?

CATATAN 2:
Kami tidak dapat mengatur batas waktu visibilitas terlalu lama, karena jika pekerja benar-benar mati, pesan akan memakan waktu terlalu lama untuk diambil oleh pekerja lain. Mengaturnya terlalu rendah akan mengekspos kondisi ini.

Sepertinya ini juga terjadi pada saya.

[2020-05-11 15:31:23,673: INFO/MainProcess] Tugas yang diterima: ee_external_attributes.tasks. recreate_specific_values[53046bd7-2a19-4f72-808f-d712eaecb0e8]
[2020-05-11 15:31:28,673: INFO/MainProcess] Tugas yang diterima: ee_external_attributes.tasks.recreate_specific_values[53046bd7-2a19-4f72-808f-d712eaecb0e8]

(Saya mengubah nama tugas di log untuk posting publik.)

Karena kendala keunikan, salah satu pekerja saya membuat kesalahan di tengah jalan, dan yang lainnya berhasil.

Saya mencoba pengaturan
CELERY_WORKER_PREFETCH_MULTIPLIER = 1
Itu ternyata tidak membantu.

saya menggunakan
seledri == 4.4.1
django-seledri-hasil==1.2.1

Dan saya menggunakan AWS SQS untuk antrian.

Saya punya teori. Rupanya pengaturan "Batas Waktu Visibilitas Default" saya pada antrian saya hanya diatur ke 5 detik. Bisa jadi pekerja kedua menarik pekerjaan itu saat pekerja pertama sedang mengerjakannya, karena diasumsikan pekerja pertama sudah meninggal. Saya meningkatkan batas waktu visibilitas menjadi 2 menit, dan tampaknya lebih baik. Saya memiliki banyak tugas yang memakan waktu 8-12 detik, jadi 2 menit mungkin berlebihan. Tapi semoga itu bisa menyelesaikannya.

Bisa jadi pekerja kedua menarik pekerjaan itu saat pekerja pertama sedang mengerjakannya, karena diasumsikan pekerja pertama sudah meninggal.

@JulieGoldberg , itu akan menjadi cara yang payah bagi Seledri untuk menangani pekerjaan. Seorang pekerja Seledri tidak boleh memulai pekerjaan yang telah dilakukan pekerja lain dari antrian dan sedang diproses secara aktif; pikir itu akan rusak parah. (Tapi ini Seledri, aku tidak terkejut lagi )

Saya memiliki masalah serupa dengan aplikasi yang berjalan di Kubernetes. Dalam instance Kubernetes, kami memiliki 10 pekerja (instance aplikasi seledri) yang menggunakan tugas dari Redis.

Gejala:
Pekerja seledri menjadwalkan tugas ETA yang akan direncanakan setelah 30 menit. Jika pod Kubernetes diputar (worker dimatikan oleh Kubernetes) atau versi aplikasi yang lebih baru di-deploy (semua pekerja dimatikan dan pekerja baru dibuat), semua pekerja akan mengambil tugas terjadwal dan mulai mengeksekusi dalam waktu yang ditentukan.
Untuk pekerja, saya mencoba mengatur nilai visibility_timeout yang berbeda selama beberapa jam hingga satu tahun, tetapi hasilnya tetap sama. Perilaku yang sama dicapai dengan pengaturan enable_utc = True , atau pengurangan worker_prefetch_multiplier = 1 .

Saya tidak tahu apakah ini akan membantu siapa pun, tetapi ini adalah masalah saya:

Saya memiliki tugas (pembuatan laporan) yang sedang dijalankan ketika halaman dimuat melalui GET. Untuk beberapa alasan (sesuatu yang berkaitan dengan favicons) Chrome akan mengirim 2 permintaan GET pada setiap pemuatan halaman, memicu tugas dua kali.
Permintaan GET seharusnya bebas efek samping, jadi saya mengubah semuanya menjadi formulir yang Anda kirimkan dan masalah telah teratasi.

Bisa jadi pekerja kedua menarik pekerjaan itu saat pekerja pertama sedang mengerjakannya, karena diasumsikan pekerja pertama sudah meninggal.

@JulieGoldberg , itu akan menjadi cara yang payah bagi Seledri untuk menangani pekerjaan. Seorang pekerja Seledri tidak boleh memulai pekerjaan yang telah dilakukan pekerja lain dari antrian dan sedang diproses secara aktif; pikir itu akan rusak parah. (Tapi ini Seledri, aku tidak terkejut lagi )

Alih-alih mengeluh, Anda dapat membantu kami memperbaiki masalah dengan memberikan solusi dan PR.

Saya memiliki masalah serupa dengan aplikasi yang berjalan di Kubernetes. Dalam instance Kubernetes, kami memiliki 10 pekerja (instance aplikasi seledri) yang menggunakan tugas dari Redis.

Gejala:
Pekerja seledri menjadwalkan tugas ETA yang akan direncanakan setelah 30 menit. Jika pod Kubernetes diputar (worker dimatikan oleh Kubernetes) atau versi aplikasi yang lebih baru di-deploy (semua pekerja dimatikan dan pekerja baru dibuat), semua pekerja akan mengambil tugas terjadwal dan mulai mengeksekusi dalam waktu yang ditentukan.

@elMateso Saya menghadapi masalah serupa dengan penyebaran Aliran Udara di k8s (konsumen di pod dan redis sebagai antrian). Tetapi saya dapat membuat penerapannya stabil dan berfungsi seperti yang diharapkan, mungkin kiat-kiat itu akan membantu Anda:
https://www.polidea.com/blog/application-scalability-kubernetes/#tips -for-hpa

Menghadapi hal yang sama di sini.

Tampaknya tidak menjadi masalah dengan konfigurasi waktu apa pun (batas waktu visibilitas, ETA, dll.), setidaknya bagi saya. Dalam kasus saya itu terjadi mikrodetik antara eksekusi. Tidak menemukan bagaimana seledri sebenarnya melakukan ACK pesan, tetapi, jika, di rabbitMQ berfungsi dengan baik, sepertinya ada masalah dengan konkurensi dan ACK di Redis.

Saya melihat masalah yang sama dan kami juga menggunakan Redis sebagai broker. Mengubah ke rabbitMQ bukanlah pilihan bagi kami.

Adakah yang pernah mencoba menggunakan kunci untuk memastikan tugas hanya dijalankan sekali saja. Bisakah itu berhasil?

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

@ErikKalkoken kami akhirnya melakukan hal itu.

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

Kode di atas tidak digunakan untuk celery, tetapi celery multiple execution adalah logika yang sama, Anda hanya perlu mendapatkan task_id dan mengatur cache. Sejauh ini bekerja dengan baik.

dapatkah seseorang memeriksa pr ini https://github.com/vinayinvicible/kombu/commit/a755ba14def558f2983b3ff3358086ba55521dcc