Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Çok Instance'lı Ortamda Job'lar: Distributed Lock, Leader Election ve Aynı İşin İki Kez Çalışması
Üç replica'daki BackgroundService gece raporunu üç kez üretir; DistributedLock ile SQL Server sp_getapplock, PostgreSQL advisory lock ya da Redis üzerinden alınan bir lock bunu bire indirir. Lock'un sahibi kill -9 ile ölünce Redis'te lock 30 saniyelik lease bitene kadar kimsede kalmaz; PostgreSQL'de ise sunucu bağlantının koptuğunu fark edene kadar, denememde yaklaşık bir dakika, ölü process'te kaldı. Lock bir garanti değil, bir lease'tir.
Distributed Lock, Lease ve Fencing Token: Kilit Neden Yetmez?
Süreli bir kilit (lease) tek başına doğruluk sağlamaz: kilidi alan process GC duraklamasında kalırsa lease dolar, başkası kilidi alır ve uyanan ilk process yine yazar. Gerçek Redis ve SQLite ile yapılan denemede eski rapor yenisinin üstüne yazılıyor; her kilitle artan bir fencing token'ı veritabanında WHERE token > LastToken ile kontrol edince eski yazma reddediliyor. Redlock tartışmasının iki tarafı ve veritabanının kendi mekanizmaları da yazıda.