Cara Kerja ​

Perolehan dan pelepasan lock ​

Ketika klien memperoleh (A) sebuah key, server merespons dengan salah satu dari tiga kemungkinan berikut.

• Pelepasan diproses secara adil dengan FIFO. Ketika pemegang melepaskan (R), lock langsung diserahkan ke yang paling depan dalam antrean — tanpa kompetisi ulang, langsung diberikan bersama token baru.
• lease adalah jaring pengaman. Meskipun klien mati atau lupa melepaskan, setelah waktu lease berlalu, server akan otomatis menarik kembali key tersebut dan dapat menyerahkannya ke penunggu berikutnya. Karena itu, terlepas dari alur pelepasan normal, sebaiknya lease diset cukup longgar, namun tetap dengan nilai yang tidak terlalu lama mengikat resource jika klien mati.
• wait adalah batas atas waktu tunggu perolehan. Jika 0 berarti menunggu tanpa batas, selain itu jika tidak diperoleh dalam waktu (detik) tersebut, server akan menyerah dan merespons dengan T (timeout) — berakhir tanpa grant, sehingga lock tidak akan bocor.

Fencing token ​

token yang disertakan dalam respons A adalah u64 yang selalu bertambah secara monoton untuk grant tersebut. Setiap kali diperoleh, diterbitkan nilai yang lebih besar dari token mana pun sebelumnya. Bahkan saat terjadi failover, node yang baru menjadi active akan melanjutkan dari nilai yang lebih besar dari token maksimum yang diterima lewat replikasi (suksesi) — sehingga token terus bertambah di seluruh cluster.

Jika resource yang ingin dilindungi (akun, file, pesanan, dll.) cukup memvalidasi "apakah token yang dipegang sekarang lebih besar dari token terakhir yang terlihat", maka klien yang terlambat bangun setelah lease kedaluwarsa dapat ditolak aksesnya karena membawa token rendah yang sudah tidak berlaku. Berkat ini, keamanan tetap terjaga meskipun server lock tidak sepenuhnya konsisten di setiap saat.

Perilaku klien ​

Klien-klien resmi secara umum berperilaku sebagai berikut (detail API per bahasa lihat Pustaka).

• Menjaga satu koneksi persisten per alamat dan mengelolanya di background. Jika hanya diberi satu alamat, secara internal dijaga dua koneksi ke node yang sama, sehingga layanan tidak terputus meskipun salah satunya sempat terputus sesaat.
• Memilih koneksi secara round-robin. Node yang koneksinya terputus otomatis dikecualikan, dan percobaan penyambungan ulang dilakukan di background setiap 3 detik.
• Permintaan di-pipeline. Permintaan berikutnya dapat dikirim tanpa menunggu respons, dan urutan respons boleh berbeda dari urutan permintaan — klien membedakan respons mana untuk permintaan mana berdasarkan kombinasi (op, key) yang di-echo kembali. Jika ada beberapa permintaan dengan kombinasi (op, key) yang sama, pencocokan dilakukan sesuai urutan pengiriman.
• Jika koneksi terputus saat mencoba memperoleh, otomatis beralih ke koneksi berikutnya. Jika setelah mencoba sebanyak jumlah koneksi terdaftar tetap tidak ada koneksi yang bisa dipakai, barulah dilaporkan sebagai error.
• Pelepasan dicoba ulang selama 5 detik dengan interval 200ms — agar meski koneksi kebetulan terputus tepat saat pelepasan, lock tidak terus tertahan di server (pada akhirnya lease yang akan menariknya kembali, tetapi ini untuk menyerahkannya ke penunggu lain lebih cepat sebelum itu).

Cluster — tanpa downtime berbasis prioritas ​

• Urutan dalam daftar peers adalah prioritas promosi (paling depan adalah prioritas tertinggi). Di antara node yang hidup, satu dengan prioritas tertinggi menjadi active, sisanya menjadi standby yang menerima replikasi status secara real-time.
• Permintaan klien hanya ditangani oleh active. Klien yang terhubung ke standby akan diarahkan (M) ke alamat active dan berpindah ke sana.
• Active gagal/restart → standby dipromosikan untuk mengambil alih.
• Saat berhenti secara graceful (Ctrl+C), active terlebih dahulu menyerahkan promosi ke penerus (handoff), lalu mengarahkan ulang klien, sehingga kekosongan active diminimalkan.
• Demosi otomatis: jika karena partisi jaringan dan sebagainya dua node menjadi active secara bersamaan, node dengan prioritas lebih rendah akan mendeteksi lawannya dan mundur sendiri menjadi standby (mencegah split-brain permanen).

Metode promosi ini bukan berbasis kuorum (voting mayoritas). Karena itu jumlah node ganjil/genap tidak penting, dan layanan tetap terjaga selama minimal satu node hidup.

Yang perlu diketahui soal konsistensi ​

Karena promosi berbasis prioritas bukanlah konsensus, pada saat partisi jaringan kedua sisi bisa sejenak menjadi active secara bersamaan, dan karena sifat replikasi asinkron, sebagian grant bisa hilang pada momen failover. Artinya, saling mengeksklusi tidak dijamin 100% pada rentang failover/partisi. Jika dibutuhkan jaminan yang kuat, implementasikan agar resource yang dilindungi memvalidasi fencing token yang telah dijelaskan sebelumnya — dengan menolak token lama (lebih kecil), keamanan tetap terjaga meskipun server lock tidak sepenuhnya konsisten.