BullMQ’nun avantajları ve dezavantajları nelerdir, ne zaman kullanılmalıdır?

Question

IT Interview Practice · Accepted Answer

BullMQ, Node.js için Redis tabanlı bir iş kuyruğudur. Uygunluğunu değerlendirmek için **HTTP yanıtından sonra tamamlanabilen ve izlenmesi veya yeniden denenmesi gereken işlerden** başlayın.

Büyük bir rapor düşünün. İstek içinde üretmek, kullanıcıyı istek zaman aşımına uğrayana kadar bekletebilir. Kuyruk, uygulamanın işi kabul etmesini, iş kimliği döndürmesini ve ayrı işlemesini sağlar.

## 1. İş kuyruğa taşındığında neyin değiştiğini görün

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

Üretici işi gönderir; worker gerçekleştirir. Kullanıcı ilerlemeyi kontrol eder ve hazır olduğunda saklanan raporu indirir.

Rapor yine işlem süresi gerektirir. İyileşme, işin ömrünün artık tek bir HTTP isteğini açık tutmaya bağlı olmaması ve worker'ların API sunucularından ayrı yönetilebilmesidir.

## 2. Faydaları gereksinimlerle eşleştirin

| İhtiyaç | BullMQ yeteneği | Uygulamanın hâlâ karar vermesi gereken |
| --- | --- | --- |
| Geçici hatalardan kurtulmak | Gecikme artırımlı yeniden deneme | Hangi hataların yeniden deneneceği ve ne zaman durulacağı. |
| Daha sonra veya zamanında çalışmak | Gecikmeli işler ve zamanlama | Gerekli zamanlama ve kesinti sonrası davranış. |
| İşleme yükünü kontrol etmek | Eşzamanlılık ve hız sınırları | Veritabanı ve dış hizmetler için güvenli sınırlar. |
| Arka plan kapasitesini artırmak | Ek worker'lar | Sonraki bağımlılığın ek yükü karşılayıp karşılayamayacağı. |

Rapor için bu özellikler kendi iş durumu ve yeniden deneme mekanizmanızı yazmanızı önler. İlerleme ve hata incelemesi için durum bilgisi de sağlar. Daha fazla worker, ancak bağımlılıkları aşırı yüklemeden tamamlanma süresini iyileştirdiği sürece yararlıdır.

## 3. Temel doğruluk ödünleşimini anlayın

Worker raporu kaydedip işi tamamlandı olarak işaretlemeden çökebilir. Yeniden deneme aynı işi tekrarlayabilir. Aynı durum para tahsil etmek veya bildirim göndermek gibi eylemlerde daha ciddidir.

İstenen iş için sabit bir iş kimliği kullanın. Aynı kimlikle tekrar, başka bir iş etkisi üretmek yerine amaçlanan sonucu yeniden kullansın veya güvenle değiştirsin. Bu idempotency'dir. Dış etkilerde varsa sağlayıcının desteğini kullanın ve belirsiz sonuçları uzlaştırın. [Idempotent işler](https://docs.bullmq.io/patterns/idempotent-jobs).

Veritabanına kayıt yapmak aynı zamanda iş oluşturmalıysa bu yazmalar arasındaki boşluğu düşünün. Outbox, talimatı iş kaydıyla aynı transaction içinde kaydeder; yayıncı daha sonra kuyruğa iletir. İletim tekrarlanabileceği için worker yine idempotency gerektirir.

## 4. Redis ve worker işletimini maliyete dahil edin

Redis bekleyen işleri saklar; bu yüzden kalıcılığı, bellek politikası ve kurtarma planı önemlidir. Kuyruk için noeviction politikası ayarlayın: bellek açmak amacıyla anahtarları sessizce kaldırmak, korunması gereken işler için uygun değildir. Uygulama yeniden başlatma güvenliğinin her Redis hatasını kapsadığını varsaymak yerine kurtarmayı test edin. [Üretim ortamı rehberi](https://docs.bullmq.io/guide/going-to-production).

Büyük rapor dosyalarını uygun depolamaya koyun ve işlerde referanslarını taşıyın. Redis kullanımını kontrol altında tutmak için tamamlanan ve başarısız iş kayıtlarının ne kadar saklanacağını tanımlayın.

Yoğun CPU işlemesi worker'ın event loop'unu engelleyerek kilit yenilemeyi aksatabilir. İş takılmış kabul edilip tekrar işlenebilir. Bu yük için uygun worker thread'leri veya yalıtılmış işleyiciler kullanın ve takılan işleri izleyin. [Takılan işler](https://docs.bullmq.io/guide/jobs/stalled).

## 5. Koşullu öneri sunun

- Node.js uygulaması gözlemlenebilir arka plan işi, yeniden deneme ve ayrı ölçeklenen worker'lar gerektiriyorsa ve ekip Redis'i güvenilir işletebiliyorsa BullMQ seçin.
- Kalıcı takip veya bağımsız yürütme gerektirmeyen basit bir yerel eylemi basit tutun.
- Ana ihtiyaç kuyruktaki görevleri tamamlamak değil, birden fazla bağımsız tüketicinin uzun vadeli yeniden oynatmasıysa kalıcı olay günlüğünü değerlendirin.

Rapor örneğinde başarısız bağımlılığı, çıktı kaydedildikten sonra worker çökmesini ve kesinti sonrası kurtarmayı test edin. Kullanıcının güvenilir durum gördüğünü ve yeniden denemenin çelişen çıktılar üretmediğini doğrulayın.

**Unutmayın:** BullMQ iş koordinasyonunu sağlar. İş doğruluğunu uygulama sağlar; kuyruğun işletimi ise ekibin sorumluluğunda kalır.

İhtiyaç	BullMQ yeteneği	Uygulamanın hâlâ karar vermesi gereken
Geçici hatalardan kurtulmak	Gecikme artırımlı yeniden deneme	Hangi hataların yeniden deneneceği ve ne zaman durulacağı.
Daha sonra veya zamanında çalışmak	Gecikmeli işler ve zamanlama	Gerekli zamanlama ve kesinti sonrası davranış.
İşleme yükünü kontrol etmek	Eşzamanlılık ve hız sınırları	Veritabanı ve dış hizmetler için güvenli sınırlar.
Arka plan kapasitesini artırmak	Ek worker'lar	Sonraki bağımlılığın ek yükü karşılayıp karşılayamayacağı.

1. İş kuyruğa taşındığında neyin değiştiğini görün

2. Faydaları gereksinimlerle eşleştirin

3. Temel doğruluk ödünleşimini anlayın

4. Redis ve worker işletimini maliyete dahil edin

5. Koşullu öneri sunun

İlgili sorular