Redis Pub/Sub Kullanımı

Bir uygulamada "kullanıcıya anlık bildirim düşür", "tüm web sunucularında önbelleği aynı anda temizle" ya da "yönetim panelinde canlı sipariş akışı göster" gibi bir ihtiyaç çıktığında akla gelen ilk araçlardan biri Redis Pub/Sub olur. Sebebi basittir: Redis zaten çoğu projede önbellek ya da oturum deposu olarak kuruludur, Pub/Sub için ek bir servis, ek bir kütüphane ya da ek bir port gerekmez ve tek satırlık bir PUBLISH komutuyla mesajınız o kanalı dinleyen bütün istemcilere milisaniyeler içinde ulaşır.

Ancak Pub/Sub'ı bir mesaj kuyruğu sanıp üretime almak, sistem yöneticisi olarak gördüğüm en pahalı Redis hatalarından biridir. Pub/Sub mesajı saklamaz, teslim edildiğine dair onay beklemez ve o anda bağlı olmayan bir aboneye mesajı asla geri getirmez. Bu rehberde önce mekanizmanın nasıl çalıştığını, komutlarını ve uygulama tarafındaki kullanımını göstereceğim; sonra bu üç sınırın ne zaman kabul edilebilir olduğunu, ne zaman Redis Streams'e ya da liste tabanlı bir kuyruğa geçmeniz gerektiğini, cluster ortamındaki farkları ve üretimde canınızı yakacak ayarları anlatacağım.

Redis Pub/Sub Nasıl Çalışır#

Pub/Sub, "yayıncı-abone" modelinin en yalın hâlidir. Bir istemci SUBSCRIBE siparis diyerek bir kanala abone olur; başka bir istemci PUBLISH siparis "12345 onaylandı" dediğinde Redis, o kanala o an abone olan tüm bağlantılara mesajın bir kopyasını yazar. Yayıncı kimin dinlediğini bilmez, abone kimin yayınladığını bilmez; ikisi arasındaki tek bağ kanal adıdır. Bu gevşek bağ, mimari olarak son derece rahat bir yapı sunar: yeni bir tüketici eklemek için mevcut kodu değiştirmeniz gerekmez, sadece aynı kanala abone olan bir süreç daha başlatırsınız.

Buradaki kritik ayrıntı şudur: kanal bir veri yapısı değildir. Redis'te SET, LPUSH ya da HSET ile yazdığınız her şey bellekte bir anahtar olarak durur ve SAVE/BGSAVE ile diske yazılabilir. Kanal ise sadece bir yönlendirme etiketidir, hiçbir yerde saklanmaz. Bu yüzden PUBLISH komutunun dönüş değeri mesajın kaç aboneye iletildiği sayısıdır ve sıfır dönmesi tamamen normaldir; kimse dinlemiyorsa mesaj sessizce yok olur. Aynı sebeple Pub/Sub trafiği RDB ya da AOF dosyalarına yazılmaz, replikasyonda ise yayılır: bir master'a yapılan PUBLISH, replikalara da aktarılır ve replikaya bağlı aboneler de mesajı alır.

# Birinci terminalde aboneyi başlat
redis-cli SUBSCRIBE siparis
# Reading messages... (press Ctrl-C to quit)
# 1) "subscribe"
# 2) "siparis"
# 3) (integer) 1

# İkinci terminalde mesaj yayınla
redis-cli PUBLISH siparis '{"id":12345,"durum":"onaylandi"}'
# (integer) 1   <- mesajın ulaştığı abone sayısı

Abone tarafında mesaj üç elemanlı bir dizi olarak gelir: message, kanal adı ve gövde. Kalıp aboneliğinde (psubscribe) dört elemanlı gelir, araya eşleşen kalıp eklenir. Uygulama kodunuzda bu farkı gözden kaçırmak, "mesaj geliyor ama gövdesi boş" tipi hatalara yol açar.

Temel Komutlar ve Kalıp Abonelikleri#

Pub/Sub'ın komut kümesi küçüktür, hepsini bir oturumda öğrenebilirsiniz. Aşağıdaki tablo hangi komutun ne yaptığını ve tipik kullanım anını özetliyor.

Kalıp abonelikleri, çok kiracılı sistemlerde çok işe yarar. Örneğin her müşteri için ayrı bir kanal kullanıyorsanız, yönetim paneli tek bir PSUBSCRIBE bildirim.* ile hepsini birden dinleyebilir:

# Kalıp aboneliği: bildirim ile başlayan tüm kanallar
redis-cli PSUBSCRIBE 'bildirim.*'

# Başka bir terminalden
redis-cli PUBLISH bildirim.musteri.42 "faturaniz hazir"
redis-cli PUBLISH bildirim.sistem "bakim 03:00'te"

# Teşhis: kim neyi dinliyor
redis-cli PUBSUB CHANNELS 'bildirim.*'
redis-cli PUBSUB NUMSUB bildirim.sistem
redis-cli PUBSUB NUMPAT

Kalıp aboneliğinin bedeli vardır: Redis her PUBLISH için kayıtlı bütün kalıpları tek tek eşleştirmek zorundadır, yani kalıp sayısı arttıkça yayın maliyeti doğrusal olarak büyür. Onlarca farklı kalıp yerine, mesajın gövdesine bir tip alanı koyup tek kanalda yayın yapmak çoğu zaman daha ucuzdur. Bir de şu uyarıyı ekleyeyim: kalıplar glob biçimindedir, düzenli ifade değildir; bildirim.* yazdığınızda nokta özel karakter değil, düz karakterdir.

Uygulama Tarafında Abone ve Yayıncı Yazmak#

Kütüphane hangisi olursa olsun değişmeyen bir kural var: abone olan bağlantı ile komut çalıştıran bağlantı ayrı olmalıdır. Bir bağlantı SUBSCRIBE yaptığı anda RESP2 protokolünde abone moduna girer ve o bağlantıda artık sadece abonelik komutları, PING ve QUIT çalışır. Aynı bağlantıdan GET, SET ya da PUBLISH çağırırsanız hata alırsınız. RESP3 protokolünde bu kısıt kalkmıştır ama taşınabilir kod yazmak istiyorsanız yine de iki ayrı istemci nesnesi kullanın.

// Node.js — node-redis ile abone ve yayıncı ayrı bağlantı
import { createClient } from "redis";

const yayinci = createClient({ url: "redis://127.0.0.1:6379" });
const abone = yayinci.duplicate();          // ayrı bağlantı, aynı ayarlar

await Promise.all([yayinci.connect(), abone.connect()]);

// Abone: kanal ve kalıp
await abone.subscribe("siparis", (govde, kanal) => {
  const veri = JSON.parse(govde);           // gövde her zaman string gelir
  console.log(kanal, veri.id, veri.durum);
});

await abone.pSubscribe("bildirim.*", (govde, kanal) => {
  console.log("kalip eslesmesi:", kanal, govde);
});

// Yayıncı: JSON'u kendiniz serileştirirsiniz
await yayinci.publish("siparis", JSON.stringify({ id: 12345, durum: "onaylandi" }));

PHP tarafında phpredis eklentisiyle abone olmak bloklayıcı bir çağrıdır; yani subscribe() çağrısı geri dönmez, kanaldan mesaj geldikçe verdiğiniz geri çağırımı (callback) çalıştırır. Bu yüzden abone tarafını web isteği içinde değil, ayrı bir CLI süreci olarak systemd altında çalıştırmak gerekir:

// abone.php — systemd servisi olarak çalıştırılacak uzun ömürlü süreç
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->auth('SIFRENIZ');
// Abone modunda okuma zaman aşımı kapatılmalı, yoksa bağlantı düşer
$redis->setOption(Redis::OPT_READ_TIMEOUT, -1);

$redis->subscribe(['siparis'], function ($redis, $kanal, $mesaj) {
    $veri = json_decode($mesaj, true);
    error_log("siparis {$veri['id']} -> {$veri['durum']}");
});

Buradaki OPT_READ_TIMEOUT satırı kritiktir. Varsayılan okuma zaman aşımı devredeyken abone süreci birkaç dakika mesaj almazsa bağlantı düşer ve süreç sessizce ölür; sabah geldiğinizde "bildirimler dün geceden beri gelmiyor" tablosuyla karşılaşırsınız. Aynı sebeple abone süreçlerini mutlaka Restart=always ile bir servis yöneticisi altında çalıştırın ve yeniden bağlanma mantığını koda gömün.

Pub/Sub'ın Üç Sert Sınırı#

Şimdi rehberin en önemli bölümüne geldik. Pub/Sub'ın üç sınırı vardır ve üçü de tasarım gereğidir, ayarla düzeltilemez.

1. Kalıcılık yok. Mesaj hiçbir yere yazılmaz. Abone süreciniz o an ayaktaysa alır, değilse mesaj kaybolur. Deploy sırasındaki üç saniyelik yeniden başlatma, o üç saniyede yayınlanan her şeyi silip süpürür.
2. Onay (ACK) yok. Redis, mesajın işlendiğini değil, sadece istemcinin soketine yazıldığını bilir. Abone mesajı alıp işlerken çökerse mesaj tekrar denenmez.
3. Geriye dönük okuma yok. Yeni bağlanan bir abone, bağlanmadan önceki mesajları göremez. Kanalda "son 100 mesaj" diye bir kavram yoktur.

Bu üçünün pratikteki sonucu şudur: Pub/Sub, kaybı tolere edilebilen sinyaller için mükemmeldir, iş yükü taşımak için uygun değildir. "Önbelleği geçersiz kıl", "canlı gösterge panelini tazele", "yazım imlecini diğer kullanıcılara göster" gibi işler kaybı tolere eder — bir sinyal kaçarsa bir sonraki gelir. Ama "fatura kes", "e-posta gönder", "ödeme al" gibi işler tolere etmez; bunlar için kalıcı bir kuyruk gerekir.

Dördüncü ve daha az bilinen bir sınır da yavaş abonedir. Redis, aboneye yazamadığı mesajları bir çıkış tamponunda biriktirir. Abone mesajları okuyamayacak kadar yavaşsa tampon şişer ve Redis o istemciyi keser. Sınırlar redis.conf içindedir:

# Biçim: <sınıf> <sert-sınır> <yumuşak-sınır> <yumuşak-süre-saniye>
# pubsub: 32MB'a ulaşınca anında kes, 8MB'ı 60 saniye boyunca aşarsa kes
client-output-buffer-limit pubsub 32mb 8mb 60

Aboneleriniz "sebepsiz yere" düşüyorsa ilk bakacağınız yer burasıdır. redis-cli CLIENT LIST çıktısındaki omem ve tot-mem sütunları, hangi istemcinin tamponunun şiştiğini gösterir. Çözüm sınırı büyütmek değil, aboneyi hızlandırmak ya da mesaj hacmini azaltmaktır; sınırı büyütmek sadece patlamayı erteler ve bu arada Redis'in belleğini yer.

Redis Streams ve Liste Kuyruğu ile Karşılaştırma#

Yukarıdaki sınırlar sizin senaryonuz için kabul edilemezse, Redis içinde iki alternatifiniz daha var. Aşağıdaki tablo üç yaklaşımı yan yana koyuyor.

Pratikte kural şudur: yayın (broadcast) istiyorsanız ve kayıp önemsizse Pub/Sub, iş dağıtımı istiyorsanız ve kayıp önemliyse Streams. Liste kuyruğu ikisinin arasında kalır; basit tek tüketicili işler için yeterlidir ama yeniden deneme mantığını kendiniz yazmanız gerekir. Streams'e geçiş, Pub/Sub'a kıyasla birkaç satır daha uzundur ama kazanç büyüktür:

# Tüketici grubu oluştur (akış yoksa MKSTREAM ile birlikte)
redis-cli XGROUP CREATE siparis-akisi isleyiciler '$' MKSTREAM

# Yayıncı: mesajı akışa ekle, otomatik kimlik al
redis-cli XADD siparis-akisi '*' id 12345 durum onaylandi

# Tüketici: gruptan blok halinde oku
redis-cli XREADGROUP GROUP isleyiciler islemci-1 COUNT 10 BLOCK 5000 STREAMS siparis-akisi '>'

# İş bitince onayla; onaylanmayan mesaj bekleyenler listesinde kalır
redis-cli XACK siparis-akisi isleyiciler 1724572800000-0

# Akışı sınırla: yaklaşık son 100000 kayıt tutulsun
redis-cli XADD siparis-akisi MAXLEN '~' 100000 '*' id 12346 durum bekliyor

Buradaki MAXLEN ~ 100000 parçası ihmal edilirse akış sonsuza kadar büyür ve Redis'in belleğini bitirir; bu, Streams'e yeni geçenlerin bir numaralı hatasıdır. Redis'in genel bellek davranışını ve önbellek katmanı olarak nasıl konumlandığını karşılaştırmalı okumak isterseniz Memcached nedir yazısı iyi bir tamamlayıcıdır.

Cluster, Sentinel ve Keyspace Bildirimleri#

Redis Cluster'da klasik PUBLISH, mesajı kümedeki tüm düğümlere yayar. Böylece hangi düğüme bağlı olursanız olun mesajı alırsınız, ama bunun bedeli düğümler arası ek trafiktir; yüksek hacimli yayınlarda küme içi bant genişliği ciddi biçimde tükenebilir. Redis 7 ile gelen parçalanmış Pub/Sub bu sorunu çözer: SPUBLISH ve SSUBSCRIBE, kanal adını da anahtar gibi bir yuvaya (slot) eşler ve mesaj yalnızca o yuvadan sorumlu parçaya gider.

# Cluster'da parçalanmış yayın: yalnızca ilgili shard'a gider
redis-cli -c -h 127.0.0.1 -p 7000 SSUBSCRIBE 'bildirim:{musteri42}'
redis-cli -c -h 127.0.0.1 -p 7001 SPUBLISH 'bildirim:{musteri42}' 'faturaniz hazir'

Süslü parantez içindeki etiket, aynı müşteriye ait tüm kanalların aynı yuvaya düşmesini sağlar. Sentinel kullanan bir kurulumda ise dikkat edilecek nokta farklıdır: yük devri (failover) sonrasında istemcinizin yeni master'a yeniden bağlanması gerekir ve bu yeniden bağlanma sırasında geçen sürede yayınlanan mesajlar kaybolur. Sentinel'in kendisi de +switch-master gibi olayları Pub/Sub üzerinden duyurur; istemci kütüphanelerinin yük devrini fark etme yöntemi tam olarak budur.

Bir başka kullanışlı özellik de keyspace bildirimleridir. Redis, anahtarlar üzerindeki olayları (silme, süre dolması, yazma) istenirse otomatik olarak Pub/Sub kanallarına basar. Varsayılan olarak kapalıdır, çünkü açık olması her yazma işlemine ek maliyet bindirir:

# redis.conf — K: keyspace, E: keyevent, x: expired, g: generic, $: string
# Yalnızca ihtiyacınız olan sınıfları açın; KEA "her şey" demektir ve pahalıdır
notify-keyspace-events Ex

# 0 numaralı veritabanında süresi dolan anahtarları dinle
redis-cli PSUBSCRIBE '__keyevent@0__:expired'

Bu mekanizmayla oturum süresi dolduğunda temizlik yapmak ya da geçici kilitlerin bittiğini yakalamak mümkündür. Ancak yine aynı uyarı geçerlidir: bu bildirimler de Pub/Sub üzerinden gider, yani kalıcı değildir. Süresi dolan anahtarı kaçırmamak hayati ise, bildirimi tetikleyici olarak kullanıp asıl doğrulamayı veritabanından yapın.

Sık Yapılan Hatalar ve İzleme#

Yıllar içinde aynı hataları defalarca gördüm; listeleyeyim ki siz tekrarlamayın. Birincisi, tek bağlantıyı hem abone hem yayıncı olarak kullanmak. RESP2'de bu doğrudan hata verir, RESP3'te çalışır ama abonelik akışıyla komut yanıtlarını karıştırdığı için ayıklanması zor kusurlara yol açar. İkincisi, abone sürecini web isteği içinde başlatmak; PHP-FPM ya da benzeri bir ortamda istek biter bitmez süreç ölür, aboneliğiniz de onunla gider. Abone daima uzun ömürlü, ayrı bir servistir.

Üçüncüsü, Pub/Sub üzerinden büyük gövdeler taşımak. Kanala 2 MB'lık bir JSON basarsanız, o gövde her abone için ayrı ayrı kopyalanıp tampona yazılır; on abonede 20 MB anlık bellek demektir bu. Doğru desen, mesaja yalnızca bir kimlik koymak ve tüketicinin asıl veriyi veritabanından ya da Redis'ten okumasıdır. Dördüncüsü, izleme yapmamak. En az şu üç ölçüyü toplayın:

# Anlık yayın hızı ve bağlı istemci sayısı
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|total_commands_processed'
redis-cli INFO clients | grep -E 'connected_clients|blocked_clients|client_recent_max_output_buffer'

# Kanal başına abone sayısı — sıfıra düşerse abone süreci ölmüş demektir
redis-cli PUBSUB NUMSUB siparis bildirim.sistem

# Yayınlanan mesajları canlı izle (üretimde kısa süreli kullanın, maliyetlidir)
redis-cli --timeout 10 MONITOR | grep -i publish

PUBSUB NUMSUB çıktısını bir izleme sistemine bağlamak, "bildirimler gelmiyor" şikâyetlerini saatler öncesinden yakalamanın en ucuz yoludur: abone sayısı beklenenin altına düştüğü an uyarı üretin. MONITOR komutunu ise yalnızca teşhis için ve kısa süreli kullanın; her komutu istemciye yazdığı için yoğun bir sunucuda ciddi yük bindirir. Redis'i internete açık bir sunucuda çalıştırıyorsanız, bu komutların hiçbirinin yetkisiz kişilerce çalıştırılamadığından emin olun; erişim denetimi için Redis güvenlik yapılandırması yazısındaki requirepass, ACL ve ağ kısıtlama adımlarını uygulayın. Kendi kaynaklarınızda tam kontrolle Redis çalıştırmak istiyorsanız VDS ya da bulut sunucu paketleri bu iş için uygun bir zemin sunar.

Sıkça Sorulan Sorular#

Redis Pub/Sub mesajları kaybolur mu#

Evet, kaybolabilir ve bu bir hata değil tasarım tercihidir. Mesaj yayınlandığı anda o kanala abone olan istemcilere yazılır; abone yoksa mesaj hiçbir yerde saklanmadan yok olur. Abone süreciniz yeniden başlarken geçen birkaç saniyede yayınlanan mesajları da göremezsiniz. Kaybı tolere edemeyecek işler için Redis Streams ya da liste tabanlı bir kuyruk kullanın.

Pub/Sub ile Redis Streams arasındaki fark nedir#

Pub/Sub anlık yayın yapar ve hiçbir şey saklamaz; Streams ise mesajları bir kayıt defterine yazar, tüketici grupları tanımlamanıza izin verir ve her mesaj için onay bekler. Streams'te bir tüketici çökerse işlenmemiş mesaj bekleyenler listesinde kalır ve başka bir tüketiciye devredilebilir. Kısacası Pub/Sub sinyal taşır, Streams iş taşır.

Aynı Redis bağlantısından hem abone olup hem komut çalıştırabilir miyim#

RESP2 protokolünde hayır; bağlantı abone moduna girdikten sonra yalnızca abonelik komutları, PING ve QUIT kabul edilir. RESP3 protokolünde bu kısıt kalkmıştır ama farklı kütüphanelerde davranış değişebilir. Taşınabilir ve öngörülebilir kod için abone ve yayıncı bağlantılarını her zaman ayırın; çoğu istemci bunun için duplicate() benzeri bir yardımcı sunar.

Kaç aboneye kadar ölçeklenir#

Sınırı belirleyen abone sayısından çok toplam yayın hacmidir. Redis her mesajı her abone için ayrı ayrı sokete yazdığından, maliyet yaklaşık olarak mesaj boyutu çarpı abone sayısıdır. Küçük gövdelerle binlerce abone sorunsuz çalışır; büyük JSON gövdeleriyle birkaç yüz abone bile ağ ve bellek darboğazı yaratabilir. Gövdeye kimlik koyup veriyi ayrıca okutmak en etkili çözümdür.

Abonelerim neden kendiliğinden bağlantıyı kaybediyor#

En sık iki sebep var. Birincisi istemci tarafındaki okuma zaman aşımıdır; abone uzun süre mesaj almazsa kütüphane bağlantıyı kapatır, bunu sonsuz olarak ayarlamanız gerekir. İkincisi sunucu tarafındaki client-output-buffer-limit pubsub sınırıdır; aboneniz mesajları okuyamayacak kadar yavaşsa Redis onu keser. CLIENT LIST çıktısındaki bellek sütunlarına bakarak hangisi olduğunu ayırt edebilirsiniz.

Pub/Sub kanallarını nasıl listelerim ve kimin dinlediğini nasıl görürüm#

PUBSUB CHANNELS komutu en az bir abonesi olan kanalları listeler, isteğe bağlı bir glob kalıbıyla daraltabilirsiniz. PUBSUB NUMSUB kanal1 kanal2 her kanalın abone sayısını, PUBSUB NUMPAT ise toplam kalıp abonelik sayısını verir. Kalıp abonelikleri CHANNELS çıktısında görünmez, bu yüzden iki komutu birlikte kullanmak gerekir. Bu üç sayıyı izleme sisteminize eklerseniz ölü abone süreçlerini erkenden yakalarsınız.

Kapanış#

Redis Pub/Sub, doğru yerde kullanıldığında kurulumu en kolay, gecikmesi en düşük yayın mekanizmalarından biridir. Aklınızda kalması gereken dört alışkanlık şudur: abone ve yayıncı bağlantılarını daima ayırın, abone süreçlerini servis yöneticisi altında sonsuz okuma zaman aşımıyla çalıştırın, kanaldan büyük gövde değil küçük kimlik geçirin ve PUBSUB NUMSUB değerini izleyerek ölü aboneleri erken yakalayın. Kaybı tolere edemeyen bir iş akışı varsa Streams'e geçmekten çekinmeyin; Pub/Sub'ı kuyruk gibi kullanmaya çalışmak, er ya da geç sessizce kaybolan mesajlarla sonuçlanır.

Kendi Redis örneğinizi barındıracaksanız root erişimli bir makine ve öngörülebilir bellek gerekir; VDS ve sanal sunucu paketlerimiz bu iş için tasarlandı, daha esnek ölçeklenme isterseniz bulut sunucu tarafına bakabilirsiniz. Kurulum, sıkılaştırma ve izleme kısmını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz Redis dahil servislerin bakımını sizin yerinize yürütür.