Spring Boot 4 Complete Guide · 강의

Redis와 TTL을 활용한 분산 캐싱

직렬화 제어 기능을 갖춘 중앙 캐시 백엔드로 Redis를 사용해 인스턴스 간 캐시 상태를 공유합니다.

레슨 3/413개 단계

Redis와 TTL을 활용한 분산 캐싱은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

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

Why Distributed Caching?

Caffeine is a brilliant in-process cache: ultra-fast, but each application instance keeps its own private copy. The moment you scale horizontally to several pods, those copies drift apart.

Instance A evicts a user; instance B still serves the stale entry.
A cache warm-up on one node helps nobody else.
Total memory cost grows linearly with replica count.

A distributed cache solves this by putting cache state in a shared backend that every instance reads and writes. In Spring Boot, Redis is the most common choice for this role.

Adding the Redis Cache Starter

Spring Boot's caching abstraction is backend-agnostic. To swap Caffeine for Redis you mostly change dependencies and a property — your @Cacheable annotations stay the same.

Pull in the Redis starter and the cache abstraction:

spring-boot-starter-data-redis provides the connection and RedisCacheManager.
spring-boot-starter-cache enables the @Cacheable/@CacheEvict annotations.

Then declare Redis as the cache type so Boot auto-configures a RedisCacheManager instead of a simple map.

<!-- pom.xml -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>
</dependencies>

Configuring the Connection and Cache Type

Point Boot at your Redis server and tell the cache abstraction to use Redis. With spring.cache.type=redis, Boot wires a RedisCacheManager automatically.

spring.data.redis.host / port configure the Lettuce client (the default driver).
spring.cache.redis.time-to-live sets a default TTL for every entry.
spring.cache.cache-names can pre-declare caches at startup.

# application.yml
spring:
  data:
    redis:
      host: localhost
      port: 6379
  cache:
    type: redis
    cache-names: products, users
    redis:
      time-to-live: 10m
      cache-null-values: false
      use-key-prefix: true

The Same @Cacheable, a Shared Backend

This is the payoff of Spring's abstraction: the service code is identical to the Caffeine version. Only the CacheManager behind it changed.

Now when instance A populates products::42, instance B reads the very same key from Redis on its next call — no duplicate computation, no drift.

@Service
public class ProductService {

    private final ProductRepository repository;

    public ProductService(ProductRepository repository) {
        this.repository = repository;
    }

    @Cacheable(cacheNames = "products", key = "#id")
    public Product findById(Long id) {
        // Runs only on a cache miss across the whole cluster
        return repository.findById(id)
                .orElseThrow(() -> new ProductNotFoundException(id));
    }

    @CacheEvict(cacheNames = "products", key = "#product.id")
    public Product update(Product product) {
        return repository.save(product);
    }
}

TTLs: Bounding Staleness

A TTL (time-to-live) is the maximum age of a cache entry before Redis evicts it automatically. TTLs are the primary defense against serving stale data in a distributed cache.

Short TTL (seconds) → fresher data, more backend load.
Long TTL (hours) → cheaper, but staleness risk grows.
TTL is enforced server-side by Redis, so it applies uniformly to every instance.

Unlike Caffeine's expireAfterWrite, Redis TTLs survive a single instance restart because the data lives outside the JVM.

Per-Cache TTLs with a Custom RedisCacheManager

A single global TTL rarely fits every cache. Override the auto-configuration to give each cache its own expiry by supplying a RedisCacheManagerBuilderCustomizer (or a full RedisCacheManager bean).

Here products tolerates 30 minutes of staleness while volatile prices expires after 1 minute.

@Configuration
public class CacheConfig {

    @Bean
    public RedisCacheManagerBuilderCustomizer cacheCustomizer() {
        return builder -> builder
            .withCacheConfiguration("products",
                RedisCacheConfiguration.defaultCacheConfig()
                    .entryTtl(Duration.ofMinutes(30)))
            .withCacheConfiguration("prices",
                RedisCacheConfiguration.defaultCacheConfig()
                    .entryTtl(Duration.ofMinutes(1)));
    }
}

Serialization: How Values Reach Redis

Redis stores bytes, not Java objects. Every cached value must be serialized on write and deserialized on read. The default RedisCacheManager uses Java's native serialization (JdkSerializationRedisSerializer), which has real drawbacks:

Values are opaque binary blobs — unreadable with redis-cli.
The cached class must implement Serializable.
Tight coupling to class internals breaks across versions.

For interoperable, human-readable entries, switch the value serializer to JSON.

Controlling Serialization with JSON

Use GenericJackson2JsonRedisSerializer for values and a plain StringRedisSerializer for keys. JSON keeps entries inspectable and decouples them from Java class internals.

The serializer embeds type metadata (@class) so polymorphic values deserialize back to the correct concrete type.

@Bean
public RedisCacheConfiguration cacheConfiguration() {
    return RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(10))
        .disableCachingNullValues()
        .serializeKeysWith(
            RedisSerializationContext.SerializationPair.fromSerializer(
                new StringRedisSerializer()))
        .serializeValuesWith(
            RedisSerializationContext.SerializationPair.fromSerializer(
                new GenericJackson2JsonRedisSerializer()));
}

Key Prefixes Prevent Collisions

When several caches share one Redis database, their keys must not collide. By default Spring prefixes every entry with the cache name, so products::42 and users::42 stay separate.

use-key-prefix: true (default) keeps caches isolated.
You can supply a custom prefix, e.g. an app or tenant name, to share a Redis instance safely across services.

This matters most in multi-tenant or shared-infrastructure setups where one Redis serves many apps.

@Bean
public RedisCacheConfiguration cacheConfiguration() {
    return RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(10))
        .computePrefixWith(cacheName -> "shop:" + cacheName + "::");
    // key becomes shop:products::42
}

Avoiding the Thundering Herd

A distributed cache concentrates risk: when a hot key's TTL expires, every instance misses at once and stampedes the database — the thundering herd problem.

Mitigations:

Stagger TTLs by adding a small random jitter so keys don't expire together.
Refresh entries proactively before expiry rather than lazily on miss.
Use a short-lived lock so only one instance recomputes a missed key while others wait.

This pure-Java helper shows how to compute a jittered TTL you would feed into entryTtl(...).

import java.time.Duration;
import java.util.concurrent.ThreadLocalRandom;

public class TtlJitter {

    static Duration withJitter(Duration base, double jitterFraction) {
        long baseMs = base.toMillis();
        long spread = (long) (baseMs * jitterFraction);
        long offset = ThreadLocalRandom.current().nextLong(-spread, spread + 1);
        return Duration.ofMillis(baseMs + offset);
    }

    public static void main(String[] args) {
        Duration base = Duration.ofMinutes(10);
        for (int i = 0; i < 3; i++) {
            Duration ttl = withJitter(base, 0.1); // +/- 10%
            System.out.println("TTL seconds: " + ttl.getSeconds());
        }
    }
}

Two-Tier Caching: Caffeine + Redis

You don't have to choose. A common production pattern is a two-tier (near) cache:

L1 — Caffeine in each instance, very short TTL, absorbs hot reads at nanosecond speed.
L2 — Redis, shared across the cluster, the source of truth for cached state.

A request checks Caffeine first; on a miss it falls back to Redis; on a Redis miss it hits the database. This cuts network round-trips while keeping the cluster consistent. Spring can compose this with a CompositeCacheManager or a dedicated near-cache library.

Quick Check: Choosing a TTL Strategy

Test your understanding of distributed cache trade-offs.

인터랙티브 레슨에서 답해보세요

Recap: Distributed Caching with Redis

You moved from a private in-process cache to a shared, distributed one:

Why Redis: one cache state across all instances eliminates drift and duplicated work.
Drop-in swap: set spring.cache.type=redis and your @Cacheable code is unchanged.
TTLs: Redis enforces expiry server-side, uniformly across the cluster, surviving instance restarts; tune per cache with a RedisCacheManagerBuilderCustomizer.
Serialization: prefer GenericJackson2JsonRedisSerializer for readable, version-tolerant values over default JDK serialization.
Key prefixes isolate caches sharing one Redis; TTL jitter and two-tier Caffeine+Redis caches tame the thundering herd.

무료로 시작

AI 튜터와 함께 Java을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 21
레슨: 84

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“Redis와 TTL을 활용한 분산 캐싱” 강의는 무료인가요?

네 — “Redis와 TTL을 활용한 분산 캐싱” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“Redis와 TTL을 활용한 분산 캐싱”에서 뭘 배우나요?

직렬화 제어 기능을 갖춘 중앙 캐시 백엔드로 Redis를 사용해 인스턴스 간 캐시 상태를 공유합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

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

“Redis와 TTL을 활용한 분산 캐싱” 강의는 얼마나 걸리나요?

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

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

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

이 강의의 모든 강의

← Spring Boot 4 Complete Guide(으)로 돌아가기