Nihai Tutarlılık: Kopyalar Neden Anında Değil, Sonunda Eşitlenir?

Nihai tutarlılık nedir?

Nihai tutarlılık (eventual consistency), bir veri kaydı güncellendikten sonra yeni bir güncelleme gelmezse sistemdeki tüm kopyaların sonunda aynı değere ulaşacağını söyleyen tutarlılık modelidir. Güncelleme ile eşitlenme arasında geçen sürede farklı kopyalar farklı değer döndürebilir; garanti edilen şey o sürenin sonunda uyumdur, anında uyum değil.

Güçlü tutarlılıkta ise her okuma en son onaylanmış yazmayı görür. Nihai tutarlılık bu garantiyi bilinçli olarak gevşetir ve karşılığında erişilebilirlik, düşük gecikme ve coğrafi ölçek kazanır.

Nasıl çalışır?

Veri birden çok düğüme ya da servise kopyalandığında yazma, önce bir düğümde onaylanır; diğerlerine arka planda iletilir. İletim ağ gecikmesi, düğüm arızası ya da kuyruk birikmesi nedeniyle gecikebilir.

Sistemin bu farkı kapatmak için kullandığı araçlar şunlardır: • Eşitleme: Arka plan süreçleri kopyaları karşılaştırıp farkı kapatır (okuma sırasında onarım, anti-entropy gibi yöntemler). • Olay akışı: Bir servisteki değişiklik olay olarak yayımlanır, diğer servisler kendi verisini bu olaya göre günceller. • Çakışma çözümü: Aynı kayıt farklı kopyalarda eşzamanlı değiştiyse son yazan kazanır, sürüm vektörü ya da birleştirilebilir veri tipleri gibi bir kural hangisinin geçerli olacağını belirler.

Örnek: sipariş ve stok

Örneğin bir e-ticaret sisteminde sipariş servisi siparişi kaydeder ve 'sipariş oluştu' olayını yayımlar. Stok servisi bu olayı biraz sonra işleyip stoğu düşer. Ara dönemde müşteri ürün sayfasını yenilediğinde stok sayısı hâlâ eski görünebilir. Birkaç saniye içinde sistem uyumlu hale gelir.

Burada iş kuralı belirleyicidir. Stok gösterimi için bu gecikme kabul edilebilir; ancak son kalan ürünü birden fazla müşteriye satmamak gerekiyorsa, rezervasyon adımı güçlü tutarlılıkla ya da koşullu güncellemeyle korunmalıdır. Nihai tutarlılık her veri için değil, gecikmeyi kaldırabilen veri için uygundur.

Mikroservislerde ve NoSQL'de nerede karşımıza çıkar?

Mikroservis mimarisinde her servis kendi veritabanını yönettiği için servisler arası tek bir ACID işlem çoğu zaman yoktur. Bunun yerine her servis kendi işlemini onaylar, sonrasında olay yoluyla diğerlerini bilgilendirir. Hata olursa telafi edici işlem (saga deseni) ile önceki adımlar geri çevrilir.

Birçok NoSQL ve dağıtık depolama sistemi de varsayılan ya da ayarlanabilir olarak nihai tutarlılık sunar. Okuma ve yazma için kaç kopyanın onay vermesi gerektiği (kuorum) ayarlanarak tutarlılık ile hız arasında denge kurulur.

Tasarımda dikkat edilecekler

Nihai tutarlılık kullanan bir sistemde uygulamanın bu gecikmeyle yaşamayı bilmesi gerekir: • İşlemler tekrar çalıştırılabilir (idempotent) yazılmalıdır; olay yinelenirse sonuç değişmemelidir. • Kullanıcıya 'işleminiz alındı' gibi dürüst geri bildirim verilmeli, anlık kesin sonuç vaadi verilmemelidir. • Kullanıcının kendi yazdığını hemen görmesi gerekiyorsa o okuma yazılan düğüme ya da önbelleğe yönlendirilebilir. • Gecikmeyi izlemek gerekir: eşitlenme süresi ölçülmüyorsa 'sonunda' ne kadar sürdüğü bilinmez. • Yinelenen, sırası bozuk ve kaybolan mesajlar baştan senaryo olarak düşünülmelidir.

Mindset eğitimlerinde nerede işlenir?

Mikroservis Mimarisi programındaki 'Veri Yönetimi ve Tutarlılık' modülü, servisler arası veri tutarlılığını; Java Mikroservisleri programı olay tabanlı entegrasyonu; NoSQL Veritabanı Sistemleri programı ise Redis, Cassandra gibi sistemlerin tutarlılık davranışını kapsar. Dağıtık sistem tasarlayan backend geliştiriciler ve mimarlar için uygundur.

Yapay Zeka ile Mikroservis Entegrasyonu programı mesaj kuyruğu ve olay mimarisini yapay zeka servisleri bağlamında ele alır; kurumsal ekipler kendi servis sınırlarındaki tutarlılık kararlarını bu çerçevede tartışabilir.