BullMQ-இன் நன்மை தீமைகள் என்ன, எப்போது பயன்படுத்தலாம்?

Question

IT Interview Practice · Accepted Answer

BullMQ என்பது Node.js-க்கான Redis அடிப்படையிலான job queue. அது பொருந்துமா என்பதை முடிவு செய்ய, **HTTP response-க்குப் பிறகு முடிக்கக்கூடிய, கண்காணிப்பு அல்லது மறுமுயற்சி தேவைப்படும் வேலை**யிலிருந்து தொடங்குங்கள்.

ஒரு பெரிய அறிக்கையை எடுத்துக்கொள்ளுங்கள். Request-க்குள் அதை உருவாக்கினால் timeout வரை பயனர் காத்திருக்கலாம். Queue வேலையை ஏற்றுக்கொண்டு job ID திருப்பி, தனியாகச் செயலாக்க application-ஐ அனுமதிக்கிறது.

## 1. வேலை queue-க்கு மாறும்போது என்ன மாறுகிறது எனப் பாருங்கள்

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

Producer job-ஐச் சமர்ப்பிக்கிறது; worker அதைச் செய்கிறது. பயனர் முன்னேற்றத்தைப் பார்த்து அறிக்கை தயாரானதும் பதிவிறக்குகிறார்.

அறிக்கைக்கு இன்னும் processing நேரம் தேவை. ஆனால் அதன் வாழ்நாள் ஒரு HTTP request திறந்திருப்பதைச் சார்ந்திருக்காது; workers-ஐ API servers-இலிருந்து தனியாக நிர்வகிக்கலாம் என்பதே மேம்பாடு.

## 2. நன்மைகளைத் தேவையுடன் பொருத்தவும்

| தேவை | BullMQ திறன் | Application இன்னும் முடிவு செய்ய வேண்டியது |
| --- | --- | --- |
| தற்காலிகத் தோல்விகளிலிருந்து மீளுதல் | Backoff உடன் retries | எந்த errors-ஐ retry செய்வது, எப்போது நிறுத்துவது. |
| பின்னர் அல்லது அட்டவணைப்படி இயக்குதல் | Delayed jobs, scheduling | தேவையான நேரம், downtime-க்குப் பிந்தைய நடத்தை. |
| Processing சுமையைக் கட்டுப்படுத்துதல் | Concurrency, rate limits | Database மற்றும் வெளிச் சேவைகளுக்கான பாதுகாப்பான வரம்புகள். |
| Background திறனை அதிகரித்தல் | கூடுதல் workers | அடுத்த dependency கூடுதல் சுமையை ஏற்குமா. |

அறிக்கைக்கு இந்த அம்சங்கள் சொந்த job-state மற்றும் retry கட்டமைப்பை எழுதுவதைத் தவிர்க்கின்றன. முன்னேற்றத்திற்கும் failure ஆய்விற்கும் status தகவலும் தருகின்றன. Dependencies-ஐ அதிகமாகச் சுமத்தாமல் completion நேரத்தைக் குறைக்கும் வரையே கூடுதல் workers பயனுள்ளவை.

## 3. முக்கிய correctness சிக்கலைப் புரிந்துகொள்ளவும்

Worker அறிக்கையைச் சேமித்துவிட்டு job complete எனக் குறிக்கும் முன் crash ஆகலாம். Retry வேலையை மீண்டும் செய்யலாம். பணம் வசூலித்தல் அல்லது notification அனுப்புதல் போன்ற செயல்களில் இதே நிலை தீவிரமானது.

கோரப்பட்ட வேலைக்கு நிலையான business identity பயன்படுத்தவும். அதே identity மீண்டும் வந்தால் புதிய வணிக விளைவுக்குப் பதிலாக ஏற்கெனவே உள்ள முடிவைப் பயன்படுத்தவோ பாதுகாப்பாக மாற்றவோ செய்யுங்கள். இதுவே idempotency. வெளிப்புற விளைவுகளுக்கு provider ஆதரவைப் பயன்படுத்தி உறுதியில்லாத outcomes-ஐச் சரிபார்க்கவும். [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

Database record சேமிப்பது job-யும் உருவாக்க வேண்டுமானால் writes இடையிலான இடைவெளியைக் கவனியுங்கள். Outbox அதே business transaction-இல் instruction-ஐப் பதிவு செய்கிறது; publisher பின்னர் queue-க்கு அனுப்பும். Delivery மீண்டும் நடக்கலாம்; worker-க்கு idempotency இன்னும் தேவை.

## 4. Redis மற்றும் worker இயக்கச் செலவையும் சேர்க்கவும்

Redis நிலுவை வேலையைச் சேமிப்பதால் அதன் persistence, memory policy, recovery plan முக்கியம். Queue-க்கு noeviction policy அமைக்கவும்: memory காலியாக keys-ஐ அமைதியாக நீக்குவது நிலைத்திருக்க வேண்டிய jobs-க்கு ஏற்றதல்ல. Application restart பாதுகாப்பு எல்லா Redis தோல்விகளையும் சமாளிக்கும் என்று கருதாமல் recovery சோதிக்கவும். [Production வழிகாட்டல்](https://docs.bullmq.io/guide/going-to-production).

பெரிய அறிக்கைக் கோப்புகளைப் பொருத்தமான storage-இல் வைத்து jobs-இல் references அனுப்பவும். முடிந்த மற்றும் தோல்வியுற்ற job records எவ்வளவு காலம் இருக்கும் என்பதை வரையறுத்து Redis பயன்பாட்டைக் கட்டுப்படுத்துங்கள்.

அதிக CPU processing worker-ன் event loop-ஐத் தடுத்து lock renewal-ஐப் பாதிக்கலாம். Job stalled எனக் கருதப்பட்டு மீண்டும் செயலாக்கப்படலாம். அந்த workload-க்கு ஏற்ற worker threads அல்லது தனிமைப்படுத்தப்பட்ட processors பயன்படுத்தி stalled jobs கண்காணிக்கவும். [Stalled jobs](https://docs.bullmq.io/guide/jobs/stalled).

## 5. நிபந்தனையுடன் பரிந்துரைக்கவும்

- Node.js application-க்கு கண்காணிக்கக்கூடிய background work, retries, தனியாக scale செய்யும் workers தேவைப்பட்டு குழுவால் Redis-ஐ நம்பகமாக இயக்க முடிந்தால் BullMQ தேர்ந்தெடுக்கவும்.
- Durable tracking அல்லது தனி execution தேவையில்லாத அற்ப உள்ளூர் செயலை எளிமையாக வைத்திருங்கள்.
- Queued tasks முடிப்பதைவிட பல சுயாதீன consumers-க்கு நீண்டகால replay முக்கியமானால் durable event log-ஐ மதிப்பிடவும்.

அறிக்கை உதாரணத்தில் dependency failure, output சேமித்த பின் worker crash, outage-க்குப் பிந்தைய recovery சோதிக்கவும். பயனர் நம்பகமான status பார்ப்பதையும் retry முரண்பட்ட outputs உருவாக்காததையும் உறுதிசெய்யவும்.

**நினைவில் கொள்ளுங்கள்:** BullMQ job ஒருங்கிணைப்பை வழங்குகிறது. Application வணிக correctness வழங்குகிறது; queue இயக்கத்திற்கு குழுவே பொறுப்பு.

தேவை	BullMQ திறன்	Application இன்னும் முடிவு செய்ய வேண்டியது
தற்காலிகத் தோல்விகளிலிருந்து மீளுதல்	Backoff உடன் retries	எந்த errors-ஐ retry செய்வது, எப்போது நிறுத்துவது.
பின்னர் அல்லது அட்டவணைப்படி இயக்குதல்	Delayed jobs, scheduling	தேவையான நேரம், downtime-க்குப் பிந்தைய நடத்தை.
Processing சுமையைக் கட்டுப்படுத்துதல்	Concurrency, rate limits	Database மற்றும் வெளிச் சேவைகளுக்கான பாதுகாப்பான வரம்புகள்.
Background திறனை அதிகரித்தல்	கூடுதல் workers	அடுத்த dependency கூடுதல் சுமையை ஏற்குமா.

1. வேலை queue-க்கு மாறும்போது என்ன மாறுகிறது எனப் பாருங்கள்

2. நன்மைகளைத் தேவையுடன் பொருத்தவும்

3. முக்கிய correctness சிக்கலைப் புரிந்துகொள்ளவும்

4. Redis மற்றும் worker இயக்கச் செலவையும் சேர்க்கவும்

5. நிபந்தனையுடன் பரிந்துரைக்கவும்

தொடர்புடைய கேள்விகள்