Apache Kafka'yı Anlamak: Topic, Partition, Consumer Group ve İlk Olay Akışınız

Kafka'yı yalnızca “arka plan işleri kuyruğu” olarak düşünmek eksik kalır. Daha iyi model, birçok uygulamanın bağımsız olarak okuyabildiği dağıtık ve eklemeli olay günlüğüdür. Sipariş servisi siparişin verildiğini kaydeder; stok, analiz ve bildirim servisleri kendi hızlarında tepki verir. Sipariş servisi hepsini kullanıcı isteği sırasında tek tek çağırmak zorunda kalmaz.

Bunun karşılığında anahtar, sıralama, saklama süresi ve hata sonrası devam davranışını tasarlamalısınız. Bir olayın Kafka içindeki yolunu adım adım inceleyelim.

Önce beş kavram

Producer kayıt yazar. Topic ilişkili olay akışının adıdır. Topic bir veya daha fazla partition içerir; her partition sıralı bir günlük gibidir. Broker partition'ları saklar ve istemcilere hizmet verir. Consumer kayıtları okur; aynı consumer group içindeki örnekler partition'ları paylaşır.

Kayıtta değer, isteğe bağlı anahtar, başlıklar ve zaman damgası bulunur. Kafka partition içinde bir offset verir. (topic, partition, offset) kayıt konumunu belirler. İki farklı partition'daki offset 42 arasında genel bir zaman sırası yoktur.

Dört partition'lı orders.placed.v1 topic'inde anahtarı orderId seçerseniz aynı siparişe ait kayıtlar, kararlı bölümleme politikası altında aynı partition'a gider. Kafka sıralamayı partition içinde garanti eder; bütün topic için tek bir sıralama sunmaz. Partition sayısını sonradan değiştirmek, yeni kayıtların anahtar dağılımını değiştirebilir.

Olay sözleşmesini belirleyin

{
  "eventId": "evt_01JQ8X8F",
  "eventType": "OrderPlaced",
  "schemaVersion": 1,
  "occurredAt": "2026-09-29T10:30:00Z",
  "orderId": "ord_782",
  "customerId": "cus_17",
  "totalMinor": 12900,
  "currency": "USD"
}

eventId tekrar işleme kontrolü içindir. Kafka kayıt anahtarı orderId olur. totalMinor tutarı para biriminin en küçük birimiyle ifade eder. Olaylar saklanıp yeniden okunabildiği için gereksiz kişisel verileri eklemeyin. OrderPlaced gerçekleşmiş bir olguyu anlatır; ReserveInventory ise ayrı sahipliği ve hata davranışı olan bir komuttur.

Yazma, okuma ve ilerleme

Producer cluster bilgisini alır, partition seçer ve kaydı lider broker'a yollar. Replikalar başka broker'larda kopya tutabilir. Onay ayarları gönderimin ne zaman başarılı sayılacağını etkiler. Consumer kendine atanmış partition'lardan veriyi çeker.

Consumer group ilerlemesini commit edilmiş offset ile kaydeder. Offset commit etmek kaydı topic'ten silmez. inventory-reservation ve sales-analytics iki ayrı grup olarak aynı olayı okuyabilir, bağımsız ilerleyebilir ve saklama süresi içindeki olayları tekrar oynatabilir.

Dört partition için aynı grupta üç consumer çalışırsa partition'lar paylaşılır. Beşinci consumer bu topic'ten ek aktif partition alamaz. Bir örnek katıldığında veya düştüğünde rebalance ile atamalar değişebilir. Kodunuz aynı partition'a sonsuza kadar sahip olduğunu varsaymamalıdır.

Kafka'yı yerelde deneyin

Resmi hızlı başlangıç resmi Docker imajını anlatır:

docker run -d --name kafka-demo -p 9092:9092 apache/kafka:4.3.1

Aşağıdaki komutları Kafka bin/ araçlarının bulunduğu ve broker'a localhost:9092 üzerinden erişen ortamda çalıştırın:

bin/kafka-topics.sh --create --topic quickstart-events \
  --bootstrap-server localhost:9092
bin/kafka-topics.sh --describe --topic quickstart-events \
  --bootstrap-server localhost:9092
bin/kafka-console-producer.sh --topic quickstart-events \
  --bootstrap-server localhost:9092

Producer terminaline birkaç satır yazın. Ayrı bir terminalde okuyun:

bin/kafka-console-consumer.sh --topic quickstart-events \
  --from-beginning --bootstrap-server localhost:9092

CLI araçlarınız container içindeyse oradaki ikili dosyaları ve uygun yerel adresi kullanın. Tek broker yalnızca öğrenme içindir; üretim hata toleransını kanıtlamaz. Sonra aynı grupta iki consumer, ayrı grupta bir consumer deneyin. Paralelliği görmek için birden fazla partition'lı topic oluşturun.

Anahtar ve partition sayısı iş kararıdır

orderId sipariş içi sıralamayı korur. customerId müşteri içi sırayı korur ama çok aktif bir müşteriyi sıcak partition'a dönüştürebilir. Sabit anahtar bütün yükü bir yere toplar; rastgele anahtar ilişkili olay sırasını kaybettirir. Önce “hangi varlığın olayları sıralı kalmalı?” sorusunu yanıtlayın.

Partition sayısı bir grubun aktif tüketici paralelliğine üst sınır koyar. Çok fazla partition metadata, dosya ve replikasyon yükü yaratır. Beklenen yükü ölçün ve büyümeyi planlayın; “dağıtık” diye gereksiz büyük sayı seçmeyin.

Saklama, tekrar oynatma ve compaction

Kafka kayıtları okunduktan hemen sonra silmez. Zaman veya boyut temelli retention sonunda eski kayıtlar kaldırılır. Bir grup bu süreden daha uzun kapalı kalırsa eski offset'inden devam edemeyebilir. Bu riski izleyin.

Log compaction, anahtar başına zaman içinde güncel bir değer saklayan durum günlükleri için uygundur; tam ve değişmez bir denetim geçmişi değildir. Anahtarlı ve null değerli tombstone silinmeyi ifade eder. Olay geçmişi ile güncel durum changelog'unun ihtiyaçlarını karıştırmayın.

Replay bir görünümü yeniden oluşturabilir, ancak tekrarlanan e-posta veya ödeme yan etki yaratır. eventId ile idempotent işlem uygulayın. Tek bir arka plan e-postası için sıradan job queue çoğu zaman yeterlidir; bağımsız aboneler ve tekrar okuma gerekiyorsa Kafka'nın maliyeti karşılık bulur.

İlk projeniz

Geliştirme ortamında orders.placed.v1 oluşturun, orderId anahtarıyla örnek olaylar gönderin, stok ve analiz gruplarını çalıştırın. Bir consumer'ı durdurup yeniden başlatın. README'de anahtar seçimini, devam offset'ini, retention sınırını ve tekrarlanan olayın yan etkisini açıklayın.

Resmi kaynaklar

• Apache Kafka girişi
• Hızlı başlangıç
• Kafka belgeleri
• KRaft ve yükseltme