İçeriğe geç
Apache Kafka

Apache Kafka, olayların yayımlanması, saklanması ve bağımsız tüketiciler tarafından işlenmesi için dağıtık bir event streaming platformudur. Uygulama olayları, veri entegrasyonu ve CDC akışlarında kullanılabilir. Resmi giriş belgesi, producer, consumer, topic ve partition modelini açıklar.

Kafka’yı seçmenin nedeni yalnız mesaj sayısının yüksek olması değildir. Olayların tekrar okunması, birden fazla tüketici grubunun bağımsız ilerlemesi ve veri akışının saklanması gerekiyorsa bu model anlamlıdır. Basit bir arka plan işi için aynı işletim karmaşıklığı gerekmeyebilir.

Kafka ile RabbitMQ arasındaki fark

İhtiyaçKafka yaklaşımıRabbitMQ yaklaşımı
Veri modeliTopic/partition üzerinde olay günlüğüExchange ve kuyruklarla mesaj yönlendirme; ayrıca Streams seçeneği
Tüketici ilerlemesiOffset ve consumer groupKuyruklarda teslim/onay; Streams’te yeniden okunabilir kayıtlar
Yeniden okumaSaklama politikasıyla korunmuş kayıtlar offset ile tekrar okunabilirKlasik/quorum kuyruk ile Streams farklı davranır
SıralamaPartition bazında değerlendirilirKuyruk, tüketici sayısı ve yeniden teslim davranışıyla değerlendirilir
Seçim odağıOlay geçmişi, veri hatları ve bağımsız tüketicilerİş kuyruğu, yönlendirme ve mesaj teslimi iş akışları

RabbitMQ için “geçmiş mesaj okunamaz” demek, Streams özelliğini dışarıda bırakır. Karşılaştırma ürün isimleriyle değil, seçilen veri yapısı, istemci ve hata senaryosuyla yapılmalıdır.

Topic, partition ve consumer group tasarımı

Topic, olayların mantıksal grubudur; partition, topic içindeki sıralı log bölümüdür. Offset, kaydın o partition içindeki konumudur; bütün topic için ortak bir sıra numarası değildir. Partition, sıralama ve paralellik sınırıdır. Aynı varlığa ait olayların sırası önemliyse anahtar ve partition stratejisi buna göre seçilir. Partition sayısının değiştirilmesi anahtarların dağılımını ve işleme davranışını etkileyebilir.

Standart consumer group modelinde partition’lar grup üyeleri arasında paylaştırılır; farklı gruplar aynı olayları bağımsız işleyebilir. Consumer lag, tüketicinin partition’daki ilerleme farkını gösterir. Bunun yanında olayların iş açısından ne kadar geciktiği de ölçülmelidir.

Tüketici uzun süre geri kalırsa gereken kayıtlar retention nedeniyle artık mevcut olmayabilir. Compaction etkin bir topic’te aynı anahtarın eski değerleri temizlenebilir; Kafka her yapılandırmada değişmez ve eksiksiz bir olay arşivi değildir.

Dayanıklılık ve exactly-once sınırı

Kafka tasarım belgesi, producer onayı, in-sync replica’lar ve tüketici offset yönetiminin birlikte değerlendirilmesini gerektirir. Replication factor, acks ve min.insync.replicas birbirinden bağımsız seçilmemelidir. Replica sayısı tek başına sıfır veri kaybı garantisi vermez.

Idempotent producer, belirli yeniden gönderim tekrarlarını önlemeye yardımcı olur; iş işleminin bütün dış etkilerini tekilleştirmez. Kafka içindeki okuma–işleme–yazma zinciri ile harici bir API çağrısı aynı transaction kapsamına girmez. Tüketicide idempotency anahtarı, offset kaydı ve hata sonrası yeniden işleme yolu tasarlanmalıdır.

Kafka 4.x ve KRaft

Kafka 4.0 yükseltme belgesi, ZooKeeper modunun kaldırıldığını belirtir. KRaft controller quorum’u ile topic verisini tutan broker replica’ları farklı sorumluluklara sahiptir. Controller ve broker yerleşimi, kaynak paylaşımı ve arıza alanları birlikte planlanır.

Eski ZooKeeper rehberleri yeni kurulumlara olduğu gibi uygulanmamalıdır. Yükseltmede broker/istemci sürümleri, metadata sürümü ve geri dönüş sınırları kontrol edilir; paket düşürmenin her aşamada mümkün olduğu varsayılmaz.

Üretim işletimi ve kurtarma

  • Topic oluşturma, veri yazma/okuma ve yönetim yetkileri ayrı sınırlandırılır; TLS ve uygun kimlik doğrulama kullanılır.
  • Partition dağılımı, ISR değişimleri, disk doluluğu, producer hataları ve consumer lag birlikte izlenir.
  • Retention ve compaction kuralları iş gereksinimine göre belirlenir; bunlar bağımsız yedek değildir.
  • Cluster ayarları, ACL’ler, topic yapılandırmaları ve kullanılan connector/şema bileşenleri kurtarma kapsamına alınır.
  • Broker, controller ve tüketici arızasında yeniden bağlantı, tekrar işleme ve veri doğruluğu pilotta sınanır.

İlgili hizmetlerimiz

Sıkça sorulan sorular

Kafka bir mesaj kuyruğu mu?
Mesajlaşma için kullanılabilir; temel modeli partition’lara bölünmüş kalıcı olay günlüğüdür. Consumer’ın okuması kaydı hemen silmez; retention ve compaction politikaları hangi kayıtların tutulacağını belirler. Görev dağıtımı, yeniden okuma, retention ve tüketici grupları klasik kuyruk modeliyle aynı varsayılmamalıdır.
Kafka bütün mesajlarda sıralama sağlar mı?
Sıralama partition içinde tanımlıdır; farklı partition’lar arasında genel bir sıra garantisi yoktur. Anahtar seçimi, partition sayısındaki değişiklik ve uygulamanın paralel işleme davranışı birlikte değerlendirilir.
Kafka exactly-once ile çift ödeme engellenir mi?
Kafka transaction’ları ve ilgili tüketici ayarları belirli Kafka içi akışlarda exactly-once işleme sağlayabilir. Harici ödeme API’si veya veritabanı yan etkisi otomatik olarak bu transaction’a katılmaz; idempotency ve koordinasyon ayrıca tasarlanmalıdır.
Kafka 4 için ZooKeeper gerekiyor mu?
Hayır. Kafka 4.0 ile ZooKeeper modu kaldırılmıştır; 4.x KRaft kullanır. Eski ZooKeeper tabanlı cluster’lar için desteklenen ara sürüm ve KRaft geçişi, ana sürüm yükseltmesinden önce planlanmalıdır.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.