문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 다음 판 양쪽 다음 판 | ||
java:ehcache [2014/09/25 11:24] kwon37xi |
java:ehcache [2014/09/30 13:42] kwon37xi [Replication과 Hibernate] |
||
---|---|---|---|
줄 1: | 줄 1: | ||
====== ehcache ====== | ====== ehcache ====== | ||
+ | ===== Singleton Cache ===== | ||
+ | * 단일 JVM에서는 가능하면 Singleton '' | ||
+ | * Hibernate와 Spring에서 Singleton Cache Manager를 사용하도록 하고 로딩 순서를 보정해주면 될 듯 하다. | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | ===== Distributed Cache ===== | ||
+ | The data is held in a Terracotta Server Array with a subset of recently used data held in each application cache node. The distributed topology, available with BigMemory Max, supports a very rich set of consistency modes. | ||
+ | |||
+ | ===== Replicated Cache ===== | ||
+ | * [[http:// | ||
+ | * Relication 전략은 각 애플리케이션의 메모리에서 각자 캐시를 하되 캐시 상태를 여러 애플리케이션이 서로 동기화한다. | ||
+ | * 이 경우 캐시 된 데이터를 각자 자기 메모리에서 읽기 때문에 로컬 캐시를 사용하는 효과와 동일할 것이다. | ||
+ | * 하지만 노드의 갯수가 증가하게 되면 그만큼 부하도 증가하고 성능도 떨어질 수 있다. 따라서 10 노드 이하 정도의 규모에서 사용한다. | ||
+ | * **Do not use Time To Idle with replicated caching**, unless you do not care about inconsistent data across nodes. | ||
+ | ==== Replication 데이터 복제 전략 ==== | ||
+ | * 각 애플리케이션에 캐시가 존재하고 RMI, JGroups, JMX 등을 통해 캐시를 서로 동기화 | ||
+ | * '' | ||
+ | * '' | ||
+ | * 복제 전략을 '' | ||
+ | * 복제 전략을 '' | ||
+ | * TODO : 내 예상으로는 '' | ||
+ | * 따라서 여러 애플리케이션이 순차적으로 배포되면서 캐시를 리플리케이션 할 때는 **'' | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | ==== Replication과 Hibernate ==== | ||
+ | * Infinispan 매뉴얼의 Hibernate 관련 절을 보면 Hibernate의 캐시 전략이 나옴. -> 좀 더 자세히 읽어볼 것. | ||
+ | * 기본적으로 Replication으로 한다. | ||
+ | * Entity와 컬렉션은 '' | ||
+ | * '' | ||
+ | |||
===== Update Check 끄기 ===== | ===== Update Check 끄기 ===== | ||
* [[http:// | * [[http:// | ||
줄 12: | 줄 43: | ||
</ | </ | ||
- | ===== Distributed Cache ===== | ||
- | * EhCache 전용 서버를 따로 두고, 각 애플리케이션이 EhCache 서버에 접속하는 방식(Memcached와 유사?) | ||
- | |||
- | ===== Replicated Cache ===== | ||
- | ==== Replication 데이터 복제 전략 ==== | ||
- | * 각 애플리케이션에 캐시가 존재하고 RMI, JGroups, JMX 등을 통해 캐시를 서로 동기화 | ||
- | * '' | ||
- | * '' | ||
- | * Copy 전략을 '' | ||
- | * Copy 전략을 '' | ||
- | * TODO : 내 예상으로는 Copy 전략을 사용하면 캐시 대상 클래스가 한쪽 애플리케이션에서만 변경되고 다른쪽에서는 변경이 안됐을 경우 오류가 발생하지 않을까 싶다. | ||
- | * 따라서 여러 애플리케이션이 순차적으로 배포되면서 캐시를 리플리케이션 할 때는 **'' | ||
- | * [[http:// | ||
- | * [[http:// |