Fencing Token Menutup Celah Writer dari Lease Kedaluwarsa

Lease terdistribusi dapat kedaluwarsa ketika pemegangnya tidak dapat berjalan. Pemegang tersebut kemudian dapat aktif lagi dengan state lokal yang masih menyatakan bahwa lease dimilikinya, padahal client lain sudah memperoleh lease yang lebih baru. Jika storage atau service yang dilindungi menerima operasi hanya karena client pernah memperoleh lease, dua client dapat memutasi resource yang sama pada titik waktu berbeda.

Fencing token memindahkan pemeriksaan penentu dari kepemilikan lease ke resource yang dilindungi. Setiap akuisisi yang berhasil memperoleh token yang berurutan setelah semua token sebelumnya. Resource mencatat token terbesar yang pernah diterima dan menolak operasi dengan nilai lebih lama. Lease tetap mengoordinasikan akuisisi, sedangkan token membatasi tindakan pemegang lama yang terlambat setelah kembali aktif.

Kedaluwarsa lease tidak membatalkan kode yang sudah berjalan

Anggap client A memperoleh lease dengan masa berlaku sepuluh detik. Client membaca shared state, lalu berhenti berjalan cukup lama hingga lease kedaluwarsa. Jeda ini dapat berasal dari suspensi proses, penjadwalan runtime, tekanan pada host, event stop-the-world yang panjang, atau putusnya konektivitas antara client dan lease service.

Client B dapat memperoleh lease setelah masa berlaku berakhir dan mulai melakukan pekerjaan yang valid. Akuisisi oleh B tidak menghapus memori A, membatalkan request storage yang sudah masuk antrean, atau memaksa proses A berhenti. Saat A kembali berjalan, control flow lokalnya dapat berlanjut dari titik yang dibuat selama interval lease lama.

Inilah celah stale writer. Lease service dapat menyatakan bahwa A tidak lagi memiliki lease, tetapi fakta tersebut tidak berdampak pada resource terpisah kecuali resource mempunyai mekanisme yang membuat otoritas lama tidak dapat dipakai.

Memperpanjang durasi lease hanya mengubah jendela waktu, bukan model otoritas. Renewal juga tidak dapat menjamin safety jika client tetap melanjutkan operasi saat hasil renewal terlambat atau ambigu. Pemeriksaan clock di sisi client memiliki batas yang sama: resource yang dilindungi tidak dapat menyimpulkan otoritas saat ini dari pemeriksaan yang dilakukan lebih awal di proses lain.

Token berurutan membuat otoritas terlihat pada batas resource

Skema fencing memberikan token yang meningkat secara monotonik pada setiap akuisisi lease yang berhasil. Misalkan A menerima token 41 dan kemudian B menerima token 42. Setiap mutasi yang dikirim ke resource membawa token dari akuisisi tersebut.

Resource menerapkan aturan urutan sederhana:

if request.token < highest_accepted_token:
    reject request
else:
    apply request
    highest_accepted_token = request.token

Jika operasi B dengan token 42 tiba lebih dahulu, operasi A yang datang kemudian dengan token 41 ditolak. Resource tidak perlu bertanya kepada lease service apakah lease A telah kedaluwarsa. Resource hanya memerlukan state yang durable atau tersinkronisasi secara tepat untuk token terbesar yang relevan bagi resource tersebut.

Urutan token harus sesuai dengan urutan akuisisi. Identifier acak dapat membedakan instance lease, tetapi pemeriksaan kesamaan saja tidak dapat menentukan lease yang lebih baru. Karena itu UUID menyediakan identitas, bukan urutan fencing, kecuali ada mekanisme pengurutan otoritatif lain yang menyertainya.

Pembuatan token dan enforcement resource membentuk satu kontrak safety

Counter pada lease service hanya berguna jika akuisisi yang berhasil tidak memperoleh nilai yang mundur atau bertabrakan sehingga merusak urutan yang dibutuhkan. Mekanismenya dapat berupa transactional sequence, revision berbasis consensus, atau sumber lain dengan semantik terdokumentasi yang menyediakan urutan monotonik yang diperlukan.

Resource yang dilindungi juga harus menerapkan perbandingan secara atomik bersama mutasi yang dijaganya. Pemeriksaan yang diikuti write terpisah dapat membentuk race baru:

read highest token -> 41
accept token 42
concurrent request accepts token 43
write data for token 42

Jika validasi token dan mutasi yang dilindungi tidak diserialisasi melalui transaction, lock, conditional write, atau primitive setara yang sesuai, operasi lebih lama dapat terlihat setelah operasi yang lebih baru. Fencing bukan properti dari format token. Fencing adalah protokol yang mencakup penerbitan token dan batas mutasi.

Cakupan state yang disimpan juga penting. Satu watermark token global dapat membuat resource yang tidak berkaitan ikut terserialisasi. Watermark per objek dapat memberi isolasi lebih halus selama setiap mutasi untuk objek tersebut melewati aturan urutan yang sama. Cakupan yang tepat mengikuti batas kepemilikan yang hendak dilindungi oleh lease.

Fencing tidak membuat side effect arbitrer dapat dibatalkan

Sebagian target tidak dapat menolak pekerjaan lama. Email yang sudah diserahkan ke server eksternal, aktuator fisik yang sudah dipicu, atau endpoint lama tanpa semantik conditional mutation tidak dapat menerapkan perbandingan fencing secara retroaktif. Dalam kondisi tersebut, fencing token pada database upstream dapat melindungi state database sementara side effect eksternal tetap berada di luar batas safety itu.

Sistem kadang dapat menempatkan perantara yang dapat melakukan enforcement di depan efek tersebut. Sebagai contoh, worker dapat menulis command ke transactional outbox yang row-nya membawa fencing token saat ini, sementara satu komponen downstream memvalidasi urutan sebelum dispatch. Pendekatan ini mengubah arsitektur; pendekatan tersebut tidak memberikan semantik fencing kepada interface yang memang tidak memilikinya.

Perbedaan ini juga memisahkan fencing dari deduplikasi. Idempotency key menjawab apakah pengiriman berulang mewakili logical request yang sama. Fencing token menjawab apakah otoritas caller lebih lama daripada otoritas yang sudah diamati resource. Stale writer dapat mengirim request hanya sekali dan tetap harus ditolak.

Failover harus mempertahankan sumber urutan

Counter fencing yang kembali ke nilai awal setelah restart dapat menerima otoritas lama. Jika client lama masih menyimpan token 900, lalu lease service pengganti mulai lagi dari token 1, perbandingan numerik tidak lagi mewakili urutan akuisisi. Masalah yang sama muncul jika replica lease service independen menerbitkan sequence yang tumpang tindih tanpa koordinasi.

Sumber urutan karena itu menjadi bagian dari failure model. Semantik persistence dan failover-nya harus memastikan token yang diterbitkan setelah recovery tetap berada setelah token yang mungkin masih tersimpan pada client atau queue yang terlambat. Sebagian sistem memakai consensus log index atau storage revision yang sudah tersedia untuk tujuan ini, sehingga tidak memerlukan counter terpisah tetapi tetap mempunyai urutan otoritatif.

Lebar integer juga merupakan batas konkret. Counter dengan lebar tetap tidak boleh wrap selama token lama masih dapat terlihat. Desain praktis biasanya memilih rentang yang cukup besar sehingga wraparound berada di luar umur sistem, tetapi argumen safety tetap bergantung pada asumsi tersebut, bukan sekadar pada istilah “monotonik”.

Resource, bukan pemegang lease, menutup celah stale writer

Kepemilikan lease merupakan koordinasi temporal. Fencing mengubah epoch kepemilikan yang berurutan menjadi nilai yang dapat dibandingkan oleh resource yang dilindungi. Perbedaan ini menjadi penting saat proses dapat berhenti melewati masa berlaku lease lalu kembali aktif, sebab kedaluwarsa hanya mengubah state pada lease service tanpa menghapus pekerjaan yang sudah berada di tempat lain.

Batas akhirnya dapat dinyatakan secara presisi: penerbitan token harus mempertahankan urutan akuisisi, setiap mutasi yang dilindungi harus membawa token, dan resource harus menolak nilai yang lebih lama daripada otoritas terbesar yang pernah diterimanya. Jika salah satu kondisi itu tidak ada, lease masih dapat mengurangi pekerjaan konkuren, tetapi lease sendiri tidak dapat mencegah pemegang lama yang terlambat memutasi resource.