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](https://kafka.apache.org/41/getting-started/introduction/), 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 modeli         | Topic/partition üzerinde olay günlüğü                                | Exchange ve kuyruklarla mesaj yönlendirme; ayrıca Streams seçeneği     |
| Tüketici ilerlemesi | Offset ve consumer group                                             | Kuyruklarda teslim/onay; Streams'te yeniden okunabilir kayıtlar        |
| Yeniden okuma       | Saklama politikasıyla korunmuş kayıtlar offset ile tekrar okunabilir | Klasik/quorum kuyruk ile Streams farklı davranır                       |
| Sıralama            | Partition bazında değerlendirilir                                    | Kuyruk, 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](/teknolojiler/rabbitmq) için “geçmiş mesaj okunamaz” demek, [Streams](https://www.rabbitmq.com/docs/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](https://kafka.apache.org/41/design/design/), 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](https://kafka.apache.org/40/getting-started/upgrade/), 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

{{< related-services >}}