두 서버간에 캐시 데이터를 동기화하는 가장 좋은 방법

Question

두 서버간에 캐시 데이터를 동기화하고 싶습니다. 두 데이터베이스는 동일한 데이터베이스를 공유하지만보다 나은 실행 데이터를 얻기 위해 시작할 때 데이터를 해시 맵에 캐시했습니다. 따라서 서버를 다시 시작하지 않고 캐시 된 데이터를 동기화하려고합니다. 두 서버는 동시에 시작됩니다.

나에게 최선의 효율적인 방법을 제안 해주세요.

Answer 1

두 서버 인스턴스간에 캐시 된 데이터를 동기화하는 대신 memcached/couchbase 또는 redis와 같은 것을 사용하여 캐싱을 중앙화하지 않는 것이 어떻습니까? ehcache와 같은 분산 캐싱을 사용하는 것은 훨씬 복잡하고 오류가 발생하기 쉬운 IMO와 앞서 언급 한 캐싱 서버를 사용하여 캐싱 된 데이터를 중앙화하는 것입니다.

원래의 대답에 대한 추가 정보로, 어떤 캐싱 접근법 (메모리에서 중앙 집중식)을 사용할지 결정할 때 고려해야 할 한 가지는 캐싱되는 데이터의 변동성입니다.

데이터가 DB에 저장되어 있지만 서버가로드 한 후에 변경되지 않으면 서버간에 동기화가 필요하지 않습니다. 각자 정적 데이터를 소스에서 메모리로로드 한 다음 그들이 수행하는 모든 일을 메리 방식으로 수행하도록하십시오. 데이터가 변경되지 않으므로 서버간에 데이터를 동기화하기위한 복잡한 패턴을 도입 할 필요가 없습니다.

실제로 데이터에 변동성이있는 경우 (예 : DB에서 조회를 저장하기 위해 DB에서 엔티티 데이터를 조회하는 것과 같이) 중앙 집중식 캐싱이 - 메모리 분산 및 동기화 캐싱. 캐싱 된 데이터에 대해 적절한 만료를 사용하여 데이터를 자연스럽게 새로 고칠 수 있도록해야합니다. 또한 특정 엔터티의 업데이트 경로에있을 때 중앙 저장소에서 캐시 된 데이터를 삭제 한 다음 해당 데이터에 대한 다음 요청시 캐시에서 다시로드 할 수 있습니다. 이것은 기본 스토어와 캐시에 쓸 진정한 write-through 캐시를 수행하는 것보다 낫다. DB 자체가 데이터를 조정할 수 있습니다 (예 : 기본 제공되지 않는 값을 통해).이 경우 캐시 된 데이터가 DB의 데이터와 일치하지 않을 수 있습니다.

편집는 :

질문은 중앙 캐시 (I 메모리 분산 캐시에 뭔가에 대해 추측하고있어)의 장점에 대한 의견 요청했다. 나는 그것에 대한 제 의견을 제시 할 것이지만, 처음에는 표준 면책 조항입니다. 중앙 집중식 캐싱은 모든 것을 치료하는 것이 아닙니다. 이것은 in-jvm-memory 캐싱과 관련된 특정 문제를 해결하는 것을 목표로합니다. 전환 여부를 평가하기 전에 먼저 문제가 무엇인지 파악하고 중앙 집중식 캐싱의 이점에 부합하는지 확인해야합니다. 중앙 집중식 캐싱은 아키텍처의 변화이며 자체 캐싱 문제가 발생할 수 있습니다. 누군가가 당신이하고있는 것보다 낫다고 말하기 때문에 간단하게 바꾸지 마십시오. 그 이유가 문제에 부합하는지 확인하십시오.

좋아요, 이제 중앙 집중식 캐싱이 jvm-memory (및 가능하게는 분산 된) 캐싱을 해결할 수있는 문제에 대한 제 견해로 돌아 왔습니다. 나는 몇 가지 더 있다고 확신하지만 두 가지를 열거 할 것이다. 내 큰 두 가지 위치 : 전체 메모리 풋 프린트 및 데이터 동기화 문제.

전체 메모리 풋 프린트부터 시작하겠습니다. 관계형 DB를 과도한 스트레스로부터 보호하기 위해 표준 엔티티 캐싱을 수행한다고 가정 해보십시오. DB를 실제로 보호하기 위해 캐시 할 데이터가 많다고 가정 해 보겠습니다. 많은 GB의 범위에서 말하십시오.in-jvm-memory 캐싱을하고 있고 애플리케이션 서버 박스가 10 개라고하면 jvm에서 캐싱을 수행해야하는 각 상자에 대해 추가 메모리 ($$$)를 10 번 가져와야합니다 기억. 또한 캐시 된 데이터를 수용하기 위해 더 큰 힙을 JVM에 할당해야합니다. 나는 가비지 콜렉션 부담을 덜어주기 위해 JVM 힙이 작고 간소화되어야한다고 생각한다. 수집 할 수없는 큰 덩어리의 늙은 겐이 있으면 전체 GC에 들어갈 때 가비지 컬렉터에게 스트레스를가하면서 그 부풀린 Old Gen 공간에서 뭔가를 되 찾으려고합니다. 긴 GC2 일시 정지 시간을 피하고 Old Gen를 부풀려서 도움을주지 않으려합니다. 또한 메모리 요구 사항이 특정 임계 값을 초과하고 응용 프로그램 계층에 32 비트 시스템을 실행하는 경우 64 비트 시스템으로 업그레이드해야하며 이는 또 다른 비용이 될 수 있습니다.

이제 (Redis 또는 Memcached와 같은 것을 사용하여) 캐시 된 데이터를 중앙 집중화하기로 결정한 경우 캐시 된 데이터의 전체 메모리 사용량이 크게 줄어들 수 있습니다. 앱 레이어의 앱 서버 상자. 클러스터 된 접근법 (두 기술 모두 지원)과 고 가용성 (availability)을 제공하고 캐싱 계층에서 단일 지점 (single point of failure)을 피하기 위해 적어도 두 개의 서버를 사용하는 것이 좋습니다. 캐싱에 필요한 메모리 요구 사항을 지원하는 두 대의 컴퓨터가있는 경우 상당한 $$을 절약 할 수 있습니다. 또한 앱 상자와 캐시 상자를 별개의 용도로 사용할 수 있도록 조정할 수 있습니다. 응용 프로그램 상자는 높은 처리량과 낮은 힙을 위해 조정될 수 있으며 캐시 상자는 큰 메모리를 위해 조정될 수 있습니다. 그리고 힙을 줄이면 앱 레이어 박스의 전반적인 처리량을 확실히 도울 수 있습니다.

이제는 중앙 집중식 캐싱을위한 핵심 사항입니다. 캐시를 사용하지 않고도 일정 시간 동안 완전히 작동 할 수있는 경우에 대비하여 응용 프로그램을 설정해야합니다. 전통적인 엔티티 캐싱에서는 캐시가 완전히 사용 불가능 해지면 모든 요청에 ​​대해 직접 DB를 사용한다는 의미입니다. 굉장하지 않고 세상 끝도 아닙니다.

오케이, 지금은 데이터 동기화 문제입니다. 분산 jvm 메모리 캐싱을 사용하면 캐시를 동기화 상태로 유지해야합니다. 한 노드에서 캐시 된 데이터를 변경하면 다른 노드에 복제하고 캐시 된 데이터로 동기화해야합니다. 이 방법은 어떤 이유로 (예를 들어 네트워크 장애) 노드 중 하나가 동기화되지 않으면 요청이 해당 노드로 이동하면 사용자가 볼 수있는 데이터가 현재 노드에있는 데이터와 정확하지 않을 수 있다는 점에서 조금 비관적입니다. DB. 다른 요청을하고 다른 노드에 도달하면 다른 데이터가 표시되어 사용자에게 혼란을줍니다. 데이터를 중앙 집중화함으로써이 문제를 해결할 수 있습니다. 이제는 중앙 집중화 된 캐시가 동일한 캐시 된 데이터 키에 대한 업데이트에 대한 동시성 제어가 필요하다고 주장 할 수 있습니다. 동일한 키에 대해 두 개의 동시 업데이트가있는 경우 두 업데이트가 서로 쾅쾅 거리지 않도록 어떻게 확인합니까? 내 생각은 여기에 대해 걱정하지 않는 것입니다. 업데이트가 발생하면 캐시에서 항목을 삭제하고 (직접 DB에 씁니다) 다음 번 읽을 때 다시로드하십시오. 이렇게하면 안전하고 편리합니다. 그렇게하고 싶지 않다면 캐시와 db를 업데이트 할 때 낙천적 동시성 제어 대신 CAS (Check-And-Set) 기능을 사용할 수 있습니다.

요약하면 캐시하는 데이터를 중앙 집중화하면 비용을 절감하고 앱 계층 컴퓨터를보다 효과적으로 조정할 수 있습니다. 데이터 동기화 문제가 줄어들어 데이터의 정확도를 높일 수 있습니다. 이게 도움이 되길 바란다.

Answer 2

먼저, 조숙 한 최적화를 잊어 버리십시오. 캐시가 정말로 필요합니까? 99 %는 필요하지 않습니다. 이 경우 해결 방법은 중복 코드를 제거하는 것입니다.

그러나 필요한 경우 휠 다시 발명을 중지하십시오. 바로 사용할 수있는 완벽한 라이브러리가 있습니다. 예를 들어 ehCache에는 분산 모드가 있습니다.

Answer 3

HazelCast을 사용하십시오. 멀티 캐스트 프로토콜을 사용하는 서버간에 데이터 동기화가 가능합니다. 사용하기 쉽습니다. 잠금 및 기타 기능을 지원합니다.