Skip to main content

> dağıtık_kilitleme:_eskrim_jetonları_(fencing_tokens),_redlock_açıkları_ve_gc_duraklama_tuzakları

Dağıtık Kilitleme: Eskrim Jetonları (Fencing Tokens), Redlock Açıkları ve GC Duraklama Tuzakları

Redis Redlock algoritması Garbage Collection (GC) duraklamaları veya saat sıçramalarında karşılıklı dışlamayı (mutual exclusion) neden garanti edemez; Martin Kleppmann Fencing Jetonları paylaşılan depolamayı veri bozulmasından nasıl korur?

Principal/Architect (L7+)

⚡ÖZET VE TEKNİK CEVAP

Dağıtık sistemlerde iki işçinin aynı anda aynı görevi yapmasını engellemek için bellek içi kilitler (Redis SET lock_key token NX PX 10000) sıkça kullanılır. Ancak dağıtık sistemler uzmanı Martin Kleppmann'ın meşhur Redlock eleştirisinde kanıtladığı gibi, tek başına bellek içi bir kilit veri güvenliğini garanti edemez:

1
  1. ▸İşçi kilidi 10 saniyeliğine alır.
2
  1. ▸İşçi 15 saniye süren beklenmedik bir Garbage Collection (GC) Duraklamasına, sanal sunucu donmasına veya disk takılmasına girer.
3

Bu sırada Redis'teki 10 saniyelik kilidin süresi dolar.

4
  1. ▸İşçi boşa çıkan kilidi alır ve veritabanını günceller.
5
  1. ▸İşçinin GC donması biter; kilidin hala kendisinde olduğunu sanarak veritabanına yazar ve 2. İşçinin verisinin üzerine yazıp siler—buna Bölünmüş Beyin (Split-Brain) Veri Bozulması denir. Canlı sistemler bu açığı Eskrim Jetonları (Fencing Tokens) ile kapatır: Kilit sunucusu her kilitle birlikte kesin olarak artan monotonik bir sayı (1, 2, 3dots) verir; depolama katmanı kendisinde kayıtlı olan son jetondan daha küçük jetonla gelen tüm eski yazma isteklerini anında reddeder.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Fencing jeton doğrulaması 4 atomik adımda gerçekleşir:

1

Monotonik Sayaçlı Kilit: İstemci dağıtık kilidi alırken (etcd, ZooKeeper veya Redis sayaç ile), kilit servisi artan benzersiz bir jeton döner: jeton = 34.

2

Depolama Eşik Kontrolü: İstemci veritabanı yazma sorgusuna bu jetonu ekler (UPDATE hesaplar SET bakiye = 500, son_jeton = 34 WHERE id = 1 AND son_jeton < 34).

3

Eski Yazmanın Reddedilmesi: 1. İşçi GC donmasından uyandığında elindeki jeton: 33 ile yazmaya çalışır; SQL WHERE son_jeton < 33 şartı sağlanmadığı için sorgu 0 satırı günceller.

4

Güvenli İptal: 1. İşçi 0 satır güncellendiğini görüp işlemini güvenle geri alır; canlı veritabanı bozulmaktan kurtulur.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Dağıtık lider seçimi, zamanlanmış cron görevlerinin tekilleştirilmesi, paylaşılan dosya depolama yazıcıları ve finansal mutabakat motorları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓

    Depolama tarafında fencing jeton kontrolü yapmadan yalnızca Redis kilit süresine güvenmek ve süreç donmalarında verilerin üzerine yazılmasına yol açmak

  • ✓

    senkronize olmayan sunucularda sistem duvar saatini jeton olarak kullanmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    Veritabanında yeni kaydedilen verilerin eski değerlerle ezildiğinin fark edilmesi

  • ✓

    JVM loglarında GC duraklama sürelerinin kilit süresini aştığının (> 10 sn) görülmesi

  • ✓

    aynı anda çalışan mükerrer cron logları

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Dağıtık kilitleri mutlaka veritabanı/depolama tarafından denetlenen Fencing Jetonları ile birlikte kullanın

  • ✓

    kritik kilitlerde asenkron Redis yerine mutabakat garantili sistemleri (etcd, ZooKeeper, Consul) tercih edin

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Fencing jetonları bölünmüş beyin krizlerine karşı matematiksel olarak kanıtlanmış kesin güvenlik sağlar; ancak alttaki veritabanının koşullu kontrol (WHERE token < X) yeteneğini desteklemesini gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir faturalama sistemi günde $5M abonelik yenilemesi yapıyordu. Çift çekimi önlemek için işçiler 5 saniyelik bir Redis kilidi (lock:user_123) alıyordu. Yoğun fatura gününde A İşçisi 8 saniyelik bir JVM GC donmasına girdi. Redis kilidi boşa çıkardı. B İşçisi kilidi aldı ve müşteriden parayı çekti. A İşçisi donmadan uyandı ve kullanıcının kartından ikinci kez para çekti. Ekip Kleppmann Fencing Jetonlarını kurdu: Kilit alınırken artan bir sıra numarası (INCR global_fence) üretildi. SQL sorgusu WHERE son_jeton < yeni_jeton şartıyla çalıştı. A İşçisi elindeki eski jetonla yazmaya çalıştığında veritabanı işlemi anında reddetti ve mükerrer para çekimleri tamamen son buldu.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Dağıtık sistemlerde Fencing Jetonu (Eskrim Jetonu) nedir?

Kilit her alındığında kilit servisi tarafından verilen, süresi geçmiş veya donmadan yeni uyanmış eski işçilerin yazma isteklerini veritabanının reddetmesini sağlayan artan bir tamsayı jetonudur.
Q2

Basit bir Redis TTL kilidi JVM Garbage Collection (GC) duraklamalarına karşı neden savunmasızdır?

Bir işçi kilit süresinden daha uzun bir GC duraklamasına girerse kilit düşer ve başkası alır; ilk işçi donmadan uyandığında kilidin hala kendisinde olduğunu sanarak veritabanına yazar ve veriyi bozar.

Dağıtık Kilitleme: Eskrim Jetonları (Fencing Tokens), Redlock Açıkları ve GC Duraklama Tuzakları — Sıkça Sorulan Sorular

Martin Kleppmann Redlock dağıtık kilitleme algoritmasını neden eleştirdi?

Çünkü Redlock, gerçek bulut ortamlarında GC duraklamaları ve NTP saat sıçramaları ile kolayca bozulan senkronize fiziksel saat ve ağ süresi varsayımlarına dayanır.

Hangi dağıtık sistemler doğrudan mutabakat garantili kilit desteği sunar?

Apache ZooKeeper (ardışık geçici düğümler), etcd (kiralamalar ve revizyon numaraları) ve HashiCorp Consul.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸

    Bellek içi kilitler tek başına GC donmaları yüzünden veri güvenliğini garanti edemez.

  • ▸

    Donmadan geç uyanan bir işçi yeni verinin üzerine yazarak veriyi bozar (Bölünmüş Beyin).

  • ▸

    Fencing jetonları eski yazma isteklerini veritabanı katmanında reddetmek için artan sıra numaraları sağlar.

  • ▸

    Kritik kilitlerde basit Redis anahtarları yerine mutabakat garantili sistemleri (etcd, ZooKeeper) kullanın.

Yaygın Yanılgılar

  • ✗

    Yanılgı: Redis kilit süresini 60 saniye yapmak sistemi %100 güvenli kılar (Gerçek: Aşırı GC donmaları ve sunucu takılmaları her türlü sabit süreyi aşabilir).

  • ✗

    Yanılgı: Dağıtık kilit veritabanı desteği olmadan sadece istemci tarafında çözülebilir (Gerçek: Güvenli kilitleme matematiksel olarak depolama katmanının fencing jetonunu denetlemesini şart koşar).

Karar Kılavuzu & Önceliklendirme

Süreç donmaları ve saat kaymalarının veri bozulmasına yol açmasını önlemek için dağıtık kilitlerle korunan tüm veritabanı güncellemelerinde monotonik Fencing Jetonları kullanın.

Doğrulanmış Kaynaklar & Referanslar