Kullanıcı bir form gönderiyor. Uygulamanız e-posta gönderiyor, görsel işliyor, dış bir servise istek atıyor ve ancak sonra "başarılı" diyor. Kullanıcı bu süre boyunca beklemek zorunda kalıyor.
Kuyruk sistemi bu işleri arka plana taşır. Bu yazı, VDS sunucunuzda arka plan iş yönetimini anlatıyor.
Neden Kuyruk?
Web istekleri kısa olmalıdır. Uzun süren her işlem şu sorunları üretir:
| Sorun | Sonucu |
|---|---|
| Kullanıcı bekler | Kötü deneyim, terk edilen işlem |
| İşçi süreç meşgul kalır | Eşzamanlı kapasite düşer |
| Zaman aşımı riski | İşlem yarıda kesilir |
| Hata durumunda kayıp | İşlem tekrarlanamaz |
| Dış servis bağımlılığı | O servis yavaşsa siteniz yavaşlar |
Son satır en sinsi olanıdır: dış bir servis yavaşladığında sizin siteniz de yavaşlar — çünkü işçi süreçleriniz o yanıtı beklerken bloke olur. Yeterince istek birikirse site tamamen yanıt veremez hâle gelir.
Nasıl Çalışır?
Mantık basittir:
- Uygulama, yapılacak işi bir kuyruğa ekler
- Kullanıcıya hemen yanıt döner
- Arka planda çalışan işçi süreçler kuyruktan iş alır
- İşi yapar, sonucu kaydeder
- Gerekirse kullanıcıya bildirim gönderilir
İkinci adım kullanıcı deneyimini dönüştürür: form gönderimi anında tamamlanır, ağır işler arkada devam eder.
Kuyruğa Taşınacak İşler
- E-posta gönderimi. En yaygın ve en kolay kazanç.
- Görsel ve video işleme. Boyutlandırma, format dönüşümü.
- Dış servis çağrıları. Ödeme bildirimi, kargo sorgusu, entegrasyon.
- Rapor üretimi. Büyük veri kümeleri üzerinde hesaplama.
- Toplu içe/dışa aktarma. Binlerce kaydın işlenmesi.
- Arama indeksi güncellemesi.
- Bildirim gönderimi. Anlık bildirim, SMS.
Birinci madde neredeyse her uygulamada uygulanabilir ve tek başına belirgin fark yaratır: e-posta gönderimini arka plana almak, form yanıt süresini saniyelerden milisaniyelere indirir.
Kuyruk Altyapısı Seçenekleri
| Yöntem | Uygunluk | Not |
|---|---|---|
| Veritabanı tablosu | Düşük hacim | Ek kurulum gerekmez |
| Bellek tabanlı depo | Orta-yüksek hacim | Hızlı, kurulumu kolay |
| Özel mesaj kuyruğu | Yüksek hacim, karmaşık akış | Daha fazla özellik ve karmaşıklık |
Başlangıç için pratik tavsiye: veritabanı tablosuyla başlayın. Ek bir servis kurmadan çalışır, hata ayıklaması kolaydır ve düşük hacimde tamamen yeterlidir.
Bu üç seçeneğin hiçbiri paylaşımlı hostingde kurulamaz — sürekli çalışan işçi süreçler kök erişimi gerektirir. Arka plan iş yönetimi ihtiyacı, bir uygulamanın VDS sunucu gerektirdiğinin en net göstergelerinden biridir.
Hacim arttığında bellek tabanlı bir depoya geçmek görece kolaydır. Özel mesaj kuyruğu sistemleri ise ancak karmaşık yönlendirme ve yüksek hacim gerektiğinde anlamlıdır.
İşçi Süreçler
Kuyruktan iş alıp yapan süreçlerdir. Yönetiminde dikkat edilecekler:
- Servis olarak tanımlayın. Elle başlatılan bir işçi, sunucu yeniden başladığında gelmez.
- Sayısını dengeli tutun. Her işçi bellek tüketir; toplam kullanım sunucu kapasitesini aşmamalı.
- Bellek sınırı koyun. Sızıntı yapan bir işçi tüm sunucuyu tüketmesin.
- Periyodik yeniden başlatın. Uzun süre çalışan işçilerde bellek birikimi olağandır.
- Nazik kapanma sağlayın. Kapanma sinyali geldiğinde eldeki işi bitirsin.
Dördüncü madde pratik bir alışkanlıktır: birçok kuyruk kütüphanesi, belirli sayıda iş işledikten sonra işçinin kendini sonlandırmasını destekler. Servis denetleyicisi onu yeniden başlatır ve bellek birikimi kendiliğinden temizlenir.
Hata Yönetimi
Arka plan işlerinin en kritik farkı şudur: hata olduğunda kimse görmez. Kullanıcı zaten "başarılı" yanıtını almıştır.
Bu yüzden hata yönetimi baştan kurulmalıdır:
- Yeniden deneme. Geçici hatalar için otomatik tekrar. Artan aralıklarla.
- Deneme sınırı. Sonsuz döngüye girmesin.
- Başarısız iş kuyruğu. Sınırı aşan işler ayrı bir yerde saklansın, kaybolmasın.
- Uyarı. Başarısız iş sayısı eşiği aştığında bildirim gelsin.
- Elle tekrar çalıştırma imkânı. Sorun düzeltildikten sonra biriken işler işlenebilmeli.
Üçüncü madde vazgeçilmezdir: başarısız işler sessizce silinirse, kaç siparişin onay e-postası gitmediğini asla bilemezsiniz.
İş Tasarımı Kuralları
Kuyruğa atılan işlerin belirli özellikleri olmalıdır:
- Tekrarlanabilir olmalı. Aynı iş iki kez çalışırsa sorun çıkmamalı — çünkü çıkabilir.
- Küçük olmalı. Binlerce kaydı tek işte işlemek yerine, parçalara bölün.
- Kendi kendine yeterli olmalı. İhtiyaç duyduğu bilgiyi taşımalı, oturum verisine bağlı olmamalı.
- Sıralamaya bağımlı olmamalı. Ya da bağımlıysa bu açıkça yönetilmeli.
Birinci madde en önemlisidir ve sıkça atlanır. Bir iş çalışır, işini bitirir ama sonucu kaydedemeden süreç çöker — sistem onu tekrar dener. Aynı e-posta iki kez gitmemeli, aynı ödeme iki kez işlenmemelidir.
Çözüm, işin yapılıp yapılmadığını kontrol eden bir işaret tutmaktır.
Kuyruk İzleme
Kuyruk, sessizce büyüyen ve fark edildiğinde çoktan sorun üretmiş bir yerdir:
- Bekleyen iş sayısı. Normal seviyenizi bilin, eşik uyarısı tanımlayın.
- En eski işin bekleme süresi. Toplam sayıdan daha anlamlıdır.
- İşlem süresi. Ortalama iş ne kadar sürüyor?
- Başarısız iş sayısı. Artıyorsa bir şey bozulmuştur.
- İşçi süreç durumu. Hepsi ayakta mı?
Beşinci madde kritik bir kontroldür ve şaşırtıcı derecede sık atlanır: tüm işçi süreçler çökmüşse kuyruk sessizce dolar ve hiçbir iş işlenmez. Site normal çalışıyor görünür, ama e-postalar gitmez ve siparişler işlenmez.
Öncelik Ayrımı
Tüm işler aynı aciliyette değildir. Ayrı kuyruklar tanımlamak faydalıdır:
- Yüksek öncelik. Şifre sıfırlama, doğrulama kodu, ödeme bildirimi.
- Normal. Sipariş onayı, bildirimler.
- Düşük öncelik. Rapor üretimi, toplu işlemler, arşivleme.
Bu ayrım olmadan klasik bir sorun yaşanır: on bin kişilik bir bülten gönderimi kuyruğa girer ve şifre sıfırlama e-postası bunların arkasında bekler. Kullanıcı dakikalarca bekler ve destek talebi açar.
Sonuç
Kuyruk sistemi, uzun işlemleri kullanıcının önünden çekmenin standart yoludur — ama asıl kritik faydası dayanıklılıktır: dış bir servis yavaşladığında siteniz yavaşlamaz. Başlangıç için veritabanı tablosu yeterlidir, ek servis kurmayın. Kurarken üç şeyi atlamayın: işleri tekrarlanabilir tasarlayın (aynı iş iki kez çalışabilir), başarısız işleri ayrı bir kuyrukta saklayın ve işçi süreçlerin ayakta olduğunu izleyin — hepsi çökerse kuyruk sessizce dolar ve site normal görünmeye devam eder.
Sıkça Sorulan Sorular (SSS)
Kuyruk sistemi gerçekten gerekli mi?
E-posta gönderimi, görsel işleme ve dış servis çağrısı yapan her uygulamada belirgin fark yaratır. En kritik faydası, dış bir servis yavaşladığında sitenizin de yavaşlamamasıdır — işçi süreçleriniz o yanıtı beklerken bloke olmaz.
Hangi kuyruk altyapısını seçmeliyim?
Veritabanı tablosuyla başlayın — ek servis kurmadan çalışır ve hata ayıklaması kolaydır. Düşük hacimde tamamen yeterlidir. Hacim arttığında bellek tabanlı bir depoya geçmek görece kolaydır.
Aynı iş iki kez çalışabilir mi?
Evet, çalışabilir. Bir iş tamamlanır ama sonucu kaydedilemeden süreç çökerse sistem onu tekrar dener. Bu yüzden işler tekrarlanabilir tasarlanmalıdır — aynı e-posta iki kez gitmemeli, aynı ödeme iki kez işlenmemelidir.
Neden ayrı kuyruklar gerekli?
Tüm işler aynı aciliyette değildir. Ayrım yapılmazsa on bin kişilik bir bülten gönderimi kuyruğa girer ve şifre sıfırlama e-postası onların arkasında bekler. Yüksek öncelikli işlemsel iletileri ayrı bir kuyrukta tutun.
