Kafka ve Redis: Olay Omurgası mı, Bellek İçi Mesajlaşma mı?

Neden karşılaştırılıyorlar?

Kafka ve Redis aynı kategoride ürünler değildir. Kafka, olayları diske yazılmış ve çoğaltılmış bir log'da tutan dağıtık bir olay akışı platformudur. Redis ise öncelikle bellek içinde çalışan bir veri yapısı sunucusudur; önbellek, oturum deposu, sayaç ve sıralı liste gibi işlerde kullanılır. Karşılaştırma, Redis'in de mesajlaşma yetenekleri sunmasından doğar: Pub/Sub kanalları, kuyruk olarak kullanılan listeler ve kalıcı bir ekleme log'u olan Streams.

Dolayısıyla soru genellikle şöyle sorulur: "Zaten Redis'imiz var, mikroservisler arası mesajlaşmayı da onunla yapsak olur mu, yoksa Kafka mı kurmalıyız?" Cevap, mesajın kaybolmasının ne kadar kabul edilebilir olduğuna, mesajların ne kadar süre saklanacağına ve kaç farklı tüketicinin aynı veriyi bağımsız olarak okuyacağına bağlıdır.

Redis'te mesajlaşmanın üç yolu

• Pub/Sub: Yayıncı bir kanala mesaj gönderir, o anda abone olan istemcilere iletilir. Redis belgeleri bu modelin en fazla bir kez (at-most-once) teslim sağladığını açıkça belirtir: abone bağlı değilse ya da hata alırsa mesaj kalıcı olarak kaybolur. Anlık bildirim ve önbellek geçersizleştirme sinyali gibi kaybın tolere edildiği işler için uygundur.
• Listeler: LPUSH ile eklenen ve BRPOP gibi engelleyici komutlarla alınan basit iş kuyrukları. Bir iş tek tüketiciye gider, alındıktan sonra listeden çıkar.
• Streams: Her kaydın zaman tabanlı bir kimlik aldığı, yalnız eklenen bir log. XADD ile yazılır, XREAD ya da tüketici gruplarıyla XREADGROUP üzerinden okunur. Teslim edilip onaylanmamış kayıtlar bekleyen kayıtlar listesinde (PEL) izlenir, XACK ile onaylanır, XAUTOCLAIM ile düşen bir tüketicinin işi başka tüketiciye devredilir. Redis belgelerine göre Streams kalıcıdır ve en az bir kez (at-least-once) teslimi destekler.

Kafka'yla gerçek anlamda kıyaslanabilecek olan Redis Streams'tir. Pub/Sub ile Kafka'yı karşılaştırmak, telsiz ile kayıt cihazını karşılaştırmak gibidir: biri yayını anlık iletir, diğeri sonradan tekrar dinlenebilecek şekilde saklar.

Ölçüt ölçüt farklar

• Veri nerede durur: Kafka / diskteki bölüm log'larında, broker'lar arasında çoğaltılmış. Redis / bellekte; kalıcılık RDB anlık görüntüleri ya da AOF günlüğüyle diske yazılır.
• Saklama ve yeniden oynatma: Kafka / tutma süresi ya da boyutu topic bazında ayarlanır; olaylar tüketildikten sonra da kalır, yeni bir tüketici geçmişi baştan okuyabilir. Redis / Streams'te kayıtlar silinene ya da MAXLEN veya XTRIM ile kırpılana kadar kalır; saklanabilecek miktar bellekle sınırlıdır.
• Ölçek: Kafka / topic bölümlere ayrılır ve kümeye yayılır; tek bir topic çok yüksek hacmi taşıyabilir. Redis / tek bir stream tek bir anahtardır ve Redis Cluster'da tek bir düğümde durur; ölçek için veri birden çok stream'e bölünür.
• Gecikme: Redis / bellek içi çalıştığı için çok düşük gecikme. Kafka / düşük gecikme, ama üretici toplu gönderim ve onay ayarlarına bağlı.
• Tüketici modeli: Kafka / tüketici grubu başına bölüm ataması ve offset. Redis / tüketici grubu içinde kayıt bazında dağıtım, onay ve sahiplik devri.
• Ekosistem: Kafka / Kafka Connect ile veritabanı ve sistem bağlayıcıları, Kafka Streams ile akış işleme. Redis / istemci kütüphaneleri geniş, ama bağlayıcı ve akış işleme ekosistemi Kafka kadar kapsamlı değil.
• İşletim: Kafka / ayrı bir küme, disk ve bölüm planlaması. Redis / altyapıda sık bulunan, tanıdık bir bileşen; bellek kapasitesi ve tahliye (eviction) politikası dikkat ister.

Aynı iş iki araçta nasıl görünür?

Örneğin bir e-ticaret sitesinde "sipariş oluşturuldu" olayı yayınlanıyor, stok servisi ve bildirim servisi bu olayı ayrı ayrı işliyor olsun.

Redis Streams ile üretici her siparişte şuna benzer bir komut çalıştırır: XADD siparisler * siparis_id abc durum olusturuldu. Stok ve bildirim servisleri için ayrı tüketici grupları XGROUP CREATE ile açılır. Her servis XREADGROUP GROUP stok isci-a STREAMS siparisler > ile yeni kayıtları alır, işledikten sonra XACK ile onaylar. Bir işçi çökerse bekleyen kayıtlar XAUTOCLAIM ile başka işçiye devredilir. Bellek dolmasın diye XADD sırasında MAXLEN ile yaklaşık bir üst sınır verilir; bu sınırın ötesindeki eski siparişler kaybolur.

Kafka ile siparisler adlı topic sipariş kimliği anahtar olacak şekilde bölümlere ayrılır, üretici her siparişi bu anahtarla gönderir. Stok ve bildirim servisleri ayrı tüketici grup kimlikleriyle bağlanır, her grup kendi offset'ini ilerletir. Aylar sonra eklenen bir analitik servisi, yeni bir grup kimliğiyle topic'i baştan okuyarak geçmiş siparişleri işleyebilir; bu, Redis'te bellek sınırı nedeniyle genellikle mümkün olmaz.

Hangi durumda hangisi?

Redis'i yeterli kılan durumlar: • Mesaj hacmi orta düzeyde ve mesajların kısa süre saklanması yeterli. • Altyapıda zaten Redis var, yeni bir küme işletmek istemiyorsunuz. • Çok düşük gecikme gerekiyor ve mesajlar daha çok iş kuyruğu ya da anlık sinyal niteliğinde. • Pub/Sub ile kayıpların kabul edilebildiği bildirimler (önbellek geçersizleştirme, canlı pano güncellemesi) gönderiyorsunuz.

Kafka'yı gerektiren durumlar: • Olaylar sistemin kalıcı kaydıdır; denetim, yeniden işleme ya da yeni servislerin geçmişi okuması gerekiyor. • Hacim yüksek ve zamanla büyüyecek; bölümleme ile yatay ölçek gerekiyor. • Veritabanlarından değişen veri yakalama, veri gölüne aktarma gibi entegrasyonlar için hazır bağlayıcılar istiyorsunuz. • Çok sayıda ekip aynı olayları bağımsız olarak tüketecek.

Birlikte kullanım: omurga ve hızlı katman

Olgun mimarilerde Kafka ve Redis birbirinin rakibi değil, tamamlayıcısıdır. Kafka olay omurgasıdır: siparişler, ödemeler ve kullanıcı hareketleri burada kalıcı olarak akar. Kafka'yı tüketen servisler, sık okunan sonuçları Redis'e yazar: ürün stok sayacı, kullanıcının son görüntülediği ürünler, anlık skor tablosu ya da oran sınırlama sayaçları gibi. Böylece web katmanı milisaniyeler mertebesinde Redis'ten okur, gerçek kayıt ise Kafka'da ve veritabanında durur.

Bu düzende dikkat edilecek nokta tutarlılıktır. Redis'teki değer, Kafka'daki olayın işlenmesiyle güncellendiği için kısa bir gecikmeyle geride kalabilir; kritik kararlar (örneğin ödeme onayı) önbellekten değil kalıcı kaynaktan verilmelidir. Redis düğümü yeniden başladığında önbelleğin Kafka'daki olaylardan ya da veritabanından yeniden doldurulabilmesi de baştan tasarlanmalıdır.

Mindset programlarında Kafka ve Redis

Apache Kafka ile Akış Mimarisi programı, olay tabanlı sistem kuran geliştiriciler için topic yönetimi, producer ve consumer API'leri ve Kafka Connect ile entegrasyonu işler; Apache Kafka Küme İşletimi ve Kapasite Yönetimi programı ise platform ekiplerinin bölümleme, tutma ve kapasite planlaması sorularına yanıt verir.

Redis tarafında Redis ile Önbellekleme ve Veri Yapıları programı, uygulama geliştiricilere önbellekleme stratejileri, geçersizleştirme ve tutarlılık ile dağıtık desenleri anlatır; yukarıdaki omurga ve hızlı katman düzenini kuran ekipler için doğrudan karşılık bulur. Redis İşletimi ve Kümeleme programı ise kalıcılık ve yedekleme, Sentinel ve Redis Cluster ile yüksek erişilebilirliği işleten operasyon ekiplerine yöneliktir.