Apache Kafka ekosistemleri için kapsamlı bir manuel test metodolojisi, şema yaşam döngüsü yönetimi, küme stres altındaki tüketici davranışları ve hata durumu yönetimi konularında yapılandırılmış bir keşif gerektirir. Test uzmanları, Confluent Schema Registry uyumluluk kurallarını doğrulamak için kasten şema değişiklikleri içeren senaryolar tasarlamalıdır. Bu, veri sözleşmelerinin, dağıtık ekipler arasında mevcut tüketicileri kırmadan sağlam kalmasını sağlar.
Bu yaklaşım, yeniden dengelemek için kontrollü tüketici grubu üye değişiklikleri oluşturarak, ardından offset taahhütlerini ve mesaj sıralama garantilerini doğrulamayı içerir. Ayrıca, hatalı Avro yüklerinin manuel olarak enjekte edilmesi, hata yönetim mekanizmalarının zehirli hapları ana tüketici boru hattını durdurmadan ölü mektup konularına doğru yönlendirdiğinden emin olmak için önemlidir. Bu faaliyetler, ağ parçalanmaları sırasında denetçi seçiminin istikrarını doğrulamak için ZooKeeper veya KRaft meta verileri ile doğrudan etkileşimi gerektirir.
Bir finansal hizmetler firmasına, ödeme işlemeyi IBM MQ'dan Kafka 3.5'e taşıma sırasında kritik veri kaybı riskleri ile karşılaştık. Sistem, Confluent Schema Registry ile işlem olayları için Avro şemalarını kullanıyordu ve şema değişikliklerinin, yeniden dengeleme olaylarının çifte ödeme kayıtları oluşturmasına neden olduğunu keşfettik. Göç teslim tarihi oldukça sıkıydı ve otomatik test suite geliştirmek için hiç zaman kalmamıştı.
İlk yaklaşım, yalnızca gömülü Kafka brokerları ile mevcut otomatik entegrasyon testlerine güvenmeyi öneriyordu. Bu, hızlı geri bildirim döngüleri ve kolay CI/CD entegrasyonu sağlasa da, gerçek dünya ağ gecikmesi etkilerini ve yalnızca çok günlük ıslak testler sırasında ortaya çıkan eşzamanlı şema evrimi senaryolarını yakalayamadı.
İkinci yaklaşım, önceden tanımlanmış hedefler olmadan saf keşif testleri yapmayı öneriyordu. Bu, beklenmedik davranışları keşfetmek için maksimum esneklik sağlarken, üretici idempotenslik hataları gibi kritik hata modlarının tutarsız kapsamını riske atarak, tam olarak bir kez işleme açısından sistematik belgelendirme eksikliği nedeniyle kenar durumlarını atlama riskine yol açıyordu.
Yapılandırılmış test hedeflerini karmaşa mühendisliği prensipleri ile birleştiren bir hibrit metodoloji seçtik. Bu yaklaşım, şema uyumluluk matrislerinin sistematik kapsamını sağlarken, ortaya çıkan davranışların adaptif keşfine olanak tanıdı. Tüketici gecikmesini ve yeniden dengeleme kalıplarını gözlemlemek için, zirve mesaj alma sırasında broker düğümlerinin yuvarlak yeniden başlatmalarını manuel olarak tetikledik, aynı zamanda geriye dönük uyumlu ve uyumsuz değişiklikler ile şemaları evrimleştirerek kayıt uygulamasını doğruladık.
Sonuçlar, çift işleme olaylarını ortadan kaldırdı ve üretime ulaşan kırılma değişikliklerini önleyen bir şema yönetim süreci oluşturdu. Tüketici grupları, simüle edilmiş düğüm arızaları sırasında istikrarlı bir verim sağladı ve ölü mektup kuyruğu bozulmuş işlem mesajlarını ana işleme akışını etkilemeden başarılı bir şekilde yalıttı.
Brokerlar yazmaları onayladığında, ancak ağ zaman aşımının istemci tarafında yeniden denemelere neden olduğu durumlarda, Kafka üretici tekrarlarının tam olarak bir kez anlamını ihlal etmediğini manuel olarak nasıl doğrularsınız?
Adaylar genellikle mesaj meta verilerindeki Üretici Kimliği (PID) ve sıralama numaralarını incelemenin önemini gözden kaçırır. Manuel test sırasında, üreticiler ve tüketiciler üzerinde DEBUG günlüğünü etkinleştirmelisiniz; ardından zaman aşımı koşullarını simüle etmek için Toxiproxy veya iptables kuralları kullanarak kasten ağ gecikmeleri eklemelisiniz. Kafka brokerının, tüketici kayıtlarındaki LogAppendTime ve Offset değerlerini kontrol ederek, tekrar yetkilendirme mantığının aynı sıralama numaralarını reddettiğini doğrulayın.
Ana içgörü, manuel test uzmanlarının __consumer_offsets konusunu doğrudan kafka-console-consumer ile koordine meta verileri görüntüleyecek şekilde kontrol etmesidir; böylece işlem işaretçileri (Taahhüt ve İptal) günlük segmentlerinde doğru bir şekilde görünür.
Tüketici gruplarında StickyAssignor ile RangeAssignor kullanırken partisyon atama dengesizliğini tanımlayan manuel teknikler nelerdir?
Birçok test uzmanı, partisyon dağılımının yeniden dengeleme sırasında tam olarak bir kez garanti verilerini doğrudan etkilediğini fark etmez. Bunu manuel olarak doğrulamak için, Thread.sleep() varyasyonları kullanarak yapay işleme gecikmeleri ile tüketici örnekleri oluşturun; ardından tüketici grubu açıklamasını kafka-consumer-groups.sh aracılığıyla izleyin ve tüketicileri ekleyip çıkararak yeniden dengelemeleri tetikleyin.
Current-OFFSET, Log-END-OFFSET ve LAG sütunlarını gözlemleyin; önemli bir varyans, görev sıralama garantilerini ihlal edebilecek atama dengesizliğini gösterir.
Uyumluluk denetimlerine bağımlı olmadan Schema Registry uyumluluk modlarını (GERİ, İLERİ, TAM) nasıl doğrulardınız?
Başlangıç seviyesindeki testerler sıklıkla kayıt düzeyindeki uyumluluk uygulaması ile çalışma zamanındaki serileştirme davranışları arasındaki ayrımı kaçırır. Belirli uyumluluk ayarları ile şema sürümlerini kaydederek, ardından daha yeni istemci kütüphaneleri ile daha eski şema sürümlerini kullanarak mesaj üreterek manuel test yapın (ve tersine).
Schema Registry REST API'sine karşı curl komutları kullanarak şemaları kaydedin ve uyumluluk uç noktalarının beklendiği gibi doğru veya yanlış sonuç döndürdüğünü doğrulayın. Ardından, üreticilerin tüketicilerden geride kaldığı senaryoları simüle etmek için açık şema sürümleri ile kafka-avro-console-producer kullanın. Kritik doğrulama , beklenen şemayı ihlal eden mesajları aldığında tüketici uygulamalarındaki SerializationException işleme davranışını gözlemlemektir; böylece SpecificRecord uygulamalarının, iş mantığını bozan alanları sessizce bırakmak veya varsayılan null ile doldurmak yerine zarif bir şekilde başarısız olmasını sağlamak.