⚡ÖZET VE TEKNİK CEVAP
Dağıtık sistemlerdeki en büyük yanılgı, 'bir dağıtık kilit tutmanın depolama alanına özel yazma garantisi sağladığına' inanmaktır. Gerçek dünyada İstemci 1, 10 saniyelik bir dağıtık kilit alır ve yazma hazırlığına başlar. Tam bu sırada İstemci 1'de 15 saniyelik bir Stop-the-World Garbage Collection duraklaması veya sanallaştırma donması yaşanır. İstemci 1 donmuşken 10 saniyelik kilit süresi dolar. Kilit servisi kilidi İstemci 2'ye devreder; İstemci 2 yazmasını yapıp işlemi bitirir. Ardından İstemci 1 donmadan uyanır: Kendisini hala kilidin sahibi zannederek eski yazmasını diske basar; İstemci 2'nin yeni verisinin üzerine yazar ve veritabanını bozar. Martin Kleppmann, Fencing Token olmadan dağıtık kilitlerin depolamayı koruyamayacağını kanıtlamıştır: Kilit servisi her kilitle birlikte sürekli artan bir sayı (v=33, 34, 35) üretir. Veritabanı her yazmada bu token'ı kontrol eder (WHERE token >= last_seen); İstemci 2 v=34 ile yazdığı için, uyandıktan sonra v=33 ile gelen İstemci 1'in bayat yazmasını anında reddeder.
Mühendislik El Kitabı & Mekanizma
6 Boyutlu Mimari Analiz⚙️1. Temel Çalışma Mekanizması
Mekanizma🎯2. Doğru Kullanım Senaryosu
Kapsam⚠️3. Prodüksiyon Arıza Modları
Kritik Risk📡4. Teşhis ve Telemetri Sinyalleri
Metrikler🛡️5. Önleme ve Mimari Bariyerler
Bariyerler⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimVaka İncelemesi (TinyCTO Saha Örneği)
Bir video işleme sistemi, S3'e aynı anda tek bir sunucunun video yazmasını sağlamak için dağıtık kilit kullanıyordu. Sunucu 1 kilidi aldı ancak 40 saniyelik bir Java GC donması yaşadı. Kilit zaman aşımına uğradı, Sunucu 2 kilidi alıp 4K videoyu render etti ve S3'e kaydetti. Sunucu 1 donmadan uyanınca, elindeki yarım kalmış 720p taslağı Sunucu 2'nin 4K videosunun üzerine yazarak dosyayı bozdu. Ekip etcd'den monotonik fencing token aldı ve S3 koşullu yazmasını açtı. Sunucu 1 uyandığında attığı istek S3 tarafından 'Eski Token' gerekçesiyle anında reddedildi ve video bozulması tamamen engellendi.
İnteraktif Konsept Alıştırmaları
2 Alıştırmaİstemci tarafındaki bir dağıtık kilit, GC donması (Garbage Collection pause) sırasında paylaşımlı depolamayı neden koruyamaz?
Bir Fencing Token bayat yazma (stale write) problemini nasıl çözer?
Dağıtık Kilit Geçersiz Kılma: Fencing Token'ları ve Asenkron Depolama Kiralamaları — Sıkça Sorulan Sorular
Redis Redlock algoritmasının resmi eleştirisini yayınlayıp fencing token gerekliliğini kim kanıtlamıştır?
Martin Kleppmann (Cambridge Üniversitesi / Designing Data-Intensive Applications yazarı) meşhur 'How to do distributed locking' makalesinde.
Redis monotonik olarak artan fencing token'ları üretebilir mi?
Evet, kilit alma script'i içinde atomik `INCR` komutuyla üretilebilir; ancak etcd veya ZooKeeper gibi uzlaşma sistemleri ağ bölünmelerinde çok daha güçlü serileştirilebilirlik garantisi sunar.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸
Distributed locks without fencing tokens CANNOT protect shared storage from corruption.
- ▸
GC pauses, OS thread starvation, and VM freezes cause lock leases to expire silently.
- ▸
Fencing tokens provide monotonically increasing version numbers (100 o 101 o 102).
- ▸
Storage MUST enforce conditional check-and-set guards (
WHERE token >= last_seen).
Yaygın Yanılgılar
- ✗
Yanılgı: A distributed lock with a long TTL (e.g. 5 minutes) makes fencing tokens unnecessary (Gerçek: Pauses and network splits can exceed any arbitrary timeout).
- ✗
Yanılgı: Redlock guarantees absolute safety without storage-side checks (Gerçek: Storage must validate fencing tokens to prevent split-brain writes).
Karar Kılavuzu & Önceliklendirme
Incorporate a monotonic fencing token column into every shared database entity guarded by locks. Use etcd or ZooKeeper linearizable revisions for distributed leader elections and leases.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL_DOCUMENTATION]How to do Distributed Locking: Martin Kleppmann on Fencing Tokens— Martin Kleppmann (University of Cambridge)