Jaké výhody a nevýhody má BullMQ a kdy jej použít?

Question

IT Interview Practice · Accepted Answer

BullMQ je fronta úloh pro Node.js založená na Redis. Její vhodnost posuzujte podle **práce, která může skončit až po HTTP odpovědi a potřebuje sledování nebo opakování**.

Uvažujme velký report. Vytváření přímo v požadavku může uživatele nechat čekat až do timeoutu. Fronta umožní práci přijmout, vrátit ID úlohy a zpracovat ji zvlášť.

## 1. Pochopte změnu po přesunu do fronty

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

Producent zadá úlohu a worker ji provede. Uživatel sleduje průběh a hotový uložený report si stáhne.

Report stále vyžaduje čas na výpočet. Zlepšení spočívá v tom, že jeho životnost nezávisí na otevřeném HTTP požadavku a workery lze spravovat odděleně od API serverů.

## 2. Přiřaďte přínosy k požadavkům

| Potřeba | Schopnost BullMQ | Co musí určit aplikace |
| --- | --- | --- |
| Zotavení z dočasných chyb | Opakování s prodlevou | Které chyby opakovat a kdy přestat. |
| Pozdější nebo plánované spuštění | Odložené úlohy a plánování | Požadované načasování a chování po výpadku. |
| Řízení zátěže | Souběh a omezení četnosti | Bezpečné limity databáze a externích služeb. |
| Větší kapacita práce na pozadí | Další workery | Zda další závislost unese zvýšený provoz. |

U reportu tyto funkce nahrazují vlastní správu stavů a opakování. Poskytují také stavové informace pro průběh a vyšetřování chyb. Více workerů pomáhá jen tehdy, když zkrátí dokončení bez přetížení závislostí.

## 3. Pochopte hlavní otázku správnosti

Worker může uložit report a spadnout před označením úlohy za hotovou. Opakování pak může práci provést znovu. U stržení peněz nebo odeslání oznámení má stejný vzorec závažnější důsledky.

Použijte stabilní obchodní identitu požadované práce. Opakování stejné identity má použít nebo bezpečně nahradit zamýšlený výsledek místo dalšího obchodního účinku. To je idempotence. U externích účinků využijte podporu poskytovatele a ověřujte nejasné výsledky. [Idempotentní úlohy](https://docs.bullmq.io/patterns/idempotent-jobs).

Pokud uložení databázového záznamu musí také vytvořit úlohu, řešte mezeru mezi zápisy. Outbox zaznamená instrukci ve stejné transakci jako obchodní záznam; publikující proces ji později doručí do fronty. Doručení se může opakovat, takže worker stále potřebuje idempotenci.

## 4. Započítejte provoz Redis a workerů

Redis uchovává čekající práci, proto záleží na persistenci, paměťové politice a obnově. Pro frontu nastavte noeviction: tiché odstraňování klíčů kvůli paměti není vhodné pro úlohy, které musí zůstat dostupné. Obnovu testujte; bezpečný restart aplikace neřeší každý výpadek Redis. [Provozní doporučení](https://docs.bullmq.io/guide/going-to-production).

Velké soubory reportů ukládejte do vhodného úložiště a v úlohách předávejte odkazy. Určete dobu uchování hotových a neúspěšných úloh, aby spotřeba Redis zůstala pod kontrolou.

Náročný výpočet může zablokovat event loop workeru a narušit obnovu zámku. Úloha pak může být považována za zastavenou a spuštěna znovu. Pro takovou práci použijte vhodná worker threads nebo izolované procesory a sledujte stalled jobs. [Zastavené úlohy](https://docs.bullmq.io/guide/jobs/stalled).

## 5. Dejte podmíněné doporučení

- BullMQ vyberte, když aplikace Node.js potřebuje sledovatelnou práci na pozadí, opakování a samostatně škálovatelné workery a tým umí spolehlivě provozovat Redis.
- Jednoduchou lokální akci ponechte jednoduchou, pokud nepotřebuje trvalé sledování nebo nezávislý běh.
- Pokud jde hlavně o dlouhodobé přehrávání několika nezávislými konzumenty, zvažte trvalý log událostí místo fronty dokončovaných úloh.

U reportu otestujte selhání závislosti, pád workeru po uložení výstupu a obnovu po výpadku. Potvrďte důvěryhodný stav pro uživatele a absenci konfliktních výstupů po opakování.

**Zapamatujte si:** BullMQ poskytuje koordinaci úloh. Aplikace zajišťuje obchodní správnost a tým odpovídá za provoz fronty.

Potřeba	Schopnost BullMQ	Co musí určit aplikace
Zotavení z dočasných chyb	Opakování s prodlevou	Které chyby opakovat a kdy přestat.
Pozdější nebo plánované spuštění	Odložené úlohy a plánování	Požadované načasování a chování po výpadku.
Řízení zátěže	Souběh a omezení četnosti	Bezpečné limity databáze a externích služeb.
Větší kapacita práce na pozadí	Další workery	Zda další závislost unese zvýšený provoz.

1. Pochopte změnu po přesunu do fronty

2. Přiřaďte přínosy k požadavkům

3. Pochopte hlavní otázku správnosti

4. Započítejte provoz Redis a workerů

5. Dejte podmíněné doporučení

Související otázky