Topik wawancara representatif

Bagaimana Anda mendesain pemilihan leader berbasis lease?

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Beberapa replika harus memastikan bahwa hanya satu instance yang menjalankan tugas penyelesaian (settlement job) terjadwal pada satu waktu. Desain pemilihan leader berbasis lease dan jelaskan keamanan (safety) serta ketersediaan (availability) selama kegagalan, partisi, dan pemulihan.

Perintah dan konteks

Beberapa replika berbagi penyimpanan koordinasi dan harus memastikan bahwa hanya satu instance yang menjalankan tugas penyelesaian (settlement job) terjadwal pada satu waktu. Desain catatan lease, pencalonan (campaign), pembaruan (renewal), serah terima (handoff), dan observabilitas. Cakup partisi jaringan, jeda proses (process pauses), clock drift, dan kegagalan penyimpanan. Lease mengontrol siapa yang boleh memulai pekerjaan; penulisan bisnis tetap memerlukan idempotensi dan pemeriksaan kondisional.

Hal yang diuji oleh pewawancara

  • Apakah Anda memisahkan keamanan lease dari efek samping bisnis (business side effects).
  • Apakah Anda memahami compare-and-set atomik, token fencing term, dan kuorum.
  • Apakah Anda dapat menjelaskan mengapa jeda, partisi, dan leader lama yang aktif kembali tidak menciptakan penulis ganda (dual writers) yang valid.
  • Apakah Anda menentukan sinyal yang terukur, injeksi kesalahan (fault injection), dan perilaku pemulihan.

Pertanyaan klarifikasi sebelum menjawab

Konfirmasikan jendela jeda yang diizinkan, toleransi eksekusi duplikat, konsistensi penyimpanan koordinasi, latensi lintas wilayah, jumlah replika, dan kualitas sinkronisasi jam. Jika konsistensi kuat lintas wilayah diperlukan, jelaskan secara eksplisit trade-off antara ketersediaan dan latensi pemilihan.

Kerangka jawaban 30 detik

Gunakan penyimpanan koordinasi yang menawarkan pembacaan linearizable dan penulisan kondisional. Setiap kandidat bersaing dengan identitas unik dan term yang meningkat secara monoton; hanya pembuatan atau pembaruan atomik yang berhasil yang menjadi leader. Leader memperbarui lease sebelum kedaluwarsa. Setiap penulisan bisnis membawa token term, dan sistem hilir (downstream) menolak token yang lebih lama. Kandidat mengambil alih kepemimpinan hanya setelah mengonfirmasi status baru. Selama partisi atau jeda yang lama, instance menghentikan efek samping; pemadaman singkat lebih aman daripada adanya penulis ganda.

Pembahasan mendalam langkah demi langkah

1. Model data dan operasi atomik

Catatan lease berisi identitas pemegang, waktu kedaluwarsa, token term, versi, dan waktu pembaruan terakhir. Persaingan menggunakan compare-and-set: buat jika tidak ada, atau perbarui hanya jika versi tidak berubah dan lease telah kedaluwarsa. Kubernetes merepresentasikan lease sebagai objek koordinasi yang berisi informasi pemegang dan pembaruan; implementasi harus memverifikasi model konsistensi penyimpanan alih-alih memercayai cache yang berkonsistensi akhir (eventually consistent).

2. Pembaruan dan penurunan takhta mandiri (self-demotion)

Lakukan pembaruan jauh sebelum durasi lease habis, sisakan ruang untuk jitter jaringan dan jeda penjadwal (scheduler pauses). Jika pembaruan gagal, konfirmasi tidak dapat dibaca, atau proses berhenti melebihi batas waktu aman, segera hentikan efek samping dan lakukan pencalonan kembali setelah pemulihan. Jangan menentukan kedaluwarsanya pemegang lain hanya dari jam lokal (wall clock).

3. Fencing dan idempotensi bisnis

Setiap pencalonan yang berhasil menghasilkan token monotonik. Worker, pembaruan database kondisional, atau layanan hilir menolak permintaan yang membawa token lama. Dengan demikian, leader lama yang terbangun setelah jeda tidak dapat menimpa penulisan leader baru. Penyelesaian transaksi tetap memerlukan kunci idempotensi, batas transaksi, dan penanganan percobaan ulang (retry).

Contoh jawaban berkualitas tinggi

Saya mendefinisikan keamanan (safety) sebagai pencegahan terhadap dua leader valid yang menulis ke sumber daya yang sama pada saat bersamaan; ketersediaan (availability) mengizinkan jeda singkat setelah lease kedaluwarsa. Penyimpanan koordinasi menyediakan CAS linearizable. Kandidat mencatat identitasnya dan term yang meningkat, serta leader memperbarui status melalui heartbeat. Setiap efek samping membawa token term, yang dibandingkan oleh penulisan kondisional di hilir. Jika partisi, jeda GC, atau hilangnya konfirmasi pembaruan terjadi, instance akan berhenti dan hanya mencalonkan diri kembali setelah mengonfirmasi ulang status; tidur (sleep) selama beberapa detik bukanlah bukti keamanan. Raft menggunakan term dan pemungutan suara mayoritas untuk kepemimpinan log, sedangkan Kubernetes Lease adalah catatan koordinasi yang lebih ringan. Keduanya memerlukan model konsistensi yang eksplisit, batas waktu (timeout budget), dan rencana pemulihan. Saya akan menginjeksikan crash pada leader, partisi, pergeseran jam, jeda panjang, dan penyimpanan yang tidak tersedia, lalu memeriksa adanya penulisan ganda, penulisan dengan token usang, serta pelanggaran batas waktu pemulihan.

Kesalahan umum

  • Menyimpan lock hanya di memori proses atau mengandalkan pembacaan Redis yang berkonsistensi akhir sambil mengklaim bahwa tidak ada leader ganda yang mungkin terjadi.
  • Membandingkan timestamp tanpa term monotonik dan token fencing.
  • Melanjutkan batch saat ini setelah pembaruan gagal, sehingga memberi jendela waktu bagi leader lama untuk menulis.
  • Menyamakan satu leader pada satu waktu dengan tidak adanya eksekusi duplikat sama sekali.
  • Hanya menguji pemilihan dalam kondisi normal dan mengabaikan jeda, partisi, latensi penyimpanan, atau kegagalan penyimpanan.

Pertanyaan lanjutan dan tanggapan

Apakah berakhirnya masa lease menjamin bahwa leader lama telah berhenti?

Tidak. Suatu proses dapat mengalami jeda atau tetap terisolasi saat masih berjalan. Validasi token fencing pada batas bisnis; kedaluwarsa hanya berarti lapisan koordinasi tidak lagi mengakui pemegang tersebut.

Bagaimana Anda memilih interval lease dan pembaruan?

Turunkan nilainya dari target deteksi kegagalan, latensi p99 lintas wilayah, toleransi jeda penjadwal, dan jitter penyimpanan, dengan margin beberapa siklus pembaruan. Pantau kegagalan pembaruan dan perputaran pemilihan (churn) alih-alih menyalin nilai milidetik yang tetap.

Bagaimana jika penyimpanan koordinasi tidak tersedia?

Hentikan efek samping baru dan pertahankan hanya hasil yang bersifat hanya-baca (read-only) atau yang telah berhasil di-commit secara aman. Setelah pemulihan, baca kembali term dan lakukan pencalonan. Jika operasi berkelanjutan wajib dilakukan, lakukan penurunan fungsi (degrade) secara eksplisit ke sharding, kepemilikan multi-aktif, atau pengambilalihan manual oleh manusia, lalu nyatakan kembali bukti keamanannya.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat