Gesaan dan konteks
Apabila Tokio select! menunggu tamat masa (timeout), token pembatalan, dan I/O, bagaimanakah anda menentukan sama ada sesuatu future itu selamat daripada pembatalan (cancellation-safe)? Bagaimanakah anda memulihkannya jika operasi yang selesai sebahagian dibatalkan?
Ini sesuai untuk peranan Rust, bahagian belakang (backend), infrastruktur, dan perkhidmatan tak segerak. Tokio menerangkan pembatalan sebagai pengguguran (drop) future; cabang select! yang menang diteruskan manakala cabang lain mungkin digugurkan pada mana-mana .await. Perbezaan utamanya ialah menghentikan penantian berbanding membatalkan kesan sampingan luaran, dengan mesin keadaan (state machine) yang boleh dimulakan semula secara selamat.
Perkara yang diuji oleh penemu duga
- Memahami bahawa pengguguran future tidak mengembalikan (roll back) I/O asas atau kesan sampingan jauh (remote).
- Mengenal pasti kemajuan separa dalam penimbal baca, baris gilir (queues), kunci (locks), dan bingkai protokol.
- Menggunakan pemilikan (ownership), mesin keadaan, dan kunci keidempotenan untuk mengelakkan kehilangan atau penyerahan pendua selepas mula semula.
- Mengetahui primitif Tokio yang mendokumentasikan keselamatan pembatalan dan yang memerlukan pembungkus (wrapper).
- Membezakan abort, tamat masa, penutupan anggun (graceful shutdown), dan pembatalan luaran.
- Mengesahkan laluan pembatalan dengan ujian model, suntikan kegagalan (fault injection), dan metrik.
Kerangka jawapan 30 saat
“Saya mentakrifkan sempadan pembatalan terlebih dahulu: menggugurkan future menghentikan pengundian (polling) tugas tersebut tetapi tidak menjamin bahawa operasi jauh telah dibatalkan. Sesuatu future adalah selamat daripada pembatalan hanya jika menggugurkannya selepas mana-mana await dan memanggilnya semula boleh menyambung atau mencuba semula dengan betul. Saya menyimpan bait yang digunakan, ID permintaan, penimbal, dan kunci keidempotenan dalam mesin keadaan yang dimiliki (owned); kesan yang tidak boleh dipulihkan disimpan secara kekal atau ditunggu pengesahannya. Ujian menyuntik pembatalan pada setiap titik await.”
Pecahan mendalam langkah demi langkah
Langkah 1: Tandakan titik pembatalan
Semak setiap .await dalam fungsi async. Adakah ia telah mengubah keadaan tempatan atau jauh, dan medan manakah yang boleh dipulihkan jika future digugurkan di situ? Anggap bacaan dan tulisan rangkaian, penantian kunci, penerimaan saluran, dan sleep sebagai titik pembatalan dan bukannya hanya menguji titik masuk dan keluar.
Langkah 2: Asingkan pembatalan daripada pembatalan tindakan (undo)
Membatalkan cabang select! biasanya menggugurkan future miliknya; permintaan yang telah dihantar ke perkhidmatan jauh mungkin diteruskan. Pengendali tamat masa merekodkan ID permintaan dan keadaan hasil-tidak-diketahui berbanding menandakan kegagalan dan menghantar semula operasi bukan idempoten secara membuta tuli. Jika pembatalan tindakan disokong, panggil operasi pembatalan protokol dan tunggu pengesahannya.
Langkah 3: Reka bentuk mesin keadaan yang boleh dipulihkan
Wakilkan keadaan persediaan, penghantaran, menunggu pengesahan, dikomit, dan pampasan. Pemilik eksplisit menyimpan keadaan dan penimbal; permulaan semula memilih sama ada untuk terus membaca, menghantar semula, menyoal hasil, atau memberi pampasan. Untuk protokol penstriman, rekodkan sempadan bingkai dan ofset yang disahkan supaya mesej separa tidak ditafsirkan semula dari bahagian tengah.
Langkah 4: Kekalkan ketekalan baris gilir dan kunci
Membatalkan selepas menerima item saluran atau strim tetapi sebelum pemprosesan tahan lasak (durable) menghasilkan item yang telah digunakan tetapi tidak diselesaikan. Gunakan pengakuan transaksi (transactional acknowledgement), bacaan boleh ulang (repeatable reads), atau pajakan tahan lasak. Jangan mengeluarkan (pop) satu-satunya salinan ke dalam pembolehubah sementara di dalam cabang select!. Pengawal kunci (lock guard) melepaskan keadaan kongsi semasa digugurkan, manakala pemulihan merekodkan sama ada operasi yang dilindungi telah dikomit.
Langkah 5: Urus sumber dan penamatan tugas
JoinHandle::abort menghentikan tugas tetapi tidak menggantikan pembersihan perniagaan. Gunakan pengawal RAII untuk soket, fail, fail sementara, dan permit semafor. Kerja yang mesti diteruskan diletakkan dalam tugas berasingan dengan pemegang yang dikekalkan. Penutupan anggun berhenti menerima kerja baharu, menunggu operasi yang boleh diselesaikan, kemudian memberi isyarat dan merekodkan pembatalan untuk bakinya.
Langkah 6: Sahkan keselamatan pembatalan
Suntik pembatalan sebelum dan selepas setiap await, periksa permulaan semula, pertindihan, kehilangan, dan kebocoran sumber. I/O palsu terkawal, model mesin keadaan, dan ujian konkurensi merangkumi tamat masa, penutupan saluran, pemutusan rakan sambungan (peer), dan pengguguran tugas. Jejaki permintaan dalam penerbangan (in-flight), padanan kunci pendua, kiraan pampasan, kependaman pembatalan, dan permit yang bocor; tanpa metrik ini “dibatalkan” hanyalah satu andaian.
Pertukaran (trade-offs), sempadan, dan perolehan maklumat
Keselamatan pembatalan bermaksud keadaan perniagaan kekal boleh dijelaskan apabila aliran kawalan async terganggu. Future kecil tanpa kesan luaran mudah untuk dimulakan semula; operasi rangkaian, pangkalan data, dan baris gilir memerlukan keidempotenan, pengesahan, dan pampasan. Menjadikan setiap tugas tidak boleh dibatalkan menyembunyikan pepijat sumber dan meningkatkan kependaman penutupan, jadi lindungi hanya sempadan atomik yang jelas.
Contoh jawapan berkualiti tinggi
“Saya menganggap setiap .await sebagai titik pembatalan dan bertanya apakah kesan sampingan yang berlaku sebelumnya dan bagaimana pengguguran dipulihkan. Tokio select! menggugurkan future yang tewas; ia tidak membatalkan permintaan yang telah dihantar. Oleh itu, tamat masa mengekalkan ID permintaan dan mencuba semula hanya dengan kunci keidempotenan atau selepas menyoal hasilnya. Mesin keadaan operasi membezakan persediaan, penghantaran, menunggu pengesahan, dikomit, dan pampasan.
Penerimaan saluran, penulisan fail, dan komit pangkalan data memerlukan pengakuan transaksi atau bacaan boleh ulang supaya item yang digunakan tidak hilang. Pengawal RAII melepaskan sumber, dan kerja yang mesti diselesaikan berada dalam tugas berasingan dengan pemegang yang diperhatikan. Penutupan anggun menghentikan pengambilan sebelum membatalkan dan menunggu.
Saya menyuntik pembatalan pada setiap await, menguji permulaan semula, pertindihan, kehilangan, dan kebocoran, serta memantau kerja dalam penerbangan, kunci pendua, pampasan, kependaman pembatalan, dan permit. Itu menunjukkan keselamatan pembatalan dan bukannya sekadar menunjukkan bahawa tugas telah berhenti.”
Kesilapan lazim
- Menganggap pengguguran (drop) sebagai pembatalan jauh → permintaan mungkin sudah berjalan → kekalkan ID-nya, soal hasilnya, atau gunakan API pembatalan eksplisit.
- Mempertimbangkan pembatalan selepas menggunakan mesej → satu-satunya salinan boleh hilang → gunakan pengakuan (acknowledgement), pajakan, atau bacaan boleh ulang.
- Menghantar semula secara membuta tuli selepas tamat masa → operasi tulis boleh mempunyai kesan pendua → gunakan kunci keidempotenan atau soal keadaan terlebih dahulu.
- Hanya menguji titik masuk fungsi → keadaan perlumbaan berlaku di antara await → suntik pembatalan pada setiap await.
- Menggunakan abort dan bukannya pembersihan → fail, kunci, dan permit mungkin bocor → gunakan pengawal dan protokol penutupan.
- Menjadikan setiap tugas tidak boleh dibatalkan → penutupan anggun boleh menunggu selama-lamanya → lindungi hanya sempadan atomik yang sebenar.
Soalan dan jawapan susulan
Bagaimanakah anda mengetahui sama ada primitif Tokio adalah selamat daripada pembatalan?
Semak dokumentasinya untuk jaminan eksplisit bahawa pembatalan di dalam select! dan memanggilnya semula tidak akan kehilangan data. Tanpa jaminan itu, anggap bahawa kemajuan separa boleh hilang, simpan keadaan, dan tulis ujian pemulihan.
Bagaimanakah anda mengetahui sama ada penulisan pangkalan data telah selesai selepas tamat masa?
Gunakan ID permintaan klien dan kekangan unik untuk menyoal hasil, atau dedahkan status operasi yang boleh disoal. Tamat masa klien sahaja bukan kebenaran untuk mengulangi penulisan bukan idempoten.
Bolehkah anda memadamkan sumber serta-merta selepas JoinHandle::abort?
Hanya selepas tugas telah berhenti dan pengguguran sumbernya telah selesai. Tunggu hasil join atau biarkan pengawal pemilik melaksanakan pembersihan; mengeluarkan abort bukanlah penyelesaian segerak.
Bilakah kerja patut dipindahkan ke tugas berasingan?
Pindahkan kerja yang mesti diselesaikan, memerlukan percubaan semula merentas permintaan, atau tidak boleh dikembalikan (roll back) pada sempadan pembatalan semasa ke baris gilir tahan lasak atau tugas bebas. Perhatikan tugas tersebut dengan pemegang, stor keadaan, dan kunci keidempotenan; jangan gunakan detached task untuk mengelak daripada semua semantik pembatalan.