Memahami tugas, broker, pekerja dan bahagian belakang dalam Celery

Saderi boleh menjadi sukar untuk dipelajari. Walaupun dokumentasinya komprehensif, ia mempunyai kecenderungan untuk melangkau perkara asas.

Siaran ini akan mentakrifkan empat daripada konsep utama dalam Saderi, membincangkan hubungan antara Saderi dan Kombu, dan menggunakan beberapa contoh kod untuk menggambarkan cara Saderi mungkin berguna dalam aplikasi sebenar. Contoh akan menggunakan rangka kerja web Django dan penghias @shared_tasknya, tetapi konsep tersebut juga boleh digunakan untuk Flask, FastAPI dan lain-lain.

Tugas, Broker, Pekerja dan Backend

Anda akan sukar untuk mencari tempat pada dokumentasi Saderi semasa yang menerangkan dengan jelas perkara yang dianggap sebagai broker atau belakang, tetapi dengan penggalian yang mencukupi anda boleh menemui dan membuat kesimpulan takrifan.

Di bawah ialah konsep yang perlu anda ketahui sebelum mula menggunakan Saderi.

Tugasan

Satu tugas ialah beberapa kerja yang akan dilakukan oleh Celery secara tak segerak (dalam konteks ini, itu adalah perkataan mewah untuk "tidak serta-merta"). Dalam aplikasi web, satu tugas mungkin menghantar e-mel selepas pengguna menyerahkan borang. Menghantar e-mel boleh menjadi operasi berbilang saat dan memaksa pengguna menunggu e-mel dihantar sebelum mengubah hala boleh membuatkan aplikasi berasa perlahan.

Tugas ditakrifkan menggunakan penghias dalam Saderi. Di bawah ini kami menggunakan penghias @shared_task untuk menukar send_thank_you_email() menjadi tugasan Saderi yang boleh digunakan dalam pengendali penyerahan borang submit_feedback().

from config.celery import shared_task
from django.core.mail import send_mail
from django.shortcuts import render, redirect
from feedback.forms import FeedbackForm

@shared_task
def send_thank_you_email(email_address):
    send_mail(
        "Thank you for your feedback!",
        "We appreciate your input.",
        "noreply@example.com",
        [email_address],
    )

def submit_feedback(request):
    if request.method == "POST":
        form = FeedbackForm(request.POST)
        if form.is_valid():
            form.save()

            # Push the task to the broker using the delay() method.
            send_thank_you_email.delay(form.cleaned_data["email"])

            return redirect("/thank-you/")
    else:
        form = FeedbackForm()

    return render(request, "feedback.html", {"form": form})

Apabila tugasan ditakrifkan menggunakan penghias dalam Saderi, ia menambahkan kaedah kelewatan() pada tugasan itu. Anda boleh melihat tugas send_thank_you_email yang memanggil kaedah delay() dalam contoh di atas selepas borang berjaya disimpan. Apabila delay() dipanggil, ia akan menghantar tugas send_thank_you_email dan datanya kepada broker di mana ia disimpan dan kemudiannya akan dilaksanakan oleh pekerja, pada ketika itu pengguna akan dihantar melalui e-mel.

Faedah menolak kerja ke Celery menjadi lebih jelas jika anda perlu menghantar e-mel tambahan selepas menyimpan borang. Sebagai contoh, anda mungkin ingin menghantar e-mel kepada pasukan sokongan pelanggan bahawa mereka telah menerima maklum balas baharu. Dengan Saderi, ini hampir tiada masa tambahan untuk respons.

Tugas saderi juga membenarkan konfigurasi lanjutan tambahan. Sekiranya e-mel gagal dihantar, anda boleh mengodkan tugas anda untuk mencuba semula secara automatik dan mengkonfigurasi tetapan seperti max_retries, retry_backoff, retry_jitter, dsb.

Broker

Glosari Cadangan Peningkatan Saderi mempunyai perkara berikut untuk dikatakan tentang Broker Mesej:

Corak Integrasi Perusahaan mentakrifkan Broker Mesej sebagai blok binaan seni bina yang boleh menerima mesej dari berbilang destinasi, menentukan destinasi yang betul dan menghalakan mesej ke saluran yang betul.

Untuk tujuan kami dengan Celery, kami akan mempertimbangkan broker sebagai "pengangkutan mesej" tempat tugasan yang dibuat disimpan. Broker sebenarnya tidak melaksanakan tugas: itu adalah tugas seorang pekerja. Broker sebaliknya adalah tempat di mana tugas yang dijadualkan disimpan ke apabila tugasan dijadualkan dan ditarik dari apabila pekerja akhirnya melaksanakan tugas. Broker ialah komponen diperlukan agar Saderi berfungsi dan Saderi akan menyambung kepada satu broker.

Halaman Backends and Brokers Celery menyenaraikan beberapa jika brokernya disokong, dan terdapat broker percubaan lain yang disokongnya yang tidak disenaraikan (seperti SQLAlchemy). Broker ini (atau "pengangkutan mesej") diuruskan oleh perpustakaan Python yang diselenggarakan oleh Celery untuk pengangkutan mesej yang dipanggil Kombu. Apabila mencari maklumat tentang mengkonfigurasi broker, kadangkala adalah berguna untuk berunding dengan dokumentasi Kombu berbanding dengan Celery.

Sesetengah broker mempunyai ciri lanjutan seperti fanout tugas dan keutamaan, manakala yang lain beroperasi sebagai baris gilir mudah.

Pekerja

Seorang pekerja ialah contoh Saderi yang menarik tugas daripada broker dan melaksanakan fungsi tugas yang ditakrifkan dalam apl Python anda. Celery dapat menjalankan kod Python dalam pekerjanya kerana Celery sendiri ditulis dalam Python.

Ramai pekerja boleh berlari serentak untuk melaksanakan tugas. Apabila anda menjalankan arahan pekerja saderi, ia akan memutarkan pekerja untuk setiap teras komputer anda secara lalai. Jika komputer anda mempunyai 16 teras, pekerja saderi menjalankan akan memulakan 16 pekerja.

Jika tiada pekerja sedang berjalan, mesej (tugas) akan terkumpul dalam broker sehingga pekerja tersedia untuk melaksanakannya.

Bahagian belakang

Halaman tugas dalam Panduan Pengguna Saderi mempunyai perkara berikut untuk dikatakan tentang belakang:

If you want to keep track of tasks or need the return values, then Celery must store or send the states somewhere so that they can be retrieved later. There are several built-in result backends to choose from: SQLAlchemy/Django ORM, Memcached, RabbitMQ/QPid (rpc), and Redis – or you can define your own.

TLDR: a backend tracks the outcomes and returned results of async tasks. What does that actually mean, and when could it be useful?

Imagine you are building an accounting app in Django that can generate an annual report. The report could take minutes to generate.

To give your users a more responsive experience, you use an AJAX request to kick off a report generation task. That request returns an ID of the task, which it can use to poll the server every few seconds to see if the report is generated. Once the task is complete, it will return the ID of the report, which the client can use to display a link to the report via JavaScript.

We can implement this with Celery and Django using the following code:

from celery import shared_task
from django.http import JsonResponse
from django.views.decorators.http import require_http_methods
from accounting.models import Asset
from accounting.reports import AnnualReportGenerator

@shared_task
def generate_report_task(year):
    # This could take minutes...
    report = AnnualReportGenerator().generate(year)
    asset = Asset.objects.create(
        name=f"{year} annual report",
        url=report.url,
    )
    return asset.id

@require_http_methods(["POST"])
def generate_annual_report_view(request):
    year = request.POST.get("year")
    task = generate_report_task.delay(year)
    return JsonResponse({"taskId": task.id})

def get_annual_report_generation_status_view(request, task_id):
    task = generate_report_task.AsyncResult(task_id)

    # The status is typically "PENDING", "SUCCESS", or "FAILURE"
    status = task.status
    return JsonResponse({"status": status, "assetId": task.result})

In this example, the asset ID returned by generate_report_task() is stored in a backend. The backend stores the outcome and returned result. The backend does not store the status of yet-to-be-processed tasks: these will only be added once there has been an outcome. A task that returns "PENDING" has a completely unknown status: an associated task might not even exist. Tasks will typically return "SUCCESS" or "FAILURE", but you can see all statuses in the Celery status docs.

Having a backend is not required for Celery to run tasks. However, it is required if you ever need to check the outcome of a task or return a task's result. If you try to check a task's status when Celery does not have a backend configured, an exception will be raised.

---

I hope this post helps you understand the individual pieces of Celery and why you might consider using it. While the official documentation is challenging to grok, learning Celery deeply can unlock new possibilities within your Python applications.

Atas ialah kandungan terperinci Memahami tugas, broker, pekerja dan bahagian belakang dalam Celery. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!