Local Cache
•
서버마다 캐시를 따로 저장한다.
•
다른 서버의 캐시를 참조하기 어렵다.
•
서버 내에서 작동하기 때문에 속도가 빠르다.
•
로컬 서버 장비의 Resource를 이용한다. (Memory, Disk)
•
캐시에 저장된 데이터가 변경되는 경우:
◦
해당 서버를 제외한 모든 peer에 변경 사항 전달
◦
All-to-All Replication
◦
WAS 인스턴스가 늘어나고, 캐시 저장 데이터 크기가 커지면 성능이 저하되는 이유는 이 때문
•
스프링에서 구현 가능한 로컬 캐시 라이브러리
◦
Ehcache
▪
Off Heap에 저장, 분산 캐시, cache listener 등 더 많은 기능을 제공
◦
Caffeine Cache
▪
Window TinyLfu eviction policy를 사용하여 최적에 가까운 적중률을 제공
▪
읽기, 쓰기 성능 모두 Ehcache에 비해 우수하다.
Caffeine Cache가 Ehcache에 비해 높은 성능을 내며 설정이 간단하다.
Ehcache는 Caffeine Cache에 비해 더 많은 기능을 제공한다.
Global Cache
•
여러 서버에서 캐시 서버에 접근하여 참조 할 수 있다.
•
별도의 캐시 서버를 이용하기 때문에 서버 간 데이터 공유가 쉽다.
•
네트워크 트래픽을 사용해야 해서 로컬 캐시보다는 느리다.
•
데이터를 분산하여 저장 할 수 있다.
◦
Replication: 두 개의 이상의 DBMS 시스템을 Mater / Slave 로 나눠서 동일한 데이터를 저장하는 방식
◦
Sharding: 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법
•
캐시에 저장된 데이터가 변경되는 경우:
◦
추가적인 작업 필요없음
◦
서비스 확장으로 WAS 인스턴스가 늘어나고, Cache 데이터 크기가 커질 수록 효과적인 이유
•
스프링에서 구현 가능한 글로벌 캐시 라이브러리
◦
Redis
▪
다양한 자료구조를 제공 (memcached는 String만 지원)
▪
disk에도 데이터를 저장하기 때문에 돌발상황에서 데이터의 복구가 가능하다.
◦
memcached
▪
redis보다 적은 메모리를 요구한다.
redis는 memcached가 가진 단점을 개선하여 만들어졌다.
redis는 읽기/쓰기 모두 균일한 성능을 보였고,
memcached는 쓰기 속도는 상대적으로 우월하지만, 읽기속도가 느리다.
