Advanced Spring Boot 4: Event-Driven Architecture (Kafka) · 강의

Spring Retry를 활용한 재시도 메커니즘

일시적인 장애가 발생하면 메시지 처리를 자동으로 다시 시도하도록 Spring Retry를 통합하여 애플리케이션의 견고성을 높입니다.

Spring Retry를 활용한 재시도 메커니즘은(는) CoddyKit의 무료 Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Do We Need Retries?

In distributed systems like those using Kafka, operations can sometimes fail due to temporary issues. These are called transient failures.

Network glitches
Temporary service unavailability
Database connection timeouts

Retries help overcome these by automatically re-attempting failed operations, improving system resilience and reducing manual intervention.

Meet Spring Retry

Spring Retry is a powerful framework that simplifies implementing retry logic in your applications. It provides both declarative (using annotations) and programmatic (using RetryTemplate) ways to handle transient errors.

It integrates seamlessly with Spring Boot to make your applications more robust, especially when interacting with external services like Kafka.

RetryTemplate Basics

The RetryTemplate is Spring Retry's programmatic core. It allows you to wrap any code that might fail and define how it should be retried. Let's see a basic example:

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.support.RetryTemplate;

public class BasicRetryDemo {
    private static int attemptCount = 0;

    public static void main(String[] args) {
        RetryTemplate retryTemplate = new RetryTemplate();

        try {
            String result = retryTemplate.execute(
                new RetryCallback<String, RuntimeException>() {
                    @Override
                    public String doWithRetry(RetryContext context) {
                        System.out.println("Executing task. Attempt: " + (++attemptCount));
                        if (attemptCount < 3) {
                            throw new RuntimeException("Simulated service failure!");
                        }
                        return "Task completed successfully!";
                    }
                });
            System.out.println(result);
        } catch (RuntimeException e) {
            System.out.println("Final failure: " + e.getMessage());
        }
    }
}

Limiting Retries: Max Attempts

By default, RetryTemplate retries 3 times (1 initial attempt + 2 retries). You can configure this using a SimpleRetryPolicy. Let's set it to 4 attempts:

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.support.RetryTemplate;
import org.springframework.retry.policy.SimpleRetryPolicy;

import java.util.Collections;

public class MaxAttemptsDemo {
    private static int attemptCount = 0;

    public static void main(String[] args) {
        RetryTemplate retryTemplate = new RetryTemplate();
        
        // Configure max attempts (1 initial + 3 retries)
        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(
            4, Collections.singletonMap(RuntimeException.class, true));
        retryTemplate.setRetryPolicy(retryPolicy);

        try {
            String result = retryTemplate.execute(
                new RetryCallback<String, RuntimeException>() {
                    @Override
                    public String doWithRetry(RetryContext context) {
                        System.out.println("Executing task. Attempt: " + (++attemptCount));
                        if (attemptCount < 4) { // Fails first 3 times
                            throw new RuntimeException("Transient error!");
                        }
                        return "Task completed!";
                    }
                });
            System.out.println(result);
        } catch (RuntimeException e) {
            System.out.println("Final failure: " + e.getMessage());
        }
    }
}

Smart Delays: Fixed Backoff

Retrying immediately might overwhelm a temporarily struggling service. A backoff policy introduces a delay between retries. FixedBackOffPolicy waits a set amount of time.

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.support.RetryTemplate;
import org.springframework.retry.policy.SimpleRetryPolicy;
import org.springframework.retry.backoff.FixedBackOffPolicy;

import java.util.Collections;

public class FixedBackoffDemo {
    private static int attemptCount = 0;

    public static void main(String[] args) {
        RetryTemplate retryTemplate = new RetryTemplate();
        retryTemplate.setRetryPolicy(
            new SimpleRetryPolicy(3, Collections.singletonMap(RuntimeException.class, true)));
        
        // Configure fixed delay of 1000ms (1 second)
        retryTemplate.setBackOffPolicy(new FixedBackOffPolicy(1000L));

        try {
            String result = retryTemplate.execute(
                new RetryCallback<String, RuntimeException>() {
                    @Override
                    public String doWithRetry(RetryContext context) {
                        System.out.println("Attempt: " + (++attemptCount));
                        if (attemptCount < 3) {
                            throw new RuntimeException("Service busy!");
                        }
                        return "Success after retries!";
                    }
                });
            System.out.println(result);
        } catch (RuntimeException e) {
            System.out.println("Final failure: " + e.getMessage());
        }
    }
}

Exponential Backoff

For services that need more time to recover, exponential backoff increases the delay after each retry. This is often more effective than a fixed delay.

ExponentialBackOffPolicy lets you set initial delay, multiplier, and max delay.

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.support.RetryTemplate;
import org.springframework.retry.policy.SimpleRetryPolicy;
import org.springframework.retry.backoff.ExponentialBackOffPolicy;

import java.util.Collections;

public class ExponentialBackoffDemo {
    private static int attemptCount = 0;

    public static void main(String[] args) {
        RetryTemplate retryTemplate = new RetryTemplate();
        retryTemplate.setRetryPolicy(
            new SimpleRetryPolicy(4, Collections.singletonMap(RuntimeException.class, true)));
        
        // Configure exponential backoff
        ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
        backOffPolicy.setInitialInterval(100L); // 100ms
        backOffPolicy.setMultiplier(2.0);      // Doubles each time
        backOffPolicy.setMaxInterval(2000L);   // Max 2 seconds
        retryTemplate.setBackOffPolicy(backOffPolicy);

        try {
            String result = retryTemplate.execute(
                new RetryCallback<String, RuntimeException>() {
                    @Override
                    public String doWithRetry(RetryContext context) {
                        System.out.println("Attempt: " + (++attemptCount));
                        if (attemptCount < 4) {
                            throw new RuntimeException("Resource contention!");
                        }
                        return "Success after exponential backoff!";
                    }
                });
            System.out.println(result);
        } catch (RuntimeException e) {
            System.out.println("Final failure: " + e.getMessage());
        }
    }
}

Retry on Specific Errors

You might only want to retry on certain types of exceptions, not all. SimpleRetryPolicy allows you to specify which exceptions should trigger a retry.

Exceptions not in the list will cause immediate failure.

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.support.RetryTemplate;
import org.springframework.retry.policy.SimpleRetryPolicy;

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

public class SpecificExceptionDemo {
    private static int attemptCount = 0;

    public static void main(String[] args) {
        RetryTemplate retryTemplate = new RetryTemplate();
        
        Map<Class<? extends Throwable>, Boolean> retryableExceptions = new HashMap<>();
        retryableExceptions.put(IOException.class, true); // Only retry IOException
        retryableExceptions.put(MyCustomTransientException.class, true); 

        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(3, retryableExceptions);
        retryTemplate.setRetryPolicy(retryPolicy);

        try {
            String result = retryTemplate.execute(
                new RetryCallback<String, Exception>() { // Note: now throws Exception
                    @Override
                    public String doWithRetry(RetryContext context) throws Exception {
                        System.out.println("Attempt: " + (++attemptCount));
                        if (attemptCount == 1) {
                            throw new IOException("Network issue!"); // Will retry
                        } else if (attemptCount == 2) {
                            throw new MyCustomTransientException("DB lock!"); // Will retry
                        } else if (attemptCount == 3) {
                            throw new IllegalArgumentException("Bad data!"); // Will NOT retry
                        }
                        return "Success!";
                    }
                });
            System.out.println(result);
        } catch (Exception e) {
            System.out.println("Final failure: " + e.getClass().getSimpleName() + " - " + e.getMessage());
        }
    }
    
    static class MyCustomTransientException extends RuntimeException {
        public MyCustomTransientException(String message) { super(message); }
    }
}

Handling Final Failures: @Recover

What happens if all retries are exhausted and the operation still fails? You need a fallback!

In a Spring context, the @Recover annotation marks a method to be called when a @Retryable method permanently fails. It lets you provide alternative logic or gracefully log the error.

For RetryTemplate, you can provide a RecoveryCallback to achieve similar fallback behavior.

Spring Kafka Listener Retries

For Spring Boot Kafka consumers, you can apply the @Retryable annotation directly to your @KafkaListener methods. This ensures that if message processing fails, the listener will retry before the message is potentially sent to a Dead Letter Topic (DLT).

Remember to enable Spring Retry with @EnableRetry on your application class!

import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Component;
import org.springframework.retry.backoff.Backoff;

// This is a conceptual example for a Kafka Listener.
// It requires a running Kafka broker and Spring Boot app.
@Component
public class MyKafkaListener {
    private int processAttempts = 0;

    @KafkaListener(topics = "myTopic", groupId = "myGroup")
    @Retryable(
        value = {RuntimeException.class}, // Retry on RuntimeException
        maxAttempts = 5,
        backoff = @Backoff(delay = 1000) // Initial 1s delay
    )
    public void listen(String message) {
        processAttempts++;
        System.out.println("Processing message: '" + message + "' (Attempt " + processAttempts + ")");
        if (processAttempts < 3) { // Simulate failure for first 2 processing attempts
            throw new RuntimeException("Failed to process: " + message);
        }
        processAttempts = 0; // Reset for next message
        System.out.println("Successfully processed: " + message);
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println("This code demonstrates @Retryable on a @KafkaListener method.");
        System.out.println("It would run within a Spring Boot application connected to Kafka.");
    }
}

Retry Configuration Check

You are building a Kafka consumer that processes orders. Sometimes, the external payment service is temporarily unavailable. You want to retry processing an order up to 5 times, with an initial delay of 500ms, doubling each time, but not exceeding 5 seconds. Which configuration for @Retryable is correct?

Recap: Spring Retry

In this lesson, you learned how to make your Kafka consumers more resilient using Spring Retry:

Understood the need for retries for transient failures in distributed systems.
Explored RetryTemplate for programmatic retry logic, demonstrating its core features.
Learned how to configure maxAttempts and different BackOffPolicy strategies (fixed and exponential).
Understood the role of @Retryable and @Recover annotations for declarative retries in a Spring context, particularly for @KafkaListener methods.

Next, we'll explore Dead Letter Topics (DLT) for handling messages that permanently fail after all retries, ensuring no data is lost.

자주 묻는 질문

“Spring Retry를 활용한 재시도 메커니즘” 강의는 무료인가요?

네 — “Spring Retry를 활용한 재시도 메커니즘” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의 전체를 잠금 해제할 수 있습니다. Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의에는 총 4개의 강의가 포함되어 있습니다.

“Spring Retry를 활용한 재시도 메커니즘”에서 뭘 배우나요?

일시적인 장애가 발생하면 메시지 처리를 자동으로 다시 시도하도록 Spring Retry를 통합하여 애플리케이션의 견고성을 높입니다. 브라우저에서 직접 실행하는 실습 코드로 Advanced Spring Boot 4: Event-Driven Architecture (Kafka)을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Advanced Spring Boot 4: Event-Driven Architecture (Kafka)을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Advanced Spring Boot 4: Event-Driven Architecture (Kafka)은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“Spring Retry를 활용한 재시도 메커니즘” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Advanced Spring Boot 4: Event-Driven Architecture (Kafka) 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Advanced Spring Boot 4: Event-Driven Architecture (Kafka)(으)로 돌아가기