Redis Streams ile Gerçek Zamanlı Olay Kuyruklama: 5 İpuçları ve Örnek Uygulama​

[PARAGRAPH]Redis Streams, 6.0 sürümünden itibaren gelen tasarruflu ve ölçeklenebilir mesaj kuyruğu çözümü olarak dikkat çekiyor. Geleneksel queue modeli yerine event‑driven mimarilere geçiş yapan geliştiriciler, Streams’in atomik tüketim ve otomatik checkpointing özelliklerini çok valide buluyor. Bu makalede, Streams’i projelerinizde en iyi şekilde kullanmanız için beş pratik ipucu ve bir örnek uygulamayı bulacaksınız.[/PARAGRAPH]

Hızlı Başlangıç: XRDB:].
[PARAGRAPH]İlk adımda, bir stream oluşturup veri eklemek için aşağıdaki komutu kullanın: [/PARAGRAPH]

Kod:

XADD my_stream * sensor_id 123 temp 23.5 humidity 45.2

[PARAGRAPH]Burada '*' karakteri, Redis’in sıralı bir mesaj ID’si üretmesini sağlar. [PTR]Client side batching[/PTR] ile çok sayıda komutu tek seferde göndermenin performans kazanımını göz önünde bulundurun.
[/PARAGRAPH]

Consumer Groups ile Paralel İşleme
[PARAGRAPH]Birden fazla tüketici aynı stream’i paylaşarak iş günlüğünü dağıtmak için consumer group kurun: [/PARAGRAPH]

Kod:

XGROUP CREATE my_stream my_group $ MKSTREAM

[PARAGRAPH]$ işareti, yeni mesajları sadece en son eklenenlerinden alacağınız anlamına gelir. Tek tek tüketici rolleri oluşturup, aynı işi bölmek, latency’i düşürür.
[/PARAGRAPH]

Multi‑Key Streams ile Senkronizasyon
[PARAGRAPH]Yüksek hacimli veri akışlarını tek bir stream’e koymak yerine, anahtar bazlı (key‑space) bir strateji takın. Örneğin, her cihaz için ayrı bir stream: `sensor:{id}:stream`. Böylece, cache evict edilince otomatik temizleme yapabilecek tek tek key‑space bütünlüğünü sağlayabilirsiniz.
[/PARAGRAPH]

Rüzgar Kaldırma ve Cleanup
[PARAGRAPH]Redis Stream’lerinde lokasyon bazlı TTL kontrolleri, veriyi silmeye yardımcı olur. `XTRIM` komutu ile specific key’ler için maksimum kayıt sayısını sabit tutabilirsiniz: [/PARAGRAPH]

Kod:

XTRIM my_stream MAXLEN 1000

[PARAGRAPH]Bu, belleğin yönetilebilir kalmasını ve “ephemeral” veri kullanım senaryolarını destekler.
[/PARAGRAPH]

İnşa Edilen Mimikler: Kafka vs. Redis Streams
[PARAGRAPH]Kafka’nın zorlukları olan “disk skimming” ve “slow producer” sorunlarının aksine, Redis Streams, RAM‑temelli olduğu için düşük gecikme süreleriyle öne çıkar. Örneğin, bir IoT veri toplama hattı 10 kB’lık paketleri saniyede 20.000’dir. Bu senaryolarda Kafka’nun disk I/O kasını geçmek için Redis’in `appendonly` yerine `RDB` snapshotlamasını tercih edin.
[/PARAGRAPH]

Örnek Uygulama – Python ile Basit Sensor İzleyici
[PARAGRAPH]Aşağıdaki kod, Redis Stream’i dinleyen basit bir tüketiciyi göstermektedir:
[/PARAGRAPH]

Kod:

import redis

r = redis.Redis(host='localhost', port=6379, db=0)

while True:
    msgs = r.xreadgroup('my_group', 'consumer_1', {'my_stream': '>'}, count=10, block=2000)
    for stream_name, messages in msgs:
        for msg_id, payload in messages:
            print(f"{msg_id}: {payload}")

[PARAGRAPH]`block=2000` parametresi 2 saniye bekleyecek demek; böylece sık bloklama olmaz. Tüketiciyi ölçeklendirerek üreticiye eşlenik yapabilir, herhangi bir kesinti durumunda sadece ilgili consumer tekrar çekilecek.
[/PARAGRAPH]

Sonuç
[PARAGRAPH]Redis Streams, hafif ama güçlü bir event kuyruğu çözümüdür. İpuçlarımızla performansı maksimize edebilir, seviyeten yüksek hacimli gerçek zamanlı veri akışlarını yönetebilirsiniz. Deneyimlerinizi, adımları ve karşılaştığınız zorlukları yorumlayarak paylaşmayı unutmayın – topluluk olarak hep birlikte gelişiriz![/PARAGRAPH]​

​​​​​​