Spring Boot 4 की संपूर्ण मार्गदर्शिका · पाठ

दर सीमांकन, पुनःप्रयास और समय सीमक

लोड को नियंत्रित करने और श्रृंखलाबद्ध विफलताओं को सीमित करने के लिए दर सीमकों, पुनःप्रयासों और समय-सीमाओं को मिलाइए।

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

दर सीमांकन, पुनःप्रयास और समय सीमक, CoddyKit पर Spring Boot 4 की संपूर्ण मार्गदर्शिका का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Spring Boot 4 की संपूर्ण मार्गदर्शिका सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Spring Boot 4 की संपूर्ण मार्गदर्शिका पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

भार को आकार देने के तीन नियंत्रण

सर्किट ब्रेकर मृत निर्भरता को कॉल करना रोकते हैं, लेकिन लचीलेपन के उपकरणों में वे केवल एक साधन हैं। आने वाले भार को आकार देने और श्रृंखलाबद्ध विफलताओं को सीमित करने के लिए आप Resilience4j के तीन अन्य मूलभूत साधनों को मिलाकर उपयोग करते हैं:

RateLimiter — प्रत्येक समय-खंड में शुरू होने की अनुमति वाली कॉल की संख्या सीमित करता है। अतिरिक्त कॉल करने वाले प्रतीक्षा करते हैं या अस्वीकार कर दिए जाते हैं।
Retry — विफल कॉल को सीमित संख्या में दोबारा चलाता है, आदर्श रूप से प्रतीक्षा-अंतराल बढ़ाते हुए, ताकि क्षणिक त्रुटियों से उबरा जा सके।
TimeLimiter — किसी एक कॉल के रद्द किए जाने से पहले उसके चलने की अधिकतम अवधि सीमित करता है, जिससे थ्रेड मुक्त होता है और अत्यधिक विलंबता सीमित रहती है।

साथ में उपयोग करने पर ये आपकी और आपकी डाउनस्ट्रीम सेवा दोनों की सुरक्षा करते हैं (अपनी सेवा पर अत्यधिक भार न डालें और संघर्ष कर रही निर्भरता को बार-बार परेशान न करें)।

Spring Boot 4 में Resilience4j जोड़ना

Spring Boot 4, Spring Cloud Circuit Breaker / resilience4j-spring-boot3 स्टार्टर के माध्यम से Resilience4j को एकीकृत करता है। यह प्रत्येक मूलभूत साधन के लिए एनोटेशन-आधारित पहलू उपलब्ध कराता है।

स्टार्टर और AOP समर्थन जोड़ें, ताकि एनोटेशन लागू किए जा सकें:

resilience4j-spring-boot3 RateLimiter, Retry, TimeLimiter, CircuitBreaker, और Bulkhead पहलू उपलब्ध कराता है।
spring-boot-starter-aop आवश्यक है — एनोटेशन AOP सलाह के रूप में लागू किए जाते हैं।
Actuator मौजूद होने पर मेट्रिक्स अपने-आप Micrometer में पहुँच जाते हैं।

<dependencies>
  <dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
</dependencies>

RateLimiter: प्रत्येक समय-खंड में कॉल सीमित करना

RateLimiter समय को रिफ़्रेश अवधियों में बाँटता है। प्रत्येक अवधि निश्चित संख्या में अनुमतियाँ देती है। जिसे कोई अनुमति उपलब्ध नहीं मिलती, वह timeoutDuration तक प्रतीक्षा करता है; फिर भी अनुमति न मिलने पर वह RequestNotPermitted के साथ तुरंत विफल हो जाता है।

application.yml में resilience4j.ratelimiter के अंतर्गत उदाहरण कॉन्फ़िगर करें:

limitForPeriod — प्रत्येक रिफ़्रेश अवधि में दी जाने वाली अनुमतियाँ।
limitRefreshPeriod — अनुमतियों की संख्या कितनी बार रीसेट होती है।
timeoutDuration — अस्वीकार किए जाने से पहले अनुमति की प्रतीक्षा में कॉल करने वाला कितनी देर तक रुकता है।

resilience4j:
  ratelimiter:
    instances:
      pricingApi:
        limitForPeriod: 50
        limitRefreshPeriod: 1s
        timeoutDuration: 200ms
        registerHealthIndicator: true

@RateLimiter लागू करना

उस विधि पर एनोटेशन लगाएँ जो सुरक्षित संसाधन को कॉल करती है। name का YAML उदाहरण से मेल खाना आवश्यक है। सीमा पार होने पर और timeoutDuration के भीतर कोई अनुमति उपलब्ध न होने पर Resilience4j RequestNotPermitted उत्पन्न करता है — इसे किसी वैकल्पिक तरीके पर भेजें, ताकि क्लाइंट को स्टैक ट्रेस के बजाय सुचारु 429 प्रतिक्रिया मिले।

मुख्य निर्णय: RateLimiter आपकी बाहर जाने वाली कॉल को नियंत्रित करता है। यह अपने-आप आने वाले HTTP ट्रैफ़िक को धीमा नहीं करता — इसे ऐसे वैकल्पिक तरीके के साथ जोड़ें जो बैक-प्रेशर का संकेत दे।

@Service
public class PricingClient {

    private final RestClient restClient;

    public PricingClient(RestClient restClient) {
        this.restClient = restClient;
    }

    @RateLimiter(name = "pricingApi", fallbackMethod = "throttled")
    public Quote fetchQuote(String symbol) {
        return restClient.get()
                .uri("/quotes/{symbol}", symbol)
                .retrieve()
                .body(Quote.class);
    }

    private Quote throttled(String symbol, RequestNotPermitted ex) {
        throw new ResponseStatusException(HttpStatus.TOO_MANY_REQUESTS,
                "Pricing rate limit exceeded, retry shortly");
    }
}

Retry: क्षणिक विफलताओं से उबरना

Retry विफल कॉल को maxAttempts बार तक दोबारा चलाता है। यह केवल क्षणिक समस्याओं — कनेक्शन रीसेट, 503, थोड़े समय के timeout — के लिए उचित है और केवल idempotent कार्यों पर सुरक्षित है। किसी गैर-idempotent POST को दोबारा चलाने से ग्राहक से दो बार शुल्क लिया जा सकता है।

एक साथ होने वाले दोबारा प्रयासों के तूफ़ान से बचने के लिए घातीय प्रतीक्षा-अंतराल का उपयोग करें और स्पष्ट रूप से बताएँ कि किन अपवादों पर दोबारा प्रयास करना है तथा किन पर तुरंत रुकना है:

retryExceptions — केवल ये दोबारा प्रयास शुरू करते हैं।
ignoreExceptions — ये तुरंत रोक देते हैं (जैसे 4xx क्लाइंट त्रुटियाँ)।
enableExponentialBackoff को गुणक के साथ उपयोग करने पर प्रयासों के बीच का अंतर बढ़ता जाता है।

resilience4j:
  retry:
    instances:
      pricingApi:
        maxAttempts: 3
        waitDuration: 200ms
        enableExponentialBackoff: true
        exponentialBackoffMultiplier: 2
        retryExceptions:
          - java.io.IOException
          - org.springframework.web.client.HttpServerErrorException
        ignoreExceptions:
          - org.springframework.web.client.HttpClientErrorException

जिटर के साथ घातीय प्रतीक्षा-अंतराल की अवधारणा

घातीय प्रतीक्षा-अंतराल प्रत्येक प्रयास के बाद प्रतीक्षा को गुणा करता है: 200ms, 400ms, 800ms... लेकिन यदि हज़ारों क्लाइंट एक ही क्षण में विफल हो जाएँ, तो वे सभी एक ही ताल में प्रतीक्षा करके फिर एक साथ प्रयास करने लगते हैं — इसे दोबारा प्रयासों का तूफ़ान कहते हैं। जिटर (यादृच्छिक प्रतीक्षा) जोड़ने से उनका समकालिक व्यवहार समाप्त हो जाता है।

यह स्वतंत्र प्रोग्राम प्रतीक्षा का क्रम तैयार करता है, ताकि आप जिटर के साथ प्रतीक्षा-अंतराल का फैलाव देख सकें और इसे कोई ऑनलाइन जाँच-प्रणाली बिना किसी फ़्रेमवर्क के चला सके:

import java.util.concurrent.ThreadLocalRandom;

public class BackoffDemo {
    static long backoffWithJitter(int attempt, long baseMillis, double multiplier) {
        double exp = baseMillis * Math.pow(multiplier, attempt - 1);
        long jitter = ThreadLocalRandom.current().nextLong((long) (exp / 2) + 1);
        return (long) (exp / 2) + jitter; // half fixed, half random
    }

    public static void main(String[] args) {
        for (int attempt = 1; attempt <= 4; attempt++) {
            long wait = backoffWithJitter(attempt, 200, 2.0);
            System.out.println("Attempt " + attempt + " -> wait ~" + wait + "ms");
        }
    }
}

@Retry लागू करना

उसी विधि पर @Retry लगाएँ। एनोटेशन के संयोजन में क्रम महत्वपूर्ण होता है: Resilience4j पहलुओं को Retry → CircuitBreaker → RateLimiter → TimeLimiter → Bulkhead क्रम में लागू करता है (बाहर से अंदर की ओर), इसलिए Retry दर-सीमित कॉल को घेरता है और प्रत्येक प्रयास में अनुमति फिर से लेनी पड़ती है।

सभी प्रयास समाप्त होने के बाद वैकल्पिक तरीके को अंतिम अपवाद मिलता है:

@Service
public class PricingClient {

    @Retry(name = "pricingApi")
    @RateLimiter(name = "pricingApi", fallbackMethod = "throttled")
    public Quote fetchQuote(String symbol) {
        return restClient.get()
                .uri("/quotes/{symbol}", symbol)
                .retrieve()
                .body(Quote.class);
    }

    private Quote throttled(String symbol, Throwable ex) {
        // Returns a last-known-good or default after retries + limit exhausted
        return Quote.unavailable(symbol);
    }
}

TimeLimiter: अत्यधिक विलंबता सीमित करना

TimeLimiter किसी एक अतुल्यकालिक कॉल के चलने की अधिकतम अवधि सीमित करता है। यह केवल फ़्यूचर के साथ काम करता है — विधि को CompletableFuture (या किसी अन्य समर्थित अतुल्यकालिक प्रकार) को लौटाना आवश्यक है, ताकि समय-सीमा समाप्त होने पर Resilience4j उसे रद्द कर सके।

यह धीमी निर्भरताओं का समाधान है: Retry विफलताओं को संभालता है, लेकिन जो कॉल 30 सेकंड तक बस अटकी रहे, वह आपके पूरे थ्रेड पूल को समाप्त कर सकती है। TimeLimiter ऐसी अटकी हुई कॉल को तेज़ TimeoutException में बदल देता है।

timeoutDuration — प्रत्येक कॉल की समय-सीमा।
cancelRunningFuture — समय-सीमा समाप्त होने पर चल रहे कार्य को रोककर उसका थ्रेड मुक्त करना।

resilience4j:
  timelimiter:
    instances:
      pricingApi:
        timeoutDuration: 2s
        cancelRunningFuture: true

अतुल्यकालिक विधि पर @TimeLimiter लागू करना

@TimeLimiter के लिए विधि का CompletableFuture लौटाना आवश्यक है। अतुल्यकालिक रिटर्न प्रकार के बिना पहलू चुपचाप कुछ नहीं करता। इसे CircuitBreaker के साथ मिलाएँ, ताकि बार-बार होने वाले timeout अंततः ब्रेकर खोल दें और व्यर्थ प्रयास रुक जाएँ।

ध्यान दें कि वैकल्पिक तरीका भी CompletableFuture लौटाता है — उसके हस्ताक्षर का सुरक्षित विधि के रिटर्न प्रकार से मेल खाना आवश्यक है:

@Service
public class PricingClient {

    @TimeLimiter(name = "pricingApi")
    @CircuitBreaker(name = "pricingApi", fallbackMethod = "timedOut")
    public CompletableFuture<Quote> fetchQuoteAsync(String symbol) {
        return CompletableFuture.supplyAsync(() ->
                restClient.get()
                        .uri("/quotes/{symbol}", symbol)
                        .retrieve()
                        .body(Quote.class));
    }

    private CompletableFuture<Quote> timedOut(String symbol, Throwable ex) {
        return CompletableFuture.completedFuture(Quote.unavailable(symbol));
    }
}

तीनों का सही क्रम निर्धारित करना

जब आप तीनों को एक साथ लगाते हैं, तो पहलुओं का क्रम व्यवहार निर्धारित करता है। Resilience4j का दस्तावेज़ित डिफ़ॉल्ट सजावट-क्रम, बाहर से अंदर की ओर, यह है:

Retry( CircuitBreaker( RateLimiter( TimeLimiter( Bulkhead( call ) ) ) ) )

Retry सबसे बाहर होना चाहिए, ताकि दोबारा प्रयास पूरी सुरक्षित श्रृंखला को फिर चलाए, हर प्रयास में सर्किट ब्रेकर की दोबारा जाँच हो और दर-सीमा की अनुमति फिर से ली जाए।
TimeLimiter अंदर होना चाहिए, ताकि प्रत्येक अलग प्रयास की अपनी समय-सीमा हो — timeout वाले कॉल का दोबारा प्रयास नई घड़ी से शुरू हो।
Retry को RateLimiter के अंदर रखने पर एक तार्किक कॉल प्रत्येक प्रयास के लिए कई अनुमतियाँ ले सकती है — जो आम तौर पर गलत है और दूसरे कॉल करने वालों को अनुमति से वंचित कर सकता है।

एनोटेशन के साथ आपको उनका क्रम स्वयं निर्धारित नहीं करना पड़ता; Resilience4j पहलू-प्राथमिकता के माध्यम से यह क्रम लागू करता है।

Actuator के माध्यम से निगरानी और समायोजन

जिसे आप देख नहीं सकते, उसे समायोजित नहीं कर सकते। क्लासपाथ पर Actuator होने पर प्रत्येक उदाहरण Micrometer मेट्रिक्स और स्वास्थ्य संकेतक प्रकाशित करता है। इन्हें उपलब्ध कराएँ और मुख्य संकेतों पर नज़र रखें:

resilience4j_ratelimiter_available_permissions — यदि यह शून्य पर बना हुआ है, तो आप वास्तविक ट्रैफ़िक को सीमित कर रहे हैं; सीमा बढ़ाएँ या सेवा का विस्तार करें।
resilience4j_retry_calls में kind=successful_with_retry और kind=failed_with_retry टैग — failed-with-retry की अधिक संख्या का अर्थ है कि दोबारा प्रयास मदद नहीं कर रहे; समस्या क्षणिक नहीं है।
resilience4j_timelimiter_calls में kind=timeout टैग — बढ़ते timeout संकेत देते हैं कि ब्रेकर खुलने से पहले ही निर्भरता की स्थिति बिगड़ रही है।

management:
  endpoints:
    web:
      exposure:
        include: health, metrics, ratelimiters, retries
  metrics:
    tags:
      application: tracing-service
  health:
    ratelimiters:
      enabled: true

त्वरित जाँच: सही मूलभूत साधन चुनना

एक डाउनस्ट्रीम pricing API कभी-कभी त्रुटि लौटाने के बजाय 30 या उससे अधिक सेकंड तक अटक जाती है, और इन अटकी हुई कॉल के कारण आपकी सेवा के अनुरोध वाले थ्रेड समाप्त हो रहे हैं। इस विशिष्ट विफलता स्थिति को सबसे सीधे कौन-सा Resilience4j मूलभूत साधन संबोधित करता है?

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

पुनरावलोकन: भार को आकार देना और विफलता सीमित करना

आपने लोड को व्यवस्थित करने और क्रमिक विफलताओं को सीमित करने के लिए तीन पूरक प्रिमिटिव को जोड़ा:

RateLimiter हर विंडो में कॉल की अधिकतम संख्या तय करता है और अतिरिक्त कॉल को RequestNotPermitted के साथ अस्वीकार करता है, ताकि आप स्वयं या किसी डाउनस्ट्रीम सेवा पर अत्यधिक लोड न डालें।
Retry क्षणिक त्रुटियों के बीच आइडेम्पोटेंट कॉल को दोबारा चलाता है और पुनःप्रयासों की बाढ़ से बचने के लिए घातांकीय बैकऑफ़ के साथ जिटर का उपयोग करता है।
TimeLimiter असमकालिक (CompletableFuture) कॉल की अधिकतम विलंबता सीमित करता है और अटक जाने वाली कॉल को त्वरित टाइमआउट में बदल देता है, जिससे थ्रेड मुक्त हो जाते हैं।

एनोटेशन के माध्यम से इन्हें एक साथ स्टैक करें; Resilience4j क्रम Retry → CircuitBreaker → RateLimiter → TimeLimiter → Bulkhead लागू करता है, इसलिए पुनःप्रयास पूरी सुरक्षित श्रृंखला को फिर से चलाता है और हर प्रयास की अपनी समय-सीमा होती है। सुचारु रूप से सीमित सेवा देने के लिए हमेशा फ़ॉलबैक जोड़ें और वास्तविक ट्रैफ़िक के आधार पर सीमाएँ समायोजित करने हेतु Actuator/Micrometer मेट्रिक्स पर नज़र रखें।

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

एआई शिक्षक के साथ Java सीखें — निःशुल्क

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

पाठ्यक्रम: 21
पाठ: 84

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

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

क्या “दर सीमांकन, पुनःप्रयास और समय सीमक” पाठ निःशुल्क है?

हाँ — Spring Boot 4 की संपूर्ण मार्गदर्शिका अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “दर सीमांकन, पुनःप्रयास और समय सीमक” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Spring Boot 4 की संपूर्ण मार्गदर्शिका पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“दर सीमांकन, पुनःप्रयास और समय सीमक” में मैं क्या सीखूँगा?

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

क्या Spring Boot 4 की संपूर्ण मार्गदर्शिका शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

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

“दर सीमांकन, पुनःप्रयास और समय सीमक” पाठ पूरा करने में कितना समय लगता है?

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

क्या मैं इस Spring Boot 4 की संपूर्ण मार्गदर्शिका पाठ में कोड लिख और चला सकता हूँ?

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

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

← Spring Boot 4 की संपूर्ण मार्गदर्शिका पर वापस जाएँ