Sorunun Cevabı
CQRS (Komut Sorgu Sorumluluk Ayrımı) deseninin, yüksek okuma senaryolarında ölçeklenebilirlik darboğazlarını çözmek için yazma optimizasyonlu modelleri (PostgreSQL, Oracle) okuma optimizasyonlu projeksiyonlardan (Elasticsearch, MongoDB) ayırarak alan odaklı tasarım uygulamalarından ortaya çıktığı görülmektedir. Bu mimari ayrım, komut kalıcılığı ile sorgu kullanılabilirliği arasında doğal bir zamansal boşluk oluşturmakta; çünkü asenkron olay işleyicileri, okuma modellerinin durum değişikliklerini yansıtması için verileri ağ sınırları boyunca denormalize etmelidir.
Bu sistemleri otomatikleştirmekteki temel sorun, test yürütme iş parçaları ile arka plandaki projeksiyon çalışanları arasındaki yarış koşuludur; burada, komut gönderildikten hemen sonra okuma modelleri üzerinde gerçekleştirilen doğrulamalar, işleme gecikmesi nedeniyle öngörülemez şekilde başarısız olmaktadır. Geleneksel çözümler, boru hatlarını kabul edilemeyecek kadar yavaşlatan veya altyapı baskısı altındaki yanlış negatifler üreten keyfi gecikmelere veya basit anketlemelere dayanır.
Kapsamlı çözüm, belirli bir senkronizasyon engeli oluşturmak için akış offsetleri veya değişim verisi yakalama token'ları (Debezium, Kafka tüketici grupları) kullanarak olay konum izleme uygular. Test çerçeveleri, en son yayımlanan alan olayının konumunu yakalar ve okuma modelinin belirli bir konumun tüketildiğini onaylayana kadar okuma modeli meta verilerini sorgular, belirli süreler boyunca sonsuz engellemeyi önlemek ve alt saniyelik hizalama hassasiyetini korumak için devre kesici zaman aşımı ile birlikte üstel geri çekilme uygulayarak.
Hayattan bir durum
Yüksek frekanslı bir ticaret platformu için test otomasyonu mimarisi oluştururken, ticaret gerçekleştirme kalıcılığı için PostgreSQL ve gerçek zamanlı bakiye sorguları için Elasticsearch kullanan portföy değerleme testlerinde kritik bir dalgalanma ile karşılaştık. Alım/satım komutlarını çalıştıran ve hemen sonrasında portföy uç noktalarını sorgulayan testler, Kafka Connect projeksiyonlarının güncellemeleri dizine almak için 300-800 ms gerektirmesi nedeniyle eski ön işlemler bakiye alıyordu ve CI yapıların %35'inin yanlış bir şekilde başarısız olmasına neden oluyordu.
İlk olarak düşündüğümüz çözüm, her yazma işleminin ardından sabit Thread.sleep(2000) ifadeleri eklemekti; bu, doğrulamalar öncesinde Elasticsearch dizinleme tamamlanmasını sağlıyordu. Bu yaklaşım, sonuçları geçici olarak istikrara kavuşturdu ancak test süresi yürütme zamanını %400 artırdı, donanım performansına dayalı kırılgan zamanlama bağımlılıkları oluşturdu ve sabit gecikmeyi aşabilen çöp toplama duraklama veya ağ yoğunluğuna karşı savunmasız kaldı.
İkinci değerlendirilen yaklaşım, sorgu uç noktasında üstel geri çekilme ile genel bir anket uyguladı ve beklenen değerler ortaya çıkana veya bir zaman aşımı dolana kadar doğrulamaları yeniden denedi. Sabit beklemelerden daha üstün olmasına rağmen, bu yöntem "henüz güncellenmedi" ile "yanlış değer" durumları arasında belirsizlik yaşadı ve birden fazla yürütmenin aynı toplu işlemleri aynı anda değiştirdiği eşzamanlı test senaryolarını ele alamadı; bu, testler arası kirlenmeye ve yanlış pozitiflere neden oldu.
Son olarak, Elasticsearch belge meta verileri içinde son işlenmiş Kafka offsetlerini ortaya çıkarmak için projeksiyon katmanını enstrümante eden üçüncü bir yaklaşımı seçtik. Test cihazımız, yayınlanmış olayın offsetini yakaladı ve okuma modelini meta verisinin o offsetin tüketildiğini gösterene kadar sorgulayan özel bir bekleme aracı kullandı; böylece zamanlama tahminleri olmaksızın tutarlılığı garanti ettik. Bu, ortalama test yürütme süresini 52 saniyeden 14 saniyeye düşürdü ve asenkron belirsizliği belirli senkronizasyon noktalarına dönüştürerek tamamen yanlış negatifleri ortadan kaldırdı.
Adayların sıkça kaçırdığı noktalar
Birden fazla paralel CI çalıştırıcısı, CQRS'nin asenkron doğasını ihlal eden kilitlenme mekanizmaları eklemeden, okuma model projeksiyonlarını paylaşan toplu işlemleri güncellerken test verisi etkileşimini nasıl önlersiniz?
Cevap: UUID ile sonlandırılmış toplu işlem tanımlayıcıları ve olay meta verisi içine gömülü test çalıştırma ilişki kimliklerini kullanarak mantıksal kiracı izolasyonu uygulayın. Okuma model indekslerini, belirli test yürütme bağlamına yalnızca ilgili belgeleri döndüren bir yönlendirme anahtarı veya filtre parametresi olarak test çalıştırma tanımlayıcısını içerecek şekilde yapılandırın. Bu, fiziksel veritabanı kilitleri olmadan paralel test yürütme olanağı tanırken, eşzamanlı boru hatları arasında sıkı veri ayrımını korur.
CQRS'de yazma modeli davranışını doğrulamak ile okuma model davranışını doğrulamak arasındaki temel mimari fark nedir ve bu ayrım neden farklı doğrulama stratejileri gerektirir?
Cevap: Yazma modeli doğrulaması, işlemsel atomiklik, iş kuralı uygulaması ve alan olayı yayımlama doğruluğuna odaklanır; genellikle test izolasyonunu sağlamak için veritabanı işlem geri alma yeteneklerini kullanır. Okuma modeli doğrulaması, denormalizasyon doğruluğu, sorgu yanıt süreleri SLA'ları ve nihai tutarlılık pencere uyumu ile ilgilenir; bu, asenkron işleme gecikmelerini dikkate alan ve projeksiyonların tekrarlayan olayları veya sırasız teslimatları idempotent bir şekilde ele almasını doğrulayan doğrulamalar gerektirir.
Asenkron veri bütünlüğünü tehlikeye atmadan, projeksiyonların iyimser eşzamanlılık kontrolü uyguladığı durumlarda, okuma modellerinin sırasız olay teslimatını veya tekrarlayan olay işleme nasıl doğru bir şekilde ele aldığını doğrulamak için otomatik testleri nasıl tasarlarsınız?
Cevap: Kafka bölümü atamasını veya zaman damgası manipülasyonunu kullanarak kasıtlı olarak olayları sırasız olarak yayımlayan bir hata enjekte etme test cihazı oluşturun, ardından okuma modelinin ya olayları kuyruklayıp yeniden sıraladığını vektör saatlerini kullanarak ya da toplu işlem sürüm numaralarına dayanan idempotent güncellemeler uyguladığını doğrulayın. Projeksiyonun monotonik tutarlılığı koruyup korumadığını doğrulamak için, sıra numaralarının asla azalmadığını ve yeniden teslim edilen olayların (manuel offset sıfırlaması ile simüle edilmiş) hayalet kayıtlar oluşturmadığını veya sorgu deposundaki sayaçları birden fazla kez artırmadığını kontrol edin.