3 kasus untuk menggunakan Seledri dalam aplikasi Django

Saya membuat aplikasi web di Django. Pada dasarnya, ini adalah layanan SaaS untuk bisnis. Semua aplikasi ini memerlukan tugas yang tidak sinkron. Untuk implementasi mereka saya menggunakan Seledri. Dalam artikel ini saya akan menceritakan tentang situasi di mana saya menggunakan Seledri, dengan contoh kode.

Seledri adalah sistem untuk mengelola antrian tugas. Secara fundamental mampu 2 hal: mengambil tugas dari antrian dan melakukan tugas sesuai jadwal. Pialang antrian biasanya RabbitMQ atau Redis. Tugas-tugas dimasukkan dalam antrian, dan kemudian pekerja Seledri mengambilnya dari sana dan melaksanakannya.

Untuk Celery, Anda dapat memikirkan sebuah aplikasi di hampir semua aplikasi, tetapi kemudian saya akan menjelaskan hanya kasus-kasus di mana saya menggunakannya sendiri.

1. Tugas Terjadwal

Seringkali ada tugas yang perlu diselesaikan pada tanggal dan waktu tertentu: mengirim pengingat kepada pengguna, mengakhiri masa percobaan akun, menerbitkan posting di jejaring sosial.

Di Seledri, dimungkinkan untuk menentukan parameter ETA saat memanggil tugas - waktu di mana tugas harus diluncurkan. Tetapi jika Anda merencanakan tugas dengan cara ini, maka itu ternyata sangat tidak dapat diandalkan: mereka mungkin tidak memulai dan mereka dapat merasa tidak nyaman untuk membatalkan.

Cara yang lebih dapat diandalkan adalah dengan menggunakan jadwal celerybeat. Artinya, buat jadwal di mana akan ada tugas yang dimulai pada frekuensi tertentu atau pada waktu tertentu. Misalnya, jika Anda perlu menerbitkan posting di jejaring sosial sesuai jadwal, maka tugas untuk ini diluncurkan satu menit sekali. Jika Anda harus menyelesaikan periode uji coba untuk akun Anda, Anda dapat menjalankan tugas sekali sehari.

# schedule.py from datetime import timedelta from celery.schedules import crontab CELERYBEAT_SCHEDULE = { 'publish_post_starter': { 'task': 'publish_post_starter', 'schedule': timedelta(minutes=1), }, 'end_trial_starter': { 'task': 'end_trial_starter', 'schedule': crontab(hour=10, minute=21), }, } 

Di starter tugas, kita mendapatkan semua instance yang waktu yang direncanakan sudah tiba. Kami melalui contoh dan untuk masing-masing kami memanggil tugas utama. Sebagai argumen, kami hanya mengirimkan id instance agar tidak menyumbat antrian dengan data yang tidak perlu. Kita dapat segera melalui semua instance dan melakukan tindakan, tetapi paling sering lebih baik memanggil tugas terpisah untuk setiap instance. Jadi kami akan mempercepat eksekusi, dan jika terjadi kesalahan, itu hanya akan mempengaruhi salah satu tugas.

 # tasks.py @app.task(name='publish_post') def publish_post(post_id): ... @app.task(name='publish_post_starter') def publish_post_starter(): post_ids = list( Post.objects.filter( publish_dt__lte=timezone.now(), is_published=False ).values_list('id', flat=True) ) for post_id in post_ids: publish_post.delay(post_id) 

2. Komputasi panjang dan panggilan API dari WSGI

WSGI mengacu pada konteks di mana permintaan dari pengguna diproses (Siklus Permintaan-Respons). Berbeda dengan konteks tugas asinkron - Seledri.

Untuk membuat antarmuka responsif, semua tombol harus merespons secara instan dan tidak boleh memblokir antarmuka lainnya. Untuk melakukan ini, setelah menekan tombol diblokir, pemintal ditempatkan di atasnya dan permintaan ajax dikirim ke server. Jika memproses permintaan membutuhkan waktu lebih dari beberapa detik, maka Anda dapat memindahkan perhitungan ke tugas Seledri.

Di WSGI, kami memanggil tugas dan mengembalikan respons. Di bagian depan, buka kunci tombol dan lepaskan pemintal. Kami menunjukkan kepada pengguna pesan bahwa tindakan sedang berjalan. Secara paralel, tugas Seledri dijalankan, yang, setelah selesai, mengembalikan respons pada soket web. Setelah menerima hasil di depan, kami menunjukkannya kepada pengguna.

 # rest_views.py from rest_framework import status from rest_framework.views import APIView from rest_framework.response import Response from tasks import send_emails class SendEmailView(APIView): def post(self, request): # this id will be used to send response with websocket request_uuid = request.data.get('request_uuid') if not request_uuid: return Response(status=status.HTTP_400_BAD_REQUEST) send_emails.delay(request.user.id, request_uuid) return Response(status=status.HTTP_200_OK) 

Secara terpisah, Anda dapat membedakan panggilan API eksternal dari WSGI. Dalam hal ini, semua panggilan, terlepas dari durasi eksekusi, diluncurkan melalui tugas Seledri. Ini adalah perlindungan dari si bodoh. Seharusnya tidak ada situasi di mana, karena tidak dapat diaksesnya beberapa API eksternal, antarmuka pengguna membeku.

3. Tantangan dari Tornado

Saat berintegrasi dengan jejaring sosial, Telegram atau layanan pembayaran, Anda memerlukan url webhook yang akan menerima notifikasi. Jumlah permintaan tidak selalu dapat dihitung sebelumnya, tetapi kemungkinan besar jumlah mereka akan melebihi permintaan dari pengguna. Permintaan ini akan diterima sampai mereka menerima tanggapan dengan kode 200.

Untuk memproses permintaan semacam itu, kerangka kerja asinkron Tornado cocok. Agar tidak mengubah pemrosesan menjadi sinkron di Tornado, tidak boleh ada operasi pemblokiran. Di sinilah diperlukan Seledri. Pawang Tornado menerima permintaan, memvalidasi data, memanggil tugas Seledri, dan mengembalikan respons yang berhasil.

 # tornado_handlers.py from tornado import gen, escape from tornado.web import RequestHandler from tasks import handle_vk_callback class VkCallbackHandler(RequestHandler): @gen.coroutine def post(self, *args, **kwargs): try: data = escape.json_decode(self.request.body) except ValueError: self.set_status(status_code=400, reason='Invalid data') return handle_vk_callback.delay(data) self.write('ok') return