Gesaan dan konteks
Soalan ini menguji API backend, storan objek dan kawalan keserentakan. Permintaan bersyarat AWS menambah prasyarat pada PutObject, CompleteMultipartUpload dan CopyObject: penciptaan boleh menetapkan syarat bahawa kunci tidak wujud, manakala kemas kini boleh menetapkan syarat bahawa ETag tidak berubah. Isu terasnya adalah memastikan storan menilai semakan tersebut bersama-sama dengan penulisan, dan bukannya membiarkan klien melakukan HEAD yang terdedah kepada keadaan perlumbaan (race condition) diikuti oleh PUT.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh memisahkan penciptaan daripada kemas kini, memilih If-None-Match: * atau If-Match dengan etag-value semasa, dan memetakan syarat yang gagal kepada tingkah laku percubaan semula atau penggabungan (merge). Ia juga merangkumi penyempurnaan multipart, ETag lemah, hasil rangkaian yang tidak menentu dan isyarat audit. Mengatakan "tambah kunci (lock)" tidak menerangkan pelbagai proses atau pemulihan kegagalan.
Soalan penjelasan untuk ditanya terlebih dahulu
Semantik penulisan
Adakah ini objek tak boleh ubah (immutable) yang ditulis sekali sahaja, atau kemas kini berdasarkan versi yang telah dibaca? Yang pertama menggunakan prasyarat kewujudan; yang kedua memerlukan ETag versi.
Dasar konflik
Patutkah konflik mengembalikan 412 supaya klien membaca semula dan menggabungkan, atau patutkah percubaan itu dibatalkan? Manifas atau registri biasanya tidak boleh ditulis ganti secara senyap.
Laluan muat naik
Adakah objek kecil akan menggunakan PutObject dan objek besar menggunakan multipart? Letakkan syarat pada permintaan penyempurnaan akhir dan tentukan tingkah laku gangguan, percubaan semula dan pembersihan.
Rangka kerja jawapan 30 saat
"Mula-mula saya menentukan sama ada ini penciptaan atau kemas kini berversi. Penciptaan menggunakan If-None-Match: *, jadi S3 menolak kunci sedia ada secara atomik. Kemas kini membaca ETag semasa dan menghantar If-Match; jika ETag berubah, S3 mengembalikan 412 dan klien membaca semula atau menggabungkan. Muat naik multipart menggunakan syarat pada CompleteMultipartUpload. Tamat masa (timeout) bukan bukti kegagalan, jadi saya menanyakan objek atau menggunakan rekod keidempotensian sebelum mencuba semula, serta memantau 412, bahagian terbiar (orphaned parts) dan bilangan percubaan semula."
Jawapan mendalam langkah demi langkah
Langkah 1: Hapuskan semak-kemudian-laksana (check-then-act)
HEAD yang diikuti oleh PUT menimbulkan perlumbaan: dua klien boleh sama-sama melihat ketiadaan objek dan kemudian menulis. Letakkan prasyarat dalam permintaan penulisan supaya perkhidmatan storan menilainya terhadap keadaan objek semasa.
Langkah 2: Pilih syarat
Gunakan If-None-Match: * untuk penciptaan tak boleh ubah; ia berjaya hanya apabila tiada perwakilan semasa wujud. Gunakan If-Match yang kukuh untuk objek sedia ada, membenarkan penulisan hanya apabila ETag sama dengan versi yang dibaca. Ketidakpadanan mengembalikan 412 dan melindungi kandungan yang lebih baharu.
Langkah 3: Tentukan protokol konflik
Jangan cuba semula 412 secara membuta tuli. Lakukan GET pada objek semasa dan tentukan sama ada perubahan klien boleh digabungkan; jika tidak, cipta rekod konflik atau kunci baharu. Tambahkan penundaan eksponen (backoff) dan had percubaan semula supaya kunci hangat (hot key) tidak mencetuskan ribut percubaan semula (retry storm).
Langkah 4: Rangkumi multipart dan salinan
Klien lain boleh mencipta kunci yang sama semasa bahagian sedang dimuat naik, jadi CompleteMultipartUpload akhir juga memerlukan syarat tersebut. Aliran kerja salin atau ganti harus membawa syarat ETag, manakala peraturan kitaran hayat membersihkan muat naik multipart yang terbengkalai.
Langkah 5: Kendalikan tamat masa dan perhatikan
Tamat masa tidak mendedahkan sama ada penulisan telah dilakukan (committed). Tanya objek dan ETag sebelum mencuba semula, dan rekod ID arahan klien untuk niat penciptaan. Pantau kadar 412, kadar percubaan semula yang berjaya, bahagian terbiar dan anjakan versi untuk mengesahkan bahawa konflik ditolak dan bukannya ditulis ganti.
Contoh jawapan berkualiti tinggi
Saya akan mengasingkan fail data tak boleh ubah daripada registri yang boleh dikemas kini. Penciptaan fail data menggunakan If-None-Match: *, jadi hanya satu penulis kunci yang sama berjaya. Registri dibaca dengan ETag dan dikemas kini dengan If-Match; 412 mencetuskan bacaan semula dan penggabungan dan bukannya menulis ganti versi lain. Muat naik yang besar menggunakan syarat pada CompleteMultipartUpload, dan tugas pembersihan menuntut semula muat naik yang gagal. Selepas tamat masa rangkaian, saya menanyakan objek dan ETag sebelum mencuba semula. S3 menyediakan semakan konflik atomik; klien memiliki dasar penggabungan dan rekod keidempotensian. Saya akan mengesahkannya dengan metrik 412, percubaan semula dan bahagian terbiar.
Kesilapan lazim
- Kesilapan: HEAD untuk menyemak ketiadaan, kemudian PUT. → Sebab ia gagal: Dua klien boleh melepasi semakan secara serentak. → Pembetulan: Gunakan
If-None-Match: *pada PUT. - Kesilapan: Gunakan
If-None-Matchuntuk kemas kini. → Sebab ia gagal: Ia bermaksud "mesti tidak wujud", bukan "mesti sama dengan versi yang saya baca." → Pembetulan: Baca ETag yang kukuh dan gunakanIf-Match. - Kesilapan: Cuba semula permintaan asal tanpa syarat selepas 412. → Sebab ia gagal: Ia boleh menulis ganti berulang kali atau mencipta ribut percubaan semula. → Pembetulan: Baca semula, gabungkan atau batalkan dengan backoff yang terhad.
- Kesilapan: Gunakan syarat hanya pada permintaan multipart yang pertama. → Sebab ia gagal: Keadaan objek boleh berubah sebelum penyempurnaan. → Pembetulan: Gunakannya sekali lagi pada
CompleteMultipartUpload.
Tindakan susulan dan respons
Tindakan susulan 1: Bolehkah ETag dianggap sebagai cincangan kandungan (content hash)?
Tidak secara sejagat. Keperluannya ialah pengesah versi; senario multipart dan penyulitan boleh mengubah semantik ETag, jadi gunakan checksum atau pengesah yang didokumenkan oleh perkhidmatan untuk operasi tersebut.
Tindakan susulan 2: Apakah perbezaan antara 412 dan 409?
Ikuti kontrak API: 412 bermaksud prasyarat permintaan gagal dan biasanya meminta klien membaca semula; status konflik lain mungkin menerangkan keadaan sumber atau operasi. Jangan membuat kesimpulan semantik daripada nombor sahaja.
Tindakan susulan 3: Bagaimana jika klien tidak boleh menggabungkan?
Kekalkan versi semasa dan cipta rekod konflik atau kunci baharu untuk diselesaikan oleh pemilik domain. Penulisan ganti secara senyap bukan kriteria kejayaan.
Tindakan susulan 4: Bagaimanakah anda menguji ketepatan keserentakan?
Jalankan penciptaan dan kemas kini serentak pada satu kunci, suntikkan tamat masa, penyempurnaan multipart pendua dan kegagalan pembersihan, kemudian sahkan bahawa paling banyak satu penciptaan berjaya, kandungan lama tidak pernah menulis ganti kandungan yang lebih baharu dan rekod audit sepadan dengan hasilnya.