Skip to main content

> TRANSACTIONAL_SAGA // Raft // CP

Bizans-Hata Korumalı Dağıtık Kaynak Kilitleyici

Zombi işçilerin depolamayı bozmasını önlemek için artan fencing belirteçleri sağlayan yüksek güvenilirlikli dağıtık karşılıklı dışlama (mutex) mimarisi.

Genel BakışCAP & PACELCMimariler18Topoloji SihirbazıInteractiveKılavuzlar10Karşılaştırma Matrisi22
Tüm Dağıtık Mimarilere Dön
CAP: CPPACELC: PC/ECConsensus: Raft

Mimarî Problem ve Çözüm Hipotezi

Fencing belirteci olmayan standart kilitler istemci GC duraklaması yaşadığında kilit düşer; uyandığında geçersiz veri yazarak depolamayı bozar.

Resmi Dağıtık Sistem Garantileri

  • ⚡Monotonically increasing 64-bit fencing tokens with every lock acquisition
  • ⚡Storage-side reject-if-token-less-than validation
  • ⚡Automatic lease revocation upon client heartbeat timeout

Ele Alınan Hata Tipleri

DS-FAIL-17: Zombie Leader Fencing Bypass
DS-FAIL-01: Split-Brain Partitioning
Ham Döküm & İndirmeHam Markdown Görüntüle

3 Ölçek ve Olgunluk Konfigürasyonu

Başlangıç kümesinden multi-datacenter ultra-ölçek seviyesine kadar kademeli üretim konfigürasyonları.

INITIAL TIER
Verim Hedefi:

1,500 locks/sec

p99 Gecikme:

< 12ms

Teslimat Garantisi:

Lease Expiration with Redis Redlock

Altyapı Topolojisi:

5 independent Redis master instances across separate failure domains.

Bileşen Yığını:
Redis (Redlock Algorithm)
⚠️ Operasyonel Ödünleşim: Redlock lacks formal fencing tokens; vulnerable to clock drift anomalies.
SCALED TIER
Verim Hedefi:

15,000 locks/sec

p99 Gecikme:

< 4ms

Teslimat Garantisi:

Strict Raft Fencing Tokens (etcd v3)

Altyapı Topolojisi:

5-node etcd cluster generating linearizable revisions. Target databases validate fencing tokens in `WHERE` clauses.

Bileşen Yığını:
etcd 3.5+ ClusterPostgreSQL Storage Gate
⚠️ Operasyonel Ödünleşim: Target databases must include fencing epoch columns in their schema.
ULTRA_SCALE TIERMISSION CRITICAL
Verim Hedefi:

90,000 locks/sec

p99 Gecikme:

< 1.2ms

Teslimat Garantisi:

Hardware-Enforced Consensus Fencing with Sub-Millisecond Leases

Altyapı Topolojisi:

Low-latency bare-metal consensus nodes communicating over RoCE / RDMA.

Bileşen Yığını:
Custom Raft LockerRDMA Network InterconnectLinux Kernel Fencing Module
⚠️ Operasyonel Ödünleşim: Specialized enterprise networking and hardware requirements.

Altyapı Kodları: Terraform, Kubernetes & Motor Konfigürasyonları

Doğrudan üretim kümelerine uygulanabilir doğrulukta açık kaynak altyapı otomasyon manifestoları.

Terraform (HCL)main.tf
resource "aws_route53_record" "etcd_discovery" {
  zone_id = aws_route53_zone.internal.zone_id
  name    = "etcd-lock-cluster.internal"
  type    = "SRV"
  ttl     = 300
  records = [
    "0 1 2380 etcd-0.internal",
    "0 1 2380 etcd-1.internal",
    "0 1 2380 etcd-2.internal"
  ]
}
Kubernetes (YAML)k8s-manifest.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: etcd-locker
spec:
  replicas: 5
  serviceName: etcd-locker-srv
  template:
    spec:
      containers:
        - name: etcd
          image: quay.io/coreos/etcd:v3.5.15
          args:
            - --experimental-initial-corrupt-check=true
Engine Configurationconfig.properties
UPDATE critical_resource 
SET state = 'MUTATED', last_fencing_token = :fencing_token
WHERE id = :resource_id AND last_fencing_token < :fencing_token;
-- If affected rows == 0, abort: a zombie lock holder tried to execute!
Yapay Zekâ Özeti — Bizans-Hata Korumalı Dağıtık Kaynak Kilitleyici
AEO / GEO / Perplexity Indexable

Zombi işçilerin depolamayı bozmasını önlemek için artan fencing belirteçleri sağlayan yüksek güvenilirlikli dağıtık karşılıklı dışlama (mutex) mimarisi.

CAP & PACELC TeoremleriCAP: CP // PACELC: PC/EC
Uzlaşı ProtokolüRaft
Ultra-Ölçek Verimi90,000 locks/sec (< 1.2ms)
Ele Alınan Hata ModlarıDS-FAIL-17: Zombie Leader Fencing Bypass; DS-FAIL-01: Split-Brain Partitioning

Mimarî Plan Sıkça Sorulan Sorular

Bizans-Hata Korumalı Dağıtık Kaynak Kilitleyici mimarisinin CAP ve PACELC teoremleri altındaki matematiksel sınıflandırması nedir?

Bizans-Hata Korumalı Dağıtık Kaynak Kilitleyici, CAP teoreminde CP ve PACELC teoreminde PC/EC olarak modellenmiştir. Ağ bölünmesi (Partition) durumunda tutarlılık (Consistency) önceliklendirilirken, normal çalışma durumunda gecikme ile tutarlılık dengesi korunur.

Bu mimari hangi dağıtık uzlaşı protokolünü (Raft) kullanır ve lider seçimi nasıl işler?

Bu mimari Raft protokolünü kullanır. Düğümler arası durum çoğaltması (state replication) ve liderlik seçimi çoğunluk oyu (quorum) ile garanti altına alınır; bölünmüş beyin (split-brain) durumu monotonik dönem numaraları (epoch/term) ve fencing belirteçleriyle engellenir.

Bu mimari hangi dağıtık hata modlarını (Failure Modes) bertaraf eder?

Bu mimari şu kritik dağıtık sistem arızalarını ele alır: DS-FAIL-17: Zombie Leader Fencing Bypass, DS-FAIL-01: Split-Brain Partitioning. Sistem veri kaybı olmadan otomatik hata devri ve durumsal yakınsama sağlar.

INITIAL ile ULTRA_SCALE seviyeleri arasındaki verim (Throughput) ve p99 gecikme farkları nelerdir?

INITIAL seviyesi 1,500 locks/sec hedefi ve < 12ms p99 gecikmesi sağlarken (5 independent Redis master instances across separate failure domains.), ULTRA_SCALE seviyesi 90,000 locks/sec ve < 1.2ms sunar (Low-latency bare-metal consensus nodes communicating over RoCE / RDMA.). Bileşenler: Custom Raft Locker, RDMA Network Interconnect, Linux Kernel Fencing Module.

Bu mimari Altyapı Kodu (IaC) ve motor ayarlarıyla nasıl devreye alınır?

Bu sayfada sunulan Terraform (main.tf), Kubernetes dağıtım bildirimleri (k8s-manifest.yaml) ve motor konfigürasyon parametreleri (config.properties) doğrudan üretime hazır olarak sağlanmıştır.