5.2. Mutabakat Algoritmaları

Mutabakat (consensus), bir grup düğümün hatalara rağmen tek bir değer üzerinde uzlaşması problemidir — ve FLP sonucu, bunu tamamen asenkron bir ağda garanti etmenin imkansız olduğunu kanıtlar. Her pratik mutabakat algoritması, bu imkansızlıkla yaşamanın bir yoludur: güvenliği (safety) her zaman, canlılığı (liveness) ise yalnızca ağ düzgün davrandığında garanti eder. Bu bölüm, mutabakatın neden zor olduğunu, ardından sektörün gerçekten kullandığı iki yanıt olan Paxos ve Raft’ı, türevlerini (Zab, etcd) ve yalan söyleyen düğümleri tolere eden Bizans varyantlarını kapsar.

İncelenen Konular

• 5.2.1. Split-Brain Problemi ve Fencing Token’ları: Split-brain problemini ve eski bir liderin eylem yapmasını engelleyen mekanizma olan fencing token’larını tanıtır.
• 5.2.2. FLP İmkansızlık Sonucu: Mutabakat Neden Zordur: FLP sonucunu açıklar: garantili mutabakatın tamamen asenkron bir ağda neden imkansız olduğunu ve kaçış yollarını.
• 5.2.3. Paxos: Temel Mantık, Prepare ve Accept Aşamaları: Paxos’un prepare ve accept aşamalarını ve hata toleranslı uzlaşmayı kanıtlanabilir kılan temel mantığı kapsar.
• 5.2.4. Raft: Lider Seçimi, Log Replikasyonu, Üyelik Değişiklikleri: Raft’ın anlaşılabilirlik için tasarlanmış lider seçimini, log replikasyonunu ve üyelik değişikliklerini açıklar.
• 5.2.5. Zab (ZooKeeper Atomic Broadcast): Dönemler ve Zxid: ZooKeeper Atomic Broadcast’i, epoch ve zxid mekaniğini ve ZooKeeper’a nasıl güç verdiğini kapsar.
• 5.2.6. etcd: Raft Üzerine Dağıtık K-V Depolama: Raft üzerine kurulu dağıtık bir anahtar-değer deposu olan etcd’yi, Kubernetes cluster durumunun omurgasını açıklar.
• 5.2.7. Bizans Hata Toleransı: PBFT, Proof of Work / Proof of Stake: Kötü niyetli düğümleri tolere eden PBFT ve blockchain mutabakatını (Proof of Work, Proof of Stake) kapsar.