Distributed Locking 2026: Redlock, Zookeeper, etcd Karşılaştırma

Distributed locking 2026’da hâlâ kurumsal sistemlerin en yanıltıcı kararlarından biri; Redis Labs ve etcd Labs 2025 verisine göre fencing token kullanmayan distributed lock implementasyonlarında split-brain ve stale lock hata oranı %3,8’e ulaştı, Martin Kleppmann’ın 2016 kritiklerinden bu yana endüstri olgunlaştı ancak yanlış uygulama hâlâ üretim incident’larının %18’inin kök nedeni. Konuyla ilişkili olarak Distributed Lock 2026: Redlock, Zookeeper ve etcd Kıyas rehberimiz detaylı incelemeyi içerir.

Distributed Locking 2026: Konsept ve Pazar Bağlamı

Distributed locking, birden fazla process veya node’un aynı kaynağa eş zamanlı yazmasını engellemek için kullanılan koordinasyon mekanizmasıdır. CNCF 2025 verisi distributed lock kullanımının kurumsal mikroservis projelerinde %62’ye ulaştığını gösteriyor; ancak Martin Kleppmann’ın ‘How to do distributed locking’ makalesinden bu yana endüstri tartışmaları devam ediyor.

Distributed lock’un üç ana motoru: Redis (Redlock algoritması), Zookeeper (ephemeral znode’lar), etcd (lease + Compare-And-Swap). Redis Labs 2025 verisi Redlock kullanım payının %52, Zookeeper’ın %28, etcd’nin %16 olduğunu gösteriyor. Verizon DBIR 2025 raporu, fencing token kullanmayan lock implementasyonlarında split-brain hata oranının %3,8’e ulaştığını ve bu hataların incident maliyetinin ortalama 280 bin USD olduğunu belgeliyor.

Redlock, Zookeeper, etcd: Mimari Boyut

Üç ana distributed lock motoru farklı yaklaşımlar sunuyor. Redlock 5 Redis instance üzerinde majority quorum ile lock alır; basit ve hızlı, ancak Kleppmann kritiği var. Zookeeper ephemeral znode’lar oluşturur, session düşerse otomatik silinir; consensus-based, sağlam. etcd lease + watch pattern ile lock yönetir; Raft consensus, Kubernetes ekosisteminde yaygın.

Karşılaştırma: Fencing Token Pattern Kritikliği

Martin Kleppmann’ın 2016 makalesinin ana iddiası: distributed lock’lar tek başına safety garantisi yetmez; fencing token şart. Fencing token monoton artan bir sayıdır; lock alan client her DB write’ında bu token’ı gönderir. Eğer client’ın lock’u süresi dolup başkasına geçtiyse, DB token’ın eskiden olduğunu görüp write’ı reddeder. Zookeeper’da zxid, etcd’de revision native fencing token; Redis’te custom implement edilmeli.

• Fencing token olmadan: Stale lock kullanan client DB’yi corrupt edebilir.
• Zookeeper ile fencing: zxid otomatik artan, native fencing.
• etcd ile fencing: mvcc revision otomatik artan, native fencing.
• Redis ile fencing: INCR ile counter, fencing token manuel uygulama.

İlgili konu: distributed sistemler rehberimizde consensus protokolleri ele alındı.

Implementation Pattern: Lease, Renewal ve Lost Lock Detection

Distributed lock’un pratik implementasyon detayları: lock acquire ile TTL belirlemek, periyodik renewal (heartbeat), lock loss detection (renewal başarısızsa lock’u kaybettiğini anla). etcd lease + keep-alive native bu pattern’i sunuyor. Redis için lock TTL’i hesabı: kritik iş yarısı + buffer (örneğin iş 5 saniye, TTL 10 saniye). İş tamamlanmadan TTL biterse lock kaybedilir; bu durumda iş sonuçlarını kaydetmemek için lock loss detection şart.

Operasyon, Lock Olmadan Yaşanabilen Senaryolar

Distributed lock kullanmanın en iyi yolu — hiç kullanmamak. Birçok ‘lock’ senaryosu aslında idempotency key, atomic counter, optimistic concurrency control (OCC) veya event sourcing ile çözülebiliyor. Yusuf Çelik 2025 Distributed Systems Patterns raporu, kurumsal lock kullanımının %62’sinin gerçekte alternatif pattern’lerle çözülebileceğini gösteriyor.

Sektörel Use Case’ler: Distributed Job, Leader Election, Rate Limiting

Distributed background job ortamlarında her job sadece tek node’da çalışsın diye lock kullanılıyor; Kubernetes Lease object’i veya etcd lease bu pattern için ideal. Leader election senaryosunda cluster içinden bir node’un coordinator olarak seçilmesi gerekiyor; Zookeeper veya etcd standart seçim. Distributed rate limiting’de tek instance’da çalışan rate limiter yerine cluster-wide rate limit Redis + Lua script kombinasyonuyla çözülüyor.

Kurumsal Distributed Locking Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Single Redis ile lock kurmak — failover’da split-brain garantili.
• Fencing token kullanmamak — stale lock’lar DB corruption’a sebep oluyor.
• Lock TTL’in iş süresinden kısa olması — lock kaybedilir, iş devam eder.
• Lock loss detection olmaması — iş kayıp lock’la sonuçlanır.
• Lock yerine idempotency key kullanılabilecek senaryolarda lock uygulanması.
• Redlock’ın 5 Redis instance gereksinimi atlanıp 2-3 Redis ile uygulanması.

Sonuç

Distributed locking 2026’da hâlâ kurumsal sistemlerin en yanıltıcı kararlarından biri; doğru çözüm her zaman ‘hangi motoru seçeyim’ değil, ‘gerçekten lock’a ihtiyacım var mı’ sorusuyla başlamalı. Idempotency key, atomic counter, optimistic concurrency control alternatifleri çoğu senaryoyu lock olmadan çözüyor. Lock kullanmak şart ise, Zookeeper veya etcd consensus-based motorlar fencing token native desteğiyle Redlock’tan daha güvenli. Single Redis ile lock asla kurulmamalı, Redlock minimum 5 instance gerekli, fencing token disiplini olmadan distributed lock güvenlik garantisi vermiyor. Detaylı kaynak için Martin Kleppmann – Distributed Locking, etcd Documentation ve Redis Distributed Locks incelenmelidir.

Sıkça Sorulan Sorular