Kafka tüketicisi çökmeden sonra işlemeye nasıl devam eder

Kafka tüketicileri sunucu yeniden başlatma, çökme veya ağ hatasından sonra işlemeye kaldıkları yerden devam etmelidir. Bu makale commit edilmiş offset'lerin, consumer group'un ve manuel commit'in bu süreçte nasıl çalıştığını C# ve Confluent.Kafka örneğiyle anlatıyor. Ayrıca çift teslim edilen mesajların nasıl ele alınacağını ve zehirli mesajların nasıl yönetileceğini inceliyor.

Kilit noktalar

• Commit edilen offset, bir sonra okunacak kaydın konumudur; işlenmemiş kaydı commit etmek onu atlamaya yol açar.
• EnableAutoCommit = false ve EnableAutoOffsetStore = false ayarlarıyla commit zamanını kendiniz belirleyin.
• Commit işlemi, iş mantığı başarıyla tamamlandıktan sonra yapılmalıdır.
• Tekrar teslim edilen mesajlar için işlemi idempotent yapın, örneğin olay kimliğini benzersiz anahtarlı bir tabloda saklayarak.
• Veritabanı işlemi ile Kafka offset commit'i ayrı atomik birimlerdir; Kafka transaction'ları SQL veya dış API çağrılarını kapsamaz.
• Sınırlı yeniden deneme sonrası zehirli mesajları dead-letter topic'e yönlendirin ve consumer lag, commit hataları ile rebalance sıklığını izleyin.

Bir Kafka tüketicisi uzun süre sorunsuz çalıştıktan sonra bir çökme ya da ağ kesintisi yüzünden durabilir. Yeniden başladığında hangi mesajdan devam edeceği, offset'in ne zaman commit edildiğine ve iş mantığının tamamlanıp tamamlanmadığına bağlıdır. Kafka, bir veritabanı güncellemesinin ya da dış API çağrısının yarıda kalıp kalmadığını kendiliğinden bilmez; bu yüzden uygulamanın işleme ile commit adımlarını birlikte yönetmesi gerekir.

Yazı, Confluent.Kafka ile EnableAutoCommit ve EnableAutoOffsetStore ayarlarını kapatıp işlemeden sonra commit yapma desenini gösteriyor. Commit edilen offset'in bir sonraki okunacak kaydı gösterdiğini, başarısız kayıtların commit edilmeden atlanmaması gerektiğini vurguluyor. Tekrar eden teslimlere karşı idempotent yazma, benzersiz kısıtlı bir işlenmiş olay tablosu ve dead-letter topic gibi yaklaşımlar da ele alınıyor. Tüketici lag'i, commit hataları ve rebalance sıklığı gibi metriklerin izlenmesi de önerilen pratikler arasında.

Gerçek dünyada kullanımı

• Sipariş işleyen bir arka plan servisinin deploy sırasında yeniden başladığında siparişleri çift işlememesi gerektiği durum.
• Ödeme sağlayıcısına istek gönderen bir tüketicide tekrar teslimlere karşı idempotency anahtarı kullanılması.
• Bozuk şemalı mesajların tüm partition'ı durdurmadan dead-letter topic'e aktarılması gereken veri hattı.

Neden önemli

Otomatik commit kullanan bir tüketici çökerse iş yarıda kalabilir veya kayıtlar sessizce atlanabilir. Commit zamanını ve tekrar teslimleri kendiniz yönetmek, Kafka tabanlı iş akışlarınızı üretimde güvenilir kılar.

Benzer haberler

• C# interface'lerinde collection dönüş tipleri: interface, view ve snapshot farkıDLNick Cosentino (Dev Leader)2 gün önce
• C# ile dinamik Gauss-Legendre sayısal integrasyonu: düğüm ve ağırlıkları taşma olmadan anında hesaplamakHBHabr C# (ru)2 gün önce
• C# olayları ve delegate'ler: sözleşme, abonelik ve bildirimDLNick Cosentino (Dev Leader)3 gün önce