यहां बताया गया है कि Functions ऐप में एक पुनर्प्राप्य दोष आउटेज कैसे बन जाता है: एक निर्भरता टाइमआउट होने लगती है, हर Functions इंस्टेंस तुरंत और अनिश्चित काल के लिए रिट्राई करता है, निर्भरता को सैकड़ों समवर्ती विफल अनुरोधों से हमला किया जाता है, और जो एक क्षणिक हिचकी के रूप में शुरू हुआ वह एक सिस्टम-व्यापी बैकप्रेशर इवेंट बन जाता है।
आप शायद यह कहानी जानते हैं। Azure Functions तेजी से स्केल आउट होती है — यही पूरा उद्देश्य है। लेकिन “तेजी से स्केल आउट” और “तुरंत रिट्राई” एक साथ विफलताओं को नाटकीय रूप से बदतर बना सकते हैं।
दो पैटर्न मदद करते हैं। एक्सपोनेंशियल बैकऑफ और सर्किट ब्रेकर। दोनों अब Service Bus-ट्रिगर्ड Azure Functions के लिए नेटिव रूप से समर्थित हैं।
दो पैटर्न, अलग-अलग भूमिकाएं
ये पैटर्न पूरक हैं, विकल्प नहीं:
एक्सपोनेंशियल बैकऑफ जवाब देता है: मुझे कब दोबारा प्रयास करना चाहिए? यह रिट्राई के बीच देरी बढ़ाता है ताकि एक निर्भरता को ठीक होने का समय मिले। संदेश स्तर पर, रिट्राई टाइमिंग को गति देना।
सर्किट ब्रेकर जवाब देता है: क्या मुझे अभी इस निर्भरता को कॉल करना चाहिए? विफलता सीमा पहुंचने के बाद एक अस्वस्थ निर्भरता पर बार-बार कॉल रोकता है, फिर कूलडाउन अवधि के बाद सावधानी से जांच करता है। सिस्टम स्तर पर, रिट्राई तूफान को रोकना।
आपको दोनों चाहिए। बैकऑफ प्रति संदेश रिट्राई पेसिंग संभालता है। सर्किट ब्रेकर एग्रीगेट स्वास्थ्य निर्णय संभालता है।
Service Bus के लिए यह विशेष रूप से क्यों महत्वपूर्ण है
कतार बर्स्ट ट्रैफिक को अवशोषित करती है, जो अच्छी बात है। लेकिन नियंत्रण के बिना, कतार बढ़ सकती है जबकि वर्कर उन कॉल पर कम्प्यूट बर्बाद करते रहते हैं जो विफल हो जाएंगे। पॉइजन संदेश उतने समय से अधिक समय तक सक्रिय रहते हैं। हॉट पार्टिशन या सीमित डाउनस्ट्रीम क्षमता कैस्केडिंग समस्याएं पैदा करती है।
सुरक्षित डिज़ाइन:
- क्षणिक विफलता का पता लगाएं
- एक्सपोनेंशियल बैकऑफ के साथ अगला प्रयास विलंबित करें
- विफलता सीमा पहुंचने पर निर्भरता को कॉल करना बंद करें (सर्किट खुला)
- कूलडाउन अवधि के बाद सावधानी से फिर से शुरू करें (सर्किट जांच)
- अप्राप्य कार्य को dead-letter या संगरोध पथ पर ले जाएं
नेटिव समर्थन कैसा दिखता है
नया समर्थन मौजूदा Azure Functions होस्ट मॉडल के साथ एकीकृत होता है — कोई अतिरिक्त लाइब्रेरी नहीं, कोई कस्टम कार्यान्वयन नहीं। कॉन्फ़िगरेशन आपके host.json में जाता है:
{
"extensions": {
"serviceBus": {
"messageHandlerOptions": {
"maxRetryCount": 5,
"retryPolicy": {
"mode": "exponentialBackoff",
"minBackoff": "00:00:02",
"maxBackoff": "00:05:00",
"maxRetryCount": 5
}
}
}
}
}
सर्किट ब्रेकर कॉन्फ़िगरेशन विफलता सीमा और रीसेट अंतराल सेट करता है ताकि अस्वस्थ निर्भरताएं रिकवरी के दौरान पीटी न जाएं।
कवर की गई भाषाएं
यह केवल .NET के लिए नहीं है। यह सुविधा dotnet, JavaScript, TypeScript और Python को कवर करती है — Azure Functions में Service Bus ट्रिगर द्वारा समर्थित भाषाओं का पूरा सेट।
निष्कर्ष
रिट्राई पैटर्न तब तक कॉन्फ़िगर करने में रोमांचक नहीं होते जब तक कि पहली बार डाउनस्ट्रीम आउटेज आपकी Functions को समस्या को बेहतर बनाने के बजाय बदतर करने का कारण नहीं बनता। इन्हें सक्रिय रूप से सेट करना सस्ता है। किसी घटना के दौरान इन्हें फिर से तैयार करना नहीं है।
मूल पोस्ट: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions
