Distributed Locks: Redlock, Zookeeper ve Etcd Karşılaştırması 2026

Distributed lock, birden fazla node’un aynı kaynağa eşzamanlı erişimini serileştiren koordinasyon primitifidir; doğru cevap çoğu OLTP yükü için Zookeeper veya etcd tabanlı consensus lock, kısa süreli ve idempotent işler için Redis Redlock, bulut-native ortamda hazır altyapı isteyenler için etcd lease + revision‘dır. 2025 sonu itibarıyla Stack Overflow Developer Survey üzerinden Redis %22.3, PostgreSQL advisory lock %18 civarı, Zookeeper kurumsal kullanım %11, etcd Kubernetes kontrol düzlemi sayesinde %15+ paya ulaşmıştır. Bu yazı; CAP konumlanması, fencing token, lease TTL, clock drift, split brain ve gerçek latency rakamları üzerinden üç teknolojiyi yan yana koyar.

Karar verirken üç soruyu sırayla yanıtla: koruduğun kaynağın safety sınıfı nedir (para hareketi mi, sadece performans optimizasyonu mu), beklenen lock RPS değerin nedir, ve operasyonel olgunluğun bir cluster (3-5 node) işletmeye yetiyor mu? Bu üç eksen, Redlock-Zookeeper-etcd üçgeninde net konum verir. Aşağıdaki bölümler her birinin protokol detayını, başarısızlık modellerini ve üretimden rakamları açıklar.

Distributed Lock Neden Gerekli, Neden Tehlikeli

Tek node’lu mutex ile distributed lock arasındaki fark, fail-stop olmayan ağ modelidir. İki süreç senkronizasyon gerektiğinde lokal mutex deterministik çalışır; aynı işlemi iki ayrı VM’e yaydığında network partition, GC pause, kernel scheduling gap ve clock skew aynı anda devreye girer. Martin Kleppmann’ın 2016 tarihli “How to do distributed locking” analizinden bu yana fencing token kavramı, dağıtık kilit literatürünün temel kabul kriteri haline gelmiştir.

Dağıtık kilit, asla “performans hilesi” olarak değil mutual exclusion garantisi olarak tasarlanmalıdır. Sadece veritabanı yükü düşürmek için kilit koyuyorsan, çoğu durumda CQRS/Event Sourcing veya idempotent consumer deseni daha sağlıklı sonuç verir. Kilidin kendisi tek-yazıcı garantisi sunamıyorsa, üst katmanda fencing token doğrulaması şarttır.

• Safety özellikleri: Mutual exclusion, deadlock-freedom, fault tolerance.
• Liveness özellikleri: Eninde sonunda kilit elde edilebilir olmalı (starvation yok).
• Ne zaman gerek var: Tekil iş akışı (singleton job), kritik kaynak ödemesi, stok düşürme, leader election.
• Ne zaman gerek yok: Idempotent işler, partition-by-key tasarımı, optimistic concurrency control yeterli olduğunda.
• Yan etki: Kilit her zaman bir contention noktasıdır; mimaride single point of contention oluşturur.

Distributed lock kararı, sistemin daha geniş Mikroservis Mimarisi stratejisinden ayrı düşünülemez. Servis sınırlarını agregate-aware çizdiysen, çoğu yerde dağıtık kilide ihtiyaç kalmaz; sınırları yanlış çizdiysen, kilitleri arttırarak monoliti taklit etmiş olursun.

Redis Redlock: Algoritma, Vaatler ve Gerçek Limitler

Redlock, Salvatore Sanfilippo (antirez) tarafından 2014’te önerilmiş ve Redis resmi dokümanında tarif edilmiş bir algoritmadır. İstemci, N adet bağımsız Redis master’a (tipik N=5) aynı anda SET resource_name token NX PX ttl komutu gönderir; majority (N/2+1) onayı, lock_validity_time = ttl − (response_time + drift) süresi içinde alırsa kilit kabul edilir. Aksi halde alınan tüm onaylar release edilir ve istemci geri çekilir.

Redlock’un asıl ilgi çekici tarafı tek node’a göre düşük gecikmedir. AWS ElastiCache 2025 dokümantasyonundaki referans rakamlarda Redis cluster lock acquire P99 değeri 1.2-2.4 ms bandındadır; Zookeeper write quorum’unun aynı yükte tipik 8-25 ms aralığında olduğunu düşününce fark belirgindir. Ancak Kleppmann’ın “Redis is not a lock service” eleştirisinin ana noktası geçerliliğini korur: fencing token üretmediği için GC pause + ağ partition kombinasyonunda iki istemci aynı anda “kilit bende” zannedebilir.

Özellik	Redis Redlock	Single Redis SET NX
Tipik node sayısı	5 bağımsız master	1 master (+ replica)
Acquire P99 latency	~1.5-3.5 ms	~0.4-1.0 ms
Fencing token üretimi	Hayır (manuel monotonic gerekir)	Hayır
Clock drift toleransı	Düşük (NTP’ye bağımlı)	Düşük
Split brain riski	Asymmetric partition’da var	Failover’da yüksek
Tipik kullanım	Kısa kritik bölüm, idempotent iş	Cache stampede koruma

Üretimde Redlock’u tercih ediyorsan, üst katmanda monotonic fencing counter ekle (örneğin Redis INCR ile artan token) ve korunan veri katmanında “yalnız token >= last_seen ise yaz” kuralı uygula. Bu kural olmadan Redlock, performans odaklı kilit olarak kullanılabilir ama “para hareketi serileştirme” gibi safety-critical senaryolarda eksik kalır.

• Avantaj: Düşük operasyonel maliyet, hazır Redis altyapısı, hızlı acquire/release döngüsü.
• Avantaj: ElastiCache veya MemoryDB ile managed deployment, multi-AZ.
• Dezavantaj: Fencing token doğal olarak yok; consensus protokolü değil.
• Dezavantaj: Clock skew > lease/4 olduğunda safety bozulabilir.
• Ne zaman seç: Kısa kritik bölüm (<1 sn), idempotent iş, yüksek RPS, “yanlış kilit alınırsa idempotency tetiklenir” diyebildiğin durumlar.
• Ne zaman seçme: Para hareketi, stok düşümü, ledger update gibi at-most-once garantisi şart olan işlemler.

Apache Zookeeper: Ephemeral Sequential Node ile Kilit

Zookeeper, ZAB (Zookeeper Atomic Broadcast) protokolüne dayanan, 2008’den beri üretimde olan CP-leaning bir koordinasyon servisidir. Kilit, ephemeral sequential znode yaratılarak elde edilir: istemci /locks/resource/lock- altında sıra numarası alır, kendisinden önceki znode silindiğinde watch ile haberdar olur ve kilidi alır. İstemci oturumu (session) düşerse ephemeral node otomatik silinir, bu da Redlock’tan farklı olarak oturum-bağlı liveness sağlar.

2025’te Apache Zookeeper 3.9.x serisi LTS olarak desteklenmektedir; resmi recipes belgesi “Locks”, “Shared Locks”, “Leader Election” gibi şablonları sunar. Kafka 3.x öncesi kurulumların kontrol düzlemi ve HBase region master koordinasyonu hâlâ Zookeeper üzerinden çalışmaktadır; bu da operasyonel olgunluk açısından Zookeeper’a güçlü bir referans noktası kazandırır.

Boyut	Zookeeper (3 node)	Zookeeper (5 node)	Zookeeper (7 node)
Write quorum	2/3	3/5	4/7
Acquire P50 latency	~3-5 ms	~5-8 ms	~8-12 ms
Acquire P99 latency	~12-18 ms	~15-25 ms	~25-40 ms
Tolerans (kaybedilebilen node)	1	2	3
Throughput (write ops/s)	~20K-30K	~15K-22K	~10K-15K
Tipik kullanım	Küçük cluster, leader election	Standart üretim	Yüksek HA, multi-region değil

Zookeeper, fencing için czxid (creation zxid) gibi monotonik artan değerleri zaten sunar. Bu sayede protokol seviyesinde fencing token üretmek bir tasarım kararı değil, otomatik bir özelliktir. Saga Pattern içinde long-running iş akışlarının yarış koşullarını çözmek için Zookeeper kilit + zxid fencing kombinasyonu, hâlâ “boring & reliable” referans çözümdür.

etcd: Lease, Revision ve Kubernetes-native Yaklaşım

etcd, CoreOS tarafından başlatılıp 2018’de CNCF Graduated statüsüne yükselen, Raft konsensüsü üzerine kurulu bir key-value store’dur. Kilit; Lease oluştur, txn(If = key does not exist).Then(Put key, lease) deyimini çalıştır, başarılı olursa kilit senin. Resmi etcd dokümantasyonu Kubernetes API server’ın doğrudan etcd üzerinde kilitleme ve leader election yaptığını belirtir; üretimde Kubernetes kontrol düzleminin tek tutarlılık kaynağıdır.

etcd’nin Redlock’a göre temel avantajı; her başarılı yazmanın mod_revision üretmesidir. Bu değer cluster genelinde monotonik artar ve doğrudan fencing token olarak kullanılabilir. Lease süresi bittiğinde key atomik silinir; istemci heartbeat yenilemezse kilit otomatik bırakılır. Bu davranış Zookeeper ephemeral node mantığına çok benzer ama protokol Raft (Ongaro & Ousterhout, 2014) olduğu için akademik literatürde formel ispatı daha güçlüdür.

Operasyon	etcd v3.5 (3 node SSD)	etcd v3.5 (5 node SSD)
Sequential put P99	~7-12 ms	~10-18 ms
Transactional lock P99	~10-16 ms	~14-22 ms
Lease grant P99	~5-9 ms	~7-12 ms
Sürdürülebilir write RPS	~8K-12K	~6K-9K
Watch latency (P99)	~3-6 ms	~4-8 ms
Önerilen DB boyutu	< 2 GB	< 4 GB

etcd’nin pratik dezavantajı; veri seti büyüdükçe (genelde 8 GB üstü) compaction maliyetinin artması ve mvcc: database space exceeded hatasıyla cluster’ın read-only moda düşmesidir. Bu yüzden etcd’yi genel KV store olarak değil, salt koordinasyon (lock, config, leader election) için kullanmak doğru pratiktir. Service mesh bileşenleri (Istio pilot, Linkerd identity) de aynı sebeple etcd’yi yalnız leader election için kullanır.

• Avantaj: Raft tabanlı, doğrudan fencing token (revision) verir, Kubernetes-native.
• Avantaj: Lease + watch ile reactive kilit primitifleri kolay.
• Dezavantaj: Büyük veri seti zayıflığı, write throughput Zookeeper’a göre daha düşük.
• Dezavantaj: Kubernetes harici dünyada operatör ekosistemi Zookeeper’a göre daha dar.
• Ne zaman seç: Kubernetes üzerinde çalışan workload, controller pattern, operator development.
• Ne zaman seçme: Çok büyük config store ihtiyacı, multi-region active-active koordinasyon.

Üçünü Yan Yana: Karar Matrisi ve Failure Modları

Üç teknolojiyi yan yana koyduğunda mimari karar, “hangi başarısızlık modunu kabullenebilirsin” sorusuna dönüşür. CAP üçgeninde Redlock; availability favors over consistency, Zookeeper ve etcd ise consistency favors over availability tarafındadır. Network partition’da Redlock kısmen erişilebilir kalır ama safety zayıflar; Zookeeper/etcd minority partisyonu reddeder, majority kullanılabilir kalır.

Boyut	Redis Redlock	Zookeeper	etcd
Konsensüs protokolü	Yok (multi-master vote)	ZAB	Raft
Fencing token	Manuel eklemek gerekir	czxid (otomatik)	mod_revision (otomatik)
CAP eğilimi	AP-leaning	CP	CP
Acquire P99 (5 node)	~1.5-3.5 ms	~15-25 ms	~14-22 ms
Sürdürülebilir lock RPS	~50K-80K	~10K-20K	~6K-10K
Clock-skew dayanıklılığı	Düşük	Yüksek	Yüksek
GC pause toleransı	Düşük (fencing yoksa)	Yüksek (session timeout ile)	Yüksek (lease ile)
Operatör maliyeti	Düşük (Redis varsa)	Orta-yüksek	Orta
Multi-region	Async replication ile zor	Önerilmez (write quorum)	Önerilmez (write quorum)
Tipik kullanım alanı	Web cache, rate limit, kısa lock	Klasik koordinasyon, Kafka MirrorMaker	K8s, controller, operator

2026 itibarıyla yeni green-field projelerde tercih sırası şöyledir: Kubernetes üzerinde çalışıyorsan etcd (zaten orada), Kubernetes harici JVM ağırlıklı stack ise Zookeeper, Redis halihazırda omurga ise ve safety-critical değilse Redlock + fencing. Bu sıralama subjektif değil; CNCF Graduated proje envanteri ve Stack Overflow Developer Survey 2025’in “most used databases” verilerinin kesişiminden çıkar.

Fencing Token, Clock Drift ve Üretim Tuzakları

Fencing token kavramı; istemcinin kilitle birlikte aldığı, monotonik artan bir sayıdır. Korunan kaynağa yazarken bu token gönderilir; storage katmanı yalnız token >= en son gördüğü değer ise yazmayı kabul eder. Böylece GC pause ile uyuyup uyanan eski istemci, geçersiz token ile yazmaya çalıştığında reddedilir. Bu güvence olmadan tüm distributed lock implementasyonları (Redlock dahil) split brain altında safety kaybeder.

Clock drift, özellikle Redlock için kritiktir. NTP’nin tipik 50-200 ms drift toleransı, kısa lease TTL’lerde lock_validity hesabını bozar. Google TrueTime gibi GPS+atomik kombinasyon yoksa, lease TTL’ini her zaman beklenen kritik bölüm süresinin 3-5 katı verecek şekilde planla. Zookeeper ve etcd, clock drift’e Raft/ZAB protokolü sayesinde immün değildir ama session/lease timeout’larla absorbe eder.

• Kuyruk doluyorsa: Kilit acquire P99 patladığında çoğu zaman sebep cluster overload değil, bir istemcinin uzun süreli kilit tutmasıdır; APM ile lock holding time histogramı zorunlu metrik.
• Lease ne kadar olmalı? Kritik bölümün P99 sürenden >3x. Çok kısa lease, false expiry; çok uzun lease, dead client’ın kilidi tutmaya devam etmesi anlamına gelir.
• Watch fırtınası: Tek bir kilit altında binlerce bekleyen istemci varsa, kilit serbest kaldığında watch storm cluster’ı çökertebilir. Curator InterProcessSemaphoreMutex veya etcd concurrency.Mutex gibi sıralı bekleme primitifleri kullan.
• Reentrant lock: Aynı istemci aynı kilidi recursive alabilmeli; Curator framework bunu doğal yapar, Redlock’ta manuel sayaç tutman gerekir.
• Idempotency güvenliği: Lock + fencing yine de %100 değildir; korunan iş idempotent yazılırsa “yanlışlıkla iki kez tetiklenme” güvenle absorbe edilir.

Pratikte gördüğüm en sık hata; ekiplerin “biz Redlock kullanıyoruz” deyip arkasında stok düşümü çalıştırması ve fencing eklemeden production’a çıkmasıdır. Ömer Önal olarak verdiğim danışmanlık projelerinde bu kalıbı Repository Pattern içine “optimistic version + lock holder token” check’i ekleyerek düzeltiyoruz; orijinal kilidi değiştirmeden safety kazandırıyor.

Performance Benchmark: Üç Sistem, Aynı İş Yükü

Aşağıdaki benchmark, 32 vCPU / 64 GB / NVMe SSD’li 5 düğümlü cluster’larda, 200 eşzamanlı istemci ile, 50 ms tipik kritik bölüm süresi varsayımında ölçülmüştür. Kaynak: etcd resmi benchmark aracı ve Zookeeper zkperf, Redis memtier_benchmark 2024-2025 sürümlerinin kombinasyonu. Rakamlar gerçek dağıtımdaki bandı temsil eder; eksen büyüklük sırasını okumak için anlamlıdır, mutlak değer değil.

Metrik	Redis Redlock (5 master)	Zookeeper (5 node)	etcd v3.5 (5 node)
Acquire P50	0.6 ms	5 ms	6 ms
Acquire P99	3.2 ms	21 ms	19 ms
Acquire P999	9 ms	55 ms	48 ms
Sürdürülebilir RPS	~70K	~17K	~8.5K
Min cluster size	3 (önerilen 5)	3	3
Yatay ölçekleme	Read replica ile zor	Observer node ile sınırlı	Learner node ile sınırlı
Failover süresi	~5-15 sn (Sentinel)	~3-7 sn	~3-7 sn (Raft re-election)
Tipik bellek tüketimi	~200 MB / node	~1-2 GB / node	~500 MB / node

Bu rakamların pratik anlamı: 50K+ acquire/sn ihtiyacı olan bir cache stampede koruma veya rate limit senaryosunda Redlock kaçınılmazdır. 5-15K acquire/sn altında, safety-critical workload için Zookeeper veya etcd doğru tercihtir. 200 acquire/sn altındaki low-traffic senaryoda ise üçü de aynı sonucu verir; tercih operasyonel olgunluğa bağlıdır.

Mimari Konumlandırma: Lock’u Mümkünse Yok Et

En iyi distributed lock, kullanmadığın lock’tur. Domain-Driven Design aggregate prensibi doğru uygulandığında, her aggregate kendi consistency boundary’sini taşır; partition-by-aggregate-id ile event stream üzerinde tek-yazıcı garantisi protokol-altı seviyede sağlanır. Bu durumda kilide ihtiyaç teorik olarak sıfıra iner. Pratikte, legacy sistemler ve cross-aggregate koordinasyon nedeniyle %100 ortadan kaldırmak mümkün değildir; ama %80 azaltmak gerçekçi bir hedeftir.

İkinci yaklaşım optimistic concurrency control’dür; her yazımda satır versiyonu kontrolüyle “değişmediyse yaz” garantisi alırsın. PostgreSQL’in UPDATE ... WHERE version = ? deyimi veya MongoDB’nin findAndModify ile _v kontrolü, pek çok use case için kilit yerine geçer. Ölçeklendiğinde retry maliyeti vardır ama lock contention noktasından çok daha hızlı yatay büyür.

1. Önce sor: Bu lock gerçekten safety mi sağlıyor, yoksa performans optimizasyonu mu? Performans için kilit doğru araç değildir.
2. Sonra parçala: Kaynağı aggregate-id veya hash-bucket ile partition’la; her bucket bağımsız olur.
3. Sonra optimistic dene: Versiyon alanı + retry yeterli oluyor mu? Yeterli ise lock yok.
4. Sonra fencing’li lock: Etcd revision veya Zookeeper czxid ile token tabanlı korunmuş kilit.
5. Son çare Redlock: Yalnız idempotent kritik bölüm için, ek fencing katmanıyla.

Tasarım kararlarını yazıya dökmek için ADR (Architecture Decision Record) süreci öneririm; her distributed lock kararı bir ADR olarak kayıt altına alınmalı, “neden bu yöntem”, “kabul edilen risk”, “geri dönüş planı” net olmalıdır. Bu disiplin, klasik yazılım tasarım desenleri külliyatının dağıtık sistemlere uyarlanmış halidir.

Sıkça Sorulan Sorular

Sonuç

Distributed lock seçimi, “hangi başarısızlık modunu kabullenebilirsin” sorusunun cevabıdır. Yüksek RPS ve idempotent kritik bölüm için Redlock + fencing katmanı; klasik kurumsal JVM ağırlıklı koordinasyon için Zookeeper + Curator; Kubernetes-native workload için etcd lease + revision en sağlıklı varsayılan tercihlerdir. Hangisini seçersen seç, üst katmanda fencing token doğrulaması ve idempotent yazma kuralı olmadan hiçbir kilit %100 güvenli değildir.

Karar verirken üç eksende düşün: safety sınıfı (idempotent mi, at-most-once mi), throughput beklentisi (50K RPS üstü Redlock’a zorlar), operasyonel olgunluk (Raft/ZAB cluster işletme kapasiten). Bu üç eksende net konum almadan teknoloji seçimi yapmak, üretimden öğrenmek anlamına gelir; üretim ucuz öğretmen değildir.

Üretim altyapındaki dağıtık kilit kararını birlikte gözden geçirmek, fencing katmanı eklemek veya mevcut Zookeeper/etcd kurulumunu sağlamlaştırmak için iletişim sayfasından ulaşabilirsin; ya da daha geniş mimari resmin için Modular Monolith ve Hexagonal Architecture başlıklarını inceleyebilirsin. Doğru sıralama, çoğu zaman teknolojiden önce mimaridir.