Tugas Terjadwal Berjalan Ganda: Bedakan Jadwal, Penguncian, dan Pengulangan Aman
Pahami penyebab tugas terjadwal berjalan ganda, perbedaan penguncian dan idempotensi, serta cara menyusun pengujian sebelum mengandalkan cron pada hosting.
Satu jadwal tidak otomatis berarti satu hasil
Sebuah tugas otomatis dapat terlihat sederhana: membuat laporan harian, memperbarui katalog, atau mengirim pemberitahuan pada waktu tertentu. Namun, tugas tersebut bisa menerima pemicu berikutnya ketika proses sebelumnya belum selesai, dipanggil dari lebih dari satu tempat, atau dicoba ulang setelah gangguan. Akibatnya, operator melihat hasil ganda dan menyalahkan jam penjadwalan, padahal penyebabnya mungkin berada pada pengaturan pemicu maupun cara aplikasi menuntaskan pekerjaan.
Untuk memahami masalah itu, pisahkan tiga pertanyaan: kapan pekerjaan dipanggil, siapa yang boleh menjalankannya bersamaan, dan apa yang terjadi bila pekerjaan sama diulang. Artikel ini memberi kerangka diskusi bagi pemilik website, pengembang, dan penyedia hosting. Contoh yang dipakai bersifat hipotetis dan tidak meminta Anda menambahkan jadwal pada server. Hasil yang diperlukan ialah rancangan perilaku yang dapat diuji, bukan keyakinan bahwa satu baris cron sudah cukup menjamin satu tindakan bisnis.
Petakan semua sumber pemicu sebelum mengubah interval
Mulailah dengan daftar tempat yang dapat memanggil pekerjaan: panel hosting, penjadwal aplikasi, server lain, atau tindakan operator yang disediakan untuk pemulihan. Catat pemilik, lingkungan, frekuensi, dan perintah atau layanan yang dipanggil tanpa menyertakan rahasia. Jika suatu tugas tercantum dua kali pada tempat berbeda, keduanya dapat terlihat benar secara terpisah tetapi menghasilkan pekerjaan yang sama. Jangan langsung menambah interval sebelum mengetahui seluruh jalur pemicunya.
Dokumentasi cPanel menjelaskan cron sebagai tugas pada waktu atau interval tertentu dan memperingatkan bahwa pemanggilan terlalu rapat dapat menimbulkan proses yang tumpang tindih. Fasilitas itu juga bergantung pada pengaturan penyedia. Dalam perencanaan, minta pengembang menentukan apakah satu pemicu sistem akan memanggil penjadwal aplikasi atau apakah tiap pekerjaan dikelola terpisah. Peta yang disepakati membantu operator menghindari penambahan pemicu kedua ketika sebenarnya aplikasi sudah memiliki mekanisme penjadwalannya sendiri.
Bedakan jadwal yang diinginkan dari durasi pekerjaan
Frekuensi menyatakan kapan percobaan dimulai, sedangkan durasi menyatakan berapa lama pekerjaan berlangsung. Contoh hipotetisnya, pemicu datang setiap lima menit tetapi satu pemrosesan kadang memerlukan delapan menit. Tanpa perlakuan khusus, pemanggilan berikutnya dapat bertemu proses yang masih berjalan. Angka ini hanya ilustrasi hubungan waktu, bukan ukuran kinerja hosting tertentu. Ukur durasi pada kondisi yang mewakili pekerjaan sebelum memilih frekuensi atau batas waktunya.
Tentukan pula apa yang seharusnya dilakukan jika proses belum selesai: melewatkan pemanggilan baru, mengantrekannya, atau menangani pekerjaan dalam bagian lebih kecil. Setiap pilihan memiliki dampak pada kesegaran hasil dan beban sistem. Jangan menganggap semua tugas harus mengejar semua pemicu yang tertinggal. Laporan yang terlambat mungkin masih diperlukan, sedangkan pembaruan tertentu bisa cukup memakai data terbaru. Keputusan itu harus berasal dari kebutuhan layanan, lalu diterjemahkan ke rancangan teknis oleh pengembang.
Penguncian membantu mengatur proses yang boleh berjalan
Kunci proses dapat dipakai untuk membatasi pelaksanaan bersamaan pada cakupan yang dirancang. Dokumentasi Laravel, misalnya, menyediakan withoutOverlapping untuk mencegah tugas terjadwal bertumpuk dan menjelaskan penggunaan cache untuk kuncinya. Contoh tersebut menunjukkan fungsi penguncian, bukan pengaturan universal untuk setiap aplikasi. Bila website memakai kerangka lain, gunakan mekanisme yang didukung perangkat lunaknya dan pastikan tim memahami lokasi, pemilik, serta masa berlaku kunci tersebut.
Perhatikan bahwa kunci yang berakhir saat proses masih bekerja dapat membuka peluang proses lain berjalan, sedangkan kunci yang tertinggal dapat menahan pekerjaan baru. Karena itu, minta pengembang menjelaskan cara memulihkan keadaan setelah proses berhenti mendadak. Jangan menghapus kunci secara spontan hanya karena hasil belum terlihat. Pastikan apakah proses memang sudah berhenti dan tindakan apa yang aman dilakukan. Penguncian perlu memiliki prosedur pemeriksaan, bukan hanya dipasang sebagai tambahan yang tidak lagi ditinjau.
Banyak server memerlukan kesepakatan yang dapat dilihat bersama
Jika aplikasi berjalan pada beberapa server, kunci lokal pada satu mesin belum tentu diketahui mesin lain. Dokumentasi Laravel menjelaskan bahwa fitur pelaksanaan pada satu server memerlukan penyimpanan cache bersama yang didukung dan dapat diakses semua server terkait. Artinya, keputusan 'hanya satu yang bekerja' memerlukan mekanisme koordinasi yang sesuai. Menyalin konfigurasi sama ke beberapa server tidak otomatis menciptakan kesepakatan mengenai siapa yang boleh memulai pekerjaan.
Kubernetes juga mendokumentasikan bahwa kebijakan konkurensi suatu CronJob berlaku pada pekerjaan dari CronJob itu sendiri, bukan seluruh definisi lain yang mungkin melakukan tindakan serupa. Contoh platform berbeda ini membantu menjelaskan pentingnya cakupan. Tim perlu mencatat pekerjaan mana yang dianggap sama dan pemicu mana yang harus berkoordinasi. Jangan menganggap fitur bernama mirip pada dua alat memiliki perilaku identik; periksa dokumentasi alat dan rancangan aplikasi yang benar-benar digunakan.
Idempotensi berfokus pada akibat ketika pekerjaan diulang
Penguncian bersamaan tidak menjawab seluruh persoalan pengulangan. Sebuah tugas dapat selesai, lalu dipanggil lagi setelah kuncinya dilepas. Idempotensi berarti pengulangan operasi yang sama tidak menambahkan akibat yang tidak diinginkan. Dokumentasi Kubernetes menyarankan pekerjaan yang idempoten karena penjadwalan dapat menghadapi keadaan ketika pekerjaan dibuat lebih dari sekali atau tidak dibuat. Prinsip ini relevan untuk membahas rancangan, meskipun website Anda tidak memakai Kubernetes.
Sebagai contoh hipotetis, laporan untuk satu periode dapat memiliki identitas pekerjaan yang tetap, sehingga percobaan ulang dikenali sebagai pekerjaan sama. Pengembang perlu merancang pencatatan identitas, pemeriksaan hasil, dan perubahan data secara konsisten; sekadar memeriksa 'belum ada' sebelum menulis dapat tetap bertabrakan dengan proses lain. Amazon Builders' Library membahas identitas permintaan serta kebutuhan menjaga pencatatannya selaras dengan operasi. Pilih identitas berdasarkan maksud pekerjaan, bukan hanya kemiripan isi yang kebetulan tampak sama.
Gangguan jaringan dapat meninggalkan hasil yang belum diketahui
Ketika tugas memanggil layanan lain, batas waktu koneksi tidak selalu menjelaskan apakah tindakan di pihak tujuan sudah terjadi. Percobaan ulang tanpa pemeriksaan dapat menambahkan tindakan kedua. Minta pengembang menggunakan fasilitas pengulangan aman yang memang didukung penyedia, atau merancang pemeriksaan hasil dan penanganan manual untuk keadaan yang tidak pasti. Jangan mengklaim setiap pengiriman dapat dijamin satu kali hanya dengan menambahkan kunci pada penjadwal website.
Pisahkan status 'gagal sebelum diproses', 'selesai', dan 'hasil belum diketahui' bila proses membutuhkannya. Untuk keadaan terakhir, operator perlu mengetahui bukti apa yang boleh diperiksa dan siapa yang mengambil keputusan melanjutkan. Contoh hipotetisnya adalah pembuatan dokumen pada layanan eksternal yang belum memberikan respons. Daripada langsung mengulang semua tindakan, tim dapat meninjau identitas permintaan dan hasil di tujuan sesuai fasilitas yang tersedia. Rencana semacam ini membantu menjaga pengulangan tetap terarah saat gangguan terjadi.
Uji skenario ganda pada lingkungan yang sesuai
Siapkan data contoh dan lingkungan uji bersama pengembang, lalu periksa lebih dari skenario berhasil sekali. Bahas dua pemanggilan yang datang bersamaan, pemanggilan kedua setelah selesai, proses yang berhenti di tengah, serta respons layanan luar yang terlambat. Tentukan hasil yang diharapkan untuk tiap keadaan sebelum pengujian. Tujuannya ialah mengetahui apakah aplikasi menolak, melanjutkan, menunda, atau memerlukan pemeriksaan tambahan berdasarkan rancangan yang telah disepakati.
Catat bukti pelaksanaan dan akibat akhirnya secara terpisah. Dua percobaan dapat tercatat tetapi hanya satu hasil yang memang dibuat; sebaliknya, satu catatan pemicu belum membuktikan bahwa tidak ada tindakan ganda di tempat lain. Periksa juga apakah pekerjaan normal berikutnya masih dapat berjalan setelah kegagalan. Hindari memakai pelanggan atau transaksi nyata sebagai bahan percobaan. Kriteria penerimaan perlu menjelaskan hasil bisnis yang dapat diamati, bukan hanya bahwa proses berhenti tanpa pesan kesalahan.
Serahkan alur yang jelas kepada operator hosting
Simpan panduan ringkas tentang sumber pemicu, zona waktu, identitas pekerjaan, cakupan kunci, perilaku pengulangan, dan jalur penanganan ketika hasil tidak pasti. Tentukan siapa yang boleh menjalankan ulang tugas dan bukti apa yang harus diperiksa sebelumnya. Saat aplikasi berpindah server, tinjau kembali apakah pemicu lama masih aktif. Prosedur ini membantu operator memahami tindakan yang boleh dilakukan tanpa harus menebak maksud setiap proses ketika suatu hasil belum muncul.
Kenali layanan melalui https://www.jagoweb.com/ dan baca informasi hosting cPanel di https://www.jagoweb.com/hosting-cpanel. Konfirmasikan dukungan serta batas pelaksanaan tugas terjadwal pada paket yang dipilih sebelum menyusun rancangan. Penyedia hosting dan pengembang perlu berbagi pemahaman tentang kewenangan masing-masing. Dengan pemicu, koordinasi, dan akibat pengulangan yang dijelaskan terpisah, tim memiliki dasar untuk menelusuri proses ganda dan memperbaikinya tanpa sekadar mengganti frekuensi setiap kali masalah muncul.
Bacaan terkait
Sumber dan referensi
