캐시와 버퍼의 차이
버퍼
데이터 전송을 관리하기 위한 임시 저장소로, 처리 속도 차이를 완화하는 목적을 가진다. 소프트웨어가 명시적으로 관리하며, 데이터가 짧게 유지되며 한 번 사용된다.
캐시
데이터 접근 속도를 높이기 위한 임시 저장소로, 반복적인 데이터 접근 속도를 높이는 목적을 가진다. 하드웨어나 시스템에 의해 자동으로 관리되며, 데이터가 여러 번 재사용되며 오래 유지될 수 있다.
- 데이터를 통신하는 시스템 쌍방 (서버와 클라이언트)는 캐시의 존재를 알지 못하며, 캐시가 있던 없건 실행 결과는 동일하다. 캐시의 목표는 오로지 성능 개선
Spring Cache
- 스프링 자체 캐시는 @EnableCaching 애너테이션과, 캐시를 적용할 메서드에 @Cacheable을 붙여 사용한다. (인메모리, Concurrent HashMap)
Application 클래스에 적용하거나, 따로 CacheConfig 클래스를 생성하여 @Configuration과 함께 사용할 수도 있다. - @CacheEvict로 캐시를 삭제하고, @CachePut으로 캐시를 갱신할 수 있다.
@Cacheable("키 값으로 사용할 이름")
public Object getObject(String name) {
...괄호에 들어갈 키 값은 해당 메서드가 받는 인자의 이름이 name일 경우, "key::name" 식으로 생성된다.
-
캐시를 사용할 때는 무엇을 캐시할지, 얼마나 오랫동안 캐시할지, 언제 캐시를 갱신할지를 고려해야 한다.
-
SpringCache는 스프링 컨테이너에서 모든 빈들이 완성되고 로딩이 끝난 후에 활성화된다.
@PostConstruct는 해당 클래스(빈)의 의존성이 모두 충족된 후이므로, 해당 시점에서 캐시가 준비되지 않았을 수 있다. 특정 이벤트 시점에 실행이 되어야 한다면 @EventListener를 사용하는 것도 방법이다.
Redis
-
redis 의존성 추가하여 Config 클래스를 따로 작성하므로 @EnableCaching 사용 x
-
로컬에서 redis를 설치한 경우에는 별도의 설정 없이도 자동으로 연결이 된다(host: localhost, port: 6379)
-
외부 저장소에 저장될 때 직렬화 과정을 거친다. 이 때, 별도의 설정을 해두지 않았다면 캐싱하는 클래스에 Serializable 구현이 필요하다. RedisConfig에서 Serializer를 따로 설정한 경우에는 구현할 필요가 없다
-
직렬화 설정 변경 시에는 CachingConfigurerSupport를 상속하여 CachManager 메서드를 오버라이딩해 구현하거나, 혹은 RedisCacheConfiguration 자체를 빈으로 등록하는 방법이 있다. 더블 콜론에서 싱글 콜론으로 변경하거나, ttl 설정도 가능하다.
