Bu mimari zorluk, bulut yerel ortamlarda konteynerleştirilmiş mikro hizmetlerin yüksek değişim oranları ve kıtalar arası dağıtımlar yaşadığı Apache ZooKeeper'ın sınırlamalarından kaynaklanmaktadır.
Erken dönem dağıtılmış sistemler merkezi koordinasyona dayanıyordu, ancak etcd ve Consul katı karar alma süreçlerinin kıtalar arası 150 ms'yi aşan WAN gecikmeleri ile mücadele ettiğini ortaya koydu.
Günümüz gereksinimleri, Kubernetes kontrol düzlemlerinin, fiber kopmaları ve bölgesel bozulmalar sırasında katı güvenlik garantileri sağlarken, kullanılabilirlik bölgeleri boyunca liderleri seçmesi ihtiyacından doğmuştur.
Temel gerginlik, CAP teoremi kısıtlamalarını, asenkron ağlar üzerinde Raft veya Paxos gibi konsensüs protokollerini uygularken uzlaştırmaktır.
Dağıtılmış kilitler, kirli süreçlerin kira süresinin sona ermesinden sonra durumu bozmasını önlemek için sınırlama mekanizmaları gerektirirken, lider seçimi, aday düğümler arasında iletişim kesildiğinde bile benzersizlik garantisi sağlamalıdır.
Ayrıca, binlerce geçici oturumu koordine etmek, arka plandaki depoya karşı aşırı yazma amplifikasyonu yaratarak performansı, kitlesel yeniden dağıtımlar veya kesinti durumlarında potansiyel olarak bozabilir.
Mimari, hata alanlarına göre bölünmüş Raft grupları kullanan hiyerarşik bir konsensüs modeli benimsemektedir ve tam durum günlüklerini sürdürmeden çoğunluk hesaplamalarına katılan tanık düğümleri ile desteklenmektedir.
Redis-uyumlu Redlock algoritmalarını, geçerli kaynak işlemlerinin eski istekleri reddetmesini sağlamak için etcd'e kaydedilmiş monotonik sınırlandırma tokenları ile geliştirin.
Ağ gecikmesini ve düğüm hatalarını ayırt etmek için Phi Accrual hata tespiti kullanın, ayrıca etkin küme üyeliği güncellemeleri için dedikodu protokolleri kullanın.
Geçici bölgesel bağlantı kopmalarını nazik bir şekilde ele almak için otomatik yenileme denemeleri ile Chubby tarzı oturum kiralama uygulayan yan proxy'ler dağıtın.
Küresel bir finansal ticaret platformu, deniz altı kablo kesintileri sırasında yıkıcı split-brain senaryolarıyla karşılaşmış ve iki bölgesel liderin aynı varlık bölümünde yetki iddia etmesi nedeniyle çelişkili ticaret işlemleri meydana gelmiştir.
Çözüm 1: Monolitik etcd dağıtımı ile küresel çoğunluk. Bu yaklaşım, ABD-Doğu bölgesinde dağıtılan tek bir etcd kümesi kullanıyordu; diğer yerlerde yalnızca okunabilir aynalarla. Artıları arasında basit doğrusal olarak tasarlanabilirlik ve minimum yapılandırma karmaşıklığı bulunmaktaydı. Eksileri arasında Asya-Pasifik traderları için 300ms'yi aşan yazma gecikmeleri ve ABD-Doğu bölgesi kesildiğinde toplam hizmetin kesintiye uğraması bulunmaktadır; bu, zorunlu %99.999 kesintisiz çalışma SLA’sını ihlal eder.
Çözüm 2: Asenkron çoğaltma ile bağımsız bölgesel kümeler. Her bölge için ayrı etcd kümeleri dağıtıldı ve son yazma galipliği ile çatışma çözümü sağlandı. Artıları, 10ms’nin altındaki yerel gecikmeler ve operasyonel izolasyon sağlar. Eksileri, birden çok liderin aynı anda paylaşılan durumu değiştirebileceği geçici ayrışmalara izin vermekte ve finansal düzenleyici gereklilikler için katı tutarlılığı ihlal etmekte, çift harcama zafiyetlerine neden olmaktadır.
Çözüm 3: Tanık düğümleri ve sınırlandırma tokenları ile hiyerarşik konsensüs. Yerel koordinasyon için bölgesel Raft grupları uygulandı, küresel bir konsensüs katmanı ile birbirine bağlandı ve diğer bölgelerdeki çoğunluğun korunması için üçüncü taraf kullanılabilirlik bölgelerinde hafif tanık düğümleri kullanıldı. Artıları sadece 50ms altı yerel işlemler ve bölünmeler sırasında çoğunluk tanıklarının yanı sıra birincil bölge konsensüsü gerektirerek güvenliği garanti altına aldı. Redis kümeleri, ticaret motoru tarafından doğrulanan kesin olarak artan sınırlandırma tokenları ile dağıtılmış kilitlemeyi sağladı. Bu çözüm, ağ bölünmeleri sırasında güvenlik değişkenini (tek lider) korumayı sağlarken, yalnızca bölgeler gerçekten izole olduğunda kullanılabilirliği feda etti, yalnızca gecikme zirveleri yaşarken değil.
Bu sonuç, split-brain olaylarını tamamen ortadan kaldırdı, kilit içeriği gecikmelerini 250ms' den 12ms' ye düşürdü ve ardından Frankfurt veri merkezinin tamamen kesilmesi sırasında ticaret sürekliliğini başarıyla sürdürdü.
Soru 1: Raft yüksek durum değiş tokuşu olan ortamlarda günlük sıkıştırmasını nasıl yönetir, lider seçimini veya istemci işlemlerini bloke etmeden?
Cevap: Raft, günlük büyümesini anlık görüntülerle ele alır; ancak adaylar genellikle anlık görüntü yüklemesinin liderin bloke olmaması için asenkron olmasının kritik uygulama detayını gözden kaçırır. Lider, durum makinesinin belirli bir anlık görüntüsünü alır ve ardından anlık görüntüyü geride kalan takipçilere parça parça gRPC akışları ile iletir. Temel nüans: lider, tüm takipçiler anlık görüntü alımını tanıdıkça günlük girişlerini korumalıdır veya normal çoğaltma ile yakalamalıdır; bu, toplu yeniden bağlantılar sırasında OOM hatalarını önlemek için dikkatli bellek yönetimi gerektirir.
Soru 2: Neden Redis Redlock güvenlik garantileri için esasen saat senkronizasyonu gerektirir ve bu bağımlılığı ortadan kaldıran mekanizma nedir?
Cevap: Adaylar genellikle Redlock'ın, saat kaymasının kilit üst üste binmesine neden olduğu için doğası gereği güvensiz olduğunu iddia eder. Redlock kabaca senkronize saatler varsayıyor olsa da, saat senkronizasyonu olmadan güvenliğin gerçekten sağlanması, her kilit verilmesine bağlı monotonik artan tam sayıları uygulamayı gerektirir. Korunan kaynak (veritabanı, dosya sistemi), işlenmiş maksimum token'i izlemesi ve daha düşük bir token taşıyan herhangi bir işlemi reddetmesi gerekir. Böylece, gecikmiş bir işlem yeniden canlanıp süresi dolmuş bir kilidi kullanmaya çalışsa bile, eski token'ları kaynak katmanı tarafından otomatik olarak reddedilir.
Soru 3: Lider kilidi süresi dolduğunda Thundering Herd problemini önleyen kesin mekanizma nedir ve binlerce istemci eşzamanlı edinim talep eder?
Cevap: Bir lider çökerse, basit uygulamalar, kilidi eşzamanlı olarak talep eden binlerce istemciyle aşırı yüklenir. Adaylar genellikle, yalnızca koordine edilmiş zirveyi hafifletmekle kalır; doğru mimari desen, ZooKeeper'ın geçici sıralı düğümlerini veya etcd'nin Watch işlevi ile prevKV'yi kullanarak dağıtılmış bir kuyruk oluşturur. İstemciler sıralı girişler oluşturur ve yalnızca hemen önceki girişi gözetler; kilit serbest bırakıldığında, yalnızca sıradaki istemci bildirim alır, alımları sıraya sokarak başvuru eğrisini O(n)'den O(1) bildirimine düşürür.