Distributed Lock: Kilidi Doğru Kurmak

Önce dur: buna gerçekten ihtiyacın var mı?

Dağıtık kilit, elimizde çekiç olunca her şeyin çivi görünmesine iyi bir örnek. Çoğu vakada daha ucuz bir cevap var:

Kural şu: korunacak şey tek bir veritabanı satırıysa kilide gerek yok. Kilit, koruman gereken şey veritabanının dışındaysa anlamlı hale geliyor.

Adım adım: yanlıştan doğruya

Deneme 1 — en masum hali (bozuk)

if (redis.GET("kilit:fatura") == null) {
    redis.SET("kilit:fatura", "1");   // ← arada boşluk var
    isiYap();
    redis.DEL("kilit:fatura");
}

Deneme 2 — atomik alım, ama süresiz (bozuk)

SETNX kilit:fatura 1      # atomik, guzel
# ... is yapiliyor ...
DEL kilit:fatura

Deneme 3 — süre var ama iki komutta (hâlâ bozuk)

SETNX kilit:fatura 1
EXPIRE kilit:fatura 60     # ← ikinci komut

Deneme 4 — doğru alım

token = uuid()                                  # bu kopyaya ozel
SET kilit:fatura <token> NX PX 30000

# NX  -> yoksa yaz (atomik)
# PX  -> 30 saniye sonra kendiliginden silinsin
# token -> "bu kilit benim" diyebilmek icin

Buradaki token hayat kurtarıyor ve bir sonraki bölümün konusu.

Asıl tuzak: kilidi bırakmak

Kilit almayı çoğu ekip doğru yapıyor. Neredeyse hiçbiri bırakmayı doğru yapmıyor. Şu senaryoya bak:

A, B’nin kilidini sildi. Şimdi B ile C aynı anda çalışıyor ve kimsenin haberi yok.

-- Redis Lua: atomik calisir
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

Süre dolarsa ne olacak?

Yukarıdaki tablonun asıl problemi silme değil aslında: A hâlâ çalışıyorken B başladı. Compare-and-delete bunu çözmez, sadece zararı azaltır.

Kısmi çözüm: kilidi tazele

-- her 10 saniyede bir, sadece hala benimse suresini uzat
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
    return 0
end

Gerçek çözüm: fencing token

Bu, dağıtık kilit konusunun en önemli ve en az bilinen parçası. Fikir şu: kilit her verildiğinde artan bir numara da ver. Korunan kaynak, gördüğünden daha küçük numaralı bir yazmayı reddetsin.

-- Redis tarafinda: her kilit alisinda artan sayac
INCR kilit:fatura:sayac        -- A icin 41, B icin 42 doner

-- Yazarken numarayi da gonder:
UPDATE fatura_durumu
   SET son_islem = 'tamam', fence = 42
 WHERE id = 7
   AND fence < 42;             -- ← eski sahibi reddeder

-- A (fence=41) gec uyanip yazmaya kalkarsa:
-- fence < 41 kosulu tutmaz, 0 satir etkilenir, yazamaz.

Güzelliği şurada: A’nın uyanıp uyanmaması, ne kadar geciktiği, kilidin süresinin dolup dolmadığı artık önemli değil. Korunan kaynağın kendisi eski sahibi reddediyor. Kilidin güvenliği artık zamanlamaya bağlı değil.

Bedeli de var: korunan kaynağın böyle bir kontrol yapabiliyor olması gerekiyor. Veritabanında kolay, bir dosya sisteminde veya üçüncü parti bir API’de çoğu zaman mümkün değil. Mümkün değilse en azından bunu bilerek yaşıyorsundur.

Redlock meselesi

Birden fazla Redis düğümüne aynı anda kilit koymayı öneren bir algoritma var ve hakkında uzun bir tartışma yaşandı. Kısaca durum şu: tek Redis düğümü tek nokta arıza demek, ama çok düğüm de saat kaymaları ve duraklamalar nedeniyle tam garanti vermiyor.

Pratik yaklaşımım:

• Verimlilik için kilitliyorsan (aynı işi iki kez yapmayalım, boşuna kaynak harcamayalım) tek Redis düğümü yeter. Nadir bir çakışma sadece israf demek.
• Doğruluk için kilitliyorsan (iki kez olursa para kaybederiz) kilide tek başına güvenme. Fencing token ekle ya da işi idempotent yap.

Bu ayrımı yapmadan “kilit koyduk, güvendeyiz” demek, bu konuda düşülen en pahalı yanılgı.

Redis yerine daha basit üç yol

1. Postgres advisory lock (kullanıyorsan bedava)

-- oturum boyunca tutulur, baglanti kopunca KENDILIGINDEN birakilir
SELECT pg_try_advisory_lock(834721);
-- true  -> kilit bende, ise basla
-- false -> baskasi calisiyor, cik

SELECT pg_advisory_unlock(834721);   -- isin bitince

2. Kilit tablosu (her veritabanında çalışır)

CREATE TABLE kilitler (
  ad          text PRIMARY KEY,
  sahip       text NOT NULL,
  gecerlilik  timestamptz NOT NULL
);

-- almak: suresi dolmussa devral
INSERT INTO kilitler (ad, sahip, gecerlilik)
VALUES ('fatura', :ben, now() + interval '30 seconds')
ON CONFLICT (ad) DO UPDATE
   SET sahip = :ben, gecerlilik = now() + interval '30 seconds'
 WHERE kilitler.gecerlilik < now()
RETURNING sahip;

-- donen sahip ben isem kilit bende

3. Hiç kilitleme: tek tüketicili kuyruk

Çoğu “aynı anda tek kişi yapsın” ihtiyacı aslında bir sıralama ihtiyacı. İşi bir kuyruğa koy ve o kuyruğu tek bir tüketici işlesin; kilide hiç gerek kalmaz. Kubernetes’te çalışıyorsan zamanlanmış işler için lease tabanlı lider seçimi de aynı işi yapar ve kendin yazmazsın.

Sahadan: fatura işine ne yaptık

Baştaki hikâyeye dönelim. İlk refleks Redis kilidi koymaktı. Koyduk, sorun bir süre görünmedi. Sonra bir gün iş beklenenden uzun sürdü, kilit düştü ve aynı hata döndü — bu sefer daha az sıklıkta, yani daha zor fark edilir şekilde.

Kalıcı çözüm iki parçalıydı ve ikisi de kilitle ilgili değildi:

1. Fatura kesme işini idempotent yaptık. Fatura tablosuna (donem, musteri_id) üzerinde tekil kısıt. İkinci deneme veritabanı tarafından reddediliyor; kilit olsa da olmasa da çift fatura imkânsız.
2. Kilidi verimlilik için tuttuk. Advisory lock’a geçtik; amacı doğruluk değil, iki kopyanın boşuna aynı işi yapmasını engellemek.

Buradaki ders bende kaldı: kilit, hatalı bir tasarımı güvenli yapmaz. İşin kendisi tekrar edilebilir olmalı; kilit sadece israfı azaltır.

Kontrol listesi

Sonuç

Dağıtık kilit, dağıtık sistemlerdeki en kolay yanlış yapılan konulardan biri; çünkü yanlış hali de çoğu zaman çalışıyor. Hata ancak yük, gecikme ve şansın birleştiği anda ortaya çıkıyor — yani en kötü anda.

Akılda kalacak sıra şu: önce kilide ihtiyacın olmayacak şekilde tasarla, olmuyorsa veritabanının kilidini kullan, o da olmuyorsa Redis yaz — ama doğruluğu kilide değil fencing token’a ya da idempotency’ye emanet et.