Queue ve Worker Sistemlerine Giriş: Neden Gereklidir?
Modern web uygulamaları, anlık veri işleme, e‑posta gönderimi, görüntü işleme gibi yoğun görevlerle karşı karşıya kalır. Bu görevleri doğrudan HTTP isteği içinde senkron olarak çalıştırmak, istek süresini uzatır ve kullanıcı deneyimini olumsuz etkiler. Örneğin, bir e‑ticaret sitesinde sipariş onayı sırasında ödeme doğrulaması, stok güncellemesi ve bildirim gönderimi gibi adımlar birleştirildiğinde, ortalama yanıt süresi %40’a kadar artabilir.
Queue (kuyruk) ve Worker (işçi) sistemleri, bu tür ağır görevleri arka plana alarak asenkron çalıştırır. İşlemler bir kuyruğa eklenir, ardından ayrı bir süreç (worker) bu kuyruktan alıp gerçekleştirir. Bu yaklaşım sayesinde:
- İstek yanıt süresi %60‑70 azalır,
- Sistem kaynakları daha verimli kullanılır,
- Gecikmeli görevler (ör. rapor üretimi) planlı bir şekilde yürütülür,
- Hata yönetimi ve yeniden deneme mekanizmaları merkezi bir noktada toplanır.
Queue sistemleri genellikle iki popüler teknoloji etrafında şekillenir: Redis ve RabbitMQ. İkisi de mesaj kuyruğu işlevi görse de mimari, performans ve kullanım senaryoları bakımından farklılıklar gösterir. Bu makalede bu farkları derinlemesine inceleyecek, kurulum adımlarını gösterecek ve hangi durumda hangi teknolojiyi tercih etmeniz gerektiğine karar vermenize yardımcı olacağız.
Redis Queue Nedir ve Nasıl Çalışır?

Redis, bellek içi veri yapısı sunucusudur ve list, set, sorted set gibi veri tiplerini destekler. Queue (kuyruk) işlevi ise LPUSH ve BRPOP gibi komutlarla sağlanır. Bir iş, LPUSH ile kuyruğun başına eklenir; worker ise BRPOP ile kuyruğun sonundan bloklanarak bekler ve bir iş geldiğinde hemen işler.
Redis’in bellek içi yapısı, milisaniye seviyesinde gecikme sağlar. Bu, gerçek zamanlı bildirim sistemleri, oyun sunucuları ve yüksek frekanslı veri akışı gerektiren mikroservis mimarileri için idealdir. Ancak, veri kalıcılığı için ek yapılandırma (RDB/AOF) gerekir; aksi takdirde sunucu yeniden başlatıldığında kuyrukta bulunan işler kaybolabilir.
Redis’i bir queue olarak kullanmanın tipik adımları şunlardır:
- Redis sunucusunu
apt-get install redis-serverya dadocker run redisile kurun. - Uygulama kodunda iş gönderimi için
LPUSH queue_name payloadkomutunu çağırın. - Worker sürecinde
BRPOP queue_name timeoutile kuyruktan iş alın ve iş mantığını çalıştırın. - İş tamamlandığında sonuçları başka bir Redis anahtarına (ör.
HASH) kaydedin veya bir callback URL’sine gönderin.
Bu basit akış, düşük gecikme ve yüksek throughput (saniyede binlerce mesaj) gerektiren senaryolarda çok etkili olur. Ancak, karmaşık yönlendirme (routing), mesaj önceliği ve kalıcı saklama gibi özellikler sınırlı olduğundan, daha gelişmiş ihtiyaçlar için RabbitMQ gibi bir mesaj aracısına geçmek mantıklı olabilir.
RabbitMQ Nedir ve Temel Özellikleri
RabbitMQ, AMQP (Advanced Message Queuing Protocol) tabanlı bir mesaj aracısıdır. Mesajlar exchange üzerinden yönlendirilir, queue’lara düşer ve consumer (worker) tarafından alınır. Bu mimari, mesaj yönlendirme, önceliklendirme, gecikmeli mesaj (delayed message) ve dead‑letter queue gibi gelişmiş özellikleri doğal olarak sunar.
RabbitMQ’nun en büyük avantajı yüksek dayanıklılık ve esnek yönlendirme kurallarıdır. Mesajlar disk üzerinde tutulabilir, bu sayede sunucu çökse bile kuyruk kaybolmaz. Ayrıca, exchange tipleri (direct, fanout, topic, headers) sayesinde aynı mesajı birden çok kuyruğa kopyalayabilir, farklı mikroservisler arasında yayın‑abone (pub/sub) modeli kurabilirsiniz.
RabbitMQ kurulumu ve temel kullanım adımları:
- Docker üzerinden
docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:managementkomutuyla hızlıca çalıştırın. - Uygulama içinde bir
exchangetanımlayın (ör.direct). - İş gönderimi sırasında mesajı
routing_keyile exchange’e gönderin. - Worker’lar
queue’a bağlanır,basic.consumeile mesajları alır ve iş mantığını yürütür. - İş tamamlandığında
ackgöndererek mesajın kuyruktan silinmesini sağlayın; hata durumundanackile yeniden kuyruğa ekleyin.
RabbitMQ, özellikle mikroservis mimarilerinde servisler arası iletişim, event‑driven architecture ve yüksek ölçeklenebilirlik gerektiren büyük ölçekli sistemlerde tercih edilir.
Redis vs RabbitMQ: Karşılaştırma Tablosu
| Özellik | Redis Queue | RabbitMQ |
|---|---|---|
| Performans (gecikme) | Milisaniye seviyesinde, bellek içi | Milisaniyeden birkaç saniyeye, disk tabanlı |
| Kalıcılık | AOF/RDB ile opsiyonel | Varsayılan olarak kalıcı |
| Mesaj yönlendirme | Sınırlı (list) | Exchange & routing key ile esnek |
| Önceliklendirme | Manuel list sırası | Priority queue desteği |
| Dead‑letter & retry | Ek kodla uygulanır | Native destek |
| Ölçeklenebilirlik | Cluster ile mümkün | Federation & clustering |
| Kullanım senaryosu | Gerçek zamanlı, düşük gecikme | Kurumsal, karmaşık yönlendirme |
Adım Adım Queue ve Worker Kurulumu: Redis Örneği

Bu bölümde bir PHP/Laravel projesinde Redis queue ve worker kurulumunu örnekleyeceğiz. Laravel, queue:work komutuyla Redis’i doğrudan destekler.
- Redis Sunucusunu Kurun:
sudo apt-get install redis-servervesystemctl start redis. - Laravel Konfigürasyonu:
.envdosyasınaQUEUE_CONNECTION=redisveREDIS_HOST=127.0.0.1ekleyin. - Job Sınıfı Oluşturun:
php artisan make:job SendWelcomeEmailile bir job sınıfı oluşturun, içinde e‑posta gönderim kodunu yazın. - Job’u Kuyruğa Atın: Controller’da
SendWelcomeEmail::dispatch($user);satırıyla işi kuyruğa gönderin. - Worker’ı Başlatın:
php artisan queue:work redis --tries=3 --timeout=60komutuyla worker sürecini başlatın. Bu süreç, kuyruğa gelen işleri alıp işler. - Supervisor ile Daemonize Edin: Production ortamında VDS sunucu paketleri üzerinde
supervisordkonfigürasyonu ekleyerek worker’ı sürekli çalışır durumda tutun.
Bu adımları tamamladığınızda, kullanıcı kaydı anında e‑posta gönderimi arka planda gerçekleşir ve HTTP yanıtı hemen döner. Böylece kullanıcı deneyimi %50 daha hızlı olur.
Adım Adım Queue ve Worker Kurulumu: RabbitMQ Örneği
Node.js tabanlı bir mikroservis için RabbitMQ entegrasyonu yapalım. amqplib paketi ile basit bir üretici (producer) ve tüketici (consumer) oluşturacağız.
- RabbitMQ Sunucusunu Çalıştırın:
docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:management. - Node Projesi Oluşturun:
npm init -y && npm install amqplib. - Producer (Gönderici) Kodunu Yazın:
const amqp = require('amqplib'); async function send(msg){ const conn = await amqp.connect('amqp://localhost'); const ch = await conn.createChannel(); const exchange = 'tasks'; await ch.assertExchange(exchange, 'direct', {durable:true}); ch.publish(exchange, 'email', Buffer.from(msg)); console.log('Gönderildi:',msg); setTimeout(()=>{conn.close()},500); } send('Welcome email for user 123'); - Consumer (Worker) Kodunu Yazın:
const amqp = require('amqplib'); async function consume(){ const conn = await amqp.connect('amqp://localhost'); const ch = await conn.createChannel(); const q = await ch.assertQueue('email_queue',{durable:true}); await ch.bindQueue(q.queue,'tasks','email'); ch.consume(q.queue, msg=>{ if(msg!==null){ console.log('İş alındı:',msg.content.toString()); // e‑posta gönderim kodu burada ch.ack(msg); } }); } consume(); - Worker’ı Daemonize Edin: fiziksel sunucu (dedicated server) üzerinde
systemdservisi tanımlayarak sürekli çalışmasını sağlayın.
Bu yapı, birden çok servis aynı exchange üzerinden farklı routing key ile mesaj gönderdiğinde, ilgili kuyruklar otomatik olarak mesajları alır. Mesaj kaybı olmaz ve yüksek ölçeklenebilirlik sağlanır.
Queue Sistemlerinde Karşılaşılan Yaygın Hatalar ve Maliyetleri
Queue ve worker mimarisini uygularken sıkça rastlanan hatalar, sistem performansını ve maliyetini doğrudan etkiler:
- İşçi (worker) sayısının yetersiz ayarlanması: Kuyrukta birikme olur, gecikme artar ve kullanıcılar zaman aşımına uğrar. Bu durum, ek sunucu kiralama maliyetine yol açar.
- Mesajın kalıcı olmaması: Redis AOF kapalıysa sunucu çökmesiyle tüm işler kaybolur, iş kaybı nedeniyle gelir kaybı yaşanır.
- Ack/Nack yönetiminin hatalı yapılması: Mesajı ack’lamadan işçi kapanırsa mesaj tekrar kuyruğa döner, aynı işin birden fazla kez işlenmesiyle veri tutarsızlığı oluşur.
- Dead‑letter kuyruğunun eksik konfigürasyonu: Hatalı mesajlar sürekli yeniden denenir, CPU ve bellek tüketimi artar, bulut ortamında ölçekleme maliyetleri %30‑40 artabilir.
Bu hataları önlemek için monitoring araçları (Prometheus, Grafana) ve alerter sistemleri kurmak şarttır. Ayrıca, kurumsal hosting paketlerinde sunucu kaynaklarını izleyebileceğiniz panel özelliklerini kullanabilirsiniz.
Gerçek Dünya Senaryosu: E‑ticaret Sitesinde Sipariş İşleme
Bir e‑ticaret platformu, sipariş alındığında şu adımları yürütür:
- Ödeme doğrulama (3rd‑party API)
- Stok güncelleme
- Müşteri bilgilendirme e‑postası
- Kargo entegrasyonu
- Analitik rapor kaydı
Bu adımların hepsini aynı HTTP isteği içinde senkron çalıştırmak, ortalama yanıt süresini 4‑5 saniyeye çıkarır. Bunun yerine:
- İstek alındığında order.process adında bir mesaj RabbitMQ exchange’ine gönderilir.
- Farklı worker’lar (payment‑worker, stock‑worker, email‑worker, shipping‑worker, analytics‑worker) ilgili kuyruğa bağlanır.
- Her worker bağımsız olarak görevini tamamlar; ödeme başarısızsa ilgili worker
nackgönderir ve sipariş durumu “beklemede” olarak kalır.
Bu mimaride, sipariş onayı 1.2 saniye içinde kullanıcıya dönerken arka planda tüm işlemler paralel olarak yürütülür. Sonuç olarak satış dönüşüm oranı %15 artar ve sunucu CPU kullanımında %30 tasarruf sağlanır. Bu örnek, queue sistemlerinin iş akışını nasıl optimize ettiğini somut bir şekilde gösterir.
Sıkça Sorulan Sorular
Redis queue ile RabbitMQ arasında performans farkı nedir?
Redis bellek içi olduğu için milisaniye seviyesinde gecikme sağlar; RabbitMQ ise disk tabanlı kalıcılık ve gelişmiş yönlendirme özellikleri sunar, gecikmesi birkaç milisaniyeden bir saniyeye kadar çıkabilir. Performans ihtiyacınıza göre seçim yapmalısınız.
Queue sisteminde mesaj kaybını nasıl önleyebilirim?
RabbitMQ’da mesajları kalıcı (durable) kuyruklara ve exchange’e gönderin; Redis için AOF veya RDB yedeklemesini aktif hale getirin. Ayrıca, worker’da ack mekanizmasını doğru kullanarak mesajın başarılı işlendiğini sunucuya bildirin.
Worker sayısını artırmak maliyeti artırır mı?
Evet, her worker bir CPU ve bellek kaynağı tüketir. Ancak, kuyrukta birikme olmaması için gereken worker sayısını doğru belirlemek, uzun vadede yüksek ölçekleme maliyetlerini önler. Otomatik ölçekleme (auto‑scaling) politikalarıyla talebe göre worker eklemek en verimli yaklaşımdır.
Queue sistemini Docker içinde nasıl izleyebilirim?
RabbitMQ için yönetim paneli (port 15672) ve Redis için redis-cli monitor komutları kullanılabilir. Ayrıca, Prometheus exporter’ları (rabbitmq_exporter, redis_exporter) ile Grafana’da görsel izleme kurabilirsiniz.
Sonuç: Hangi Sistem Sizin İçin Daha Uygun?
Queue ve worker mimarileri, uygulamanızın ölçeklenebilirliğini ve yanıt süresini dramatik şekilde iyileştirir. Redis, düşük gecikme, yüksek throughput ve basit yapı gerektiren gerçek zamanlı uygulamalar için ideal bir seçimdir. RabbitMQ ise mesaj yönlendirme, kalıcılık ve karmaşık iş akışları gerektiren kurumsal seviyedeki sistemler için daha uygundur.
Karar verirken şu soruları yanıtlayın:
- İş akışınızda mesaj önceliği ve yönlendirme ihtiyacınız var mı?
- Veri kaybı toleransınız ne kadar?
- Performans (gecikme) ne kadar kritik?
Eğer cevaplarınız “yüksek öncelik, kalıcı mesaj, karmaşık yönlendirme” ise RabbitMQ; “milisaniye gecikme, basit kuyruk, yüksek throughput” ise Redis tercih edin. Her iki sistem de AMD Ryzen VDS sunucular ve Intel i9 VDS sunucular üzerinde sorunsuz çalışır, bu yüzden mevcut altyapınıza uygun bir sunucu paketi seçerek hemen kurulum aşamasına geçebilirsiniz.