Dağıtık sistemlerde en büyük problemlerden biri şudur:

Birden fazla sunucu aynı kaynağı aynı anda değiştirmeye çalıştığında veri tutarsızlığı oluşur.

İçindekilerListeyi göstermek için tıklayın

Bu duruma race condition denir. İşte distributed lock mekanizmaları, bu durumların önüne geçmek için vardır.

Aşağıdaki örneği düşün:

• 3 farklı backend sunucusu var (Server A, B, C)

• Hepsi aynı anda bir stok bilgisini güncellemek istiyor

• Eğer lock kullanılmazsa:

  • Stok sayısı yanlış hesaplanır

  • Aynı ürün birden fazla kişiye satılabilir

  • Veritabanında çakışmalar olur

Distributed lock mekanizmaları:

• Kaynağı “tek bir işlemciye” tahsis eder

• Diğerlerini sıraya sokar

• İş bitince kilidi bırakır

Şimdi bu mekanizmaların nasıl çalıştığını anlatmaya başlıcam hazırız.

1) Neden Distributed Lock’a İhtiyaç Var?

 Tek sunuculu sistemlerde:

• JVM içi lock

• Python threading.Lock

• MySQL row-level lock

yeterlidir.

Ama dağıtık sistemlerde:

• Bir işlem birden çok sunucuda çalışabilir

• Aynı anda çalışmaları mümkün ve tehlikelidir

Örnek bir problem:

Örnek Problem: Kredi başvurusu onay sistemi

3 farklı API sunucusu aynı SMS kodunu doğrulayıp kullanıcıya 3 farklı kredi oluşturabilir.

Bu hem finansal hem güvenlik açısından büyük bir sıkıntıdır.

Distributed lock burada devreye girer.

2) Distributed Lock Türleri

Dağıtık kilitleme çeşitli yöntemlerle yapılabilir.

A) Redis Üzerinden Lock (Redlock)

B) Zookeeper Üzerinden Lock

C) Etcd Üzerinden Distributed Mutex

D) Database Üzerinden Lock (en zayıf yöntem)

Aşağıda hepsini örneklerle detaylandırıyorum.

A) Redis Distributed Lock (Redlock Algoritması)

Redis, özellikle performans isteyen sistemlerde tercih edilir.
Ana amaç:

Anahtar set edildiğinde lock alınır, süre dolunca veya işlem bitince lock salınır.

 Temel kullanım logic:

• NX: Anahtar yoksa oluştur

• PX: Süreli (expire time)

• 30000: 30 saniye kilit süresi

• unique_id: Kilidi alan sunucunun kendine özgü ID’si

 Lock alma:

Lock bırakma:

Redis Lua script ile:

 Avantajlar:

• Çok hızlı

• En yoğun yükte bile performans kaybı minimal

• Basit mantık

 Dezavantaj:

• Tek Redis node kullanılmamalı

• Redlock eleştiriliyor (teorik olarak %100 güvenli değil)

B) Zookeeper Lock

Zookeeper daha “güvenlik odaklı” distributed lock yöntemidir.

Mantık:

• Her lock denemesi için sıralı bir node oluşturulur

• En küçük numaraya sahip node lock sahibidir

• İş bitince node silinir

 Örnek node yapısı:

0001 kilidi alır.

Watch mekanizması

0001 silinirse 0002 otomatik olarak lock’ı devralır.

 Avantajlar

• Çok güvenilir

• Failover güçlü

• Seçim algoritması doğrudan içinde var

 Dezavantajlar

• Redis’ten çok daha yavaş

• Kurulumu daha zor

C) Etcd Dağıtık Mutex

Etcd, Kubernetes’in kendisinde kullandığı dağıtık KV store’dur.

 Lease mantığıyla çalışır:

• Bir key oluşturulur

• Lease ID verilir

• Lease ayakta olduğu sürece lock geçerlidir

• Lease düşerse lock otomatik çözülür

 Kod mantığı:

(Pseudocode)

 Avantajlar:

• Çok stabil

• Kubernetes ile doğal uyum

• Leader election için hazır yapı

D) Database locking

MySQL, PostgreSQL gibi sistemlerde:

Pessimistic lock:

Optimistic lock:

✔ Basittir
✔ Ek yazılım gerektirmez

❌ Ama yüksek yükte çökebilir
❌ Ölçeklenmez

3) Distributed Lock Ne Zaman Kullanılır?

• Stok kontrolü

• Hesap bakiyesi güncelleme

• Ödeme sistemleri

• Kredi/başvuru onay süreçleri

• Oyunlarda eşzamanlı obje erişimi

• Tek seferlik job çalıştırma (Cron deduplication)

4) Hangi Sistem Ne Zaman Seçilmeli?

5) En Basit Gerçek Hayat Örneği

 Stok yönetimi

3 API sunucusu aynı anda şöyle istekte bulunuyor:

Hepsi stok = 2 olarak okuyor.

Kilit olmasa:

• A → stok 1

• B → stok 1

• C → stok 1

Toplamda 3 satılır.

Lock ile:

1. A lock alır → iş yapar → bırakır

2. B lock alır → iş yapar → bırakır

3. C lock alır → iş yapar → bırakır

Problem çözülür.

6) Hatalı Lock Senaryosu (Çok Önemli)

Eğer expire süresi yanlış ayarlanırsa:

❌ İşlem uzun sürer → lock otomatik düşer
❌ Başkası lock alır
❌ Aynı veri iki kez işlenir

Bu yüzden süre belirlerken:

• İşlem süresini tahmini hesapla

• Lease/renew mekanizması kullan

7) Sonuç

Distributed lock mekanizmaları modern yazılımın temel taşlarından biridir.
Doğru yapı kullanılırsa:

• Veri tutarsızlığı olmaz

• İşlem çakışmaları önlenir

• Sistem kararlılığı artar

Yanlış yapı kullanılırsa:

• Deadlock

• Veri kaybı

• Çifte işlem

• Performans çökmesi

gibi kritik hatalar oluşabilir.