Cara Menjalankan Tugas Latar Belakang dalam Aplikasi Web: Queue, Penjadual dan Cron

Untuk menjalankan tugas latar belakang dalam aplikasi web, mula-mula bahagikan kerja kepada dua jenis. Tugas yang dicetuskan (hantar e-mel alu-aluan, proses muat naik) boleh disimpan dalam queue tugas, selalunya jadual dalam pangkalan data anda, dan dikendalikan oleh pekerja dengan percubaan semula. Tugas berjadual (laporan malam, peringatan setiap 15 minit) memerlukan sesuatu yang berjalan mengikut jadual: ciri cron hos, atau penjadual luaran yang memanggil titik akhir yang dilindungi dalam aplikasi anda. Sentiasa pastikan tugas selamat untuk dijalankan dua kali, rekod kegagalan, dan jangan bergantung pada pemasa dalam pelayan yang boleh melelap atau dimulakan semula.

Panduan ini menerangkan pilihan, bila setiap satu sesuai, dan cara menyediakannya dengan pembina aplikasi AI, termasuk pada hos yang diskalakan ke sifar.

Apa yang dikira sebagai tugas latar belakang

Apa sahaja yang perlahan, tidak boleh dipercayai atau tidak diperlukan untuk respons segera pengguna:

• Menghantar e-mel, pemberitahuan dan resit
• Menukar saiz imej, transkod video, menjana PDF
• Memanggil API pihak ketiga yang perlahan, termasuk model AI untuk tugas panjang
• Mengimport atau menyegerakkan data daripada sistem lain
• Pembersihan malam, laporan dan peringatan

Melakukannya dalam permintaan menjadikan halaman perlahan dan rapuh: jika pembekal e-mel tidak berfungsi, pendaftaran pengguna gagal. Memindahkannya ke latar belakang bermakna pengguna mendapat respons serta-merta dan tugas itu boleh dicuba semula.

Pilihannya

Tiada jawapan tunggal yang betul. Aplikasi kecil selalunya hanya memerlukan queue pangkalan data dan penjadual luaran.

Mengapa hos yang diskalakan ke sifar mengubah gambaran

Banyak hos moden meletakkan aplikasi anda dalam keadaan tidur apabila tiada siapa menggunakannya dan membangunkannya pada permintaan seterusnya. Itu menjimatkan wang, tetapi pelayan yang tidur tidak menjalankan kod: pemasa tidak berbunyi dan pekerja tidak meninjau. Pada hos ini, kerja berjadual mesti bermula dengan permintaan masuk, dan sumber permintaan yang paling mudah ialah penjadual luaran. Setiap panggilan membangunkan aplikasi (dan selalunya pangkalan datanya), jadi memanggil setiap minit kosnya lebih daripada setiap 15 minit. Pilih jadual paling perlahan yang memenuhi keperluan.

Corak 1: queue pangkalan data

Untuk tugas yang dicetuskan:

1. Cipta jadual jobs: jenis, muatan (JSON), status (pending, running, done, failed), percubaan, run_after, last_error, cap masa.
2. Apabila sesuatu berlaku, masukkan baris tugas dalam transaksi yang sama dengan perubahan yang menyebabkannya, supaya kedua-duanya berjaya atau gagal bersama.
3. Pekerja mengambil tugas yang sudah tiba, menandakannya running, melakukan kerja dan menandakannya done.
4. Jika gagal, tambah attempts, tetapkan run_after lebih lewat (contohnya 1, 5, kemudian 30 minit) dan simpan ralat. Selepas had maksimum, tandakan failed dan beritahu seseorang.

Jika lebih daripada satu pekerja mungkin berjalan serentak, tugas mesti diambil dengan selamat. Pada Postgres, SELECT ... FOR UPDATE SKIP LOCKED membolehkan setiap pekerja mengambil baris yang berbeza tanpa bertembung.

Apa yang menjalankan pekerja? Pada pelayan yang sentiasa hidup, gelung dalam proses berasingan. Pada hos yang diskalakan ke sifar, titik akhir berjadual dalam Corak 2 boleh memproses sekumpulan tugas yang sudah tiba pada setiap panggilan.

Corak 2: penjadual luaran yang memanggil aplikasi anda

Untuk tugas berjadual:

1. Tambah titik akhir seperti POST /api/cron/send-reminders.
2. Lindunginya: minta token rahsia dalam header, disimpan sebagai rahsia di kedua-dua belah, dan tolak apa sahaja yang lain.
3. Jadikan ia idempoten: menjalankannya dua kali dalam minit yang sama tidak boleh menghantar dua peringatan. Rekod apa yang telah dihantar.
4. Pastikan setiap panggilan pendek: proses satu kumpulan (katakan 100 item) dan biarkan panggilan seterusnya mengambil yang lain.
5. Tunjukkan penjadual ke titik akhir itu.

Pilihan penjadual:

• Aliran kerja berjadual GitHub Actions. Percuma dalam had penggunaan GitHub. Setakat September 2026, dokumentasi GitHub menyatakan selang terpendek ialah sekali setiap 5 minit, larian mungkin tertangguh pada waktu sibuk (terutamanya pada permulaan setiap jam), jadual menggunakan UTC secara lalai, dan aliran kerja berjadual dalam repositori awam dimatikan selepas 60 hari tanpa aktiviti repositori.
• Perkhidmatan cron dihoskan. Banyak perkhidmatan wujud yang tugas satu-satunya ialah memanggil URL mengikut jadual. Semak kebolehpercayaan, selang minimum dan amaran sebelum anda bergantung kepadanya.
• Penjadual penyedia awan anda. Jika anda sudah menggunakan penyedia awan besar, ia akan mempunyai penjadual terurus yang boleh memanggil titik akhir HTTPS.
• Perkhidmatan tugas atau aliran kerja dihoskan. Ini menggabungkan penjadualan, queue dan percubaan semula, dan memanggil titik akhir anda untuk setiap langkah. Bandingkan harga dan had di laman setiap vendor.

Corak 3: biarkan penyedia melakukannya

Kadangkala tugas latar belakang terbaik ialah tiada langsung:

• Pembayaran. Stripe mencuba semula pembayaran langganan yang gagal dan menghantar webhook; anda bertindak balas dan bukannya meninjau. Lihat apa itu webhook.
• E-mel. Penyedia meng-queue dan mencuba semula penghantaran sebaik sahaja anda menyerahkan mesej.
• Kerja AI berkelompok. OpenAI dan Anthropic menawarkan API kelompok untuk permintaan tidak mendesak yang anda hantar dan kumpulkan kemudian.

Arahan untuk pembina AI anda

Untuk queue:

Tambah queue tugas latar belakang menggunakan jadual jobs dalam pangkalan data kami (jenis, muatan JSON, status, attempts, run_after, last_error). Apabila pengguna mendaftar, masukkan tugas send_welcome_email dalam transaksi yang sama dan bukannya menghantar secara sebaris. Tambah fungsi processJobs(limit) yang mengambil tugas yang sudah tiba dengan SELECT ... FOR UPDATE SKIP LOCKED, menjalankannya, dan mencuba semula kegagalan selepas 1, 5 dan 30 minit, menandakannya failed selepas 4 percubaan.

Untuk pencetus berjadual:

Tambah POST /api/cron/tick yang dilindungi oleh token bearer dari rahsia CRON_SECRET; tolak apa-apa permintaan tanpanya. Setiap panggilan menjalankan processJobs(100) dan menghantar peringatan tempahan yang tiba dalam 24 jam akan datang yang belum dihantar, sambil merekod peringatan yang dihantar supaya tiada apa dihantar dua kali. Pulangkan ringkasan JSON tentang apa yang dijalankan. Kemudian tulis aliran kerja GitHub Actions yang memanggil titik akhir ini setiap 15 minit, membaca URL dan token daripada rahsia repositori.

Kesilapan biasa

• Bergantung pada setInterval. Ia berhenti secara senyap apabila pelayan melelap atau dimulakan semula, dan berganda apabila dua salinan berjalan.
• Titik akhir cron yang tidak dilindungi. Sesiapa yang menemuinya boleh mencetuskan tugas anda, atau bil e-mel anda.
• Tugas yang tidak idempoten. Percubaan semula dan panggilan penjadual berganda akan berlaku. Reka untuk itu.
• Tiada keterlihatan kegagalan. Tugas yang gagal secara senyap selama seminggu lebih teruk daripada yang gagal dengan kuat. Log ralat dan beri amaran tentang kegagalan berulang.
• Larian panjang dalam satu permintaan. Permintaan tamat masa. Proses dalam kelompok.
• Penjadualan terlalu kerap. Setiap panggilan pada hos yang diskalakan ke sifar membangunkan dan mengenakan bayaran kepada aplikasi. Padankan selang dengan keperluan sebenar.
• Zon masa. “9 pagi” bermaksud perkara berbeza bagi penjadual anda (selalunya UTC) dan pengguna anda. Simpan masa dalam UTC dan tukar mengikut pengguna.
• Rahsia dalam fail aliran kerja. Simpan token dalam stor rahsia penjadual. Lihat cara menjaga kunci API dengan selamat.

Senarai semak

• Kerja perlahan dipindahkan keluar daripada permintaan pengguna
• Tugas disimpan secara tahan lasak, bukan hanya dalam memori
• Percubaan semula dengan kelewatan yang semakin meningkat dan had maksimum
• Setiap tugas selamat untuk dijalankan dua kali
• Titik akhir berjadual dilindungi oleh token rahsia
• Setiap larian memproses kelompok yang terhad
• Tugas gagal kelihatan, dengan amaran
• Selang jadual dipilih dengan mengambil kira kos hosting
• Masa disimpan dalam UTC

Tugas latar belakang dalam Mythex

Dokumentasi Mythex tidak menerangkan tugas berjadual atau cron, dan aplikasi terbit serta pangkalan datanya melelap apabila tidak aktif dan bangun pada permintaan seterusnya (lihat Had hosting). Jadi jangan bergantung pada pemasa dalam aplikasi anda. Pendekatan yang berfungsi ialah yang dinyatakan di atas: minta ejen jadual jobs dan titik akhir yang dilindungi token, kemudian tunjukkan penjadual luaran ke URL terbit anda. Simpan token sebagai rahsia projek, dan ingat bahawa setiap kali aplikasi dikejutkan ia menggunakan kredit untuk masa aplikasi dan pangkalan data terjaga, jadi pilih selang yang munasabah. Jika aplikasi anda memerlukan backend API untuk ini, resipi backend REST API ialah titik permulaan, dan cara membina REST API meliputi reka bentuk titik akhir. Jika pekerja atau bot yang sentiasa hidup ialah teras produk anda, hos yang dibina untuk proses berterusan mungkin lebih sesuai.

Soalan lazim