Gesaan dan skop
Sebuah kluster mendayakan pemalam penjadualan yang memanggil pelayan API. Apabila kependaman API meningkat, panggilan segerak menduduki kitaran penjadualan dan Pod yang tidak dijadualkan terkumpul. Reka pendekatan tak segerak seperti yang diterangkan oleh KEP-5229, merangkumi baris gilir keutamaan, penyatuan permintaan (request coalescing), percubaan semula, pembatalan, keadilan dan pengunduran (rollback).
Perkara yang diuji oleh penemu duga
- Sama ada anda memisahkan semantik kitaran penjadualan bersiri daripada kesan sampingan API tak segerak.
- Sama ada baris gilir keutamaan terikat dan penyatuan permintaan menghalang kebuluran (starvation) dan penulisan pendua.
- Sama ada anda mentakrifkan kunci keidempotanan (idempotency keys), batas masa (deadlines), pembatalan, hasil lapuk (stale results) dan ralat kekal.
- Sama ada anda merangkumi keadilan keutamaan, tekanan balik (backpressure), metrik dan pelancaran berpintu ciri (feature-gated).
Soalan penjelasan untuk ditanya
- Adakah panggilan tersebut merupakan bacaan, penulisan idempoten, atau penciptaan sumber luaran? Kesan sampingan menentukan had percubaan semula.
- Bolehkah pemalam menerima keadaan luaran yang berkesudahan (eventual), atau adakah ia mesti mengesahkan keadaan sebelum pengikatan (binding)?
- Adakah kegagalan memasukkan semula Pod ke dalam baris gilir sebagai tidak boleh dijadualkan, atau hanya mencuba semula operasi API? Pastikan gelung tersebut berasingan.
- Apakah QPS API kluster, tahap penjadualan serentak dan belanjawan baris gilir?
Kerangka jawapan 30 saat
Pindahkan operasi API yang perlahan daripada bebenang penjadualan ke baris gilir keutamaan terikat. Penjadual menghantar tugas dengan kunci keidempotanan dan meneruskan pemprosesan Pod lain. Layan mengikut keutamaan Pod dan masa menunggu, sambil menyatukan (coalescing) kunci yang serupa. Penyelesaian tugas hanya mencetuskan penilaian semula yang selamat; hasil yang lapuk tidak boleh mengikat Pod. Kelaskan ralat kepada yang boleh dicuba semula dan kekal, dengan batas masa, pembatalan, backoff dan had keserentakan. Lancarkan di sebalik feature gate menggunakan kedalaman baris gilir, masa menunggu, kadar kejayaan dan kependaman penjadualan; lumpuhkan laluan tak segerak dan undur semula (fall back) apabila ambang gagal dipenuhi.
Analisis mendalam langkah demi langkah
1. Tentukan sempadan segerak
Kitaran penjadualan memilih nod dan memiliki konteks penjadualan; tugas tak segerak melakukan kerja yang boleh ditangguhkan. Jika hasilnya adalah prasyarat pengikatan yang tegar, modelkannya sebagai belum selesai (pending) dan halang pengikatan sehingga pengesahan diperoleh. Hanya kerja yang tidak menjejaskan kitaran semasa boleh dijadikan tak segerak.
2. Bina baris gilir keutamaan terikat
Setiap tugas membawa UID Pod, jenis operasi, kunci keidempotanan, batas masa dan konteks pembatalan. Baris gilir mempunyai had kapasiti. Apabila penuh, kembalikan isyarat tekanan balik (backpressure) yang jelas dan bukannya mengumpul memori tanpa had. Layan kerja berkeutamaan tinggi terlebih dahulu, manakala penuaan (aging) atau kuota menghalang kebuluran kekal.
submit(key, priority, deadline, operation)
if same key is pending: coalesce(operation)
else if queue is full: return Backpressure
else enqueue(operation)3. Penyatuan (coalescing) dan keidempotanan
Penyatuan menggabungkan permintaan serentak untuk satu operasi logik; ia tidak menyediakan keidempotanan pelayan API. Operasi penulisan memerlukan kunci sumber yang stabil, kemas kini bersyarat, atau keidempotanan bahagian pelayan. Periksa hasil terdahulu sebelum mencuba semula supaya sumber luaran tidak dicipta dua kali. Permintaan untuk versi atau sasaran yang berbeza tidak boleh digabungkan semata-mata kerana rentetannya kelihatan serupa.
4. Penyelesaian, pembatalan dan hasil lapuk
Terbitkan peristiwa penyelesaian yang meminta Pod berkaitan menilai semula; jangan anggap bahawa keadaan penjadualan masih sah. Batalkan tugas apabila Pod dipadamkan, diprapintas (preempted), atau memasuki konteks penjadualan baharu. Gugurkan hasil yang melepasi batas masa dan rekodkan sebabnya. Panggilan API yang berjaya daripada konteks yang telah tamat tempoh tidak boleh melaksanakan pengikatan lama.
5. Percubaan semula, tekanan balik dan keadilan
Cuba semula batas masa tamat, ralat rangkaian sementara dan respons 429 dengan backoff eksponen. Kegagalan pengesahan, parameter tidak sah dan konflik memerlukan pengendalian kegagalan kekal atau pengiraan baharu. Hadkan bilangan pekerja (workers), kuota setiap pemalam dan QPS API. Kira percubaan semula penjadualan Pod secara berasingan daripada percubaan semula tugas API, jika tidak, satu operasi perlahan boleh membesarkan baris gilir.
6. Keserasian, pelancaran dan pengunduran (rollback)
Kekalkan API pemalam dan semantik penjadualan sambil meletakkan laluan tak segerak di sebalik feature gate. Mulakan dengan pemalam berisiko rendah dan kluster keserentakan rendah. Bandingkan P99 penjadualan, masa menunggu baris gilir, kependaman API, kegagalan tugas, permintaan pendua dan percubaan semula yang tidak boleh dijadualkan. Jika tunggakan (backlog), ralat pengikatan, atau tekanan API melebihi garis dasar, hentikan penyerahan baharu, salirkan (drain) atau batalkan tugas, dan kembali ke laluan segerak.
Contoh jawapan berkualiti tinggi
Mula-mula kelaskan panggilan mana yang boleh ditangguhkan dan mana yang merupakan prasyarat pengikatan. Letakkan yang pertama dalam baris gilir keutamaan terikat dan wakilkan yang kedua sebagai keadaan pending yang jelas. Sertakan UID Pod, jenis operasi, kunci keidempotanan, batas masa dan konteks pembatalan; satukan kunci yang sama dan gunakan tekanan balik apabila penuh. Pekerja hanya melaksanakan operasi yang idempoten atau boleh dicuba semula dengan selamat, melakukan backoff pada ralat sementara dan menyerahkan ralat kekal kepada pengendalian kegagalan pemalam. Penyelesaian mencetuskan penilaian semula, bukannya pengikatan tanpa syarat. Lancarkan di sebalik feature gate dan ukur P99 penjadualan, kedalaman baris gilir, QPS API, kadar pendua, kadar kegagalan dan ketepatan pengikatan. Jika berlaku pelanggaran, hentikan penyerahan, bersihkan tugas dan undur semula.
Kesilapan lazim
- Menghantar setiap panggilan ke latar belakang → prasyarat pengikatan mungkin dipintas → lakarkan mesin keadaan penjadualan terlebih dahulu.
- Menggunakan satu FIFO global → Pod berkeutamaan tinggi menunggu di belakang kerja berkeutamaan rendah → tambahkan keutamaan, penuaan dan kuota.
- Menyahduplikasi mengikut teks permintaan → versi atau kesan sampingan mungkin digabungkan secara salah → gunakan kunci sumber dan keidempotanan eksplisit.
- Mencuba semula selama-lamanya → gangguan API menjadi ribut baris gilir → gunakan batas masa, backoff, had percubaan dan pemutus litar (circuit breaker).
- Hanya mengukur pemprosesan (throughput) → regresi kependaman dan ketepatan kekal tersembunyi → perhatikan baris gilir, API, percubaan semula dan pengikatan.
Soalan susulan dan jawapan
Bolehkah operasi baca dan tulis untuk Pod yang sama disatukan (coalesced)?
Bukan daripada UID Pod sahaja. Operasi baca boleh disatukan mengikut versi sumber; operasi tulis memerlukan jenis operasi, sasaran dan kunci keidempotanan, sambil mengekalkan susunan yang diperlukan.
Tugas yang manakah patut digugurkan apabila baris gilir penuh?
Gunakan batas masa, keutamaan dan kebolehan untuk dibina semula. Prasyarat pengikatan yang tidak boleh digugurkan harus menghasilkan tekanan balik. Mana-mana tugas yang digugurkan mesti membawa kepada keadaan percubaan semula atau kegagalan yang boleh dijelaskan, bukannya pemadaman senyap.
Bagaimana jika panggilan API berjaya selepas Pod diprapintas (preempted)?
Gunakan pembatalan dan semakan versi objek untuk menghalang konteks lama daripada terus menulis. Simpan kejayaan tersebut untuk tujuan audit, kemudian biarkan konteks penjadualan baharu mengira semula dan bukannya menggunakan semula niat pengikatan yang lapuk.