Gunakan lease dengan hati-hati

Pertanyaan

Bagaimana memastikan hanya satu pemilik yang bisa mengubah sumber daya, padahal pemilik lama mungkin belum sadar haknya sudah habis?

Setelah baca ini, kamu bisa menjelaskan lease, menunjukkan bagaimana pemilik usang tetap menulis setelah failover, dan memakai fencing token untuk menolak tulisannya.

Prasyarat dan contoh

Kamu sudah paham konsensus dan quorum (M08.05) dan batas jam fisik (M08.04).

Sebuah worker memegang lock "kirim laporan bulanan" dengan lease 30 detik di layanan koordinasi. Di detik ke-20 JVM worker berhenti 40 detik karena garbage collection panjang. Lease habis di detik 30, worker kedua mengambil lock dan mulai mengirim. Di detik 60 worker pertama bangun, tidak tahu lease-nya sudah habis, dan melanjutkan kirim. Laporan terkirim dua kali. Layanan lock bekerja benar. Yang salah adalah anggapan bahwa memegang lock berarti masih aman menulis.

Mekanisme

Lease. Lock dengan kedaluwarsa. Pemilik mendapat hak eksklusif sampai waktu tertentu dan harus memperpanjang sebelum habis. Kalau pemilik mati, hak berpindah setelah lease habis tanpa perlu intervensi manusia. Itu kelebihannya dibanding lock tanpa kedaluwarsa, yang macet selamanya kalau pemegangnya mati.

Failover leader. Pola yang sama dipakai untuk memilih leader di sistem lain: node yang memegang lease "leader" boleh menerima tulisan. Saat lease tidak diperpanjang, node lain mengambilnya. Waktu failover kira-kira durasi lease ditambah waktu pemilihan, jadi lease 10 detik berarti layanan tulis bisa berhenti sampai belasan detik.

Pemilik usang (stale owner). Pemilik lama bisa tertunda tanpa sadar: jeda GC, VM yang dibekukan, paket yang tertahan, atau jam yang melompat. Saat ia melanjutkan, ia masih mengira haknya berlaku. Memeriksa "lease masih berlaku?" sebelum menulis tidak menyelesaikan masalah, karena jeda bisa terjadi antara pemeriksaan dan penulisan.

Split brain. Dua node sama-sama bertindak sebagai leader. Penyebab umum: failover otomatis yang mengira leader mati padahal hanya lambat atau terpartisi. Akibatnya dua riwayat bercabang di penyimpanan yang tidak punya cara menolak salah satunya.

Fencing token. Solusinya memindahkan pengecekan ke sumber daya yang dilindungi. Tiap kali lease diberikan, layanan koordinasi memberi nomor yang selalu naik (33, 34, ...). Pemilik menyertakan nomor itu di tiap tulisan. Sumber daya mengingat nomor tertinggi yang pernah dilihat dan menolak tulisan dengan nomor lebih kecil.

worker 1 dapat lease, token=33
worker 1 berhenti (GC)
lease habis; worker 2 dapat lease, token=34
worker 2 tulis(token=34) -> diterima, tertinggi=34
worker 1 bangun: tulis(token=33) -> DITOLAK (33 < 34)

Token berasal dari log konsensus (M08.05), bukan dari jam, jadi monotonik walau jam melenceng.

Kapan lock tanpa fencing sebenarnya cukup. Kalau dua pemilik sekaligus hanya menyebabkan kerja ganda yang idempoten, misalnya dua worker membuat thumbnail yang sama, lease murni cukup dan lebih murah. Pilih berdasarkan akibat dari dua pemilik, bukan berdasarkan seberapa penting kedengarannya.

Menentukan durasi. Lease pendek: failover cepat, tapi jeda singkat atau jaringan lambat membuat pemilik sehat kehilangan hak dan leader sering berganti. Lease panjang: failover lambat. Aturan kasar: durasi lebih besar dari beberapa kali jeda terburuk yang wajar, perpanjang sekitar sepertiga durasi.

Saat rancangan ini gagal

• Lease tanpa fencing untuk penulisan yang tidak idempoten. Contoh pengiriman laporan di atas: dua pengiriman.
• Penyimpanan target tidak bisa memeriksa token. Layanan pihak ketiga yang menerima tulisan apa adanya. Kamu perlu kunci idempotensi atau batasan di sisi kamu.
• Mengandalkan jam lokal untuk kedaluwarsa. Pemilik mengira lease berlaku 5 detik lagi padahal di layanan sudah habis. Batas keamanan dan jam monotonik membantu, tapi tidak menutup jeda mendadak.
• Failover otomatis terlalu agresif. Timeout 3 detik dengan beban yang kadang membuat jeda 5 detik menghasilkan leader yang berganti bolak-balik dan tulisan yang hilang di antaranya.
• Layanan koordinasi menjadi titik gagal. Kalau layanannya sendiri kehilangan quorum, tidak ada yang bisa mengambil atau memperpanjang lease, dan semua pemilik harus berhenti dengan aman.

Contoh tandingan: dua instance cron yang sama-sama menjalankan pembersihan cache temp. Tidak ada akibat buruk selain kerja ganda. Memasang layanan lock plus fencing untuk ini lebih rumit daripada masalahnya.

Latihan

Layanan koordinasi memberi lease 15 detik dengan fencing token naik. Worker W1 (token 7) menulis ke penyimpanan file yang menerima parameter token. W1 berhenti 25 detik karena VM dibekukan. W2 mendapat lease (token 8) dan menulis. W1 bangun dan menulis. (1) Apa yang terjadi di penyimpanan kalau ia memeriksa token? (2) Apa yang terjadi kalau penyimpanannya tidak bisa memeriksa token? (3) Apa yang W1 lakukan kalau dia memeriksa lease sebelum menulis?

Lihat pembahasan+

(1) Penyimpanan sudah melihat token 8 dari W2, jadi tulisan W1 dengan token 7 ditolak. W1 menerima error dan harus berhenti, lalu mencoba mendapatkan lease lagi.

(2) Tulisan W1 diterima dan menimpa atau mencampur hasil W2. Lease tidak mencegahnya, karena W1 tidak tahu sudah kehilangan hak. Mitigasi: tulis ke nama file yang menyertakan token lalu pindah lewat operasi atomik bersyarat, atau pakai kunci idempotensi sehingga hasil kedua tidak dihitung, atau ganti penyimpanan dengan yang mendukung penulisan bersyarat.

(3) Pemeriksaan lease hanya mengurangi peluang. Kalau VM dibekukan setelah pemeriksaan dan sebelum tulisan, W1 tetap menulis dengan hak yang sudah habis. Jadi pemeriksaan sebelum menulis bukan pengganti fencing.

Jawaban yang bagus menunjuk titik pengecekan yang benar: di sumber daya, bukan di pemilik.

Terkait

• M08.05 Pahami konsensus menjelaskan layanan yang menerbitkan lease dan token yang monotonik.
• M08.04 Pisahkan waktu dari kausalitas menjelaskan kenapa kedaluwarsa berbasis jam rawan.
• M05.03 membahas pembaruan bersyarat yang bisa dipakai sebagai fencing, dan M10 membahas efek ganda serta consumer idempoten.

Catatan

• Asumsi: layanan koordinasi berbasis konsensus yang bisa menerbitkan nomor naik; penyimpanan target bisa membandingkan nomor.
• Yang tidak dibahas: algoritma lock tertentu (misalnya Redlock), health check lanjutan, dan leader election di layanan terkelola tertentu.
• Durasi lease dalam contoh hanya ilustrasi. Pilih dari jeda terburuk yang kamu ukur.
• Terakhir ditinjau: 26 Oktober 2026.