Kafka Mimari Diyagramı: Broker'lar, Partition'lar, Replikalar ve Consumer Group'lar

Kafka'yı içine ve dışına oklar giden, "Kafka" etiketli tek bir kutu olarak çizmek kolaydır; ama o kutu, insanların güvendiği her özelliği gizler: neyin sıralı olup neyin olmadığı, verinin kaç kopyası bulunduğu, bir broker öldüğünde ne olduğu ve birkaç servisin aynı akışı birbirinin ayağına basmadan nasıl okuyabildiği.

Bu yazı bir Kafka cluster'ını önemli parçalarıyla çiziyor: broker'lar, topic'ler ve partition'lar, leader ve follower replikalar, anahtarlı producer'lar, consumer group'lar ve offset'ler ve cluster'ı yöneten KRaft controller'ları.

Topic'ler, partition'lar ve broker'lar

Bir topic, orders gibi adı olan bir kayıt akışıdır. Her topic partition'lara bölünür ve her partition, her kaydın artan bir offset aldığı, yalnızca sonuna ekleme yapılan bir log'dur.

Partition'lar her şeyin birimidir:

• Sıralama: kayıtlar bir partition içinde sıralıdır, partition'lar arasında asla.
• Paralellik: bir topic, tek bir group içinde en fazla partition sayısı kadar consumer tarafından tüketilebilir.
• Yerleşim: partition'lar, cluster'ın sunucuları olan broker'lara dağıtılır.

Partition sayısını topic başına ihtiyaç duyduğunuz verime ve paralel çalıştırmak istediğiniz consumer sayısına göre, pay bırakarak seçin. Sonradan partition eklemek mümkündür, ama bir anahtarın hangi partition'a düştüğünü değiştirir.

Replikasyon

Her partition'ın genellikle 3 olan bir replikasyon faktörü vardır. Replikalardan biri leader'dır ve okuma ile yazmaları karşılar; diğerleri leader'ın log'unu kopyalayan follower'lardır. Güncel kalan follower'lar in-sync replica kümesini (ISR) oluşturur. Bir leader'ın broker'ı çökerse güncel bir follower yeni leader olur.

Dayanıklılığı belirleyen ayarlar:

Faktör 3, min.insync.replicas=2 ve acks=all ile onaylanmış bir yazma en az iki broker'da bulunur ve cluster bir broker kapalıyken de yazma kabul etmeye devam eder. Kafka belgeleri bu ayarları ve birbirleriyle etkileşimlerini anlatır.

Producer'lar ve anahtarlar

Producer'lar her kayıt için bir partition seçer. Anahtar varsa varsayılan partitioner anahtarı hash'ler; böylece aynı anahtara sahip tüm kayıtlar aynı partition'a düşer ve sıralı kalır. Anahtar yoksa kayıtlar denge için dağıtılır ve aralarındaki sıralamayı kaybeder.

Anahtarları, olaylarının sıralı kalması gereken varlığa göre seçin: bir sipariş kimliği, bir hesap kimliği. Anahtarı diyagramda producer'ın üzerine yazın; bir producer'ın sahip olduğu en sonuç doğurucu ayar budur. Birkaç devasa değeri olan anahtarlardan kaçının, çünkü tek bir sıcak anahtar, kaç partition'ınız olursa olsun tek bir partition'ı aşırı yükler.

Yeniden denemeler kayıtları çoğaltabilir. Güncel Kafka sürümleri idempotent producer'ları varsayılan olarak açar; bu, bir partition içinde producer'ın yeniden denemelerinden kaynaklanan kopyaları ortadan kaldırır. Kendi uygulamanızın yeniden denemelerinden gelen kopyalar yine de mümkündür, bu yüzden consumer'lar da idempotent olmalıdır.

Consumer group'lar ve offset'ler

Bir consumer group, tek bir amaç için işi paylaşan bir consumer kümesidir. Kafka her partition'ı group'taki tam olarak bir consumer'a atar; bu yüzden üç partition en fazla üç consumer'ı meşgul edebilir, dördüncüsü boşta bekler. Consumer'lar katılıp ayrıldıkça group yeniden dengelenir (rebalance) ve partition'lar yer değiştirir.

Her group kendi konumunu, yani partition başına commit edilmiş offset'i izler; Kafka bunu dahili bir topic'te saklar. Birkaç servis aynı akışı bu sayede bağımsız okur: fulfillment ve analytics'in her birinin kendi group'u ve kendi offset'leri vardır ve hiçbiri diğerini etkilemez.

Offset'leri işlemeden önce değil sonra commit edin; böylece at-least-once işleme elde edersiniz: bir çökmeden sonra consumer, son commit'ten bu yana gelen kayıtları yeniden işler. Tekrarlar zararsız olsun diye işlemeyi idempotent yapın.

Saklama ve compaction

Kafka kayıtları okunduktan sonra da tutar. Zamana ya da boyuta dayalı saklama (retention) eski segmentleri siler, örneğin 7 gün sonra. Log compaction ise her anahtar için en son kaydı süresiz tutar; bu da bir topic'i güncel durumun changelog'una dönüştürür. Topic bazında seçin: olaylar genellikle retention kullanır, "müşteri başına en son adres" gibi durum bilgileri compaction kullanır.

Örnek bir boyutlandırma hesabı

Diyelim ki checkout zirvede saniyede 3.000 sipariş olayı üretiyor, her biri yaklaşık 1 KB, yani 3 MB/s. Fulfillment servisindeki bir consumer saniyede 400 olay işleyebiliyor. Zirvede en az 8 paralel consumer'a, dolayısıyla en az 8 partition'a ihtiyacınız var; büyümeye ve çöken bir consumer'ın partition'larına yer bırakmak için 12 seçin. Replikasyon faktörü 3 ile cluster, broker'lar genelinde diske 9 MB/s yazar ve bu hızla 7 günlük saklama, replike edilmiş yaklaşık 5,4 TB'a kadar veri tutar. Ortalama trafik zirveden düşüktür, bu yüzden bunu disk planlaması için üst sınır olarak görün. Bu tür sayılar diyagramın yanına aittir, çünkü broker sayısını ve diskleri Kafka etiketli kutu değil, bu sayılar belirler.

KRaft: artık ZooKeeper yok

Eski cluster'lar metadata'larını ZooKeeper'da saklardı. Kafka artık metadata'yı, KRaft adı verilen Raft tabanlı bir controller quorum'uyla kendisi yönetir. Mart 2025'te yayımlanan Kafka 4.0, tamamen ZooKeeper'sız çalışan ilk büyük sürümdür. Diyagramda controller quorum'unu, küçük cluster'lar iki rolü aynı makinelerde çalıştırsa bile, broker'lardan ayrı çizin.

Mimari diyagram

Nasıl okunur:

• Sol: iki producer, sipariş kimliğiyle anahtarlanmış olaylar gönderir. 8812 numaralı sipariş partition 0'a, 9001 numaralı sipariş partition 2'ye hash'lenir.
• Orta: üç broker var; her biri bir partition'ın leader'ı, diğer ikisinin follower'ı. Kesikli kenarlar replikasyonu gösterir; aşağıdaki KRaft controller'ları metadata'yı ve leader seçimini yönetir.
• Sağ: fulfillment group'unda, partition başına bir tane olmak üzere üç consumer var. Analytics consumer'ı farklı bir group'a aittir, bu yüzden her olayı kendi offset'leriyle okur.
• Markdown bloğu resmin dayandığı topic ayarlarını listeler.

Kafka diyagramına neler konmalı

• Topic başına partition sayısı ve anahtar, çünkü sıralamayı ve paralelliği bunlar belirler.
• Replikasyon faktörü ve min.insync.replicas, çünkü dayanıklılığı bunlar belirler.
• Her consumer group adıyla, consumer'larıyla birlikte.
• Topic başına retention ya da compaction.
• Kimin ürettiği ve kimin tükettiği, servisler arasında, sahiplik net olsun diye.

Kafka üzerine kurulan desenler için olay güdümlü mimari diyagramına, bir veritabanından güvenilir yayın için transactional outbox desenine ve analitiği besleyen Kafka için veri hattı mimari diyagramına bakın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Producer'lar için C4 Modeli paketinden Konteyner düğümleri ekleyin ve anahtarlarını açıklamaya yazın.
3. Broker'lar için Veri paketinden üç Kafka düğümü ekleyin ve her birini leader ve follower olduğu partition'larla etiketleyin; KRaft controller'ları için de bir Konteyner ekleyin.
4. Consumer group için Temel paketinden bir Çerçeve ekleyin ve içine consumer başına bir Konteyner koyun; ikinci group için ayrı bir consumer daha ekleyin.
5. Replikasyonu kesikli kenarlarla çizin ve topic ayarlarını içeren, Temel paketinden bir Markdown bloğu ekleyin.

Örnek 12 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Kafka mesaj sırasını garanti eder mi? Bir partition içinde evet, partition'lar arasında hayır. Sıralı kalması gereken kayıtların aynı partition'ı paylaşması için bir anahtar kullanın.

Bir topic'in kaç partition'ı olmalı? İhtiyaç duyduğunuz verime ve paralel çalıştırmak istediğiniz consumer sayısına yetecek kadar, büyümeye de yer bırakarak. Sayıyı sonradan değiştirmek, anahtarların partition'lara eşlenmesini değiştirir.

Bir broker çöktüğünde ne olur? Leader'ı olduğu her partition için başka bir broker'daki güncel bir follower leader olur. Replikasyon faktörü 3 ve min.insync.replicas=2 ile yazmalar devam eder.

Consumer group nedir? Bir topic'in partition'larını aralarında paylaşan bir consumer kümesi. Farklı group'lar aynı topic'i, her biri kendi offset'leriyle, bağımsız olarak okur.

Kafka'nın hâlâ ZooKeeper'a ihtiyacı var mı? Hayır. Kafka 4.0 ve sonrası yalnızca KRaft modunda çalışır; bu modda cluster metadata'sını bir controller quorum'u yönetir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.