Node.js-இல் EventEmitter மற்றும் job queue எப்படி வேறுபடுகின்றன?

Question

IT Interview Practice · Accepted Answer

EventEmitter அல்லது job queue தேர்வில் **வேலை எங்கு இயங்க வேண்டும், process நின்றால் என்ன நடக்கும்** என்று கேளுங்கள்.

EventEmitter ஒரு Node.js process-க்குள் listeners-க்கு அறிவிக்கிறது. Durable queue பின்னர் workers செயலாக்குவதற்கான வேலையைச் சேமிக்கிறது. இரண்டும் பொறுப்புகளைப் பிரித்தாலும் தோல்வி நடத்தை வேறுபடும்.

## 1. உள்ளூர் அறிவிப்பைப் பின்தொடரவும்

ஒரு component initialization முடிந்து அதே process-இல் உள்ள பிற components செயல்பட வேண்டும் எனக் கொள்வோம். EventEmitter இயல்பான தேர்வு: listeners பதிவு செய்து event emit செய்யுங்கள்.

```text
[One process]
emit("ready") -> Listener A
              -> Listener B
```

Node.js பதிவுசெய்த listeners-ஐப் பதிவு வரிசையில் synchronously அழைக்கிறது. பின்னர் பதிவாகும் listeners-க்காக event சேமிக்கப்படாது; முடியாத வேலை process crash-ஐத் தாங்காது. [Node.js Events](https://nodejs.org/api/events.html).

அறிவிப்பு உள்ளூரானதாகவும் இழக்கக்கூடியதாக அல்லது மீள உருவாக்கக்கூடியதாகவும் இருந்தால் இது பொருந்தும். Sender நின்ற பிறகும் வேலை தொடர வேண்டும் என்ற வணிக எதிர்பார்ப்புக்கு இது போதாது.

## 2. Async listener என்ன மாற்றுகிறது எனப் புரிந்துகொள்ளவும்

Async listener asynchronous வேலையைத் தொடங்கலாம்; ஆனால் அது திருப்பும் promise-க்காக emit காத்திருக்காது. ஆகவே அழைப்பு வரிசையே முடியும் வரிசையாக இருக்க வேண்டியதில்லை.

அந்த listener-க்குள் CPU-heavy synchronous code process-ஐ இன்னும் தாமதப்படுத்தும். Thrown errors மற்றும் rejected promises-ஐத் திட்டமிட்டுக் கையாளுங்கள்; captureRejections rejection-ஐ error handling-க்கு அனுப்பலாம், ஆனால் task-ஐ நிலையாகச் சேமிக்கவோ retry செய்யவோ முடியாது.

Async சேர்ப்பது listener வேலைசெய்யும் முறையை மாற்றுகிறது. Memory event-ஐ durable queue ஆக மாற்றாது.

## 3. Queue-இல் உள்ள வேலையைப் பின்தொடரவும்

இப்போது order சேமிக்கப்பட்டால் இறுதியில் invoice உருவாக வேண்டும் எனக் கொள்வோம். Workers கிடைக்காதபோதோ busy-ஆக இருக்கும்போதோ instruction வைக்க queue இடமளிக்கிறது.

```text
[Producer] -> [Durable queue] -> [Available worker]
                    |                   |
              [Pending work]      [Result / retry]
```

Producer job சமர்ப்பிக்கிறது; worker ஒரு attempt-ஐச் செயலாக்கி முடிவைப் பதிவு செய்கிறது. Workers-ஐ API-யிலிருந்து தனியாக deploy, scale செய்யலாம். Durability இன்னும் queue storage மற்றும் configuration-ஐச் சார்ந்தது.

வழக்கமான competing-worker queue-இல் ஒவ்வொரு attempt-ஐயும் ஒரு worker கையாளும். இது ஒவ்வொரு EventEmitter listener-க்கும் event broadcast செய்வதிலிருந்து வேறுபடும். பல independent subscribers ஒவ்வொருவருக்கும் event தேவைப்பட்டால் அதைப் பொருத்த delivery model தேர்ந்தெடுக்கவோ அமைக்கவோ வேண்டும்.

## 4. சேமிப்புக்கும் enqueue செய்வதற்குமான இடைவெளியைச் சரிபார்க்கவும்

EventEmitter-இல் order சேமித்த பின் emit செய்யும்முன் crash ஆனால் invoice instruction இழக்கலாம். Durable queue ஏற்றுக்கொண்ட பின் job-ஐப் பாதுகாக்கும்; database commit மற்றும் submission இடையிலான முந்தைய இடைவெளியைத் தானாகப் பாதுகாக்காது.

Outbox order-யும் instruction-யும் ஒரே database transaction-இல் சேமித்து இடைவெளியை மூடுகிறது. Publisher outbox படித்து job-ஐப் பின்னர் அனுப்புகிறது.

Publisher confirmation இழந்தால் delivery மீண்டும் நிகழலாம். Invoice உருவாக்கத்திற்கு நிலையான business key மற்றும் uniqueness constraint அல்லது வேறு idempotent implementation கொடுங்கள். மீண்டும் attempt செய்வது இரண்டாவது invoice உருவாக்கக்கூடாது. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. உண்மையான தேவையுடன் விருப்பங்களை ஒப்பிடவும்

| தேவை | EventEmitter | Durable job queue |
| --- | --- | --- |
| ஒரே process-இல் components-க்கு அறிவித்தல் | நேரடியானது, இலகுவானது | பொதுவாகத் தேவையற்ற infrastructure சேர்க்கும். |
| Sender நின்ற பின்பும் pending work வைத்திருத்தல் | Built-in durable record இல்லை | பொருத்தமான storage, recovery மூலம் சாத்தியம். |
| Retry மற்றும் backlog ஆய்வு | Application உருவாக்க வேண்டும் | Configuration உடன் பொதுவான queue திறன்கள். |
| பிற machines-இல் வேலை இயக்குதல் | அதன் பங்கு அல்ல | Workers தனியாக இயங்கலாம். |

Initialization உதாரணத்திற்கு EventEmitter பயன்படுத்துவேன். Failure-இலிருந்து மீள வேண்டிய invoice generation-க்கு durable queue பயன்படுத்தி database handoff மற்றும் duplicate attempts-ஐக் கையாளுவேன்.

Submission-க்கு முன், acceptance-க்குப் பின், business effect-க்குப் பின் போன்ற முக்கிய எல்லைகளில் process-ஐ நிறுத்திச் சோதியுங்கள். முடிவு பயனர் எதிர்பார்க்கும் உத்தரவாதத்துடன் பொருந்த வேண்டும்.

**நினைவில் கொள்ளுங்கள்:** உள்ளூர் அறிவிப்பு → EventEmitter; மீட்கக்கூடிய background work → durable queue. முக்கிய விளைவுகளுக்கு handoff மற்றும் idempotency-யையும் வடிவமைக்கவும்.

தேவை	EventEmitter	Durable job queue
ஒரே process-இல் components-க்கு அறிவித்தல்	நேரடியானது, இலகுவானது	பொதுவாகத் தேவையற்ற infrastructure சேர்க்கும்.
Sender நின்ற பின்பும் pending work வைத்திருத்தல்	Built-in durable record இல்லை	பொருத்தமான storage, recovery மூலம் சாத்தியம்.
Retry மற்றும் backlog ஆய்வு	Application உருவாக்க வேண்டும்	Configuration உடன் பொதுவான queue திறன்கள்.
பிற machines-இல் வேலை இயக்குதல்	அதன் பங்கு அல்ல	Workers தனியாக இயங்கலாம்.

1. உள்ளூர் அறிவிப்பைப் பின்தொடரவும்

2. Async listener என்ன மாற்றுகிறது எனப் புரிந்துகொள்ளவும்

3. Queue-இல் உள்ள வேலையைப் பின்தொடரவும்

4. சேமிப்புக்கும் enqueue செய்வதற்குமான இடைவெளியைச் சரிபார்க்கவும்

5. உண்மையான தேவையுடன் விருப்பங்களை ஒப்பிடவும்

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