Prompt dan skop
Soalan ini menguji sama ada jurutera backend boleh memberikan semantik pelaksanaan dan hasil yang tepat untuk "kelompok" (batch). Andaikan pelanggan ingin mengemas kini label pesanan atau tetapan pengguna secara pukal; item mungkin bebas atau berkongsi kuota, versi, atau kebergantungan, dan tamat masa rangkaian boleh berlaku selepas pelayan menyelesaikan beberapa item. Anda mesti mentakrifkan sempadan segerak (synchronous) dan tak segerak (asynchronous) supaya klien boleh meneruskan dengan selamat.
Ia sesuai untuk jurutera backend, pereka bentuk API, dan jurutera platform. Berikan tumpuan kepada keatomikan (atomicity), keadaan bagi setiap item, identiti permintaan, percubaan semula idempoten, kebenaran dan had sumber, keserasian respons, serta pemulihan berbanding pilihan REST, gRPC, atau barisan gilir tertentu. Nyatakan tingkah laku lalai, cara kejayaan separa dipilih secara eksplisit, dan perbezaan antara kegagalan penuh, kegagalan separa, dan hasil yang tidak diketahui.
Perkara yang dinilai oleh penemu duga
Jawapan yang kukuh bertanyakan sama ada item bergantung antara satu sama lain sebelum memilih pemprosesan atomik, kejayaan separa pilih masuk (opt-in), atau operasi tak segerak. Ia tidak hanya mengembalikan HTTP 200 dan bilangan kegagalan; ia memetakan setiap input kepada hasil yang stabil, kelas ralat, dan kebolehcubaan semula. Google AIP-234 menyatakan bahawa menukar kaedah kelompok segerak sedia ada kepada kejayaan separa boleh memecahkan klien dan mengesyorkan keadaan kegagalan terperinci bagi setiap indeks; panduan keidempotenan Stripe mengikat percubaan semula kepada parameter yang sama dan mengekalkan hasil pertama. Sertakan had, audit, dan pemantauan juga.
Soalan penjelasan untuk ditanya
- Adakah terdapat kebergantungan susunan atau transaksi antara item? Adakah perniagaan mesti bersifat semua-atau-tiada (all-or-nothing)?
- Adakah pemprosesan mencipta kesan sampingan luaran, dan bolehkah kunci keidempotenan menjadikan main semula selamat?
- Adakah klien memerlukan hasil segerak, atau bolehkah ia menerima operasi dan melakukan tinjauan (poll) atau melanggan kemajuan?
- Apakah had kelompok, saiz badan, tamat masa, kuota penyewa, dan keperluan keadilan (fairness)?
- Ralat manakah yang boleh dicuba semula, yang mana memerlukan perubahan input, dan bagaimanakah hasil yang tidak diketahui boleh ditanya?
Kerangka jawapan 30 saat
"Saya akan memisahkan kelompok atomik daripada kelompok kejayaan separa dan mengutamakan tingkah laku yang lebih selamat secara lalai; kejayaan separa hanya didayakan apabila klien memilih masuk dan perniagaan membenarkannya. Setiap input mendapat indeks atau ID permintaan klien yang stabil, manakala pelayan merekodkan keadaan keidempotenan, hasil, dan kelas ralat pada peringkat kelompok serta peringkat item. Kerja segerak dihadkan; kerja yang lebih besar mencipta operasi yang berjalan dalam syard (shards) dan mendedahkan kemajuan. Respons membezakan antara kejayaan, kegagalan kekal, kegagalan sementara, dan keadaan tidak diketahui, dan percubaan semula menggunakan semula kunci item yang sama. Saya akan mengesahkan reka bentuk dengan had kadar, rekod audit, metrik, dan suntikan kerosakan (fault injection) untuk membuktikan bahawa kesan sampingan tidak diduplikasi atau hilang."
Jawapan langkah demi langkah
Langkah 1: Pilih model keatomikan
Jika item berkongsi invarian perniagaan yang tidak boleh dibahagikan, seperti kedua-dua belah pemindahan perlu berjaya bersama-sama, gunakan transaksi kelompok atomik atau tolak antara muka kelompok tersebut. Jika item adalah bebas, pertimbangkan kejayaan separa. Jangan sembunyikan model di sebalik "usaha terbaik" (best effort); klien mesti tahu sama ada semua berjaya, semua gagal, sebahagian selesai, atau pelayan tidak dapat mengesahkan hasilnya.
Langkah 2: Takrifkan identiti permintaan dan item
Sertakan ID kelompok, tatasusunan item, dan ID permintaan item yang dijana oleh klien. ID item adalah stabil dalam skop perniagaannya. Penyerahan pendua dengan ID yang sama mesti membandingkan parameter penting; parameter yang berbeza harus menghasilkan konflik dan bukannya penggantian senyap. ID kelompok menyokong penjejakan tetapi tidak boleh menggantikan keidempotenan item kerana percubaan semula separa mungkin hanya mengandungi item yang gagal daripada kelompok asal.
Langkah 3: Tetapkan sempadan segerak/tak segerak
Kelompok kecil boleh mengembalikan hasil akhir bagi setiap item secara segerak, dengan belanjawan masa dan sumber keseluruhan. Kelompok besar atau operasi yang memanggil sistem luaran harus mengembalikan ID operasi, dilaksanakan dalam syard terhad, dan mengekalkan kemajuan. Klien menanyakan bilangan yang selesai, sedang diproses, boleh dicuba semula, dan kegagalan kekal; selepas terputus sambungan, ia membuat pertanyaan dan bukannya memulakan kesan sampingan semula.
Langkah 4: Reka bentuk respons yang boleh dihuraikan
Respons mesti membolehkan klien mencari hasil mengikut identiti input, walaupun pelayan menyusun semula kerja. Gunakan indeks dan ID klien yang stabil; sertakan kod ralat yang boleh dibaca mesin, kebolehcubaan semula, kemungkinan perubahan keadaan semasa percubaan semula, dan mesej pengguna yang selamat. Sebagai contoh:
{
"batch_id": "b_123",
"status": "PARTIAL",
"results": [
{"index": 0, "request_id": "r_0", "status": "SUCCEEDED"},
{"index": 1, "request_id": "r_1", "status": "FAILED", "error": {"code": "VERSION_CONFLICT", "retryable": false}}
],
"next_page_token": null
}Google AIP-234 mengesyorkan peta failed_requests daripada indeks input kepada status terperinci untuk kemas kini kelompok tak segerak. Ia mengelakkan klien daripada terpaksa mengekalkan peta ID-permintaan-ke-permintaan dan mengelakkan gema badan permintaan yang sensitif. Jika API segerak sedia ada memerlukan semantik kejayaan separa, terbitkan versi baharu atau rundingkan dengan medan eksplisit supaya klien lama tidak mentafsirkan status kejayaan sebagai penyiapan setiap item.
Langkah 5: Kendalikan keidempotenan, percubaan semula, dan hasil yang tidak diketahui
Pelayan boleh menolak parameter yang tidak sah sebelum kesan sampingan bermula tanpa menyimpan hasil idempoten. Sebaik sahaja pelaksanaan bermula, simpan hasil atau keadaan sedang berjalan yang boleh ditanya. Selepas tamat masa rangkaian, klien tidak boleh meneka dan mengulangi keseluruhan kelompok; ia menggunakan semula kunci kelompok dan item, menanyakan item yang tidak diketahui, dan mencuba semula hanya item yang jelas boleh dicuba semula. Gunakan backoff dan jitter untuk ralat sementara, perlukan perubahan input untuk ralat kekal, dan kembalikan konflik apabila kunci yang digunakan semula membawa parameter berbeza.
Langkah 6: Asingkan sumber dan susunan
Bahagikan kerja kepada syard yang terhad dan hadkan konkurensi bagi setiap penyewa, kelompok, dan kebergantungan. Laksanakan item bersandar mengikut topologi atau fasa eksplisit; jalankan item bebas secara selari dengan belanjawan percubaan semula yang dikongsi untuk mengelakkan ribut kegagalan (failure storm). Periksa kebenaran dan kuota sebelum setiap item, supaya titik akhir kelompok tidak dapat memintas dasar API item tunggal.
Langkah 7: Takrifkan semantik ralat, pembatalan, dan pemulihan
Kelaskan ralat pengesahan input, kebenaran, konflik versi, kuota, kebergantungan sementara, dan hasil tidak diketahui. Pembatalan menghentikan item yang belum dimulakan; kesan sampingan yang telah selesai tidak boleh berpura-pura diundur balik (rolled back). Jika perniagaan memerlukan pembalikan, sediakan operasi pampasan yang berasingan. Kekalkan tugasan latar belakang, hasil, dan permintaan asal supaya permulaan semula menyambung daripada keadaan item dan bukannya melaksanakan setiap item sekali lagi.
Langkah 8: Sahkan ketekalan dan keterlihatan operasi
Uji semua-kejayaan, semua-kegagalan, hasil bercampur, permintaan pendua, konflik parameter, tamat-masa-kemudian-tanya, kebergantungan flapping, perlumbaan pembatalan (cancellation races), dan permulaan semula pekerja. Pantau kejayaan kelompok, kelas ralat bagi setiap item, keadaan tidak diketahui, penguatan percubaan semula, usia barisan gilir, kependaman pemprosesan, penolakan kuota, dan penyerahan pendua. Audit kelompok, item, pelaku, keputusan kebenaran, dan hasil akhir supaya kakitangan sokongan boleh menerangkan dengan tepat item mana yang telah selesai.
Kompromi dan sempadan reka bentuk
Kejayaan separa bukanlah pilihan yang lebih maju secara automatik. Ia sesuai untuk item bebas yang pelanggan boleh baiki satu demi satu; baki, inventori, dan invarian rentas sumber adalah lebih selamat dengan keatomikan atau aliran kerja eksplisit. HTTP 207 Multi-Status boleh membawa beberapa status sumber, tetapi RFC 4918 mentakrifkannya untuk WebDAV. API JSON umum tidak seharusnya menganggap klien memahami hasil separa semata-mata kerana ia mengembalikan 207. Letakkan semantik item dalam badan respons yang stabil dan pilih kod status dengan mengambil kira keserasian klien sedia ada.
Bilakah anda patut memilih kelompok atomik?
Pilih keatomikan apabila sebarang kegagalan item menjadikan keadaan agregat tidak sah atau pampasan tidak dapat diterima. Gunakan transaksi, pra-pemeriksaan (preflight), atau aliran kerja, sambil mengakui bahawa kerja yang disyardkan dan kesan sampingan luaran tidak berkongsi transaksi pangkalan data; ia mungkin memerlukan fasa simpanan (reserve), komit, dan pampasan.
Bilakah anda patut memilih operasi tak segerak?
Kembalikan operasi apabila tempoh masa tidak dapat diramalkan, kelompok bersaiz besar, panggilan luaran terlibat, atau klien tidak sepatutnya membiarkan sambungan terbuka. Keadaannya mesti boleh ditanya semula, dan hasilnya harus dipaginasikan. Kemajuan tidak boleh memanggil "diterima" sebagai "selesai."
Latih tubi kegagalan dan pelan evolusi
Lakukan perintis dengan set penyewa terhad, rekodkan keadaan item dan tingkah laku percubaan semula, kemudian tingkatkan had kelompok secara beransur-ansur. Suntik pemutusan rangkaian selepas item 30 berjaya, kebergantungan yang mengembalikan 503 secara berterusan, kunci yang sama dengan parameter berbeza, dan permulaan semula pekerja operasi. Kembangkan kuota atau dayakan kejayaan separa hanya selepas klien boleh menanyakan hasil yang tidak diketahui dan pelayan membuktikan ia tidak menduplikasi kesan sampingan.
Bagaimanakah anda mengembangkan API segerak kepada kejayaan separa?
Kekalkan semantik atomik versi lama dan tambah versi yang mengembalikan operasi serta kegagalan bagi setiap item. Sebagai alternatif, perlukan medan return_partial_success eksplisit dan kekalkan tingkah laku lama apabila ia tiada. Dokumentasikan kod status, medan respons, peraturan percubaan semula, dan tarikh penamatan penggunaan supaya klien tidak mengubah tafsiran mereka secara senyap.
Bagaimanakah anda menilai ketepatan klien?
Perhatikan sama ada klien mengekalkan ID item, mencuba semula hanya kegagalan yang boleh dicuba semula, menanyakan hasil yang tidak diketahui, dan mengelakkan kesan sampingan pendua serta percubaan semula yang tidak sah. Sediakan pembantu penghuraian dan pertanyaan dalam SDK penting, sementara pelayan masih bertolak ansur dengan medan yang tidak diketahui dan permintaan pendua.
Kesilapan lazim dan susulan
Mengembalikan HTTP 200 dengan bilangan kegagalan
Klien lama mungkin menganggap penyiapan separa sebagai selesai sepenuhnya, dan ia masih tidak dapat mengetahui item mana yang perlu dicuba semula. Respons memerlukan keadaan keseluruhan, identiti item, kelas ralat, dan tindakan seterusnya.
Mencuba semula keseluruhan kelompok pada sebarang kegagalan
Tindakan itu boleh mengulangi kesan sampingan yang telah pun berjaya. Tanya keadaan keidempotenan kelompok dan item terlebih dahulu, cuba semula hanya kegagalan sementara yang eksplisit, dan gunakan ID permintaan perniagaan baharu apabila parameter berubah.
Bagaimanakah hasil harus disusun?
Kaitkan hasil mengikut indeks input atau ID permintaan yang stabil, bukan susunan penyiapan. Kekalkan identiti apabila hasil dipaginasikan supaya klien boleh menggabungkan halaman dengan selamat.
Bolehkah anda mengundur balik (rollback) selepas satu item berjaya dan kelompok dibatalkan?
Pembatalan hanya mempengaruhi item yang belum dimulakan. Kesan sampingan luaran yang telah dilakukan memerlukan API pampasan atau pengendalian manual; "kelompok dibatalkan" bukanlah jaminan undur balik.
Bagaimanakah anda menghalang titik akhir kelompok daripada memintas kebenaran?
Semak kebenaran penyewa dan operasi pada peringkat kelompok, kemudian semak semula pemilikan sumber, versi, dan kebenaran medan sebelum setiap item. Pengelompokan mengubah penjadualan, bukan skop kebenaran.
Bagaimanakah anda menerangkan kegagalan separa akhir?
Sediakan ID kelompok yang boleh diaudit, ID item, status, kod ralat, kebolehcubaan semula, dan cap masa. Berikan sokongan penjelasan perniagaan yang selamat dan simpan ralat surih serta kebergantungan untuk diagnosis kejuruteraan.