Temuduga Reka Bentuk Sistem: Mereka Bentuk Perkhidmatan Kunci Teragih

Masalah dan Skop

Reka bentuk perkhidmatan kunci teragih yang digunakan merentasi tiga zon ketersediaan dalam satu rantau. Ia menguruskan 100,000 sumber yang boleh dikunci, biasanya mengekalkan 20,000 kunci aktif, dan mengendalikan 2,000 pemerolehan sesaat pada waktu puncak. Pajakan lalai ialah 30 saat, klien memperbaharui setiap 10 saat, dan sasaran p99 bagi pemerolehan tanpa pertikaian ialah 200 milisaat. Storan atau perkhidmatan yang dilindungi boleh membandingkan token pemagaran secara atomik dan menolak permintaan daripada pemegang yang lebih lama.

Skala, tempoh pajakan, dan kependaman adalah input temuduga, bukannya tuntutan prestasi untuk etcd, ZooKeeper, atau produk lain. Skop ini merangkumi kunci eksklusif, menunggu, pembaharuan, pelepasan, failover, dan kebolehcerapan. Kunci baris pangkalan data yang berbutir halus, koordinator transaksi penuh, pelaksanaan konsensus dari awal, dan penguncian rentas rantau aktif-aktif berada di luar reka bentuk utama.

Ini ialah soalan reka bentuk sistem, infrastruktur, dan backend kanan yang representatif. Panduan temuduga SDE II Amazon semasa secara eksplisit merangkumi reka bentuk sistem dan menilai kepraktisan, ketepatan, kecekapan, kebolehpercayaan, pengoptimuman, dan kebolehskalaan. Mod kegagalan utama menyentuh kesemuanya: perkhidmatan mesti memulihkan kunci selepas klien gagal tanpa membiarkan klien lama yang menyambung semula kemudian merosakkan data pemegang baharu.

Perkara yang Dinilai oleh Penemuduga

Pertama, bolehkah calon memisahkan keselamatan saling eksklusif daripada pembersihan kegagalan? Pajakan menjawab bila pemegang lain boleh mengambil alih selepas pemegang semasa hilang. Ia tidak menghalang klien yang terhenti seketika untuk masa yang lama daripada menyambung semula dan menulis. Reka bentuk yang ketat juga memerlukan token pemagaran dan pengesahan pada sumber yang dilindungi.

Kedua, adakah sempadan konsistensi dinyatakan secara eksplisit? Pemerolehan, pembaharuan, dan pelepasan mesti melalui satu mesin keadaan konsisten kukuh. Sekatan minoriti tidak boleh terus mengeluarkan kunci. Jika tiga zon ketersediaan membuat keputusan secara bebas, sekatan rangkaian boleh mewujudkan dua pemegang untuk sumber yang sama.

Ketiga, adakah perancangan kapasiti merangkumi trafik pembaharuan? Dengan 20,000 kunci aktif diperbaharui setiap 10 saat, pembaharuan sahaja menghasilkan kira-kira 2,000 operasi sesaat. Jika waktu puncak juga mempunyai 2,000 pemerolehan sesaat dan bilangan pelepasan yang serupa, mesin keadaan memerlukan kira-kira 6,000 komit sesaat, bukan sekadar kadar pemerolehan.

Keempat, adakah semantik kegagalan mencapai tahap permintaan? Jawapan harus merangkumi pemerolehan yang dikomit tetapi kehilangan responsnya, klien yang terhenti melebihi tempoh pajakan, klien lama yang melepaskan kunci pemegang baharu, kehilangan korum, dan token monotonik merentasi pertukaran ketua.

Akhir sekali, adakah calon tahu bila tidak patut menggunakan perkhidmatan ini? Google Chubby bertujuan untuk koordinasi berbutir kasar. Jika kekangan unik pangkalan data, kemas kini bersyarat, baris gilir pengguna tunggal, atau kunci ketakbolehubahan perniagaan telah menyelesaikan masalah tersebut, kunci jarak jauh menambah satu lagi titik kegagalan segerak.

Soalan Penjelasan Sebelum Menjawab

• Adakah kita memerlukan kunci eksklusif atau pembaca-penulis? Reka bentuk ini bermula dengan kunci eksklusif. Kunci pembaca-penulis menambah

keadaan, peningkatan taraf, dan semantik kelaparan yang tidak seharusnya dijanjikan secara sambil lewa.

• Bolehkah sumber yang dilindungi mengesahkan token pemagaran? Gesaan ini mengandaikan perbandingan atomik dan penyimpanan token terkini.

Tanpanya, pajakan hanya mengurangkan tetingkap konflik dan tidak dapat mengecualikan klien zombi secara ketat.

• Sejauh manakah keadilan menunggu diperlukan? Lalai ialah anggaran FIFO. Keadilan mutlak mengurangkan fleksibiliti semasa pemulihan dan di bawah beban kerja yang berubah-ubah.
• Berapa lama klien boleh menunggu? waitTimeout dihadkan dan boleh dibatalkan supaya keadaan menunggu tidak berkembang selama-lamanya.
• Bolehkah tempoh pajakan berbeza mengikut beban kerja? Lalai ialah 30 saat dengan pembaharuan setiap 10 saat. Tugas yang panjang boleh

meminta tempoh dalam dasar yang terhad, tetapi pajakan tidak boleh dilanjutkan tanpa had.

• Bolehkah pemerolehan dicuba semula secara automatik? Hanya percubaan semula yang membawa requestId stabil yang sama adalah selamat. Jika tidak,

respons yang hilang meninggalkan hasil yang tidak diketahui.

• Apakah yang berlaku tanpa korum? Keselamatan diutamakan: tolak pemerolehan dan pembaharuan baharu. Setiap sekatan tidak boleh mengeluarkan kunci.
• Adakah operasi yang dilindungi masih perlu bersifat idempoten? Ya. Pemagaran menolak epok yang lebih lama; percubaan semula perniagaan dan

penyerahan pendua masih memerlukan kunci atau transaksi ketakbolehubahan perniagaan.

• Adakah penguncian rentas rantau berkependaman rendah diperlukan? Reka bentuk utama adalah satu rantau merentasi zon ketersediaan. Kunci

rentas rantau yang ketat menanggung kependaman yang lebih tinggi atau kehilangan ketersediaan semasa sekatan rangkaian dan tergolong dalam perbincangan susulan.

Kerangka Jawapan 30 Saat

“Saya akan menyimpan keadaan kunci dalam mesin keadaan konsisten kukuh yang direplikasi merentasi tiga zon ketersediaan. Setiap pemerolehan, pembaharuan, dan pelepasan dikomit oleh korum. Pemerolehan yang berjaya mengembalikan leaseId, tempoh luput 30 saat, dan fencingToken yang meningkat secara monotonik. Klien memperbaharui setiap 10 saat dan menghentikan kerja apabila pembaharuan tidak pasti. Setiap operasi yang dilindungi membawa token tersebut; sumber menyimpan epok tertinggi yang telah diterimanya dan menolak token yang lebih lama. Pajakan membenarkan pemegang baharu, manakala pemagaran menolak pemegang lama yang bersambung semula. requestId yang dinyahduplikasi mengendalikan pemerolehan yang telah dikomit tetapi responsnya hilang. Pengantri yang teratur hanya memerhatikan pendahulu mereka untuk mengelakkan kesesakan serentak (thundering herd). Dua puluh ribu kunci menghasilkan kira-kira 2,000 pembaharuan sesaat; bersama pemerolehan dan pelepasan, saya akan menguji kira-kira 6,000 komit keadaan sesaat di bawah ketahanan dan failover.”

Pecahan Terperinci Langkah Demi Langkah

Mulakan dengan batas kekal (invariants) dan bukannya rajah komponen:

1. Untuk satu sumber, mesin keadaan yang konsisten merekodkan paling banyak satu leaseId yang sah pada satu-satu masa.
2. Setiap kunci yang baru diperoleh menerima token pemagaran yang lebih besar.
3. Sumber yang dilindungi menolak token yang lebih rendah daripada token tertinggi yang telah diterimanya.
4. Hanya permintaan yang sepadan dengan leaseId semasa boleh memperbaharui atau melepaskan kunci.
5. Perkhidmatan tidak mencipta kunci atau mendakwa kejayaan pembaharuan tanpa mencapai korum.

Batas kekal ini memisahkan “siapa yang dianggap oleh perkhidmatan kunci sebagai pemegang” daripada “hasil kerja siapa yang masih akan diterima oleh sumber.” Mesin keadaan memutuskan yang pertama; pemagaran di sempadan kesan sampingan memutuskan yang kedua.

Langkah 1: Tentukan API dan keadaan.

Acquire(resource, requestId, leaseTtl, waitTimeout)
  -> { leaseId, fencingToken, expiresAt }

Renew(resource, leaseId)
  -> { expiresAt }

Release(resource, leaseId)
  -> { released }

resource ialah pengecam perniagaan yang dinormalkan, bukan input pengguna mentah tanpa batas. leaseId ialah pengecam yang tidak boleh diteka untuk epok pemilikan ini. fencingToken menggunakan semakan monotonik global bagi log konsensus yang telah dikomit, manakala setiap sumber yang dilindungi menyimpan token tertinggi yang telah diterimanya. Hasil penyahduplikasian untuk requestId kekal sekurang-kurangnya selama tetingkap percubaan semula pemanggil. Pelepasan adalah idempoten, tetapi pelepasan dengan leaseId lama tidak boleh memadam kunci pemegang baharu.

Rekod kunci mengandungi sumber, leaseId, identiti pemegang, token pemagaran, tempoh luput, dan rujukan pengantri pilihan. Rekod kunci yang melahu boleh dialih keluar, tetapi token tidak boleh berundur ke belakang. Semakan monotonik global mengelakkan penetapan semula epok satu sumber kepada 1 selepas rekod melahunya dipadamkan.

Langkah 2: Pilih sempadan replikasi konsisten kukuh.

Gunakan stor konsensus atau sistem koordinasi yang terbukti untuk mesin keadaan; jangan laksanakan semula Raft atau Paxos di dalam perkhidmatan aplikasi. Tempatkan satu replika dalam setiap satu daripada tiga zon ketersediaan. Ketua mengembalikan kejayaan hanya selepas sekurang-kurangnya dua replika mengkomit arahan tersebut. Bacaan keadaan kunci mesti boleh dilinearisekan atau dikendalikan oleh ketua; replika yang ketinggalan tidak boleh mengisytiharkan sumber sebagai bebas.

Laluan pemerolehan biasa mengesahkan parameter dan kunci penyahduplikasian, mengesahkan bahawa tiada kunci wujud atau mesin keadaan telah meluputkan pajakannya, menetapkan leaseId dan semakan baharu, mengkomitkannya kepada korum, dan mengembalikannya. Jika ketua gagal selepas komit tetapi sebelum responsnya tiba, percubaan semula dengan requestId yang sama mendapat hasil asal daripada ketua baharu dan bukannya mencipta pajakan kedua.

Apabila hanya satu daripada tiga replika kekal boleh dicapai, perkhidmatan menolak pemerolehan dan pembaharuan. Ini mengurangkan ketersediaan tetapi mengekalkan sifat saling eksklusif. Membenarkan minoriti memperbaharui kunci kelihatan membantu, tetapi selepas penyambungan semula tiada cara selamat untuk menganggap kedua-dua pemegang yang terpisah sebagai sah.

Langkah 3: Gunakan pajakan untuk memulihkan pemegang yang gagal.

Pajakan lalai ialah 30 saat dan klien memperbaharui setiap 10 saat, meninggalkan dua selang pembaharuan untuk variasi kependaman (jitter) dan kegagalan sementara. Masa pajakan berwibawa diuruskan oleh mesin keadaan koordinasi bahagian pelayan. Jam tempatan klien boleh memutuskan bila untuk mencuba pembaharuan, tetapi ia tidak dapat membuktikan pemilikan. Selepas kegagalan pembaharuan berulang atau respons yang tidak pasti, klien memasuki keadaan senyap (quiescent), tidak memulakan kerja baharu, dan menghentikan kerja dalam proses yang boleh diganggu secepat mungkin.

Pertukaran ketua mesti mengendalikan baki masa pajakan secara konservatif; jam yang laju pada ketua baharu tidak boleh menyerahkan kunci kepada pihak lain terlalu awal. Sistem pengeluaran harus menggunakan semula pelaksanaan pajakan yang telah diuji dan memasukkan sisihan jam maksimum, masa pemilihan, dan percubaan semula rangkaian dalam belanjawan pajakan. Memendekkan pajakan kepada ratusan milisaat meningkatkan kelajuan pembersihan tetapi mengubah jitter biasa menjadi kehilangan kunci yang kerap.

Langkah 4: Gunakan token pemagaran untuk menghentikan klien zombi.

Katakan klien A memperoleh token 41 dan kemudian terhenti seketika untuk pemungutan sampah (garbage collection) yang panjang. Pajakan 30 saatnya luput, klien B memperoleh token 42, dan B memulakan kerja. A menyambung semula tanpa mengetahui ia kehilangan kunci dan menghantar operasi tulis yang tertangguh. Jika stor hanya mengetahui bahawa A pernah memperoleh kunci, operasi tulis yang lapuk itu boleh menimpa hasil baharu B.

Oleh itu, setiap permintaan yang dilindungi membawa tokennya. Stor mengingati secara atomik epok tertinggi yang dilihat untuk setiap sumber. Selepas menerima token 42, ia menolak setiap permintaan dengan token 41. Pelbagai operasi dengan token yang sama mungkin masih sah; susunan, ketakbolehubahan, dan konflik versi mereka tergolong dalam protokol perniagaan. Perbandingan menolak token yang lebih rendah daripada epok terkini dan bukannya menolak secara membuta tuli token yang sama.

Dokumentasi etcd menyatakan sempadan yang sama secara eksplisit: pajakan sahaja tidak menjamin sifat saling eksklusif ke atas sumber luaran; sumber tersebut mesti mengesahkan versi. Jika sasaran tidak dapat menyimpan atau membandingkan token, reka bentuk tidak dapat menjanjikan keselamatan yang ketat. Alternatif termasuk kemas kini bersyarat pangkalan data, kekangan unik, kunci transaksi natif, baris gilir penulis tunggal, atau proksi tulis yang boleh menguatkuasakan token tersebut.

Langkah 5: Kendalikan menunggu, keadilan, dan kesesakan serentak (herds).

Untuk sumber yang rendah pertikaian, pemanggil yang gagal boleh mencuba semula dengan undur eksponen (exponential backoff) dan jitter. Untuk sumber hangat yang memerlukan proses menunggu, tetapkan nombor jujukan yang meningkat dan biarkan setiap pengantri hanya memerhatikan pendahulu terdekatnya. Apabila pendahulu melepaskan kunci atau luput, hanya pengantri seterusnya yang terjaga dan bukannya setiap klien bersaing serentak. Resipi kunci ZooKeeper menggunakan nod jujukan fana dan pemerhatian pendahulu atas sebab ini.

Baris gilir menyediakan anggaran FIFO, bukan keadilan mutlak. Pembatalan, tamat masa, dan tamat tempoh sesi akan mengalih keluar nod menunggu. Jika respons kepada penciptaan nod hilang, requestId akan mencari nod asal dan bukannya menambah nod lain. Had pengantri bagi setiap sumber dan setiap penyewa menghalang satu kunci hangat daripada menghabiskan memori.

Langkah 6: Anggarkan kapasiti dan pemetakan.

Dua puluh ribu kunci aktif yang diperbaharui setiap 10 saat menghasilkan kira-kira 2,000 pembaharuan sesaat. Pada waktu puncak 2,000 pemerolehan sesaat, dan dengan mengandaikan pelepasan adalah kira-kira sama dengan pemerolehan, mesin keadaan konsensus mengendalikan kira-kira 2,000 + 2,000 + 2,000 = 6,000 komit tulis sesaat. Rekod memasukkan ke baris gilir, pembatalan, peluputan, dan penyahduplikasian menambah amplifikasi penulisan. Ujian kapasiti harus menggabungkan trafik puncak, kehilangan satu replika, dan pemadatan log.

Jika 100,000 sumber mengekalkan kira-kira 500 bait keadaan logik setiap satu, jumlah logik adalah kira-kira 50 MB. Replika, log, indeks, pengantri, dan overhed enjin storan meningkatkan jejak sebenar secara ketara. Ketahanan segerak, sumber hangat, dan volum pembaharuan berkemungkinan besar menjadi kekangan utama di sini berbanding saiz rekod statik.

Mulakan dengan satu kumpulan konsensus untuk skala yang dinyatakan. Lakukan pemetakan mengikut cincangan sumber hanya jika pengukuran menunjukkan bahawa satu kumpulan gagal mencapai sasaran. Pemeringkatan (sharding) meningkatkan daya pemprosesan agregat tetapi tidak dapat membahagikan satu sumber yang sangat hangat, dan ia merumitkan penguncian atomik merentasi sumber. Reka bentuk ini tidak menjanjikan kunci transaksi pelbagai sumber. Jika pemanggil mesti mengunci beberapa sumber, mereka menggunakan susunan tetap dan tamat masa keseluruhan, atau domain dimodelkan semula sebagai satu sumber peringkat lebih tinggi.

Langkah 7: Tutup gelung kegagalan dan operasi.

• Kegagalan ketua: ketua baharu memulihkan keadaan yang telah dikomit; requestId menyelesaikan permintaan dengan respons yang tidak diketahui secara selamat.
• Sekatan rangkaian: hanya korum yang melayani permintaan; minoriti menolak, dan pemagaran akhirnya menolak penulisan pemegang lama.
• Klien terhenti seketika: kunci baharu boleh dikeluarkan selepas tamat tempoh, manakala klien yang bersambung semula gagal dalam pengesahan token di bahagian sumber.
• Kunci hangat: ukur panjang menunggu, kependaman pemerolehan, dan masa pegangan; hadkan baris gilir dan pertimbangkan baris gilir tugas atau tugasan yang dipetakkan.
• Ribut pembaharuan: gunakan jitter pada jadual klien dan utamakan pajakan yang paling hampir tamat tempoh dan bukannya memperbaharui setiap kunci secara serentak.
• Sumber tanpa pengesahan token: turunkan taraf secara eksplisit kepada pengecualian usaha terbaik (best-effort) atau larang penulisan wang dan inventori yang ketat.

Metrik teras merangkumi p50/p95/p99 pemerolehan, pembaharuan, dan pelepasan; hasil kejayaan, tamat masa, konflik, dan tidak diketahui; kunci aktif, pengantri, peluputan, kegagalan pembaharuan, tempoh pemilihan ketua, kependaman komit konsensus, penolakan pemagaran, dan sumber hangat. Log audit merekodkan sumber, leaseId, token, pemanggil, dan hasil tanpa muatan sensitif.

Pengesahan melangkaui ujian unit. Ujian model mesin keadaan memeriksa pemilikan tunggal dan token monotonik. Suntikan kerosakan merangkumi respons yang hilang selepas komit, klien yang terhenti melebihi 30 saat, penulisan lama yang tertangguh, pengasingan satu replika, kehilangan majoriti, pertukaran ketua, dan pembatalan pengantri. Pernyataan hujung ke hujung yang kritikal ialah: selepas sumber menerima token 42 B, token 41 A tidak boleh mengubah sumber itu lagi.

Contoh Jawapan Berkualiti Tinggi

“Saya akan bermula dengan sasaran keselamatan: satu sumber mempunyai paling banyak satu pajakan yang sah dalam keadaan kunci konsisten kukuh, dan sumber yang dilindungi tidak pernah menerima penulisan pemegang yang lebih lama. Perkhidmatan ini berjalan merentasi tiga zon ketersediaan pada stor konsensus yang terbukti. Pemerolehan, pembaharuan, dan pelepasan memerlukan korum. Dengan hanya minoriti, perkhidmatan menolak kerja dan bukannya menukar sifat saling eksklusif demi ketersediaan.

API mengembalikan leaseId, masa luput, dan fencingToken yang meningkat secara monotonik. Pajakan lalai ialah 30 saat dan klien memperbaharui setiap 10 saat. Jam tempatannya hanya menjadualkan pembaharuan; jika pembaharuan tidak pasti, klien menghentikan kerja. Pajakan membenarkan pengambilalihan selepas kegagalan, tetapi sumber adalah sempadan keselamatan sebenar: setiap permintaan yang dilindungi membawa token, dan sumber menyimpan epok tertinggi yang telah diterimanya dan menolak yang lebih lama. Jika klien token 41 menyambung semula selepas token 42 mengambil alih, penulisan lapuknya tidak boleh dilaksanakan.

Setiap pemerolehan membawa requestId. Jika perkhidmatan mengkomit tetapi kehilangan responsnya, pemanggil mencuba semula dengan ID yang sama dan menerima pajakan asal dan bukannya mencipta pajakan lain. Pembaharuan dan pelepasan mesti sepadan dengan leaseId semasa, jadi klien lama tidak boleh melepaskan pemegang baharu. Bagi kunci yang dipertikaikan, pengantri yang teratur hanya memerhatikan pendahulu mereka, memberikan anggaran FIFO tanpa berlakunya kesesakan serentak (thundering herd).

Bagi kapasiti, 20,000 kunci yang diperbaharui setiap 10 saat sudah menghasilkan kira-kira 2,000 penulisan sesaat. Menambah 2,000 pemerolehan dan kadar pelepasan yang serupa memberikan kira-kira 6,000 komit konsensus sesaat. Saya akan mengesahkan sasaran p99 200 milisaat semasa satu replika terhenti dan pemadatan log sedang berjalan dan bukannya memetik tanda aras vendor. Saya akan bermula dengan satu kumpulan konsensus dan melakukan pemeringkatan mengikut sumber hanya jika ujian beban membuktikannya perlu.

Akhir sekali, ujian model dan suntikan kerosakan merangkumi kehilangan respons selepas komit, klien terhenti seketika, paket tertangguh, sekatan rangkaian, pemilihan ketua, dan pembatalan pengantri. Saya akan memantau kependaman pemerolehan dan pembaharuan, konflik, peluputan, panjang baris gilir, pemilihan ketua, dan penolakan pemagaran. Jika sistem yang dilindungi tidak dapat membandingkan token secara atomik, saya akan menyatakan bahawa sifat saling eksklusif yang ketat tidak tersedia dan lebih mengutamakan kemas kini bersyarat pangkalan data, kekangan unik, atau baris gilir penulis tunggal.”

Kesilapan Biasa

• Menyimpan hanya kunci dengan TTL → klien lama yang terhenti seketika boleh menyambung semula dan menulis → keluarkan token monotonik untuk setiap pemerolehan dan sahkan ia pada sumber.
• Membiarkan setiap zon ketersediaan mengeluarkan kunci → sekatan rangkaian mewujudkan pelbagai pemegang → salurkan setiap perubahan keadaan melalui satu mesin keadaan yang disokong korum.
• Menganggap jam klien sebagai kebenaran pajakan → sisihan jam dan jeda proses menyebabkan pemilikan palsu → urus pajakan pada bahagian pelayan dan pastikan klien yang tidak pasti menghentikan kerja.
• Mencuba semula pemerolehan dengan ID permintaan baharu → permintaan asal mungkin telah dikomit → gunakan requestId yang stabil untuk mendapatkan semula hasil pertama.
• Membenarkan pelepasan menggunakan nama sumber sahaja → permintaan lama boleh memadam pemegang baharu → wajibkan leaseId semasa untuk pembaharuan dan pelepasan.
• Mengira saiz hanya untuk 2,000 pemerolehan sesaat → 2,000 pembaharuan dan pelepasan yang serupa terlepas pandang → uji kira-kira 6,000 komit keadaan garis dasar sesaat.
• Menjadikan setiap pengantri memerhatikan punca kunci → setiap pelepasan mengejutkan seluruh baris gilir → jadikan setiap pengantri hanya memerhatikan pendahulu terdekatnya.
• Membuat pemeringkatan kepada banyak kumpulan konsensus serta-merta → operasi dan semantik rentas sumber menjadi rumit terlebih dahulu → ukur satu kumpulan, kemudian lakukan pemeringkatan berdasarkan bukti.
• Menggunakan kunci teragih untuk setiap baris → koordinasi menjadi laluan transaksi frekuensi tinggi dan titik hambatan → lebih utamakan kekangan atomik pangkalan data untuk konkurensi berbutir halus.
• Mendakwa keselamatan ketat apabila sasaran tidak dapat mengesahkan token → pajakan tidak dapat menghentikan penulisan lapuk yang tertangguh → turunkan taraf jaminan atau ubah sempadan penulisan.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapakah token pemagaran diperlukan jika kunci mempunyai pajakan?

Pajakan hanya membenarkan perkhidmatan kunci memberikan kunci kepada B selepas 30 saat. Ia tidak dapat membatalkan operasi yang telah dihantar oleh A ke sistem luaran tetapi masih berada dalam rangkaian atau baris gilir proses. A juga mungkin menyambung semula selepas jeda yang lama tanpa mengetahui pajakannya telah luput. Sebaik sahaja sumber menerima token 42, menolak token 41 akan menghentikan kerja epok lama pada titik di mana kesan sampingan berlaku. Peraturan yang boleh diguna semula ialah: pajakan menentukan bila pemegang baharu boleh dipilih; pemagaran menentukan sama ada hasil kerja pemegang lama masih diterima.

Susulan 2: Bagaimana jika pangkalan data yang dilindungi tidak dapat menyimpan token pemagaran?

Cari dahulu syarat versi atomik yang setara seperti UPDATE ... WHERE version = expected, kekangan unik, kunci transaksi, atau kunci nasihat (advisory lock) pangkalan data. Operasi penulisan juga boleh melalui proksi atau baris gilir pengguna tunggal yang mengesahkan token tersebut. Jika tiada yang boleh dilakukan, jaminan yang diberikan hanyalah pengecualian usaha terbaik (best-effort); jeda proses dan mesej yang tertangguh masih boleh memecahkan ketepatan. Aliran kerja wang dan inventori tidak seharusnya menerima tuntutan yang samar-samar.

Susulan 3: Bagaimanakah anda mereka bentuk kunci global merentasi rantau?

Reka bentuk terus memberikan setiap sumber rantau asal (home region) dan memastikan setiap rantau menggunakan satu korum rentas rantau. Ini menambah kependaman penulisan jarak jauh, dan rantau minoriti tidak boleh memperoleh kunci semasa sekatan rangkaian berlaku. Kunci serantau yang bebas tidak boleh digabungkan secara tak segerak kerana konflik saling eksklusif tidak boleh dibatalkan kemudian. Jika ketersediaan serantau lebih penting, petakkan pemilikan sumber supaya satu sumber hanya boleh ditulis dalam satu rantau dan bukannya mencipta penguncian global aktif-aktif.

Susulan 4: Bagaimanakah anda memilih pajakan 30 saat dan selang pembaharuan 10 saat?

Kedua-duanya adalah input gesaan temuduga. Nilai sebenar bergantung pada jeda proses normal yang paling lama, p99 rangkaian, masa pemilihan ketua, belanjawan ralat jam, dan masa pemulihan kegagalan yang boleh diterima. Pajakan yang terlalu pendek menganggap jitter biasa sebagai kehilangan kunci; pajakan yang terlalu panjang melambatkan pemulihan daripada pemegang yang gagal. Pembaharuan 10 saat memberikan dua peluang tambahan dalam tempoh pajakan 30 saat. Tambahkan jitter rawak supaya 20,000 klien tidak menghasilkan lonjakan pembaharuan yang serentak.

Susulan 5: Bagaimanakah anda menyokong pemerolehan beberapa kunci serentak?

Sempadan paling mudah ialah perkhidmatan ini tidak menawarkan penguncian rentas sumber secara atomik. Pemanggil memperoleh nama sumber yang dinormalkan dalam susunan tetap dengan tamat masa keseluruhan yang singkat, dan melepaskannya dalam susunan terbalik selepas kegagalan. Ini mengurangkan kebuntuan (deadlock) tetapi bukan keatoman transaksi. Jika domain tersebut benar-benar memerlukan pemerolehan semua-atau-tiada (all-or-nothing), modelkan set tersebut sebagai satu sumber peringkat lebih tinggi atau simpan semua kunci dalam satu transaksi konsensus dan terima kos daya pemprosesan serta kerumitannya.

Susulan 6: Bagaimanakah anda membuktikan pelaksanaan tidak pernah mewujudkan dua pemegang yang sah?

Gunakan model mesin keadaan untuk menjana jujukan pemerolehan, pembaharuan, pelepasan, peluputan, dan percubaan semula, sambil menyemak bahawa setiap kedudukan log mempunyai paling banyak satu leaseId yang sah dan token sentiasa meningkat. Kemudian suntik kerosakan: hilangkan respons selepas komit, jedakan A melebihi tempoh pajakan, biarkan B memperoleh kunci dan menulis, dan sambung semula A dengan penulisan lamanya; sumber mesti menolak token lama tersebut. Asingkan juga minoriti dan majoriti, tukar ketua berulang kali, batalkan pengantri, dan semak setiap sejarah serentak terhadap batas kekal (invariants).