परिचय

पोली किसी भी कारण का एक महत्वपूर्ण हिस्सा है. यह एक लाइब्रेरी है जो आपको अपवादों को नियंत्रित करने तथा अपने अनुप्रयोग में रीट्रेसियों को पारिभाषित करने देता है. इस लेख में हम देखेंगे कि हम किस तरह की जाँच करेंगे आई इस अनुप्रयोग में पुनर्वास को हैंडल करने के लिए पोली का प्रयोग करें.

पोली

जबकि पोली वास्तव में यह सब नहीं कर सकता है, यह वास्तव में अपने अनुप्रयोगों को जोड़ने के लिए एक औजार है. दोनों को बाहर की सेवाओं और आंतरिक रूप से कॉल करना पड़ता है ।

ये पकड़े गए हैं पोलली मुख्य पृष्ठ और ये मुख्य पैटर्न हैं जिन्हें आप पोलली से इस्तेमाल कर सकते हैं:

फिर से कोशिश करें यदि कोई असफल हो. यह तब उपयोगी हो सकता है जब समस्या अस्थायी है और शायद दूर चली जाए ।
सर्किट ब्रेकर: अगर कुछ टूटी या व्यस्त हो तो कोशिश करना बंद करो. इससे आपको बहुत फायदा होगा । यह तंत्र को ठीक करने के लिए समर्थन दे सकता है.
टाइमआउट: यदि कुछ बहुत लंबा लगता है तो छोड़ दो. यह आपके कार्य को बेहतर बनाने के द्वारा अंतरिक्ष और संसाधनों को मुक्‍त करने के द्वारा बेहतर बना सकता है ।
सीमा सीमा: सीमित करें कि आप कितने निवेदन करते हैं या स्वीकार करते हैं । यह आपको बोझ को नियंत्रित करने और समस्याओं को रोकने में समर्थ कर सकता है ।
फालबैक: अगर कुछ असफल हो जाए तो कुछ और करना. यह आपके उपयोक्ता अनुभव को बेहतर बना सकता है तथा कार्यक्रम कार्य करते रहने देता है. वह समाधान: एक ही समय पर एक से ज़्यादा काम कीजिए और जल्दी से एक ही ले लीजिए । यह आपके कार्यक्रम को तेज़ी से और अधिक प्रतिक्रिया दिखा सकता है ।

मैं पोली का कैसे इस्तेमाल करता हूँ

इस अनुप्रयोग में मैं कई जगहों पर पोल्स का उपयोग करता हूँ.

पृष्ठभूमि अनुवाद

मेरी अनुवाद सेवा शुरू करने के लिए और आसानNMT सर्वर की जाँच करने के लिए उपलब्ध हैं. टीसी मुझे सेवा जाँच करने की अनुमति देता है मेरे ऐप में अनुवाद सेवा शुरू करने से पहले. आप इस दोनों के लिए उपयोग में लिया जाएगा याद करेंगे मेरे संपादक 'y' आप चिन्हित करने के लिए सक्षम करने के लिए और मेरे मक्खी पर 'पर' करने के लिए' ब्लॉग पोस्ट अनुवाद इंजिन___ तो यह महत्वपूर्ण है कि मैं आसानMMT नीचे नहीं चला गया है (और जब तक यह ऊपर आता है, जो कुछ सेकंड ले जा सकते हैं).

 private async Task StartupHealthCheck(CancellationToken cancellationToken)
    {
        var retryPolicy = Policy
            .HandleResult<bool>(result => !result) // Retry when Ping returns false (service not available)
            .WaitAndRetryAsync(3, // Retry 3 times
                attempt => TimeSpan.FromSeconds(5), // Wait 5 seconds between retries
                (result, timeSpan, retryCount, context) =>
                {
                    logger.LogWarning("Translation service is not available, retrying attempt {RetryCount}", retryCount);
                });

        try
        {
            var isUp = await retryPolicy.ExecuteAsync(async () =>
            {
                return await Ping(cancellationToken); // Ping to check if the service is up
            });

            if (isUp)
            {
                logger.LogInformation("Translation service is available");
                TranslationServiceUp = true;
            }
            else
            {
                logger.LogError("Translation service is not available after retries");
                await HandleTranslationServiceFailure();
                TranslationServiceUp = false;
            }
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "An error occurred while checking the translation service availability");
            await HandleTranslationServiceFailure();
            TranslationServiceUp = false;
        }
    }

यहाँ आप देख सकते हैं कि हम एक पोली कोशिश नीति स्थापित कर सकते हैं कि हर प्रयास के बीच एक 5 बार एक 5 सेकंड के साथ 3 बार फिर से इंतजार करेंगे. यदि सेवा फिर से लोड करने के बाद उपलब्ध नहीं है, तो हम एक त्रुटि का लॉग और विफलता को सेटिंग के द्वारा संभालते हैं TranslationServiceUp गलत पर फ्लैग करें. फिर यह किसी भी सेवाओं को अनुवाद सेवा से यह पता लगाने की अनुमति देता है कि यह उपलब्ध नहीं है ।

graph LR A[Start Health Check] --> B[Define Retry Policy] B --> C[Retry Policy: Retry 3 times] C --> D[Wait 5 seconds between retries] D --> E[Ping Translation Service] E --> F{Ping successful?} F -- Yes --> G[Log: Translation service is available] G --> H[Set TranslationServiceUp = true] F -- No --> I[Log: Translation service not available] I --> J[Check retry count] J -- Retry Limit Reached --> K[Log: Translation service not available after retries] K --> L[HandleTranslationServiceFailure] L --> M[Set TranslationServiceUp = false] J -- Retry Again --> E E --> N{Exception Occurs?} N -- Yes --> O[Log: Error occurred] O --> L

उममी.Net

मैं अपनी उममी लाइब्रेरी को फिर से काम करने के लिए भी पोली का प्रयोग करता हूँ जब उममी एपीआई से अनुरोध करता है. यह पुस्तकालय का एक महत्वपूर्ण हिस्सा है जब यह मुझे Na के साथ किसी भी मुद्दों को संभालने की अनुमति देता है और अगर आवश्यक हो तो निवेदन फिर से कोशिश करें.

यहाँ मैं अपने ऊपर सेट HttpClient एक फिर नीति का उपयोग करने के लिए, इस मामले में मैं एक की जाँच कर रहा हूँ HttpStatusCode.ServiceUnavailable और अगर यह हो जाता है तो निवेदन फिर से कोशिश करें. मैं भी एक का उपयोग कर रहा हूँ Decorrelated Jitter Backoff पुनःपुष्टि के बीच इंतजार करने के लिए रणनीति. यह का उपयोग करने के लिए एक अच्छी रणनीति है का उपयोग करने के लिए 'बिंगिंग' समस्या से दूर करने में मदद करता है जहां सभी ग्राहक एक ही समय पर फिर से कोशिश करते हैं (हालाँकि यह सिर्फ मुझे है:) यह सर्वर पर लोड को कम करने और बाद के लिए निवेदन करने की संभावना को सुधारने में मदद कर सकता है.

     var httpClientBuilder = services.AddHttpClient<AuthService>(options =>
            {
                options.BaseAddress = new Uri(umamiSettings.UmamiPath);
            })
            .SetHandlerLifetime(TimeSpan.FromMinutes(5)) 
            .AddPolicyHandler(RetryPolicyExtension.GetRetryPolicy());


    public static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
    {
        var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromSeconds(1), 3);
        return HttpPolicyExtensions
            .HandleTransientHttpError()
            .OrResult(msg => msg.StatusCode == HttpStatusCode.ServiceUnavailable)
            .WaitAndRetryAsync(delay);
    }

इसके लिए फिर से कोशिश की जा रही है HttpClient यह सच बोलने का एक अहम तरीका है । जबकि हमें लगता है कि हमारे वेब सेवाओं हमेशा उपलब्ध हैं हमेशा कुछ नीचे समय (जब उदाहरण के लिए मेरे मामले में) प्रहरीदुर्ग अद्यतन स्थगित है तथा उममी कंटेनर फिर से चालू करता है. इसलिए अगर आप किसी मामले पर ध्यान दें, तो यह तय करने में मदद दे सकता है कि आपका अनुप्रयोग इन हालात को अच्छी तरह निपटा सकता है ।

फ़ाइल तंत्र वाचवर

एक और प्रयोग है जो मैं पोलली का इस्तेमाल करता हूँ जब मैं अपने अनुप्रयोग में फ़ाइलों को लोड करने और बचाने के लिए करता हूँ । मैं एक उपयोग FileSystemWatcher डिरेक्ट्री को मॉनीटर करने के लिए जहाँ मेरी निशानी फ़ाइलें जमा हैं. जब एक फ़ाइल बनाया जाता है या अद्यतन किया जाता है मैं फ़ाइल लोड करता हूँ और प्रक्रिया कर रहा हूँ. यह समस्या हो सकती है यदि फ़ाइल को अभी भी लिखा जा रहा है जब घटना ट्रिगर हो. तो मैं एक का उपयोग करें RetryPolicy इस स्थिति से निपटने के लिए.

यहाँ तुम देख सकते हो मैं संभाल IOException जब फाइल उपयोग में है तो उसे फेंका जाएगा तथा ऑपरेशन को फिर कोशिश करें. मैं एक उपयोग WaitAndRetryAsync क्रिया 5 बार फिर कोशिश करने की नीति प्रत्येक फिर कोशिश के बीच विलम्ब से कोशिश करें. यह मुझे स्थिति को संभालने की अनुमति देता है जहाँ फ़ाइल अभी भी लिखा जा रहा है और ऑपरेशन को सफल होने तक फिर से कोशिश करें.

यहाँ क्या महत्वपूर्ण है कि मैं'अप' फेंक दें IOException मेरी तरफ से SavePost विधि जो पोली नीति को कोशिश करने की अनुमति देती है. यह एक अच्छा नमूना है का पालन करने के लिए जब यह आपको एक केंद्रीय जगह में फिर से तर्क को संभालने की अनुमति देता है और इसके बारे में चिंता करने की जरूरत नहीं है हर तरह जो ऑपरेशन को फिर से कोशिश करने की हो.

सामान्य हमेशा अपवाद संभाल जहां आप कर सकते हैं और ऊपर फेंक दें उच्च स्तर पर जहाँ आप उन्हें अधिक विशिष्ट तरीके से संभाल सकते हैं यह आपके कोड की जटिलता को कम करने में मदद कर सकता है और अपवादों को नियमित रूप से नियंत्रित करना आसान बना सकता है ।

      private async Task OnChangedAsync(WaitForChangedResult e)
    {
       ...
        var retryPolicy = Policy
            .Handle<IOException>() // Only handle IO exceptions (like file in use)
            .WaitAndRetryAsync(5, retryAttempt => TimeSpan.FromMilliseconds(500 * retryAttempt),
                (exception, timeSpan, retryCount, context) =>
                {
                    activity?.Activity?.SetTag("Retry Attempt", retryCount);
                    // Log the retry attempt
                    logger.LogWarning("File is in use, retrying attempt {RetryCount} after {TimeSpan}", retryCount,
                        timeSpan);
                });

      ...

            // Use the Polly retry policy for executing the operation
            await retryPolicy.ExecuteAsync(async () =>
            {
              ...
                var blogService = scope.ServiceProvider.GetRequiredService<IBlogService>();
                await blogService.SavePost(blogModel);
               ...
            });
...
    }

इस मामले में फिर से यह मेरे कोड का एक उदाहरण है एक बाहरी सेवा के साथ, इस मामले में। जहां मैं निश्चित रूप से कुछ त्रुटि प्रकार होने के लिए। मैं भी इन उपयोग में लॉग करें सेरेसिखिएशन जिसने मुझे S से डराने के लिए भेजा है वह मुझे ई- मेल भेजता है जब गलती करनेवाला लॉग कर रहा हो तो मैं किसी भी विषय को पहचान सकता हूँ जो हो सकता है.

फिर, सामान्य तरीका अपवादों से निपटने के लिए है जहाँ आप कर सकते हैं, उन्हें ले लो जब आप नहीं कर सकते और सुनिश्चित करें कि आप क्या हो रहा है पता करने के लिए एक रास्ता है। यह निश्‍चित करने में मदद कर सकता है कि आपका अनुप्रयोग भारी मात्रा में है और जो भी हो सकता है उसे संभाल सकता है ।

ईमेल- सर्विस

मैं दोनों उपयोग अपने ई- मेल सेवा में CircuitBreaker पैटर्न और एक कोशिश नीति. पुनः कोशिश नीति उस मामले को हैंडल करने के लिए प्रयोग की जाती है जहाँ ईमेल सेवा उपलब्ध नहीं है तथा सर्किट ब्रेकर मामले को संभालने के लिए प्रयोग किया जाता है जहाँ ईमेल सेवा व्यस्त है या लोड किया जाता है.

इन दोनों में से दोनों को ईमेल के मामले में महत्त्वपूर्ण है; एसएमटीपी एक अपेक्षाकृत धीमी और संभवतः अविश्‍वसनीय प्रोटोकॉल है ।

यहाँ मैं Smampacs संभालता हूँ, जहां जब SMTP सेवा से एक त्रुटि आती है यह पहले तीन बार कोशिश करेंगे प्रत्येक प्रयास के बीच एक देरी के साथ. यदि सेवा अभी तक उपलब्ध नहीं है (और दो नए भेजने के लिए), सर्किट ब्रेकर एक मिनट के लिए ई- मेल भेजने के बाद खोलेगा और बंद कर देगा. यह ईमेल सेवा को लोड होने से रोका जा सकता है (और मेरे खाते को बन्द किया जा रहा है) और ईमेल को सफलतापूर्वक भेजा जा रहा की संभावना को सुधारने में मदद कर सकता है.

         // Initialize the retry policy
            var retryPolicy = Policy
                .Handle<SmtpException>() // Retry on any exception
                .WaitAndRetryAsync(3, // Retry 3 times
                    attempt => TimeSpan.FromSeconds(2 * attempt),
                    (exception, timeSpan, retryCount, context) =>
                    {
                        logger.LogWarning(exception, "Retry {RetryCount} for sending email failed", retryCount);
                    });

            // Initialize the circuit breaker policy
            var circuitBreakerPolicy = Policy
                .Handle<SmtpException>()
                .CircuitBreakerAsync(
                    5,
                    TimeSpan.FromMinutes(1), 
                    onBreak: (exception, timespan) =>
                    {
                        logger.LogError("Circuit broken due to too many failures. Breaking for {BreakDuration}", timespan);
                    },
                    onReset: () =>
                    {
                        logger.LogInformation("Circuit reset. Resuming email delivery.");
                    },
                    onHalfOpen: () =>
                    {
                        logger.LogInformation("Circuit in half-open state. Testing connection...");
                    });
            _policyWrap = Policy.WrapAsync(retryPolicy, circuitBreakerPolicy);

यह तब मेरे ईमेल भेजना लूप में प्रयोग किया जाता है जो चैनल में नए संदेश को जोड़ने के लिए इंतजार करता है फिर उन्हें भेजने की कोशिश करता है.

ई- मेल भेजने की प्रक्रिया में शामिल होने के लिए यह सभी आनंदमय नीति में उपयोग करता है.

 while (await _mailMessages.Reader.WaitToReadAsync(token))
        {
            BaseEmailModel? message = null;
            try
            {
                message = await _mailMessages.Reader.ReadAsync(token);

                // Execute retry policy and circuit breaker around the email sending logic
                await _policyWrap.ExecuteAsync(async () =>
                {
                    switch (message)
                    {
                        case ContactEmailModel contactEmailModel:
                            await _emailService.SendContactEmail(contactEmailModel);
                            break;
                        case CommentEmailModel commentEmailModel:
                            await _emailService.SendCommentEmail(commentEmailModel);
                            break;
                    }
                });

                _logger.LogInformation("Email from {SenderEmail} sent", message.SenderEmail);
            }
            catch (OperationCanceledException)
            {
                break;
            }
            catch (Exception exc)
            {
                _logger.LogError(exc, "Couldn't send an e-mail from {SenderEmail}", message?.SenderEmail);
            }
        }

ऑन्टियम

यह सच है कि एक शक्‍तिशाली पुस्तकालय है जो आपको आपके कार्यक्रम में प्रवेश करने के लिए मदद कर सकता है । एक बार जब आप गाड़ी चलाते हैं, तो गाड़ी चलाते वक्‍त आप उसे ठीक - ठीक ठीक ठीक कर सकते हैं । यह निश्‍चित करने में मदद कर सकता है कि आपका अनुप्रयोग भरोसेमंद है और जो भी हो सकता है, उसे संभाल सकता है । इस पोस्ट में मैंने वास्तव में पोलली के एक पहलू को कवर किया; ये एक ऐसी प्रक्रिया है जो आपके अनुप्रयोग के अनुकूल और विश्‍वसनीय हो सकती है । आप जो भी कदम उठा सकते हैं, उसके लिए आप क्या कर सकते हैं?

कोशिशों के लिए पोल्‌स का इस्तेमाल