आधी ‘फक्त एक नोड cronjob चालवतो’ याचा अर्थ ठरवा. समांतर अंमलबजावणी थांबवणे आणि व्यवसाय परिणाम पुन्हा होऊ न देणे या वेगळ्या गरजा आहेत. सामायिक scheduler अंमलबजावणी समन्वित करतो; कृती crash नंतर पुन्हा केल्यावरही सुरक्षित असावी.
तीन NestJS नोडवर रोजचा इनव्हॉइस जॉब आहे असे समजा. नियोजित काम झाले पाहिजे, पण worker restart मुळे आणखी इनव्हॉइस तयार होता कामा नये.
प्रत्येक अॅप instance स्वतःचा cron callback नोंदवतो. ठरलेल्या वेळी प्रत्येक स्वतंत्र सुरू होऊ शकतो:
00:00 -> Node A -> invoice task
-> Node B -> invoice task
-> Node C -> invoice task
स्थानिक isRunning flag एका प्रक्रियेतच असतो. NestJS waitForCompletion त्या instance मधील callback overlap रोखतो, पण इतर नोडशी समन्वय करत नाही. तिन्ही नोडवर तोच flag असला तरी तीन स्वतंत्र निर्णय राहतात. NestJS scheduling.
म्हणून कोणते काम आहे आणि कोण ते करू शकतो हे ठरवण्यासाठी सामायिक जागा हवी.
| परिस्थिती | तपासायचा पर्याय | उरलेली जबाबदारी |
|---|---|---|
| प्लॅटफॉर्ममध्ये नियोजित जॉब आहेत | वेब instance बाहेर scheduling | Overlap, recovery आणि चुकलेले रन ठरवणे. |
| टीम BullMQ चालवते | सामायिक Job Scheduler आणि खास queue | सामायिक concurrency आणि सुरक्षित retry. |
| काम अॅप नोडवरच ठेवायचे | सामायिक lock किंवा lease | मालकी, मुदत आणि जुने worker योग्य हाताळणे. |
इनव्हॉइससाठी Redis आणि BullMQ आधीच असतील तर स्थिर scheduler ID असलेला सामायिक scheduler व्यावहारिक पर्याय आहे. Schedule worker पासून वेगळा ठेवा, म्हणजे वेब नोड वाढवल्याने स्वतंत्र schedule तयार होणार नाहीत.
समर्थित BullMQ आवृत्तीत खास queue ची global concurrency एक ठेवा. याने सर्व worker मधील सक्रिय जॉब मर्यादित होतात; प्रत्येकाची local concurrency एक केल्याने तरी अनेक worker वेगवेगळे जॉब एकत्र करू शकतात. Global concurrency.
कालचे काम अजून सुरू असल्यास थांबायचे, वगळायचे की वेळापत्रकातील रन एकत्र करायचे ते ठरवा. टाइम झोन आणि downtime मधील चुकलेल्या व्यवसाय तारखा नंतर प्रक्रिया करायच्या का हेही ठरवा.
Worker ने इनव्हॉइस तयार केला आणि completion लिहिण्याआधी crash झाला असे समजा. इनव्हॉइस असूनही recovery जॉब पुन्हा चालवू शकते.
[Create invoice] -> [Crash before completion]
|
[Retry]
|
[Same business key: reuse result]
ग्राहक आणि बिलिंग कालावधीसारखी स्थिर व्यवसाय key वापरा. स्थानिक डेटाबेसमध्ये unique constraint आणि transaction इनव्हॉइस निर्मितीला पूर्ण रनच्या नोंदीशी जोडू शकतात. Retry नवीन इनव्हॉइस न करता जुना निकाल मिळवतो.
बाह्य सेवेसाठी समर्थित idempotency key वापरा आणि अनिश्चित निकाल जुळवून पाहा. Queue job ID किंवा जतन केलेली जॉब नोंद ही व्यवसाय कृती कधीच पुन्हा होणार नाही याची कायम हमी नाही. Idempotent jobs.
सामायिक lock atomic पद्धतीने घ्या. मालकी token, expiry आणि renewal वापरा; token अजून जुळत असेल तरच सोडा. नाहीतर जुना worker नवीन worker चा lock सोडू शकतो.
Expiry मुळे आणखी प्रसंग येतो: थांबलेला worker lease संपल्यावर पुन्हा सुरू होतो आणि नवीन worker आधीच चालू असतो. महत्त्वाच्या लेखनाला fencing token लागू शकतो — वाढता मालकी क्रमांक, जो गंतव्य तपासून जुन्या worker ला नाकारते. फक्त मोठा timeout धोका काढत नाही.
समन्वय उपलब्ध नसल्यास मालकीशिवाय चालण्याऐवजी थांबायचे का ठरवा. गंभीर परिणामाच्या कामासाठी थांबणे अनेकदा सुरक्षित असते.
अनेक नोड, इनव्हॉइसनंतर crash, lease पेक्षा मोठी विश्रांती, Redis संपर्क तुटणे आणि rolling deployment तपासा. व्यवसाय तारीख, worker, प्रयत्न आणि निकाल नोंदवा, म्हणजे पुनर्प्रयत्न आणि दुहेरी परिणाम वेगळे ओळखता येतील.
लक्षात ठेवा: schedule समन्वय → सामायिक अंमलबजावणी मर्यादा → व्यवसाय कृती retry-safe → recovery चाचणी. ‘एक सक्रिय जॉब’ म्हणजे व्यवसाय परिणाम नेमका एकदाच झाला याचा पुरावा नाही.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या