BullMQ ਦੇ ਫ਼ਾਇਦੇ ਤੇ ਨੁਕਸਾਨ ਕੀ ਹਨ ਅਤੇ ਕਦੋਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?

Question

IT Interview Practice · Accepted Answer

BullMQ Node.js ਲਈ Redis-ਆਧਾਰਿਤ job queue ਹੈ। ਇਸ ਦੀ ਯੋਗਤਾ ਪਰਖਣ ਲਈ **ਉਹ ਕੰਮ ਵੇਖੋ ਜੋ HTTP ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਮੁੱਕ ਸਕਦਾ ਹੈ ਅਤੇ ਜਿਸ ਦੀ ਸਥਿਤੀ ਦੇਖਣ ਜਾਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ**।

ਵੱਡੀ ਰਿਪੋਰਟ ਸੋਚੋ। ਬੇਨਤੀ ਅੰਦਰ ਬਣਾਉਣ ਨਾਲ ਵਰਤੋਂਕਾਰ timeout ਤੱਕ ਉਡੀਕ ਸਕਦਾ ਹੈ। ਕਿਊ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੰਮ ਸਵੀਕਾਰ ਕਰਨ, job ID ਦੇਣ ਅਤੇ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦਿੰਦੀ ਹੈ।

## 1. ਵੇਖੋ ਕਿ ਕੰਮ ਕਿਊ ਵਿੱਚ ਜਾਣ ਨਾਲ ਕੀ ਬਦਲਦਾ ਹੈ

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

Producer ਜੌਬ ਭੇਜਦਾ ਹੈ; worker ਉਸ ਨੂੰ ਕਰਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਤਰੱਕੀ ਵੇਖਦਾ ਹੈ ਅਤੇ ਤਿਆਰ ਹੋਣ ਉੱਤੇ ਸੰਭਾਲੀ ਰਿਪੋਰਟ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।

ਰਿਪੋਰਟ ਨੂੰ ਅਜੇ ਵੀ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਉਸ ਦੀ ਉਮਰ ਇੱਕ HTTP ਬੇਨਤੀ ਖੁੱਲ੍ਹੀ ਰੱਖਣ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੀ ਅਤੇ workers API ਸਰਵਰਾਂ ਤੋਂ ਵੱਖ ਸੰਭਾਲੇ ਜਾ ਸਕਦੇ ਹਨ।

## 2. ਫਾਇਦੇ ਨੂੰ ਲੋੜ ਨਾਲ ਮਿਲਾਓ

| ਲੋੜ | BullMQ ਦੀ ਸਮਰੱਥਾ | ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਅਜੇ ਕੀ ਤੈਅ ਕਰਨਾ ਹੈ |
| --- | --- | --- |
| ਅਸਥਾਈ ਫੇਲ੍ਹ ਤੋਂ ਬਹਾਲੀ | ਵਧਦੇ ਅੰਤਰ ਨਾਲ retries | ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਯੋਗ ਹਨ ਅਤੇ ਕਦੋਂ ਰੁਕਣਾ ਹੈ। |
| ਬਾਅਦ ਵਿੱਚ ਜਾਂ schedule ਉੱਤੇ ਚਲਾਉਣਾ | Delayed jobs ਅਤੇ scheduling | ਲੋੜੀਂਦਾ ਸਮਾਂ ਅਤੇ downtime ਮਗਰੋਂ ਵਿਹਾਰ। |
| ਪ੍ਰੋਸੈਸਿੰਗ ਲੋਡ ਸੰਭਾਲਣਾ | Concurrency ਅਤੇ rate limits | ਡਾਟਾਬੇਸ ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੀਆਂ ਸੁਰੱਖਿਅਤ ਹੱਦਾਂ। |
| ਪਿਛੋਕੜ ਸਮਰੱਥਾ ਵਧਾਉਣਾ | ਵਾਧੂ workers | ਅਗਲੀ ਨਿਰਭਰਤਾ ਵਧਿਆ ਲੋਡ ਸਹਿ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। |

ਰਿਪੋਰਟ ਲਈ ਇਹ ਫੀਚਰ ਆਪਣਾ job-state ਅਤੇ retry ਤੰਤਰ ਲਿਖਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। ਇਹ ਤਰੱਕੀ ਅਤੇ ਫੇਲ੍ਹ ਦੀ ਜਾਂਚ ਲਈ ਸਥਿਤੀ ਵੀ ਦਿੰਦੇ ਹਨ। ਹੋਰ workers ਤਦੋਂ ਹੀ ਲਾਭਕਾਰੀ ਹਨ ਜਦੋਂ ਨਿਰਭਰਤਾਵਾਂ ਉੱਤੇ ਬੇਹੱਦ ਲੋਡ ਪਾਏ ਬਿਨਾਂ ਕੰਮ ਜਲਦੀ ਮੁਕਾਉਣ।

## 3. ਸਹੀਪਣ ਦੀ ਮੁੱਖ ਚੁਣੌਤੀ ਸਮਝੋ

Worker ਰਿਪੋਰਟ ਸੰਭਾਲ ਕੇ ਜੌਬ ਪੂਰੀ ਦਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ। Retry ਫਿਰ ਕੰਮ ਦੁਹਰਾ ਸਕਦਾ ਹੈ। ਪੈਸੇ ਕੱਟਣ ਜਾਂ ਸੂਚਨਾ ਭੇਜਣ ਵਰਗੇ ਕੰਮ ਵਿੱਚ ਇਹ ਹੋਰ ਗੰਭੀਰ ਹੈ।

ਮੰਗੇ ਕੰਮ ਲਈ ਸਥਿਰ ਕਾਰੋਬਾਰੀ ਪਛਾਣ ਵਰਤੋ। ਉਹੀ ਪਛਾਣ ਦੁਹਰਾਉਣ ਨਾਲ ਹੋਰ ਅਸਰ ਪੈਦਾ ਕਰਨ ਦੀ ਥਾਂ ਨਤੀਜਾ ਮੁੜ ਵਰਤਿਆ ਜਾਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਿਆ ਜਾਵੇ। ਇਹ idempotency ਹੈ। ਬਾਹਰੀ ਅਸਰਾਂ ਲਈ ਪ੍ਰਦਾਤਾ ਦਾ ਸਮਰਥਨ ਵਰਤੋ ਜਿੱਥੇ ਮਿਲੇ ਅਤੇ ਅਨਿਸ਼ਚਿਤ ਨਤੀਜੇ ਮਿਲਾਓ। [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs)।

ਜੇ ਡਾਟਾਬੇਸ ਰਿਕਾਰਡ ਸੰਭਾਲਣ ਨਾਲ ਜੌਬ ਵੀ ਬਣਨੀ ਹੈ, ਤਾਂ ਦੋ ਲਿਖਤਾਂ ਵਿਚਲਾ ਅੰਤਰ ਸੋਚੋ। Outbox ਕਾਰੋਬਾਰੀ ਰਿਕਾਰਡ ਵਾਲੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਹੀ ਹਦਾਇਤ ਰੱਖਦਾ ਹੈ; publisher ਬਾਅਦ ਵਿੱਚ ਕਿਊ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਭੇਜਣਾ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ worker ਨੂੰ ਅਜੇ ਵੀ idempotency ਚਾਹੀਦੀ ਹੈ।

## 4. Redis ਅਤੇ worker ਚਲਾਉਣ ਦੀ ਲਾਗਤ ਵੀ ਜੋੜੋ

Redis ਉਡੀਕਦਾ ਕੰਮ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ persistence, ਮੈਮੋਰੀ ਨੀਤੀ ਅਤੇ ਬਹਾਲੀ ਯੋਜਨਾ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਕਿਊ ਲਈ noeviction ਨੀਤੀ ਰੱਖੋ: ਮੈਮੋਰੀ ਖਾਲੀ ਕਰਨ ਲਈ ਚੁੱਪਚਾਪ keys ਹਟਾਉਣਾ ਲਾਜ਼ਮੀ ਬਚਣ ਵਾਲੀਆਂ jobs ਲਈ ਠੀਕ ਨਹੀਂ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ restart ਸੁਰੱਖਿਅਤ ਹੋਣ ਨਾਲ Redis ਦੀ ਹਰ ਫੇਲ੍ਹ ਹਾਲਤ ਢੱਕੀ ਜਾਂਦੀ ਹੈ; ਬਹਾਲੀ ਟੈਸਟ ਕਰੋ। [Production guidance](https://docs.bullmq.io/guide/going-to-production)।

ਵੱਡੇ ਰਿਪੋਰਟ ਫਾਈਲ ਉਚਿਤ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ ਅਤੇ jobs ਵਿੱਚ ਹਵਾਲੇ ਦਿਓ। ਪੂਰੀਆਂ ਅਤੇ ਫੇਲ੍ਹ jobs ਦੇ ਰਿਕਾਰਡ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖਣੇ ਹਨ ਤੈਅ ਕਰੋ, ਤਾਂ ਜੋ Redis ਵਰਤੋਂ ਕਾਬੂ ਵਿੱਚ ਰਹੇ।

ਭਾਰੀ CPU ਕੰਮ worker ਦਾ event loop ਰੋਕ ਕੇ lock renewal ਵਿੱਚ ਰੁਕਾਵਟ ਪਾ ਸਕਦਾ ਹੈ। ਜੌਬ stalled ਮੰਨੀ ਜਾ ਕੇ ਮੁੜ ਚੱਲ ਸਕਦੀ ਹੈ। ਅਜਿਹੇ ਕੰਮ ਲਈ ਉਚਿਤ worker threads ਜਾਂ ਵੱਖਰੇ processors ਵਰਤੋ ਅਤੇ stalled jobs ਵੇਖੋ। [Stalled jobs](https://docs.bullmq.io/guide/jobs/stalled)।

## 5. ਸ਼ਰਤਾਂ ਅਨੁਸਾਰ ਸਿਫਾਰਸ਼ ਕਰੋ

- BullMQ ਚੁਣੋ ਜੇ Node.js ਐਪ ਨੂੰ ਨਿਗਰਾਨੀਯੋਗ ਪਿਛੋਕੜ ਕੰਮ, retries ਅਤੇ ਵੱਖਰੇ scale ਹੋਣ ਵਾਲੇ workers ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਟੀਮ Redis ਭਰੋਸੇਯੋਗ ਚਲਾ ਸਕਦੀ ਹੈ।
- ਛੋਟਾ ਸਥਾਨਕ ਕੰਮ ਸਧਾਰਨ ਰੱਖੋ ਜੇ ਉਸ ਨੂੰ ਟਿਕਾਊ tracking ਜਾਂ ਸੁਤੰਤਰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।
- ਜੇ ਮੁੱਖ ਲੋੜ ਕਿਊ ਕੰਮ ਮੁਕਾਉਣਾ ਨਹੀਂ ਸਗੋਂ ਕਈ ਸੁਤੰਤਰ consumers ਵੱਲੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ replay ਹੈ, ਤਾਂ ਟਿਕਾਊ event log ਪਰਖੋ।

ਰਿਪੋਰਟ ਲਈ ਫੇਲ੍ਹ ਨਿਰਭਰਤਾ, ਨਤੀਜਾ ਸੰਭਾਲਣ ਮਗਰੋਂ worker crash ਅਤੇ outage ਮਗਰੋਂ ਬਹਾਲੀ ਟੈਸਟ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਵਰਤੋਂਕਾਰ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਥਿਤੀ ਦਿਸਦੀ ਹੈ ਅਤੇ retries ਟਕਰਾਉਂਦੇ ਨਤੀਜੇ ਨਹੀਂ ਬਣਾਉਂਦੇ।

**ਯਾਦ ਰੱਖੋ:** BullMQ ਜੌਬ ਤਾਲਮੇਲ ਦਿੰਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਸਹੀਪਣ ਐਪਲੀਕੇਸ਼ਨ ਦਿੰਦੀ ਹੈ ਅਤੇ ਕਿਊ ਚਲਾਉਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਟੀਮ ਦੀ ਰਹਿੰਦੀ ਹੈ।

ਲੋੜ	BullMQ ਦੀ ਸਮਰੱਥਾ	ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਅਜੇ ਕੀ ਤੈਅ ਕਰਨਾ ਹੈ
ਅਸਥਾਈ ਫੇਲ੍ਹ ਤੋਂ ਬਹਾਲੀ	ਵਧਦੇ ਅੰਤਰ ਨਾਲ retries	ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਯੋਗ ਹਨ ਅਤੇ ਕਦੋਂ ਰੁਕਣਾ ਹੈ।
ਬਾਅਦ ਵਿੱਚ ਜਾਂ schedule ਉੱਤੇ ਚਲਾਉਣਾ	Delayed jobs ਅਤੇ scheduling	ਲੋੜੀਂਦਾ ਸਮਾਂ ਅਤੇ downtime ਮਗਰੋਂ ਵਿਹਾਰ।
ਪ੍ਰੋਸੈਸਿੰਗ ਲੋਡ ਸੰਭਾਲਣਾ	Concurrency ਅਤੇ rate limits	ਡਾਟਾਬੇਸ ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੀਆਂ ਸੁਰੱਖਿਅਤ ਹੱਦਾਂ।
ਪਿਛੋਕੜ ਸਮਰੱਥਾ ਵਧਾਉਣਾ	ਵਾਧੂ workers	ਅਗਲੀ ਨਿਰਭਰਤਾ ਵਧਿਆ ਲੋਡ ਸਹਿ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

1. ਵੇਖੋ ਕਿ ਕੰਮ ਕਿਊ ਵਿੱਚ ਜਾਣ ਨਾਲ ਕੀ ਬਦਲਦਾ ਹੈ

2. ਫਾਇਦੇ ਨੂੰ ਲੋੜ ਨਾਲ ਮਿਲਾਓ

3. ਸਹੀਪਣ ਦੀ ਮੁੱਖ ਚੁਣੌਤੀ ਸਮਝੋ

4. Redis ਅਤੇ worker ਚਲਾਉਣ ਦੀ ਲਾਗਤ ਵੀ ਜੋੜੋ

5. ਸ਼ਰਤਾਂ ਅਨੁਸਾਰ ਸਿਫਾਰਸ਼ ਕਰੋ

ਸੰਬੰਧਿਤ ਸਵਾਲ