TIL - Redis 캐싱 적용

Redis 캐싱을 적용한 이유

허브 프로젝트에서 다음과 같은 특징이 있었다.

• 허브 정보 -> 거의 변경되지 않음
• 허브 간 이동경로 -> 거의 변경되지 않음
• 조회는 자주 발생

이런 데이터는 매번  DB를 조회할 필요가 없기 때문에 Redis를 이용한 캐싱을 적용했다.

즉, 조회 성능 개선 + DB 부하 감소가 목적이다.

전체 구조

구조는 다음과 같다

DB -> 실제 데이터 저장

Redis -> 조회 성능을 위한 캐시

client -> service -> Redis ->있으면 반환 없으면 DB조회 후 Redis  저장

 

적용 방식

조회

@Cacheable(value = "hubs", key = "#hubId")

동작 : 

1. Redis에서 먼저 조회

2. 있으면 바로 반환

3. 없으면 DB조회

4. 결과를 Redis에 저장

수정

@CacheEvict(value = {"hubList", "hubRouteList"}, allEntries = true)

DB 데이터가 변경되면 기존 캐시는 의미가 없기 때문에 캐시를 삭제한다.

 

수정 후 갱신

@CachePut(value = "hubs", key = "#hubId")

수정된 데이터를 다시 캐시에 저장하여 항상 최신 상태 유지

 

Redis 설정

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {

        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(30))
                .disableCachingNullValues()
                .serializeKeysWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())
                )
                .serializeValuesWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(
                                new GenericJackson2JsonRedisSerializer()
                        )
                );

        return RedisCacheManager.builder(connectionFactory)
                .cacheDefaults(config)
                .build();
    }

TTL 설정 -> 캐시 자동 만료

Key -> String

Value -> JSON

 

마무리

DB -> 원본 데이터

Redis -> 조회 최적화

Cacheable -> 조회 캐시

CacheEvict -> 캐시 삭제

CachePut -> 캐시 갱신