Cara Mengimplementasikan Distributed Locking (2016)

Mengimplementasikan kunci terdistribusi

• Menemukan algoritme Redlock di situs web Redis, yang mengklaim mengimplementasikan kunci terdistribusi yang toleran terhadap kegagalan di atas Redis.
• Sudah ada beberapa implementasi independen untuk Redlock, dan karena mungkin ada orang yang bergantung pada algoritme ini, penulis memutuskan untuk membagikan catatannya.
• Redis berguna saat berbagi data yang sementara dan cepat berubah antar server, tetapi ada kekhawatiran ketika diperluas ke ranah pengelolaan data yang membutuhkan konsistensi kuat dan durabilitas.

Tujuan dari kunci

• Kunci berperan memastikan hanya satu dari beberapa node yang menjalankan tugas tertentu.
• Jika kunci digunakan demi efisiensi, menggunakan satu instance Redis saja mungkin lebih baik.
• Jika kunci digunakan demi ketepatan, Redlock tidak cocok.

Melindungi sumber daya dengan kunci

• Kunci dalam sistem terdistribusi berbeda dari mutex dalam aplikasi multithread.
• Mencegah klien lain melakukan pekerjaan yang sama pada saat klien membaca file, memodifikasinya, lalu menuliskannya kembali.

Mengimplementasikan kunci yang aman melalui fencing

• Kunci yang aman dapat diimplementasikan dengan menggunakan fencing token dan menyertakannya dalam permintaan penulisan.
• Redlock tidak aman karena tidak memiliki kemampuan untuk menghasilkan fencing token.

Menggunakan waktu untuk konsensus

• Tidak seperti algoritme dalam model asinkron, Redlock sangat banyak bergantung pada asumsi tentang waktu.
• Jika jam sistem bekerja secara tidak normal, masa berlaku kunci bisa berakhir lebih cepat atau lebih lambat dari yang diperkirakan.

Merusak asumsi waktu Redlock

• Redlock mengasumsikan model sistem sinkron, dan hanya bekerja dengan benar ketika latensi jaringan, jeda proses, dan kesalahan jam berada dalam batas tertentu.
• Kasus seperti insiden penundaan paket 90 detik di GitHub dapat mengancam keamanan Redlock.

Kesimpulan

• Redlock terlalu berat untuk kunci yang dioptimalkan demi efisiensi, dan tidak cukup aman untuk situasi yang menuntut ketepatan.
• Jika memerlukan kunci demi ketepatan, lebih baik menggunakan sistem konsensus yang tepat seperti ZooKeeper.

Ringkasan GN⁺

• Algoritme Redlock menawarkan diskusi penting tentang implementasi kunci dalam sistem terdistribusi.
• Artikel ini menyoroti masalah asumsi waktu dan keamanan dalam sistem terdistribusi, serta menjelaskan pentingnya implementasi kunci yang benar.
• Merekomendasikan sistem alternatif seperti ZooKeeper, dan membantu memahami kompleksitas sistem terdistribusi.

[GN⁺]

Opini Hacker News

• Saya pernah mengimplementasikan kunci terdistribusi menggunakan Temporal, dan sejauh ini berjalan dengan baik. Dengan memanfaatkan fitur Temporal, implementasi kunci terdistribusi menjadi sederhana
• Saya meninggalkan komentar di blog bahwa ada poin penting dari algoritme yang terlewat, dan karena itu saya menunjukkan bahwa penolakan terhadap algoritme tersebut bertumpu pada titik lemahnya
• Dengan komputer dan API modern, kita bisa mengandalkan perkiraan waktu tunggu; jeda GC terbatas dan jam monotonic berfungsi. Ini adalah asumsi yang dapat diterima
• Mengkritik mekanisme pelepasan otomatis adalah persoalan yang berbeda dari mengkritik tujuan algoritme dan model sistemnya
• Redlock telah berhasil digunakan dalam berbagai kasus penggunaan, dan jika timeout diatur dengan tepat, sulit memicu race condition. Menetapkan timeout yang terlalu kecil adalah kesalahan desain
• Saya sedang memperbarui pengetahuan tentang low-level dan algoritme, dan ingin membuat sesuatu untuk bersenang-senang, tetapi sebagian besar materi yang ada hanya setingkat mainan atau sangat rumit
• Saya mengimplementasikan kunci terdistribusi menggunakan PostgreSQL: memulai transaksi, mengambil advisory lock, lalu mempertahankan status terkunci sampai transaksi dilepas
• Saya sadar bahwa saya tidak memeriksa status koneksi database, jadi jika pekerjaannya bukan terkait database, mungkin saja kuncinya sudah hilang
• Saya mengimplementasikan kunci terdistribusi menggunakan Deno dan Deno KV, yang berbasis FoundationDB
• Saya sempat meninjau Redis, tetapi menyelesaikan masalah ketepatan dengan menggunakan PostgreSQL dan mengubah permintaan menjadi operasi SET
• Banyak engineer tidak terlalu memedulikan masalah ketepatan, padahal ada edge case di mana pesan bisa hilang atau urutannya menjadi salah
• Menetapkan timeout pada kunci adalah ide yang baik, dan jika klien crash, OS atau supervisor akan melepaskan kunci tersebut
• Jika kunci tidak diperlukan, integritas data bisa dijaga dengan menggunakan version token. Nilai unik seperti UUID dapat digunakan