Apache Kafka'nın ne olduğunu, konular ve partition'ların nasıl çalıştığını ve Kafka'nın gerçek zamanlı olaylar, loglar ve veri boru hatlarında modern sistemlerde nerede kullanıldığını öğrenin.
Apache Kafka, dağıtık bir olay akışı platformudur. Basitçe söylemek gerekirse, birçok sistemin ne olduğuna dair gerçekleri yayınlamasına ve diğer sistemlerin bu gerçekleri—hızlı, ölçeklenebilir ve sıralı şekilde—okumasına izin veren, paylaşılan, dayanıklı bir “boru” gibidir.
Ekipler, verinin sistemler arasında güvenilir şekilde taşınması gerektiğinde Kafka'yı kullanır. Bir uygulamanın başka bir uygulamayı doğrudan çağırması (ve bunun yavaş ya da kapalı olması durumunda başarısız olması) yerine üreticiler olayları Kafka'ya yazar. Tüketiciler hazır olduklarında bunları okur. Kafka olayları yapılandırılabilir süreyle saklar; böylece sistemler kesintilerden kurtulabilir ve geçmişi yeniden işleyebilir.
Bu kılavuz, pratik bir Kafka zihinsel modeli edinmek isteyen ürün odaklı mühendisler, veri uzmanları ve teknik liderler içindir.
Temel yapı taşlarını (producers, consumers, topics, brokers), Kafka'nın partition'larla nasıl ölçeklendiğini, olayları nasıl saklayıp yeniden oynattığını ve olay tabanlı mimaride nerede durduğunu öğreneceksiniz. Ayrıca yaygın kullanım senaryoları, teslimat garantileri, güvenlik temelleri, operasyon planlaması ve Kafka'nın ne zaman (ve ne zaman değil) doğru araç olduğuna dair bilgiler de olacak.
Kafka, bir paylaşılan olay günlüğü olarak en kolay anlaşılır: uygulamalar olayları yazar, diğer uygulamalar bu olayları daha sonra okur—çoğu zaman gerçek zamanlı, bazen saatler veya günler sonra.
Producers yazanlardır. Bir producer “sipariş verildi”, “ödeme onaylandı” veya “sıcaklık ölçümü” gibi bir olay yayınlayabilir. Producers olayları doğrudan belirli uygulamalara göndermez—onları Kafka'ya yollar.
Consumers okuyanlardır. Bir consumer gösterge panosunu besleyebilir, sevkiyat iş akışını tetikleyebilir veya verileri analitiklere yükleyebilir. Tüketiciler olaylarla ne yapacaklarına karar verir ve kendi hızlarında okuyabilirler.
Kafka'daki olaylar konulara (topics) gruplanır; bunlar temelde adlandırılmış kategorilerdir. Örneğin:
orders siparişle ilgili olaylar içinpayments ödeme olayları içininventory stok değişiklikleri içinBir topic, o türdeki olaylar için “gerçeğin kaynağı” akışı olur; bu da birçok ekibin aynı veriyi özel çözümler yazmadan yeniden kullanmasını kolaylaştırır.
Bir broker, olayları depolayan ve tüketicilere sunan bir Kafka sunucusudur. Gerçekte Kafka, daha fazla trafikle başa çıkmak ve bir makine arızalansa bile çalışmaya devam etmek için bir cluster (birden çok broker) olarak çalışır.
Tüketiciler genellikle bir consumer group içinde çalışır. Kafka, okuma işini grup arasında dağıtır; böylece işleme kapasitesini arttırmak için daha fazla tüketici örneği ekleyebilirsiniz—her örneğin aynı işi yapmasına gerek kalmaz.
Kafka, işi ilgili olay akışları olan konulara bölerek ve ardından her konuyu o akışın daha küçük, bağımsız dilimleri olan partition'lara ayırarak ölçeklendirir.
Tek partition'lı bir topic, bir consumer grubunda aynı anda yalnızca bir tüketici tarafından okunabilir. Daha fazla partition ekleyin, daha fazla tüketici ekleyin ve olayları paralel olarak işleyebilirsiniz. Bu, Kafka'nın yüksek hacimli olay akışı ve gerçek zamanlı veri boru hatları için nasıl darboğaz yaratmadan çalıştığını gösterir.
Partition'lar ayrıca yükü broker'lara yaymaya yardımcı olur. Bir topic için tüm yazma/okuma işlemlerini tek bir makinenin yapması yerine, farklı partition'lar farklı broker'larda barınabilir ve trafiği paylaşabilir.
Kafka, tek bir partition içinde sıralamayı garanti eder. Eğer A, B ve C olayları aynı partition'a bu sırayla yazıldıysa, tüketiciler onları A → B → C şeklinde okur.
Partition'lar arasında sıralama garanti edilmez. Eğer belirli bir varlık için (müşteri veya sipariş gibi) katı sıralama gerekiyorsa, o varlığa ait tüm olayların aynı partition'a gitmesini sağlarsınız.
Producer'lar bir olay gönderirken bir key (örneğin order_id) ekleyebilir. Kafka bu anahtarı, ilgili olayları tutarlı olarak aynı partition'a yönlendirmek için kullanır. Bu, o anahtar için tahmin edilebilir sıralama sağlar ve yine de genel konu birçok partition'a yayılabilir.
Her partition başka broker'lara replike edilebilir. Bir broker arızalanırsa, replikalardan biri devralabilir. Replikasyon, Kafka'nın kritik iş yükleri için neden güvenilir olduğunun büyük nedenlerinden biridir: erişilebilirliği artırır ve uygulamaların kendi failover mantıklarını yazmasını gerektirmeden hata toleransı sağlar.
Apache Kafka'daki kilit fikir, olayların sadece iletilip unutulmadığıdır. Olaylar, sıralı bir günlük olarak diske yazılır; böylece tüketiciler şimdi ya da daha sonra okuyabilir. Bu, Kafka'yı sadece veriyi taşımak için değil, aynı zamanda ne olduğunu gösteren dayanıklı bir geçmiş tutmak için de kullanışlı kılar.
Producer bir olayı bir topic'e gönderdiğinde, Kafka bunu broker'da depolamaya ekler. Tüketiciler daha sonra bu depolanan günlükten kendi hızlarında okur. Bir tüketici bir saat boyunca kapalıysa, olaylar yine de vardır ve geri döndüğünde yakalanabilir.
Kafka olayları retention politikalarına göre saklar:
Retention konu başına yapılandırılır; bu sayede denetim (audit) konuları ile yüksek hacimli telemetri farklı şekilde ele alınabilir.
Bazı konular tarihsel arşivden ziyade değişiklik günlüğü gibidir—örneğin “müşteri ayarları”. Log kompaksiyonu, her anahtar için en azından en güncel kaydı tutar; eski üstün gelen kayıtlar kaldırılabilir. Böylece en son duruma dair dayanıklı bir gerçek kaynağı elde ederken sınırsız büyümeden kaçınırsınız.
Olaylar saklandığı için onları yeniden oynatabilir ve durumu yeniden oluşturabilirsiniz:
Uygulamada yeniden oynatma, bir tüketicinin nereden okumaya başladığını (offset) kontrol ederek yönetilir; bu, sistemler değişirken ekipler için güçlü bir güvenlik ağı sağlar.
Kafka, sistemin parçaları arızalansa bile verinin akmasını sağlamak üzere tasarlanmıştır. Bunu replikasyon, her partition için kimin “lider” olduğuna dair net kurallar ve yapılandırılabilir yazma onayları (acks) ile yapar.
Her topic partition'ının bir lider broker'ı ve diğer broker'larda bir veya daha fazla follower replikası vardır. Producer ve consumer'lar o partition için lidere konuşur.
Takipçiler liderin verisini sürekli kopyalar. Eğer lider kapanırsa, Kafka yeterince güncel bir takipçiyi yeni lider yapabilir, böylece partition erişilebilir kalır.
Bir broker arızalanırsa, lider olduğu partition'lar kısa süreliğine erişilemez hale gelebilir. Kafka'nın controller'ı arızayı tespit eder ve o partition'lar için lider seçimi tetikler.
Eğer en az bir takipçi yeterince senkron ise devralabilir ve istemciler üretmeye/tüketmeye devam eder. Eğer senkron bir replik yoksa, ayarlarınıza bağlı olarak Kafka yazmayı durdurabilir; bu, onaylanmış veriyi kaybetmemek için yapılır.
İki ana ayar dayanıklılığı şekillendirir:
Kavramsal olarak:
Yeniden denemeler sırasında çoğaltmaları azaltmak için ekipler genellikle güvenli acks ile idempotent producer'ları ve sağlam tüketici işleme desenlerini birleştirir.
Daha yüksek güvenlik genelde daha fazla onay beklemek ve daha çok replikanın senkron kalmasını gerektirir; bu da gecikmeyi artırıp tepe verimini düşürebilir.
Daha düşük gecikme ayarları telemetri veya clickstream gibi ara sıra veri kaybının kabul edilebilir olduğu durumlar için uygundur; ancak ödemeler, envanter ve denetim kayıtları genelde ekstra güvenliği haklı çıkarır.
Olay tabanlı mimari (EDA), işte meydana gelen şeylerin—bir sipariş verildi, bir ödeme onaylandı, bir paket gönderildi—sistemin diğer bölümlerinin tepki verebileceği olaylar olarak temsil edildiği bir sistem kurma yaklaşımıdır.
Kafka genellikle EDA'nın merkezinde, paylaşılan “olay akışı” olarak konumlanır. Servis A, Servis B'yi doğrudan çağırmak yerine bir Kafka topic'ine (OrderCreated gibi) olay yayınlar. İstediğiniz sayıda diğer servis bu olayı tüketebilir ve eylem alabilir—e-posta gönderme, envanter ayırma, dolandırıcılık kontrolü başlatma—Servis A'nın bunların varlığını bilmesine gerek kalmadan.
Servisler olaylarla iletişim kurduğunda, her etkileşim için request/response API'leri koordine etmek zorunda kalmazsınız. Bu, ekipler arası sıkı bağımlılıkları azaltır ve yeni özellik eklemeyi kolaylaştırır: mevcut bir olayı tüketen yeni bir tüketici eklemek genellikle üreticiyi değiştirmeyi gerektirmez.
EDA doğal olarak asenkrondur: producer'lar olayları hızlıca yazar, tüketiciler bunları kendi hızlarında işler. Trafik zirvelerinde Kafka, akışı tamponlayarak aşağı akış sistemlerin anında çökmesini engellemeye yardımcı olur. Tüketiciler yetişmek için yatay ölçeklenebilir; bir tüketici geçici olarak kapansa, kaldığı yerden devam edebilir.
Kafka'yı sistemin “etkinlik akışı” olarak düşünün. Producers gerçekleri yayınlar; consumers ilgilendikleri gerçeklere abone olur. Bu desen gerçek zamanlı veri boru hatlarını ve olay tabanlı iş akışlarını mümkün kılarken servisleri daha basit ve bağımsız tutar.
Kafka genellikle, birçok küçük "olmuş şey"in (olayların) sistemler arasında—hızlı, güvenilir ve birden çok tüketicinin yeniden kullanabileceği şekilde—taşınması gerektiğinde ortaya çıkar.
Uygulamalar genelde ekleme-yalnızca bir geçmişe ihtiyaç duyar: kullanıcı girişleri, izin değişiklikleri, kayıt güncellemeleri veya yönetici işlemleri. Kafka, bu olayların merkezi bir akışı olarak iyi çalışır; güvenlik araçları, raporlama ve uyumluluk dışa aktarımları aynı kaynağı okuyabilir. Olaylar bir süre saklandığı için, hatalar veya şema değişiklikleri sonrası denetim görünümünü yeniden oluşturmak için tekrar oynatılabilirler.
Servisler birbirini doğrudan çağırmak yerine “sipariş oluşturuldu” veya “ödeme alındı” gibi olayları yayınlayabilir. Diğer servisler abone olur ve kendi zamanlarında tepki verir. Bu sıkı bağlılığı azaltır, kısmi arızalar sırasında sistemlerin çalışmaya devam etmesine yardımcı olur ve örneğin dolandırıcılık kontrolleri gibi yeni yetenekler eklemeyi kolaylaştırır.
Kafka, operasyonel sistemlerden analitik platformlarına veri taşımada sık kullanılan bir omurgadır. Ekipler uygulama verilerindeki değişiklikleri akış halinde alıp ambar veya data lake'e düşük gecikmeyle teslim edebilir; ağır analiz sorgularının üretim uygulamasını etkilemesini önler.
Sensörler, cihazlar ve uygulama telemetrisi sık sık zirveler halinde gelir. Kafka bu patlamaları emebilir, güvenli şekilde tamponlayabilir ve aşağı akış işlemenin yakalamasına izin verir—izleme, uyarı ve uzun vadeli analiz için kullanışlıdır.
Kafka sadece brokerlar ve topic'lerden ibaret değildir. Çoğu ekip, günlük veri hareketi, akış işleme ve operasyonel işler için Kafka'yı pratik hale getiren yardımcı araçlara dayanır.
Kafka Connect, veriyi Kafka'ya getirmek (source) ve Kafka'dan çıkarmak (sink) için entegrasyon çerçevesidir. Tek seferlik boru hattı kodları inşa etmek yerine Connect'i çalıştırır ve konektörleri yapılandırırsınız.
Yaygın örnekler: veritabanlarından değişiklikleri çekmek, SaaS olaylarını almak veya Kafka verisini bir veri ambarına ya da obje depolamaya teslim etmek. Connect aynı zamanda yeniden denemeler, offset yönetimi ve paralellik gibi operasyonel konuları standardize eder.
Connect entegrasyon içindir; Kafka Streams hesaplama içindir. Uygulamanıza eklediğiniz bir kütüphane ile akışları gerçek zamanlı dönüştürebilirsiniz—olayları filtreleme, zenginleştirme, akışları birleştirme ve agregatlar oluşturma (ör. "dakikadaki siparişler").
Streams uygulamaları konulardan okur ve konulara yazar; bu nedenle olay tabanlı sistemlere doğal olarak uyar ve daha fazla örnek ekleyerek ölçeklenebilir.
Birden çok ekip olay yayınladıkça tutarlılık önemlidir. Şema yönetimi (çoğunlukla bir şema kaydı aracılığıyla) bir olayın hangi alanlara sahip olması gerektiğini ve zaman içinde nasıl evrileceğini tanımlar. Bu, bir üreticinin bir alanın adını değiştirmesi gibi tüketiciyi bozacak hataların önlenmesine yardımcı olur.
Kafka operasyonel olarak hassastır, bu yüzden temel izleme gereklidir:
Çoğu ekip ayrıca dağıtım, konu yapılandırması ve erişim kontrol politikaları için yönetim UI'ları ve otomasyon kullanır (bakınız /blog/kafka-security-governance).
Kafka genelde "dayanıklı günlük + tüketiciler" olarak tanımlanır, ama ekiplerin gerçekten önem verdiği soru şudur: her olayı bir kez mi işleyeceğim ve bir şey ters giderse ne olacak? Kafka size yapı taşları verir; siz takasları seçersiniz.
At-most-once: olayları kaybedebilirsiniz ama çoğaltma olmaz. Bu, tüketici pozisyonunu (offset) önce commit edip sonra işini bitirmeden çökerse olur.
At-least-once: olayları kaybetmezsiniz ama tekrarlar olabilir (örneğin tüketici olayı işledikten sonra çöker ve yeniden işler). Bu en yaygın varsayılandır.
Exactly-once: hem kaybı hem de çoğaltmayı önlemeye çalışır. Kafka'da bu genelde transactional producer'lar ve uyumlu işleme (çoğunlukla Kafka Streams ile) gerektirir. Güçlüdür ama daha sınırlayıcıdır ve dikkatli kurulum ister.
Pratikte birçok sistem at-least-once'ı kabul eder ve ek önlemler alır:
Bir tüketici offset ile partition içindeki son işlenen kaydın konumunu belirtir. Offset commit etmek, "buraya kadar işledim" demektir. Çok erken commit kayba yol açar; çok geç commit tekrar işlemeye neden olur.
Yeniden denemeler sınırlı ve görünür olmalıdır. Yaygın bir desen:
Bu, tek bir "zehirli mesaj"ın tüm consumer grubunu engellemesini önlerken veriyi ileride düzeltmek üzere saklar.
Kafka genellikle iş açısından kritik olayları taşır (siparişler, ödemeler, kullanıcı etkinliği). Bu yüzden güvenlik ve yönetişim tasarımın bir parçası olmalıdır.
Kimlik doğrulama “sen kimsin?” sorusunu, yetkilendirme ise “ne yapmana izin var?” sorusunu yanıtlar. Kafka'da kimlik doğrulama genellikle SASL (ör. SCRAM veya Kerberos) ile yapılır; yetkilendirme ise topic, consumer group ve cluster seviyelerinde ACL'lerle uygulanır.
Pratik bir desen en az ayrıcalık (least privilege) prensibidir: üreticiler yalnızca sahip oldukları topic'lere yazsın, tüketiciler yalnızca ihtiyaç duydukları topic'leri okusun. Bu, kimlik bilgileri sızarsa hasarı sınırlar.
TLS, uygulamalar, broker'lar ve araçlar arasındaki veriyi şifreler. Olmadan, olaylar yalnızca genel internette değil, dahili ağlarda da ele geçirilebilir. TLS ayrıca broker kimliklerinin doğrulanmasına yardımcı olur ve MITM (ortadaki adam) saldırılarını zorlaştırır.
Birden çok ekip bir küme paylaşıyorsa, koruyucu önlemler önemlidir. Açık konu adlandırma kuralları (ör. <ekip>.<alan>.<olay>.<versiyon>) sahipliği görünür kılar ve politikaların tutarlı uygulanmasına yardımcı olur.
Adlandırmayı kota ve ACL şablonları ile eşleştirin ki gürültülü bir iş yükü diğerlerini tüketmesin ve yeni servisler güvenli varsayılanlarla başlasın.
Kafka'yı olay geçmişi için bir kayıt sistemi olarak ele almayı ancak niyetliyorsanız yapın. Olaylar PII içeriyorsa veri minimizasyonu yapın (tam profiller yerine ID gönderin), alan düzeyinde şifreleme düşünün ve hangi konuların hassas olduğunu belgeleyin.
Retention ayarları yasal ve iş gereksinimleriyle eşleşmeli. Politika "30 gün sonra sil" diyorsa, 6 ay boyunca veriyi "acaba lazım olur mu" diye tutmayın. Düzenli gözden geçirmeler ve denetimler konfigürasyonların evrimle uyumlu kalmasını sağlar.
Apache Kafka'yı çalıştırmak "kur ve unut" işi değildir. Bir hizmet gibi davranır: birçok ekip buna bağlıdır ve küçük hatalar bile aşağı akış uygulamalarına yayılabilir.
Kafka kapasitesi çoğunlukla düzenli olarak tekrar değerlendirdiğiniz bir muhasebe problemidir. En büyük etkenler partition sayısı (paralellik), throughput (MB/s giren ve çıkan) ve depolama büyümesi (retention ile)dir.
Trafik iki katına çıkarsa, yükü broker'lara yaymak için daha fazla partition gerekebilir, retention için daha fazla disk gerekir ve replikasyon için daha fazla ağ bant genişliği gerekir. Pratik bir alışkanlık, tepe yazma oranını tahmin etmek, bunu retention ile çarpmak ve disk büyümesini tahmin etmek, sonra replikasyon ve beklenmeyen başarı için tampon eklemektir.
Sunucuları ayakta tutmanın ötesinde rutin işler bekleyin:
Maliyetler diskler, ağ çıkışı ve broker sayısı/ebadı tarafından yönlendirilir. Yönetilen Kafka, personel yükünü azaltıp yükseltmeleri sadeleştirirken; kendi kendine barındırma, deneyimli operatörleriniz varsa ölçekte daha ucuz olabilir. Takas, kurtarma süresi ve on-call yüküdür.
Ekipler tipik olarak şunları izler:
İyi panolar ve alarmlar Kafka'yı bir "gizem kutusu" olmaktan çıkarıp anlaşılır bir hizmet haline getirir.
Kafka, çok sayıda olayı güvenilir şekilde taşımak, bir süre saklamak ve birçok sistemin aynı veri akışına kendi hızlarında tepki vermesine izin vermek istediğinizde iyi bir seçenektir. Özellikle yeniden oynatma (backfill, audit, yeni servis kurulumunda) gerektiğinde ve zaman içinde daha fazla üretici/tüketici ekleneceğini bekliyorsanız faydalıdır.
Kafka genellikle iyi işler:
Kafka, ihtiyaçlar basitse aşırıya kaçabilir:
Bu durumlarda işletme yükü (küme boyutlandırma, yükseltmeler, izleme, on-call) faydaları aşabilir.
Kafka ayrıca veritabanlarının (kayıt sistemi), cache'lerin (hızlı okuma) ve batch ETL araçlarının yerini almaz—tamamlayıcıdır.
Sorun:
Bu soruların çoğuna “evet” yanıtı veriyorsanız Kafka genelde mantıklı bir seçimdir.
Kafka, birçok sistemin gerçek zamanlı olay akışları için ortak bir “gerçeğin kaynağı” olduğu durumlarda en iyi şekilde uyar: birçok üretici olay üretiyor (sipariş oluşturuldu, ödeme yetkilendirildi, envanter değişti) ve birçok tüketici bu olayları boru hatlarını, analitiği ve reaktif özellikleri güçlendirmek için tüketiyor.
Başlangıçta dar ve yüksek değerli bir akış seçin—örneğin downstream servisler (e-posta, dolandırıcılık, sevkiyat) için "OrderPlaced" olaylarını yayınlamak. İlk günden Kafka'yı genel bir kuyruk haline getirmeyin.
Şunları yazın:
Erken şemaları basit ve tutarlı tutun (zaman damgası, kimlikler ve net bir olay adı). Şemaları baştan zorunlu kılmak mı yoksa zaman içinde dikkatli evrim mi yapacağınız konusunda karar verin.
Kafka, şu şeylerin bir sahibi olduğunda başarılı olur:
Hemen izleme ekleyin (consumer lag, broker sağlığı, throughput, hata oranları). Eğer henüz bir platform ekibiniz yoksa, yönetilen bir teklif ile başlayın ve net sınırlar belirleyin.
Bir sistemden olay üretin, bir yerde tüketin ve döngüyü uçtan uca kanıtlayın. Ancak sonra daha fazla tüketici, partition ve entegrasyon ekleyin.
Hızla fikirden çalışan bir olay tabanlı servise geçmek istiyorsanız, Koder.ai gibi araçlar çevresindeki uygulamayı (React web UI, Go backend, PostgreSQL) prototiplemenize yardımcı olabilir ve sohbet tabanlı iş akışıyla producer/consumer eklemeyi hızlandırır. Bu araç, dahili panolar ve hafif tüketici servisleri oluşturmak için planlama modu, kaynak kodu dışa aktarma, dağıtım/barındırma ve anlık görüntülerle geri alma gibi özellikler sunar.
Eğer bunu olay tabanlı yaklaşıma haritalıyorsanız, bakınız /blog/event-driven-architecture. Maliyet ve ortam planlaması için bakınız /pricing.
Kafka, olayları kalıcı, ekleme-yalnızca (append-only) günlüklerde saklayan dağıtık bir olay akışı platformudur.
Üreticiler (producers) olayları konulara (topics) yazar; tüketiciler (consumers) bunları bağımsız olarak okur (çoğunlukla gerçek zamanlı ama istenirse daha sonra da).
Birden çok sistemin aynı olay akışına ihtiyacı olduğunda, gevşek bağlılık ve geçmişi yeniden oynatma (replay) gerektirdiğinde Kafka kullanın.
Özellikle faydalıdır:
Bir topic, orders veya payments gibi olayların adlandırılmış kategorisidir.
Bir partition ise bir topic'in dilimidir ve şunları sağlar:
Kafka sadece tek bir partition içinde sıralamayı garanti eder.
Kafka, kayıt anahtarı (örneğin order_id) ile ilişkili olayları aynı partition'a yönlendirir.
Pratik kural: bir varlık için (sipariş/müşteri) sıralama gerekiyorsa, o varlığı temsil eden bir anahtar kullanın ki olaylar aynı partition'a düşsün.
Bir consumer group, bir topic için işi paylaşan tüketici örnekleri kümesidir.
Bir grup içinde:
İki farklı uygulamanın her olayı alması gerekiyorsa, farklı consumer group'lar kullanmalıdırlar.
Kafka, konulara göre disk üzerinde olayları saklar, böylece tüketiciler kesinti sonrası yakalayabilir veya geçmişi yeniden işleyebilir.
Yaygın saklama türleri:
Saklama konu başına ayarlanır; audit amaçlı konular ile yüksek hacimli telemetri farklı tutulabilir.
Log kompaksiyonu, her anahtar için en azından en güncel kaydı tutar ve zamanla eskilerini kaldırır.
Bu, her değişikliğin tamamını değil, her anahtarın güncel durumunu korumak istediğiniz "mevcut durum" akışları için uygundur.
En yaygın uçtan uca desen "at-least-once" şeklindedir: olaylar kaybolmaz ama çoğaltmalar olabilir.
Güvenli uygulamalar için:
Offsetler, her partition için tüketicinin son işlenen konumudur.
Erken commit ederseniz çökme durumunda iş kaybolur; geç commit ederseniz yeniden işleme ve çoğaltma olur.
Yaygın operasyonel desen: arızalar için sınırlı yeniden deneme, ardından başarısız kaydı bir dead-letter topic'e gönderme—böylece tek bir kötü kayıt tüm grup işini engellemez.
Kafka Connect, veri kaynaklarını (source) Kafka'ya ve Kafka'dan hedeflere (sink) taşımak için konektörler çalıştıran entegrasyon çerçevesidir. Tek seferlik boru hattı kodları yazmak yerine Connect yapılandırılır.
Kafka Streams ise uygulamalarınıza eklediğiniz bir kütüphanedir; konulardan okur, filtreler, zenginleştirir, join'ler ve toplar, sonra sonuçları konulara yazar.
Kısaca: Connect entegrasyon içindir; Streams hesaplama/işleme içindir.