Bagaimanakah Anda Akan Mereka Bentuk Penjadual Kerja Teragih?

Kehendak dan skop soalan

Reka bentuk penjadual kerja teragih berbilang penyewa. Ia menyokong kerja sekali sahaja dan kerja cron dengan zon masa IANA, menyimpan 20 juta jadual aktif, mencipta 200 juta kejadian setiap hari, dan mungkin mempunyai 500,000 pencetus tepat pada awal jam. Di bawah beban puncak normal, kerja ketat mesti sampai ke baris gilir tahan lasak (durable queue) dalam masa 5 saat dari masa yang dijadualkan pada p99. Kerja yang tidak memerlukan masa yang tepat boleh diagihkan merentasi tetingkap fleksibel selama 5 minit.

API menyokong penciptaan, menjeda, menyambung semula, mengemas kini, dan membatalkan jadual. Penghantaran adalah sekurang-kurangnya sekali. Penjadual bertanggungjawab untuk menukar masa yang dijadualkan menjadi suatu kejadian dan meletakkannya ke dalam baris gilir sasaran. Penempatan kontena, kebergantungan DAG, dan orkestrasi aliran kerja sebarangan berada di luar skop. Masa penyiapan tugas sebenar bukan sebahagian daripada SLO penjadualan 5 saat.

Soalan ini sesuai untuk peranan peringkat pertengahan hingga kanan bagi backend, platform, infrastruktur, dan reka bentuk sistem. Bahan reka bentuk sistem awam 2026 masih menganggap penjadual kerja sebagai masalah temu duga kendiri, manakala dokumentasi semasa AWS dan Kubernetes mendedahkan batasan praktikal berkaitan tetingkap fleksibel, penciptaan pendua atau yang hilang, misfire, zon masa, dan percubaan semula. Cabaran terasnya bukanlah menghuraikan cron. Ia adalah merealisasikan (materializing) satu masa yang dijadualkan secara andal ke dalam pelaksanaan yang boleh dijejak, boleh dicuba semula, dan beridempoten.

Perkara yang dinilai oleh penemu duga

Isyarat pertama ialah memisahkan Schedule, Occurrence, dan Attempt. Suatu jadual (schedule) menerangkan pemasaan masa hadapan. Suatu kejadian (occurrence) mewakili satu masa tertentu yang dijadualkan. Suatu percubaan (attempt) mewakili satu percubaan penghantaran atau pemprosesan untuk kejadian tersebut. Satu baris tunggal dengan next_run_at dan status mencampuradukkan percubaan semula, sejarah, kemas kini, dan pencetus seterusnya.

Isyarat kedua ialah enggan menjanjikan tepat sekali (exactly-once) secara sambil lewa. Penjadual mungkin terhenti (crash) selepas memasukkan ke dalam baris gilir tetapi sebelum merekodkan kejayaan, dan pekerja mungkin menyelesaikan kesan sampingan sebelum kehilangan perakuan (acknowledgment) daripadanya. Kubernetes secara eksplisit menyatakan bahawa CronJob kadangkala boleh mencipta dua Job atau tiada Job langsung dan oleh itu mengesyorkan kerja yang beridempoten. Pajakan keterlihatan (visibility lease) baris gilir standard juga tidak boleh menghalang penghantaran pendua secara mutlak. Jawapan yang kukuh memilih penghantaran sekurang-kurangnya sekali dan menjadikan kesan perniagaan beridempoten dengan ID kejadian yang stabil.

Isyarat ketiga ialah mengendalikan lonjakan serentak. Purata harian hanyalah sekitar 2,315 kejadian sesaat, tetapi meletakkan 500,000 pencetus ketat ke dalam baris gilir dalam masa 5 saat memerlukan kira-kira 100,000 penghantaran sesaat. Kapasiti yang berdasarkan purata akan gagal pada awal jam. Satu timbunan tertib masa global (global time-ordered heap) juga mewujudkan titik panas (hot spot) kapasiti dan ketersediaan.

Akhir sekali, tingkah laku masa dan kegagalan mestilah menjadi kontrak produk: sama ada cron bermaksud waktu jam dinding tempatan atau selang masa tetap, apa yang berlaku kepada waktu penjimatan siang (daylight-saving) yang tidak wujud dan berulang, sama ada gangguan sepuluh minit menyebabkan proses susulan (catch-up) atau langkauan, sama ada larian boleh bertindih, dan maksud kemas kini atau pembatalan selepas kejadian dimasukkan ke dalam baris gilir.

Soalan untuk penjelasan

• Apakah yang diukur oleh lima saat? Takrifkannya sebagai enqueued_at - scheduled_for, yang hanya merangkumi penjadualan dan kemasukan ke dalam baris gilir. Jika penyiapan diperlukan, model kapasiti berubah sepenuhnya.
• Adakah jadual sekali sahaja, cron, dan kadar tetap semuanya diperlukan? Reka bentuk ini menyokong sekali sahaja dan cron. Setiap 24 jam berbeza daripada 09:00 waktu tempatan merentasi perubahan waktu penjimatan siang dan tidak boleh menggunakan pengiraan yang sama.
• Adakah pendua lebih baik daripada peninggalan? Reka bentuk ini memilih penghantaran sekurang-kurangnya sekali dan mengendalikan pendua dengan idempotensi. Kesan luaran yang tidak boleh diulang memerlukan kunci idempotensi atau risiko sisa yang eksplisit.
• Apakah yang berlaku kepada kejadian yang terlepas semasa masa henti (downtime)? Setiap jadual memerlukan misfire_policy, kelewatan maksimum, dan had susulan (catch-up cap). Jika tidak, pemulihan mungkin tiba-tiba mencipta berjuta-juta kejadian yang sudah lapuk.
• Bolehkah satu jadual bertindih dengan dirinya sendiri? Nilai lalai ialah ALLOW, dengan SKIP_IF_RUNNING sebagai pilihan lain. Menggantikan kerja sedia ada yang sedang berjalan (in-flight work) sewenang-wenangnya adalah tidak selamat apabila kesan sampingan tidak boleh dibatalkan semula.
• Sejauh manakah jaminan kemas kini dan pembatalan? Kejadian yang belum selesai daripada versi lama harus menjadi tidak sah. Memadam jadual tidak boleh menarik balik kerja yang telah dituntut atau diselesaikan oleh pekerja, jadi API mesti melaporkan keadaan sebenar.
• Apakah sasaran yang dituju? Reka bentuk ini meletakkan kejadian ke dalam baris gilir tahan lasak untuk pengendali yang berdaftar. Kod pengguna sebarangan dikecualikan supaya persekitaran kotak pasir (sandboxing) dan penempatan pengkomputeran tidak mengaburkan masalah penjadualan.
• Apakah pengasingan penyewa yang diperlukan? Kuat kuasakan kuota berasingan untuk kiraan jadual, kadar pencetus, keserempakan larian, dan kadar susulan. Satu kelompok awal jam tidak boleh menggunakan setiap shard dan baris gilir.

Jawapan 30 saat

“Saya akan memisahkan jadual, kejadian, dan percubaan. Suatu jadual menyimpan ungkapan, zon masa IANA, versi, dan pencetus seterusnya. Nod penjadual melakukan pembahagian shard mengikut baldi masa (time bucket) dan cincangan ID jadual serta hanya merealisasikan ufuk yang terhad (bounded horizon). ID kejadian diperoleh daripada ID jadual, versi, dan masa asal yang dijadualkan; kekangan unik menghalang realisasi pendua semasa failover berlaku. Kejadian, pencetus seterusnya, dan outbox dilakukan (commit) dalam satu transaksi, kemudian penghubung (relay) menulis ke baris gilir tahan lasak sekurang-kurangnya sekali. Pekerja memproses di bawah pajakan keterlihatan yang boleh diperbaharui, manakala pengendali perniagaan menyahduplikasi mengikut ID kejadian. Kerja ketat diperuntukkan untuk kadar puncak, dan kerja fleksibel menggunakan jitter deterministik. Tingkah laku misfire, pertindihan, zon masa, dan pembatalan adalah dasar yang eksplisit. Saya akan mengesahkan dengan 500,000 pencetus serentak, kegagalan pada setiap titik serahan, sempadan waktu penjimatan siang, dan perlumbaan pembatalan.”

Analisis mendalam langkah demi langkah

Kira satah data (data plane) sebelum melukis komponen:

average = 200,000,000 / 86,400 ≈ 2,315 occurrences/s
strict_peak = 500,000 / 5 = 100,000 dispatches/s

Kemuncak ketat adalah lebih daripada 43 kali ganda purata harian. Jika jadual aktif dan kejadian masing-masing menggunakan kira-kira 1 KB storan logik, metadata jadual adalah kira-kira 20 GB dan kejadian menambah kira-kira 200 GB setiap hari. Indeks, replika, mesej baris gilir, dan pengekalan sejarah menambah lagi saiz ini. Ini adalah andaian saiz untuk pemetakan (partitioning) dan peringkat storan; medan dan indeks sebenar mesti diuji bebannya.

Satah kawalan (control plane) mengesahkan ungkapan, mengizinkan penyewa, menguatkuasakan kuota, mencipta secara beridempoten, dan menetapkan versi kemas kini. Model yang dipermudahkan ialah:

Schedule(schedule_id, tenant_id, expression, time_zone, version,
         next_run_at, state, misfire_policy, max_lateness,
         overlap_policy, flexible_window)

Occurrence(occurrence_id, schedule_id, schedule_version,
           scheduled_for, available_at, state, attempt_count)

Attempt(attempt_id, occurrence_id, lease_token, started_at,
        finished_at, result)

UNIQUE(schedule_id, schedule_version, scheduled_for)

API penciptaan menerima kunci idempotensi pemanggil. Ia mengesahkan ungkapan cron dan zon masa serta memaparkan beberapa pencetus masa hadapan supaya ungkapan yang sah dari segi sintaks tetapi tidak disengajakan dapat dikesan awal. Simpan next_run_at dalam UTC sambil mengekalkan ungkapan asal dan zon IANA. Kerja harian waktu tempatan mesti memperoleh masa seterusnya daripada peraturan zon dan bukannya menambah 24 jam pada cap masa UTC sebelumnya.

Punca tepi zon masa memerlukan kontrak yang stabil. Reka bentuk ini melangkau waktu tempatan yang tidak wujud semasa peralihan jam ke hadapan (spring-forward) dan dijalankan sekali apabila peralihan jam ke belakang (fall-back) mengulangi waktu jam dinding. Kemas kini zon masa hanya mempengaruhi kejadian masa hadapan di bawah versi jadual baharu. AWS Scheduler mendokumenkan tingkah laku langkau-dan-jalan-sekali yang sama, tetapi ia kekal sebagai pilihan produk di sini dan bukannya peraturan penjadual universal. Jenis kadar tetap masa hadapan akan menggunakan tempoh masa berlalu dan tidak akan beranjak mengikut penjimatan siang.

Storan jadual mempunyai indeks yang setara dengan (time_bucket, shard, next_run_at), bersama-sama shard = hash(schedule_id) mod N. Nod penjadual memajak berbilang shard logik dan mengimbas ufuk perancangan terhad, seperti beberapa minit seterusnya. Satu ketua global tunggal mengehadkan kapasiti dan pemulihan. Pajakan shard mengurangkan imbasan pendua, manakala keunikan pangkalan data dan penulisan bersyarat menyediakan sempadan ketepatan muktamad.

Bagi setiap jadual yang sampai masanya, satu transaksi menyisipkan Occurrence yang deterministik, memajukan next_run_at secara bersyarat daripada versi jadual semasa, dan menulis baris outbox penghantaran dengan available_at. Jika dua nod bertindih semasa peralihan pajakan, keunikan mengekalkan satu kejadian (schedule_id, version, scheduled_for). Kemas kini bersyarat menghalang nod lama daripada menggerakkan pencetus seterusnya ke belakang.

Jangan jana sejarah cron yang tidak terhingga terlebih dahulu. Ufuk perancangan yang terlalu pendek memindahkan jitter storan terus ke dalam SLO 5 saat. Ufuk yang terlalu panjang pula menyebabkan kemas kini dan pembatalan membatalkan set besar kejadian versi lama. Pilih ufuk yang meliputi belanjawan failover dan kemasukan baris gilir penjadual, kemudian sesuaikan daripada kelengahan (lag) yang diukur. Jadual sekali sahaja menjadi terminal; jadual berulang hanya menyimpan kursor pencetus seterusnya manakala kejadian lama berpindah ke sejarah bertingkat.

Berhampiran dengan available_at, penghubung penghantaran (dispatch relay) menulis peristiwa outbox ke baris gilir tahan lasak yang dipetakkan mengikut penyewa dan keutamaan. Jika penghubung terhenti selepas baris gilir menerima mesej tetapi sebelum perakuan pangkalan data, ia menghantar occurrence_id yang sama sekali lagi. Pendua itu disengajakan. Menandakan dihantar sebelum masuk baris gilir boleh menyebabkan kerja tertinggal, manakala memasukkan baris gilir sebelum menanda boleh menduplikasi kerja. Outbox bertransaksi menjadikan pertukaran kompromi (trade-off) ini sebagai laluan sekurang-kurangnya sekali yang eksplisit dan boleh dicuba semula secara beridempoten.

Lima ratus ribu kerja awal jam memerlukan lebih daripada sekadar benang undian (polling threads) tambahan. Bahagikan setiap baldi masa kepada shard cincangan ID jadual yang mencukupi. Jika ujian beban menunjukkan bahawa satu shard secara selamat melakukan Q penghantaran sesaat dengan transaksi sebenar, indeks, dan penulisan baris gilir, satah ketat memerlukan sekurang-kurangnya ceil(100,000 / Q) shard yang tersedia serentak ditambah ruang simpanan kegagalan (failure headroom). Baris gilir menggunakan keadilan berwajaran penyewa (tenant-weighted fairness) dan kuota kadar supaya satu penyewa tidak dapat memonopoli lorong ketat.

Kerja dengan tetingkap 5 minit menggunakan jitter deterministik: available_at = scheduled_for + hash(occurrence_id) mod 300s. Kejadian yang sama mendapat masa yang sama selepas percubaan semula dan failover, menjadikan tingkah laku boleh dihasilkan semula sambil menyebarkan pencetus yang berkorelasi. Kerja ketat mengekalkan masa asal dan kapasiti yang diperuntukkan. Amazon's Builders' Library juga mengenal pasti jitter pada kerja penyelenggaraan berkala sebagai satu cara untuk mengurangkan kegagalan berkorelasi.

Seorang pekerja menerima kejadian di bawah pajakan keterlihatan yang terhad masa dan memperbaharuinya dengan denyutan jantung (heartbeats) untuk kerja yang panjang. Tamat tempoh pajakan menjadikan mesej kelihatan semula, dan penghantaran pendua tidak dapat dikecualikan walaupun semasa dalam tetingkap. Oleh itu, mesin keadaan (state machine) tidak boleh menganggap pajakan sebagai tepat sekali:

SCHEDULED -> ENQUEUED -> RUNNING -> SUCCEEDED
                         |   |
                         |   +-> RETRY_WAIT -> ENQUEUED
                         +------> DEAD

Side states: MISSED, CANCELED, SKIPPED_OVERLAP

Setiap tuntutan mendapat lease_token baharu atau generasi percubaan yang meningkat. Kemas kini penyiapan mesti sepadan dengan token semasa supaya pekerja yang telah tamat masa tidak boleh menulis ganti keadaan percubaan yang lebih baharu. Pemagaran (fencing) ini melindungi keadaan penjadual, bukan kesan luaran yang telah dilakukan oleh pekerja lama. Idempotensi perniagaan menggunakan occurrence_id sebagai kunci unik dalam transaksi yang sama seperti kesan tersebut, atau sebagai kunci idempotensi API hiliran. Jika sasaran luaran tidak mempunyai idempotensi dan tidak boleh ditanya, risiko pendua tetap wujud.

Cuba semula mengikut kelas ralat. Ralat parameter kekal dihantar ke DEAD. Kegagalan rangkaian, pendikit (throttling), dan respons 5xx sementara menggunakan backoff eksponen dengan jitter penuh, dibatasi oleh percubaan maksimum, tarikh akhir kejadian, dan belanjawan penyewa. DLQ baris gilir mengekalkan kejadian yang telah kehabisan percubaan. Main semula manual mengekalkan occurrence_id yang sama; memperuntukkan ID baharu akan memintas penyahduplikasian.

Pemulihan satah kawalan memerlukan dasar misfire yang eksplisit. SKIP menandakan kejadian yang melepasi kelewatan maksimum sebagai MISSED. FIRE_ONCE mengeluarkan hanya kejadian terlepas yang terkini. CATCH_UP mengeluarkan paling banyak K, tertakluk kepada kadar susulan penyewa. Had tarikh akhir permulaan dan jadual terlepas Kubernetes mendedahkan keputusan yang sama: pemulihan tanpa batasan sama ada kehilangan kerja yang diperlukan atau mewujudkan ribut pemulihan.

SKIP_IF_RUNNING memeriksa secara atomik untuk kejadian RUNNING semasa daripada jadual yang sama sebelum menandakan yang baharu sebagai SKIPPED_OVERLAP. Tanpa peralihan keadaan atomik, dua kejadian mungkin kedua-duanya melihat tiada pendahulu. Membatalkan atau mengemas kini meningkatkan versi jadual dan membatalkan kejadian versi lama yang belum dituntut. Pekerja menyemak semula versi dan penanda pembatalan sebelum melaksanakan kesan sampingan. Kerja yang telah dimulakan memerlukan pembatalan secara bekerjasama (cooperative cancellation), dan kesan luaran yang telah selesai tidak boleh diundur balik oleh penjadual.

Kebolehcerapan (observability) mengikut jaminan: p50/p95/p99 untuk schedule_lag = enqueued_at - scheduled_for; baris belum selesai bagi setiap baldi masa; kelengahan realisasi; konflik keunikan; tunggakan outbox; usia baris gilir; tuntutan pendua; percubaan semula dan DLQ; MISSED dan langkauan pertindihan; pendikit penyewa; ofset jam; dan masa yang dihabiskan dalam setiap keadaan kejadian. Ketersediaan API tidak membuktikan bahawa kejadian yang dijangkakan sampai ke baris gilir tepat pada masanya.

Ujian penerimaan pertama kali menyuntik 500,000 kejadian ketat pada awal jam dan memeriksa p99 5 saat serta keadilan penyewa. Kemudian henti paksa (crash) penjadual sebelum penyisipan, selepas commit transaksi, dan selepas penghantaran baris gilir; pastikan tiada peninggalan senyap dan sahkan penyahduplikasian mengikut ID kejadian yang sama. Liputi juga situasi pekerja kehilangan perakuan selepas kesannya, tamat tempoh pajakan, ketiga-tiga dasar misfire selepas gangguan satah kawalan selama sepuluh minit, kedua-dua peralihan waktu penjimatan siang, perlumbaan kemas kini dan pembatalan, pertindihan larian yang panjang, dan ribut susulan daripada satu penyewa.

Contoh jawapan yang kukuh

“Saya akan mentakrifkan SLO sebagai masa dijadualkan hingga penerimaan baris gilir tahan lasak, tidak termasuk pelaksanaan. Dua ratus juta pencetus harian secara puratanya sekitar 2,315 sesaat, tetapi 500,000 pencetus awal jam dalam masa lima saat memerlukan satah ketat bersaiz untuk 100,000 sesaat. Kerja fleksibel boleh diagihkan secara deterministik merentasi lima minit.

Model ini memisahkan jadual, kejadian, dan percubaan. Suatu jadual menyimpan ungkapan cron, zon IANA, versi, dan next_run_at. ID kejadian diperoleh daripada ID jadual, versi, dan scheduled_for serta mempunyai kekangan unik. Nod penjadual melakukan shard mengikut baldi masa dan cincangan ID jadual serta memajak shard untuk pengimbasan. Satu transaksi menyisipkan kejadian, memajukan pencetus seterusnya, dan menulis outbox penghantaran, jadi failover tidak meninggalkan kerja secara senyap dan penghubung yang berulang hanya menghantar ID kejadian yang sama.

Baris gilir dan pekerja menggunakan semantik sekurang-kurangnya sekali. Pekerja mempunyai pajakan keterlihatan yang boleh diperbaharui, dan penyiapan mesti sepadan dengan token pajakan semasa. Pengendali perniagaan menggunakan ID kejadian sebagai kunci unik pangkalan data atau kunci idempotensi hiliran. Tamat tempoh pajakan kemudiannya boleh menambah percubaan tanpa menambah kesan perniagaan; sasaran luaran tanpa idempotensi mengekalkan risiko pendua yang eksplisit.

Tingkah laku misfire, pertindihan, zon masa, dan pembatalan ialah dasar API. Selepas masa henti, jadual boleh melangkau, mencetus sekali, atau mengejar paling banyak K kali. Masa cron yang tidak wujud dilangkau dan waktu jam dinding yang berulang dijalankan sekali. Kemas kini meningkatkan versi, dan pekerja menyemak semula sebelum melakukan kesan sampingan. Saya akan menguji kemuncak awal jam, setiap tetingkap henti paksa, mesej pendua, sempadan waktu penjimatan siang, dan perlumbaan pembatalan, sambil memantau kelengahan jadual, tunggakan masa matang, tuntutan pendua, kejadian terlepas, DLQ, dan pendikit penyewa.”

Kesilapan biasa

• Menggabungkan jadual, kejadian, dan percubaan dalam satu baris → Percubaan semula menulis ganti sejarah dan kemas kini tidak dapat mengenal pasti kejadian lama → Pisahkan Schedule, Occurrence, dan Attempt.
• Menetapkan saiz berdasarkan purata harian 2,315 sesaat → Lima ratus ribu pencetus awal jam menyebabkan kelengahan yang teruk → Uji beban shard pada kemuncak ketat dan agihkan kerja fleksibel secara deterministik.
• Menggunakan satu ketua global dengan min-heap dalam memori → Ketua menjadi botol leher (bottleneck) kapasiti dan pemulihan, dan but semula membina semula semua kerja masa hadapan → Gunakan indeks masa tahan lasak, shard logik, dan ufuk terhad.
• Menandakan dihantar sebelum menulis ke baris gilir → Kegagalan baris gilir meninggalkan kejadian secara senyap → Tulis outbox secara bertransaksi dan hubungkan sekurang-kurangnya sekali.
• Mendakwa kunci dan tamat masa keterlihatan menjamin tepat sekali → Tamat masa dan kehilangan perakuan masih menyebabkan percubaan bertindih → Gabungkan ID kejadian yang stabil, token pemagaran (fencing tokens), dan idempotensi perniagaan.
• Memainkan semula setiap kejadian sejarah yang terlepas selepas pemulihan → Berjuta-juta tugas lapuk mewujudkan gangguan kedua → Tetapkan kelewatan maksimum, had susulan, dan kadar penyewa.
• Menambah 24 jam dalam UTC untuk cron harian tempatan → Waktu jam dinding hanyut merentasi waktu penjimatan siang → Kekalkan zon IANA dan kira kejadian tempatan seterusnya.
• Memadam baris untuk menjeda atau membatalkan → Kerja yang telah direalisasikan atau dimasukkan ke dalam baris gilir mungkin masih berjalan, dan sejarah audit hilang → Batalkan mengikut versi dan semak semula keadaan sebelum kesan sampingan.
• Meletakkan setiap penyewa pada satu baris gilir FIFO → Kelompok awal jam yang besar menyekat penyewa lain → Gunakan penjadualan adil peka penyewa serta asingkan kuota pencetus dan keserempakan.
• Hanya memantau kejayaan API → Suatu jadual boleh berjaya dicipta tetapi tidak pernah mencetus tepat pada masanya → Jejak kelengahan jadual, tunggakan masa matang, kejadian terlepas, dan penyesuaian keadaan (state reconciliation).

Soalan susulan

Soalan susulan 1: Bagaimana jika penjadual terhenti selepas penghantaran ke baris gilir tetapi sebelum mengemas kini outbox?

Penghubung menghantar occurrence_id yang sama sekali lagi. Pengguna baris gilir dan sasaran perniagaan menyahduplikasi berdasarkan ID tersebut, dan perakuan outbox adalah bersyarat. Pendua dipilih berbanding peninggalan kerana pangkalan data dan baris gilir tidak berkongsi satu transaksi. Log bertransaksi boleh mengecilkan tetingkap risiko, tetapi kesan luaran masih memerlukan idempotensi.

Soalan susulan 2: Bagaimanakah anda menyokong rantau aktif-aktif (active-active regions)?

Tetapkan satu rantau asal dan generasi yang meningkat bagi setiap jadual. Hanya rantau yang memegang generasi semasa boleh merealisasikan kejadian, manakala baris gilir pelaksanaan boleh menghala ke rantau sasaran. Failover memajukan generasi sebelum rantau baharu menyambung semula daripada kursor tahan lasak. Kunci kejadian yang unik secara global atau lapisan pengagregatan kekal sebagai sempadan pendua muktamad. Satah kawalan penulis tunggal (single-writer) dengan failover serantau adalah lebih mudah apabila penulisan merentasi rantau tidak diperlukan.

Soalan susulan 3: Semasa fall-back, waktu tempatan 01:30 berlaku dua kali. Berapa kalikah ia patut dijalankan?

Tiada jawapan universal; ia adalah sebahagian daripada kontrak jadual. Reka bentuk ini berjalan sekali dengan menggabungkan dua calon UTC tersebut menggunakan tarikh tempatan, waktu jam dinding, dan zon. Penyesuaian kewangan yang memerlukan kedua-dua detik fizikal akan memilih dua kejadian dengan nilai scheduled_for yang berbeza. API harus memaparkan larian masa hadapan sebelum menyimpan.

Soalan susulan 4: Suatu kerja berjalan selama dua jam tetapi berulang setiap jam. Apakah yang berlaku?

ALLOW menjalankannya secara serentak. SKIP_IF_RUNNING menandakan kejadian baharu sebagai SKIPPED_OVERLAP secara atomik. Jika produk memerlukan penungguan, tambah QUEUE_ONE dan kekalkan paling banyak satu kejadian yang belum selesai. Menggantikan larian lama hanya selamat apabila pengendali menyokong pembatalan secara bekerjasama kerana kesannya mungkin sudah wujud.

Soalan susulan 5: Penjadual tidak berfungsi selama sehari. Bagaimanakah anda pulih tanpa membebani sasaran secara berlebihan?

Gunakan SKIP, FIRE_ONCE, atau CATCH_UP terhad bagi setiap jadual, kemudian sekat kadar mengikut kapasiti penyewa dan sasaran. Sambung semula pengimbasan daripada next_run_at tahan lasak dan bukannya menggantikan kursor dengan masa semasa. Jejak masa belum selesai yang paling lama dan anggaran tempoh pengosongan, serta asingkan kerja baharu yang ketat daripada kapasiti susulan.

Soalan susulan 6: Bagaimanakah anda membuktikan tiada peninggalan senyap berlaku?

Penyesuai luar talian (offline reconciler) mengira semula secara bebas set kejadian yang dijangkakan daripada versi jadual dan peraturan masa, kemudian membandingkannya dengan set kunci unik Occurrence. Setiap item yang dijangkakan mestilah berjaya, gagal, dibatalkan, terlepas, atau tidak hadir. Metrik dalam talian mengesan kelengahan; penyesuaian mengesan jurang di mana sistem tidak melaporkan sebarang ralat kerana sesuatu kejadian tidak pernah dicipta sama sekali.