Wawancara Desain Sistem: Bagaimana Anda Merancang Layanan Pemilihan Pemimpin yang Aman?

Pertanyaan dan konteks

Beberapa worker stateless harus memiliki tepat satu instance yang menjalankan tugas penyelesaian terjadwal pada satu waktu. Worker dapat mengalami crash, restart, jeda, atau terpartisi, dan sistem tidak boleh membiarkan dua worker menulis dalam jangka waktu yang lama. Rancang pemilihan pemimpin dengan koordinator, lease, perpanjangan, fencing, failover, dan batasan operasional. Intinya adalah koordinasi penulis tunggal yang aman, bukan sekadar mutex.

Apa yang sedang diuji oleh pewawancara

Mendefinisikan safety dan liveness

Safety berarti paling banyak satu pemimpin untuk suatu term yang diterima oleh sumber daya; liveness berarti kandidat yang sehat pada akhirnya mengambil alih setelah lease lama dipastikan kedaluwarsa. Partisi minoritas tidak dapat mengumumkan pemimpin baru hanya demi mempertahankan ketersediaan.

Memilih koordinator dengan semantik konsensus

Catatan pemimpin membutuhkan compare-and-set yang linearizable, lease, dan semantik watch, seperti etcd. Redis TTL atau jam lokal saja tidak dapat membuktikan bahwa pemimpin yang usang tidak mampu menulis.

Mencegah penulisan yang usang

Setelah lease kedaluwarsa, proses lama mungkin pulih dan melanjutkan pekerjaan. Setiap operasi penulisan downstream harus membawa fencing token yang meningkat secara monoton, dan sumber daya harus menolak token yang lebih lama untuk mencegah kerusakan split-brain.

Pertanyaan klarifikasi awal

• Bisakah tugas dijalankan dua kali, atau haruskah downstream secara ketat menerima satu eksekusi terserialisasi?
• Apakah pemilihan berlaku global, per tenant, per shard, atau per tugas?
• Berapa waktu failover dan jendela jeda yang dapat diterima?
• Berapa banyak failure domain koordinator dan kuorum/cadangan apa yang tersedia?
• Bisakah sumber daya downstream memvalidasi fencing token dan memulihkan secara idempoten?
• Apakah event watch, riwayat audit, peringatan, dan transfer manual diperlukan?

Jawaban 30 detik

“Saya akan mendefinisikan cakupan pemilihan dan batas toleransi kegagalan terlebih dahulu, lalu menyimpan catatan pemimpin ber-lease di koordinator yang didukung konsensus dan linearizable. Kandidat bersaing dengan pembaruan create-or-compare transaksional; pemenang mendapatkan term fencing yang lebih tinggi dan memperpanjangnya dalam rentang TTL. Kegagalan perpanjangan akan menghentikan pekerjaan baru dan penulisan. Setiap penulisan downstream memvalidasi term tersebut, sehingga pemimpin usang yang pulih tidak dapat menulis. Watch hanya mempercepat upaya CAS baru. Saya akan memantau term, latensi perpanjangan, waktu failover, penolakan fencing, duplikasi, dan kesehatan kuorum.”

Jawaban mendalam langkah demi langkah

Mendefinisikan catatan term

Simpan election_name, leader_id, lease_id, term, metadata kandidat, dan stempel waktu. Term atau fencing token harus meningkat secara monoton dan ditetapkan secara atomik oleh koordinator, bukan dihasilkan dari jam klien.

Memilih koordinator dan kondisi penulisan

Kandidat membuat catatan ephemeral yang didukung lease; transaksi linearizable hanya boleh menulis jika kuncinya tidak ada. Jika pemimpin sudah ada, kandidat memantau (watch) kunci tersebut dan mencoba lagi. API pemilihan etcd memungkinkan peserta bersaing pada satu nama pemilihan dengan satu pemimpin yang berhasil pada satu waktu.

Memperpanjang dan fail closed

Pemimpin memperpanjang lease melalui loop keepalive independen. Waktu habis perpanjangan, terputusnya koneksi, jeda proses, atau anomali jam lokal akan memindahkannya ke suspect, di mana ia berhenti menerima pekerjaan baru dan penulisan downstream. Ia tidak boleh terus bekerja dengan yakin saat terputus dari koordinator.

Menangani failover

Kandidat tidak dapat memutuskan bahwa pemimpin lama telah mati hanya berdasarkan TTL lokalnya. Ia harus mengamati kedaluwarsa atau penghapusan lease yang dikonfirmasi oleh koordinator, lalu bersaing dengan CAS. Waktu failover adalah jumlah dari TTL, deteksi, dan penundaan penjadwalan, jadi tetapkan batas dengan margin jitter.

Menambahkan fencing token

Pemimpin baru memperoleh term yang lebih tinggi dan melampirkannya ke pembaruan basis data, pesan, atau permintaan API eksternal. Sumber daya menyimpan token tertinggi yang diterima dan menolak token yang lebih rendah. Ini memblokir penulisan berbahaya bahkan ketika proses lama belum berhenti.

Menangani partisi dan split brain

Partisi minoritas tidak dapat menerbitkan term baru. Kandidat yang tidak dapat mencapai kuorum koordinator harus berhenti atau tetap dalam mode baca-saja. Setelah terhubung kembali, pemimpin lama harus membaca ulang term saat ini dan bersaing kembali alih-alih memercayai status yang di-cache.

Pseudokode

~~~text campaign(): lease = coordinator.grant(ttl) result = coordinator.txn(key absent -> put(candidate, lease, next_term)) if result.succeeded: token = result.term keepalive(lease) runwithfencing(token) else: watch(key)

onkeepalivefailureorexpiry: stopnewwork() stopdownstreamwrites() ~~~

Kompleksitas, pemulihan, dan observabilitas

Setiap pemilihan dan perpanjangan melibatkan round trip ke koordinator; lebih banyak kandidat menambah beban watch dan percobaan ulang, jadi gunakan exponential backoff dengan jitter. Catat pemimpin saat ini, term, RTT perpanjangan, kedaluwarsa lease, durasi pemilihan, penolakan fencing, tugas duplikat, dan kesehatan kuorum untuk merekonstruksi transisi term.

Contoh jawaban

“Saya akan menyimpan catatan pemimpin ber-lease di koordinator yang didukung konsensus dengan transaksi linearizable. Kandidat bersaing dengan membuat catatan hanya jika belum ada; pemenang menerima term yang meningkat secara monoton dan memperpanjangnya dalam rentang TTL. Jika perpanjangan gagal, ia segera menghentikan tugas baru dan penulisan downstream. Setiap penulisan basis data, pesan, atau panggilan eksternal membawa fencing token, dan sumber daya menolak token di bawah nilai tertinggi yang pernah diterima, sehingga pemimpin lama yang dijeda atau terpartisi tidak dapat melanjutkan penulisan. Minoritas tidak dapat menerbitkan term baru, sementara watch hanya mengurangi penundaan pemilihan. Saya akan memantau RTT perpanjangan, term, durasi failover, penolakan fencing, tugas duplikat, dan kuorum, dengan kill switch manual.”

Kesalahan umum

Hanya menggunakan Redis TTL

Kedaluwarsa lease dan pengamatan kedaluwarsa oleh klien adalah dua hal yang berbeda. Penundaan jaringan dan jeda proses dapat membuat dua klien percaya bahwa mereka boleh bekerja. Gunakan koordinasi linearizable ditambah downstream fencing.

Menganggap lease sebagai perlindungan penulisan

Lease membantu mendeteksi kegagalan tetapi tidak dapat menghentikan proses lama secara instan. Tanpa validasi token, pemimpin usang dapat menimpa hasil dari pemimpin baru.

Menghasilkan term dari waktu lokal

Jam dapat mengalami deviasi, lompatan, atau jeda. Koordinator harus mengalokasikan dan mempertahankan term secara atomik.

Memaksa pengambilalihan selama partisi

Minoritas tidak dapat mengonfirmasi status pemimpin lama. Pengambilalihan paksa menciptakan split brain; desain yang aman menerima kehilangan ketersediaan singkat.

Membiarkan event watch menentukan safety

Event watch dapat tertunda, hilang, atau tersambung ulang. Event tersebut harus memicu pembacaan ulang dan CAS, bukan menggantikan pembacaan dan penulisan linearizable.

Mengabaikan idempotensi tugas

Pemilihan yang benar tidak mencegah terjadinya duplikasi setelah crash atau pengiriman ulang pesan. Tugas memerlukan kunci idempotensi, catatan progres, atau transaksi yang dapat diputar ulang.

Pertanyaan lanjutan dan tanggapan

Apa perbedaan pemilihan pemimpin dengan distributed lock?

Kunci (lock) melindungi critical section; pemilihan mempertahankan peran koordinator berumur panjang dengan term, perpanjangan, watch, fencing, dan failover. Keduanya dapat berbagi koordinator, tetapi cakupan safety pemilihan pemimpin lebih luas.

Bagaimana sebaiknya Anda memilih TTL?

Cakup RTT perpanjangan normal, jeda GC atau scheduler, jitter jaringan, dan SLO failover. TTL yang terlalu pendek menyebabkan churn; TTL yang terlalu panjang menunda pengambilalihan. Kalibrasi dengan fault injection.

Mengapa sumber daya harus memeriksa fencing token?

Koordinator tidak dapat secara instan menghentikan setiap proses yang usang. Penolakan di sisi sumber daya memblokir penulisan berbahaya saat proses tersebut masih berjalan.

Apa yang terjadi jika kluster etcd kehilangan kuorum?

Kluster tersebut tidak dapat melakukan commit pada term atau status lease baru; pemimpin saat ini harus menghentikan penulisan setelah tidak dapat memperpanjang lease. Kandidat akan bersaing kembali setelah kuorum pulih.

Bagaimana Anda menangani jeda panjang pada pemimpin?

Perpanjangan gagal selama jeda berlangsung dan kandidat baru dapat mengambil alih. Ketika proses lama melanjutkan eksekusi, token lamanya akan ditolak dan ia harus bergabung kembali ke dalam pemilihan.

Bagaimana Anda menguji split brain?

Lakukan injeksi jeda proses, partisi jaringan, lompatan jam, dan kegagalan koordinator. Pastikan bahwa hanya satu token per term yang diterima untuk penulisan, serta periksa durasi failover dan catatan penolakan.