Gesaan dan konteks
Penemuduga memberikan anda pengendali permintaan yang menjalankan tiga operasi berkaitan secara selari: mengambil profil pengguna, mengambil pesanan, dan menjana syor. Klien terputus sambungan, tugas anak kritikal gagal, atau batas masa keseluruhan tamat. Sistem tidak boleh membiarkan kerja yatim (orphan work) terus berjalan selepas permintaan telah berakhir. Terangkan structured concurrency, kemudian petakannya kepada kumpulan tugas (task groups), skop korutin (coroutine scopes), atau skop tugas berstruktur tanpa menjadikan jawapan bergantung pada satu API tertentu.
Soalan ini sesuai untuk peranan backend peringkat pertengahan dan kanan, platform, mudah alih, dan infrastruktur rentas bahasa. Sasaran penilaian adalah penaakulan kitaran hayat: masuk, keluar, dasar kegagalan, dan pemilikan sumber.
Perkara yang diuji oleh penemuduga
Penemuduga ingin mengetahui sama ada anda menganggap kerja serentak sebagai sebahagian daripada tugas induk dan bukannya menyerahkan kerja kepada kolam global (global pool) lalu kembali (return). Jawapan yang mantap menyatakan bahawa anak tidak hidup lebih lama daripada skopnya, pembatalan induk disebarkan, kegagalan boleh bersifat gagal pantas (fail-fast) atau separa mengikut nilai perniagaan, serta percantuman (joining) dan pembersihan berlaku di dalam sempadan yang jelas.
Jawapan yang lemah hanya menyatakan "gunakan async/await secara selari." Jawapan yang mantap membezakan structured concurrency daripada future yang terasing (detached futures) dan menerangkan bila kerja mesti dialihkan ke barisan giliran tahan lasak (durable queue) yang berasingan dengan pemilik baharu.
Soalan untuk dijelaskan terlebih dahulu
- Adakah ketiga-tiga anak mesti berjaya, atau adakah profil dan pesanan wajib manakala syor adalah pilihan?
- Adakah batas masa itu merupakan batas masa permintaan yang ketat (hard deadline), atau bolehkah pelayan menyelesaikannya di bawah belanjawan lembut (soft budget) yang berasingan?
- Adakah anak hanya melakukan I/O yang boleh dibatalkan, atau bolehkah mereka mencetuskan kesan sampingan luaran yang tidak boleh diundur?
- Selepas klien terputus sambungan, bolehkah kerja dialihkan kepada pemberitahuan tak segerak atau kerja latar belakang?
- Patutkah kegagalan mengembalikan satu ralat, keputusan separa, atau respons yang diturunkan tarafnya secara eksplisit?
Jawapan-jawapan ini mengubah sempadan skop: kerja permintaan pendek kekal di dalam skop induk; kerja yang berterusan selepas permintaan memerlukan pemindahan pemilikan yang eksplisit.
Jawapan 30 saat
Saya menganggap permintaan sebagai tugas induk dan tiga operasi bacaan selari sebagai tugas anak. Induk hanya keluar selepas anak selesai, gagal, atau dibatalkan dan dibersihkan. Kegagalan profil atau pesanan membatalkan tugas selevel (siblings) dan mengembalikan ralat yang boleh dicuba semula; kegagalan syor mengembalikan respons penurunan taraf yang eksplisit. Klien terputus sambungan dan batas masa menyebarkan pembatalan ke bawah, dan setiap anak menutup sambungan serta pemegang dalam laluan pembersihannya. Jika kerja mesti diteruskan selepas permintaan, saya menulisnya ke barisan giliran tahan lasak dan memulakan kitaran hayat baharu dan bukannya membiarkan future latar belakang terasing. Saya mengesahkan pembatalan, tamat masa, kegagalan separa, dan metrik kebocoran dengan suntikan kegagalan (fault injection).
Jawapan langkah demi langkah
Langkah 1: Lukis pohon tugas (task tree)
Jadikan pengendali permintaan sebagai punca (root). Profil, pesanan, dan syor adalah anak langsung. Anak mewarisi batas masa induk, konteks pengesanan (tracing), dan isyarat pembatalan. Induk memiliki proses menunggu, komposisi ralat, dan penutupan skop; anak tidak boleh menyerahkan kerja kepada pelaksana global (global executor) dan membiarkan induk kembali tanpa pemindahan pemilikan.
Invarian utamanya boleh disemak: apabila induk keluar, setiap anak telah selesai, telah dibatalkan, atau telah dipindahkan secara eksplisit kepada pemilik lain yang direkodkan. Tanpa invarian tersebut, kebocoran benang, penulisan pendua, dan pendam hujung (tail latency) yang tidak dapat dijelaskan akan kekal tersembunyi.
Langkah 2: Pilih dasar kegagalan dan hasil separa
Kelaskan mengikut nilai perniagaan. Profil dan pesanan diperlukan untuk paparan daftar keluar, jadi kegagalan mana-mana satu membatalkan siblings dan mengembalikan ralat yang boleh dicuba semula. Syor adalah penambahbaikan, jadi kegagalan mengembalikan respons tanpa syor dan merekodkan penurunan taraf tersebut. Jangan biarkan kegagalan bernilai rendah menjatuhkan keseluruhan permintaan, dan jangan menyamarkan data kritikal yang hilang sebagai objek kosong.
Pseudokod boleh menyatakan dasar ini tanpa memilih bahasa pengaturcaraan tertentu:
within request_scope(deadline):
profile = child(fetch_profile)
orders = child(fetch_orders)
recommendations = child(fetch_recommendations)
wait(profile, orders)
if profile.failed or orders.failed:
cancel_all_children()
return retryable_error
return compose(profile, orders, recommendations.or_empty)Langkah 3: Pastikan pembatalan sampai ke sempadan sumber
Pembatalan bukan sekadar nilai boolean pada objek tugas. Klien rangkaian, pemacu pangkalan data, dan bacaan fail mesti mematuhi isyarat tersebut; proses menunggu mesti boleh diganggu; gelung cuba semula mesti menyemak semula batas masa sebelum percubaan lain. Bagi kesan sampingan yang tidak boleh diundur, seperti pembayaran yang telah diterima atau e-mel yang telah dihantar, pembatalan boleh menghentikan langkah seterusnya tetapi tidak boleh mendakwa bahawa kesan sampingan yang telah selesai itu telah diundur (rolled back).
Apabila klien terputus sambungan, titik masuk membatalkan punca. Punca menyebarkan pembatalan, dan anak menutup badan respons, sambungan, langganan, dan fail sementara dalam laluan pembersihan mereka. Pembersihan itu sendiri memerlukan had masa supaya "menunggu pembersihan" tidak menyekat penutupan permintaan selama-lamanya.
Langkah 4: Asingkan tamat masa, pembatalan, dan kegagalan
Tamat masa bermakna belanjawan masa telah habis. Pembatalan bermakna pihak huluan tidak lagi memerlukan hasilnya. Kegagalan bermakna tugas tidak dapat diselesaikan. Ketiga-tiganya boleh berlaku serentak, tetapi log dan keadaan pengguna tidak sepatutnya digabungkan menjadi satu ralat 500. Rekodkan punca asal, pencetus, dan laluan tugas. Biasanya jangan cuba semula apabila klien terputus sambungan; benarkan satu percubaan semula singkat selepas tamat masa kebergantungan hanya jika baki belanjawan mengizinkan; hantar ralat perniagaan melalui dasar penurunan taraf yang eksplisit.
Jangan meletakkan percubaan semula membuta tuli atau sleep di luar skop. Tindakan tersebut menggunakan belanjawan yang telah tamat tempoh dan terus menjana beban selepas induk telah kembali.
Langkah 5: Buktikan bahawa struktur dipelihara
Uji penyelesaian normal, kegagalan anak kritikal, kegagalan anak pilihan, pembatalan induk, batas masa tamat, dan pembatalan sebelum anak bermula. Setiap ujian menyemak bahawa anak yang aktif kembali kepada sifar, sambungan hiliran ditutup, jejak menunjukkan hubungan induk-anak, kesan sampingan tidak diduplikasi, dan pengelasan ralat sepadan dengan keadaan yang dapat dilihat oleh pengguna.
Jejak tugas aktif, pendaman penyebaran pembatalan, kadar tamat masa batas masa, pengecualian anak, tempoh pembersihan, tugas yang masih berjalan selepas pembatalan, dan sebaran keluar (fan-out) maksimum bagi setiap permintaan. Respons yang berjaya sahaja tidak membuktikan structured concurrency telah wujud.
Contoh jawapan berkualiti tinggi
"Saya akan menganggap satu permintaan sebagai tugas induk dan meletakkan ketiga-tiga bacaan dalam satu skop yang terikat dengan batas masa. Induk mencipta, menunggu, dan menutup anak-anaknya; tiada anak yang boleh hidup lebih lama daripada skop tersebut. Profil dan pesanan adalah kebergantungan kritikal, jadi kegagalan mana-mana satu akan membatalkan siblings dan mengembalikan ralat yang boleh dicuba semula. Syor adalah pilihan; jika gagal, saya mengembalikan keadaan syor kosong yang eksplisit dan merekodkan penurunan taraf.
Klien yang terputus sambungan, tamat masa induk, atau pembatalan huluan menyebar ke bawah pohon tugas. Setiap panggilan I/O menggunakan antara muka yang boleh dibatalkan, percubaan semula menyemak baki belanjawan, dan pembersihan menutup sambungan serta langganan. Saya tidak berpura-pura bahawa kesan sampingan luaran boleh diundur selepas ia berlaku. Jika kerja mesti diteruskan selepas permintaan, saya terlebih dahulu menulisnya ke barisan giliran tahan lasak dan membiarkan pengguna (consumer) mencipta pohon tugas baharu.
Saya akan menyuntik kegagalan kritikal, kegagalan pilihan, perlumbaan pembatalan (cancellation races), dan tamat masa pembersihan, kemudian memerhati tugas aktif, pendaman pembatalan, kebocoran sumber, dan jejak induk-anak. Bahagian yang penting ialah kitaran hayat dan pemilikan, bukan API Java, Kotlin, atau Swift yang khusus."
Mod kegagalan biasa
- Menyamakan structured concurrency dengan pelaksanaan selari → Anda hanya menerangkan memulakan tugas bersama dan mengabaikan jangka hayat → Tunjukkan sempadan skop, cantuman (join), pembatalan, dan pembersihan.
- Menyerahkan kepada pelaksana global dan kembali → Kerja boleh mengakses sumber permintaan selepas induk tiada → Kekalkannya dalam skop permintaan atau pindahkannya secara eksplisit ke barisan giliran tahan lasak.
- Menganggap pembatalan sebagai penamatan paksa (forced kill) → Kesan luaran mungkin telah selesai dan sumber mungkin tidak ditutup secara automatik → Nyatakan pembatalan secara kerjasama (cooperative cancellation), kerja yang tidak boleh diundur, dan pemilikan pembersihan.
- Mengembalikan hasil kosong untuk setiap kegagalan → Kehilangan data kritikal disembunyikan daripada pemanggil → Takrifkan peraturan gagal pantas dan hasil separa mengikut kekritisan perniagaan.
- Hanya menguji kejayaan → Perlumbaan pembatalan dan kerja yatim kekal tidak kelihatan → Suntik pemutusan sambungan, batas masa, kegagalan tugas selevel, dan pembatalan berulang, kemudian semak bahawa kerja aktif mencapai sifar.
Soalan susulan
Soalan susulan 1: Penjanaan syor mengambil masa beberapa saat, tetapi permintaan telah pun berakhir. Apakah yang anda lakukan?
Mula-mula tanya sama ada pengguna masih memerlukan hasilnya. Jika ia hanya untuk halaman semasa, batalkannya bersama-sama induk. Jika perniagaan mahukan penjanaan tak segerak, simpan input dan kunci kedap kuasa (idempotency key), kemudian biarkan consumer mencipta skop baharu. Consumer tersebut memiliki batas masa baharu, dasar percubaan semula, dan amaran; ia tidak boleh meminjam konteks permintaan yang telah selesai.
Soalan susulan 2: Mengapa tidak membiarkan anak-anak yang lain selesai selepas satu anak gagal?
Anda boleh berbuat demikian, jika baki kerja mempunyai nilai dan sesuai dengan belanjawan masa. Meneruskan carian pesanan selepas data profil kritikal gagal biasanya membazirkan sambungan dan kapasiti hiliran; menyelesaikan penyegaran cache atau rekod audit yang bebas mungkin munasabah. Nyatakan syarat untuk pembatalan dan bukannya menganggap gagal pantas sebagai sesuatu yang sejagat.
Soalan susulan 3: Isyarat pembatalan telah dihantar, tetapi pertanyaan pangkalan data masih berjalan. Bagaimana anda mengendalikannya?
Semak sama ada pemacu menyokong pembatalan dan mengembalikan sambungan. Jika tidak, gunakan tamat masa pertanyaan yang bebas, asingkan kolam sambungan, dan lindungi daripada menggunakan hasil yang lewat tiba. Ukur masa dari pembatalan sehingga pelepasan sumber; melebihi ambang batas harus mencetuskan penurunan taraf, pengasingan, atau amaran. Pertanyaan yang tidak boleh dibatalkan tidak boleh memegang kapasiti peringkat permintaan tanpa had.
Soalan susulan 4: Adakah structured concurrency menggantikan setiap kolam benang (thread pool) dan barisan giliran mesej?
Tidak. Ia sesuai untuk kerja jangka pendek dengan hubungan induk-anak yang jelas serta pembatalan dan pembersihan yang dikongsi. Kerja rentas permintaan, kerja berjadual, dan percubaan semula tahan lasak masih memerlukan barisan giliran atau aliran kerja (workflow). Kolam yang dikongsi boleh menyediakan sumber pelaksanaan, tetapi skop yang menyerahkan tugas mesti mentakrifkan siapa yang menunggu, siapa yang membatalkan, dan siapa yang memiliki hasilnya.