Gesaan dan senario
Satu SaaS global membolehkan pengguna mengedit profil di mana-mana rantau. Semasa pemisahan rangkaian (network partition), kedua-dua Eropah dan Amerika Syarikat menerima kemas kini untuk pengguna yang sama; selepas pemulihan, nama, avatar, zon masa dan tetapan privasi mengalami konflik. Reka bentuk penulisan, replikasi, pengesanan konflik, penggabungan, audit dan pemulihan pengguna, serta terangkan pertukaran (trade-off) antara ketersediaan dan ketekalan.
Perkara yang diuji oleh penemu duga
- Sama ada anda mengklasifikasikan ketekalan mengikut semantik medan dan bukannya menggunakan satu peraturan konflik untuk keseluruhan rekod.
- Sama ada anda mereka bentuk penghalaan serantau, metadata versi, kelewatan replikasi dan percubaan semula idempoten.
- Sama ada anda mengendalikan medan privasi dan keselamatan yang tidak boleh digabungkan secara automatik serta memberikan hasil yang boleh dijelaskan.
- Sama ada anda membuat pertukaran yang jelas antara pemulihan, kos, kependaman dan risiko kehilangan data.
Soalan penjelasan untuk ditanya terlebih dahulu
- Medan manakah yang boleh digabungkan secara bebas, dan manakah yang melibatkan privasi, identiti atau keselamatan serta memerlukan penyirikan (serialization) atau pengesahan manusia?
- Adakah sasarannya ketekalan kukuh, sesi, atau ketekalan akhirnya (eventual consistency), dan berapa banyak kelewatan replikasi yang boleh diterima pengguna?
- Bolehkah seorang pengguna menulis secara aktif di pelbagai rantau, atau bolehkah rantau asal (home region) ditetapkan bagi setiap pengguna atau penyewa (tenant)?
- Berapa lamakah kedua-dua versi mesti kekal tersedia, dan apakah yang mesti dilihat oleh pengguna, sokongan dan juruaudit?
Jawapan 30 saat
Saya akan mengklasifikasikan ketekalan mengikut medan: avatar dan biografi boleh menggunakan penggabungan peringkat medan, manakala tetapan privasi dan keselamatan memerlukan pemeriksaan versi yang lebih ketat. Setiap penulisan membawa versi pengguna, rantau, ID operasi dan medan yang diubah, manakala replikasi menggunakan peristiwa idempoten. Saya akan menetapkan rantau asal secara lalai untuk mengurangkan konflik; jika berbilang penulis (multi-writer) diperlukan, kesan versi serentak, gabungkan medan yang selamat secara automatik, dan cipta konflik semakan untuk medan sensitif. Kekalkan rekod audit yang tidak boleh diubah dan sediakan laluan pemulihan yang dapat dilihat oleh pengguna. Ukur kadar konflik, kelewatan replikasi, kemas kini yang hilang dan masa pemulihan.
Perbincangan mendalam
1. Klasifikasikan ketekalan pada peringkat medan
Bahagikan profil kepada medan yang boleh digabungkan dan medan yang sensitif terhadap keselamatan. Nama paparan, biografi atau avatar boleh menggunakan penggabungan berasaskan penulisan terakhir atau versi, manakala e-mel, MFA, keterlihatan privasi dan status akaun mungkin memerlukan penulisan bersyarat, penulis tunggal atau semakan manusia. Klasifikasi ini memacu model data, UI dan kebenaran pemulihan; cap masa peringkat baris adalah tidak mencukupi.
2. Pilih penghalaan single-home, partition-home, atau multi-writer
Reka bentuk paling mudah menetapkan rantau asal bagi setiap pengguna atau penyewa, menyediakan bacaan berdekatan di tempat lain, dan mengambil alih buat sementara waktu semasa kegagalan. Jika perniagaan memerlukan multi-writer, terima kos pengesanan dan penggabungan konflik. Penghalaan harus membawa metadata rantau dan versi; peralihan kegagalan (failover) memerlukan pajakan (lease) atau epok pengambilalihan yang jelas supaya rantau asal lama yang telah pulih tidak terus menulis dan mencipta konflik main semula (replay).
3. Reka bentuk versi, peristiwa dan keidempotenan
Simpan vektor versi, rantau, masa logik dan ID operasi terakhir bagi setiap medan atau kumpulan medan. Penulisan bersyarat mengesahkan bahawa versi asas klien masih sah; percubaan semula dinyahduplikasi melalui ID operasi. Peristiwa replikasi membawa versi lama, versi baharu dan medan yang diubah, supaya penghantaran pendua, tidak teratur dan tertangguh tidak boleh menggunakan atau menulis ganti perubahan sebanyak dua kali.
4. Tentukan pengesanan konflik dan penggabungan automatik
Dua versi berkonflik apabila tiada satu pun yang merangkumi antara satu sama lain. Medan yang tidak bertindih (disjoint) boleh digabungkan; medan yang sama mengikut peraturan perniagaan seperti keutamaan rantau asal, penulis terakhir atau semakan eksplisit. Jangan anggap masa jam dinding (wall-clock time) sebagai niat pengguna: pencongan jam (clock skew) boleh menyebabkan kandungan yang lebih lama menang. Rekodkan peraturan, versi sumber dan hasil bagi setiap penggabungan.
5. Lindungi medan privasi dan keselamatan
Keterlihatan privasi, e-mel, kaedah log masuk dan MFA tidak boleh menggunakan peraturan penulisan terakhir menang (last-write-wins) yang biasa. Wajibkan penulisan bersyarat, kebenaran rantau asal atau semakan manusia, dan kekalkan keterlihatan secara konservatif semasa konflik. API pemulihan mesti mengesahkan operator serta menyemak sebab dan kebenaran supaya “menyelesaikan konflik” tidak menjadi laluan peningkatan keistimewaan.
6. Jadikan pemulihan dan kebolehcerapan sebagai keutamaan utama
Kekalkan versi sebelum dan selepas konflik, rantaian peristiwa dan keputusan penggabungan, serta benarkan pengguna membuat asal (undo) atau memilih versi. Pantau kadar konflik, kelewatan replikasi, versi yang tersekat, kemas kini yang hilang, masa penyelesaian manual dan pertukaran rantau. Lakukan latihan pengasingan serantau, kebangkitan semula rantau asal lama, peristiwa pendua dan main semula supaya pemulihan tidak mencipta penulisan ganti kali kedua.
Jawapan kukuh yang lengkap
Saya akan mengklasifikasikan ketekalan mengikut medan dan memberikan peraturan bersyarat atau penulis tunggal yang lebih ketat kepada medan privasi dan keselamatan. Gunakan rantau asal pengguna secara lalai dengan bacaan berdekatan; jika multi-writer diperlukan, sertakan rantau, versi, ID operasi dan set medan yang diubah dalam setiap peristiwa serta jadikan replikasi idempoten dan selamat daripada penyusunan semula. Kesan versi serentak, gabungkan medan yang tidak bertindih secara automatik, dan gunakan peraturan perniagaan atau semakan pengguna untuk medan yang sama; jangan sekali-kali menganggap masa jam dinding sebagai niat. Tulis versi, peraturan penggabungan dan operator ke log audit, pantau kadar konflik, kelewatan, kemas kini yang hilang dan masa pemulihan, serta jalankan latihan kebangkitan semula rantau asal lama dan peristiwa pendua.
Mod kegagalan biasa
- Menggunakan satu peraturan last-write-wins peringkat rekod yang menulis ganti perubahan privasi atau keselamatan.
- Menyatakan "gunakan vektor versi" tanpa menerangkan granulariti medan, kos storan dan pengalaman pengguna selepas konflik.
- Mengabaikan replikasi pendua, tidak teratur, tertangguh dan kebangkitan semula rantau asal lama, yang menyebabkan satu lagi penulisan ganti semasa pemulihan.
- Meniadakan ID operasi, sejarah audit dan laluan buat asal pengguna, menjadikan penggabungan tidak dapat dijelaskan dan tidak dapat dibaiki.
- Membincangkan ketersediaan dan kependaman sahaja tanpa mengukur kemas kini yang hilang, kadar konflik dan kos manual.
Susulan dan lanjutan
Susulan 1: Mengapa tidak menggunakan last-write-wins di semua tempat?
Ia mudah dan menumpu (converges), tetapi masa jam dinding tidak menyatakan niat pengguna dan pencongan jam boleh membenarkan kandungan lama menang. Ia mungkin boleh diterima untuk medan berisiko rendah; privasi, keselamatan dan kandungan bernilai tinggi memerlukan penulisan bersyarat, penulis asal atau pengendalian konflik yang eksplisit.
Susulan 2: Adakah rantau asal menjejaskan ketersediaan?
Ia menambah kependaman penulisan rentas rantau dan memerlukan pengambilalihan semasa kegagalan rantau asal, tetapi sangat mengurangkan konflik dan kerumitan operasi. Pilih rantau asal mengikut penyewa, sediakan epok pengambilalihan sementara, dan nilaikan matlamat ketersediaan bersama-sama keperluan keselamatan data.
Susulan 3: Bagaimanakah UI harus memaparkan konflik?
Tunjukkan medan, kedua-dua sumber dan masa kemas kini serta terangkan sebab pilihan diperlukan. Kekalkan medan sensitif secara konservatif dan elakkan daripada mendedahkan istilah dalaman rantau atau pangkalan data. Sediakan laluan buat asal, cuba semula dan sokongan serta rekodkan pilihan pengguna.
Susulan 4: Bagaimanakah anda membaca apabila replikasi sangat tertangguh?
Kembalikan tera air (watermark) versi atau rantau supaya klien mengetahui tahap kesegaran data. Halakan bacaan-selepas-tulis (read-after-write) untuk aliran kritikal ke rantau penulisan manakala bacaan biasa menerima ketekalan akhirnya. Berikan amaran, hadkan perubahan berisiko tinggi, atau arahkan pengguna ke rantau asal apabila kelewatan melebihi ambang.