AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड · पाठ

डेड-लेटर कतारें और विफलता प्रबंधन

संदेशों का संसाधन विफल हो सकता है। जानें कि डेड-लेटर कतारें खराब संदेशों को कैसे पकड़ती हैं और लचीले इवेंट-आधारित सिस्टम के लिए पुनःप्रयास तथा पुनर्संसाधन कैसे डिज़ाइन करें।

पाठ 4, कुल 4 में से13 चरण

डेड-लेटर कतारें और विफलता प्रबंधन, CoddyKit पर AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

विफल संदेशों की समस्या

इवेंट-आधारित सिस्टम में कोई संदेश बार-बार विफल हो सकता है — खराब डेटा, डाउनस्ट्रीम सेवा की रुकावट या किसी बग के कारण। सुरक्षा उपाय के बिना वह कतार को रोक सकता है या हमेशा के लिए खो सकता है।

डेड-लेटर कतार क्या है?

डेड-लेटर कतार (DLQ) एक अलग कतार है, जो निर्धारित संख्या में प्रयासों के बाद संसाधित न हो सके संदेशों को अपने पास रखती है। इससे खराब संदेश अलग हो जाते हैं और खोते नहीं हैं।

रीड्राइव नीति

SQS कतार रीड्राइव नीति के माध्यम से DLQ में संदेश भेजती है। इस नीति में DLQ और एक maxReceiveCount निर्दिष्ट होता है। इतनी बार प्राप्त करने में विफल होने के बाद संदेश DLQ में चला जाता है।

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:orders-dlq",
  "maxReceiveCount": 5
}

Lambda के लिए DLQ कॉन्फ़िगर करना

असिंक्रोनस Lambda इनवोकेशन (S3, SNS) इवेंट इनवोकेशन कॉन्फ़िगरेशन के माध्यम से विफलताओं को DLQ या विफलता-गंतव्य पर भेज सकते हैं।

aws lambda put-function-event-invoke-config \
  --function-name processOrder \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:orders-dlq"}}'

maxReceiveCount का समझदारी से निर्धारण

मान बहुत कम होने पर अस्थायी रुकावटों के कारण सही संदेश भी डेड-लेटर हो जाते हैं; बहुत अधिक होने पर खराब संदेश कई पुनःप्रयास व्यर्थ कराता है। 3 से 5 का मान एक सामान्य शुरुआती विकल्प है।

डेड-लेटर संदेशों की जाँच

DLQ में मौजूद संदेशों का मूल बॉडी बनी रहती है और साथ में यह बताने वाले एट्रिब्यूट भी होते हैं कि वे क्यों विफल हुए। दोबारा संसाधित करने से पहले मूल कारण का पता लगाने के लिए उन्हें पढ़ें।

aws sqs receive-message \
  --queue-url https://sqs.../orders-dlq \
  --attribute-names All

संदेशों को वापस रीड्राइव करना

बग ठीक हो जाने के बाद SQS संदेशों को DLQ से स्रोत कतार में वापस रीड्राइव करके दोबारा संसाधित कर सकता है — हाथ से कॉपी करने की आवश्यकता नहीं होती।

आइडेम्पोटेंसी महत्वपूर्ण है

पुनःप्रयास और रीड्राइव के कारण एक ही संदेश एक से अधिक बार पहुँच सकता है, इसलिए आपका हैंडलर आइडेम्पोटेंट होना चाहिए: एक ही संदेश को दो बार संसाधित करने पर दोहरा शुल्क नहीं लगना चाहिए और रिकॉर्ड की डुप्लिकेट कॉपी नहीं बननी चाहिए।

DLQ पर चेतावनी

बढ़ती हुई DLQ इस बात का संकेत है कि कुछ खराब है। सूचना पाने के लिए DLQ के ApproximateNumberOfMessagesVisible मेट्रिक पर CloudWatch अलार्म सेट करें।

बैच की आंशिक विफलताएँ

जब Lambda SQS से एक बैच पढ़ता है, तो batchItemFailures की रिपोर्ट करने से पूरे बैच को दोबारा संसाधित करने के बजाय केवल विफल संदेश कतार में लौटते हैं।

{
  "batchItemFailures": [
    { "itemIdentifier": "msg-id-3" }
  ]
}

लचीलेपन के लिए डिज़ाइन

एक लचीली पाइपलाइन में शामिल होते हैं:

अस्थायी त्रुटियों के लिए पुनःप्रयास
खराब संदेशों के लिए DLQ
आइडेम्पोटेंट हैंडलर
अलार्म और रीड्राइव योजना

त्वरित जाँच

विफलता-प्रबंधन संबंधी अपने ज्ञान की जाँच करें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन

आपने विफल संदेशों को संभालना सीखा:

DLQ maxReceiveCount के बाद खराब संदेशों को अलग करता है
रीड्राइव नीतियाँ और Lambda की विफलता-गंतव्य कॉन्फ़िगर करें
संदेशों की जाँच करें, समस्या ठीक करें और फिर उन्हें वापस रीड्राइव करें
हैंडलर को आइडेम्पोटेंट बनाएँ और DLQ की गहराई पर अलार्म लगाएँ
बैच के आंशिक पुनःप्रयास के लिए batchItemFailures का उपयोग करें

शुरुआत निःशुल्क

एआई शिक्षक के साथ AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 12
पाठ: 48

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “डेड-लेटर कतारें और विफलता प्रबंधन” पाठ निःशुल्क है?

हाँ—“डेड-लेटर कतारें और विफलता प्रबंधन” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“डेड-लेटर कतारें और विफलता प्रबंधन” में मैं क्या सीखूँगा?

संदेशों का संसाधन विफल हो सकता है। जानें कि डेड-लेटर कतारें खराब संदेशों को कैसे पकड़ती हैं और लचीले इवेंट-आधारित सिस्टम के लिए पुनःप्रयास तथा पुनर्संसाधन कैसे डिज़ाइन करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“डेड-लेटर कतारें और विफलता प्रबंधन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← AWS Lambda और API Gateway के साथ सर्वररहित बैकएंड पर वापस जाएँ