NCache 아키텍처

피어 투 피어 클러스터(자가 복구)

NCache 클러스터에는 PXNUMXP 클러스터 아키텍처가 있습니다. 이는 마스터/슬레이브 노드가 없으며 각 서버가 피어임을 의미합니다. 클러스터에서 가장 오래된 노드인 클러스터 코디네이터 노드가 있습니다. 클러스터 코디네이터 노드가 다운되면 다음으로 오래된 노드가 자동으로 코디네이터가 됩니다.

클러스터 코디네이터는 노드 추가 또는 제거 시 클러스터 멤버십, 노드 분산 맵 등 클러스터 관련 모든 작업을 관리합니다. 파티션된 캐시 / 파티션 복제본 캐시 토폴로지 및 기타 캐시 구성 정보. 또한 Cluster Coordinator는 클러스터 상태를 관리하고 클러스터의 다른 모든 서버에 부분적으로 연결된 모든 캐시 서버를 강제로 제거합니다.

동적 클러스터링

NCache 있다 동적 클러스터링 아키텍처. 이것은 당신이 할 수 있음을 의미합니다 더하다 or 제거 캐시 또는 애플리케이션을 중지하지 않고 클러스터의 모든 캐시 서버. 캐시 서버를 추가하거나 제거할 때마다 클러스터 멤버십은 런타임 시 즉시 업데이트되고 클러스터에 연결된 모든 클라이언트는 물론 클러스터의 모든 서버에 전파됩니다. 이 런타임 업데이트 및 전파를 통해 NCache 이러한 변경 사항이 적용되는 경우에도 항상 가동 및 실행되도록 합니다.

동적 클러스터링을 사용하면 다음을 수행할 수 있습니다.

• - 런타임 시 캐시 서버 추가/제거: 캐시나 애플리케이션을 중지하지 않고
• - 클러스터 멤버십: 런타임 시 업데이트되어 클러스터의 모든 서버와 클러스터에 연결된 모든 클라이언트에 전파됩니다.

분할 브레인 클러스터 처리

다른 부분 NCache 동적 클러스터링은 지능적입니다. 스플릿 브레인 감지 및 복구 능력. 스플릿 브레인은 본질적으로 일부 네트워킹 문제로 인해 이러한 캐시 서버 간의 네트워크 연결이 끊어지고 이로 인해 각 하위 클러스터가 다른 모든 캐시 서버가 다운되고 올바른 나머지 클러스터라고 가정하는 여러 개의 독립 하위 클러스터가 발생하는 경우 발생합니다. .

그런 경우는, NCache 서버는 다른 캐시 서버가 갑자기 클러스터를 떠난 것을 인식하고 계속해서 해당 서버에 다시 연결하려고 시도합니다. 그런 다음 네트워킹 문제가 사라지면 이러한 NCache 서버는 다른 캐시 서버와 다시 연결할 수 있습니다. 그러나 이제 각 하위 클러스터는 다른 캐시 서버와 동기화하지 않고 병렬로 캐시를 업데이트하므로 하위 클러스터 전체에 여러 버전의 데이터가 존재합니다.

NCache 어떤 캐시 서버가 데이터를 포기해야 하고 다른 캐시 서버가 데이터를 유지해야 하는지 자동으로 결정하여 이러한 "분할 두뇌"에서 복구할 수 있는 방법을 제공합니다. 일부 데이터 손실이 있지만 최종 결과는 사람의 개입 없이 캐시 클러스터를 빠르게 복원하는 것입니다.

동적 클라이언트 연결

NCache 또한 당신을 할 수 있습니다 런타임 시 캐시 클라이언트 추가 또는 제거 캐시나 다른 클라이언트를 중지하지 않고. 클라이언트를 추가할 때 이 클라이언트는 연결할 클러스터의 캐시 서버 중 하나에 대해서만 알아야 합니다. 해당 서버에 연결되면 연결할 다른 서버를 결정하는 기준에 따라 클러스터 멤버십 및 캐싱 토폴로지 정보를 받습니다.

• - 런타임 시 클라이언트 추가/제거: 캐시나 애플리케이션을 중지하지 않고.
• - 분할된 캐시/파티션-복제 캐시: 클라이언트는 모든 캐시 서버의 모든 파티션에 연결합니다(파티션이 해당 복제본과 통신하기 때문에 복제본이 아님). 이를 통해 클라이언트는 읽기 및 쓰기를 위해 데이터가 있는 위치로 직접 이동할 수 있습니다. 그리고 클러스터에 새로운 서버가 추가되면 클라이언트는 업데이트된 클러스터 멤버십 정보를 수신한 후 새로 추가된 캐시 서버에도 연결합니다.
• - 복제된 캐시:의 경우 복제된 캐시, 클라이언트는 클러스터의 하나의 캐시 서버에 연결하지만 모든 캐시 서버에 동일한 수의 클라이언트가 있는지 확인하기 위해 로드 밸런싱 방식으로 연결합니다. 클라이언트는 이 캐시 서버에서 로드 밸런싱 정보를 얻고 이를 기반으로 필요한 경우 적절한 캐시 서버에 다시 연결합니다. 클라이언트는 각 서버에 전체 캐시가 있으므로 모든 읽기 및 쓰기가 바로 그곳에서 가능하기 때문에 클라이언트는 하나의 캐시 서버에만 연결합니다.
• - 미러링된 캐시:의 경우 미러링된 캐시, 클라이언트는 이 2노드 클러스터의 활성 노드에만 연결합니다. 클라이언트가 수동 노드에 연결하면 수동 노드는 클라이언트에게 능동 노드에 대해 알리고 클라이언트는 자동으로 능동 노드에 다시 연결합니다. 활성 노드가 다운되고 수동 노드가 활성이 되면 모든 클라이언트가 자동으로 새 활성 노드에 연결합니다.

동적 구성

NCache 또한 캐시 및 클라이언트의 동적 구성을 제공합니다. 목적은 캐시나 애플리케이션을 중지하지 않고 캐시가 실행 중일 때 나중에 변경할 수 있도록 하는 것입니다.

• - 런타임 시 모든 서버 및 클라이언트에 전파: 여기에는 모든 구성과 변경 사항 및 배포 맵이 포함됩니다.
• - 캐시 구성: 관리 도구를 통해 캐시 구성이 생성되면 이 구성 정보가 당시 알려진 모든 캐시 서버에 복사됩니다. 그리고 런타임 시 추가되는 새 서버는 이 전체 캐시 구성을 수신하여 로컬 디스크에 복사합니다.
• - 핫 적용 구성 변경 사항: 런타임 시 "를 통해 일부 캐시 구성을 변경할 수 있습니다.뜨거운 적용"의 특징 NCache. 그렇게 하면 업데이트된 구성 정보가 런타임 시 모든 캐시 서버에 전파되고 해당 디스크에 저장됩니다. 이 정보의 일부는 또한 그들의 요구와 관련된 모든 클라이언트에게 전송됩니다.
• - 배포 맵(파티션됨/파티션-복제 캐시): 캐시가 시작될 때 생성되어 모든 캐시 서버와 캐시 클라이언트에 복사됩니다. 이 배포 맵에는 어떤 버킷(클러스터 캐시의 총 1000개 버킷 중)이 어떤 파티션에 있는지에 대한 정보가 포함되어 있습니다.

클러스터 내 연결 장애 조치

클러스터의 모든 캐시 서버는 TCP를 통해 서로 연결됩니다. 그리고 모든 캐시 서버는 런타임에 추가된 새 서버를 포함하여 클러스터의 다른 모든 캐시 서버에 연결됩니다. NCache 연결 끊김에도 불구하고 클러스터 내의 모든 연결이 활성 상태로 유지되도록 하는 다양한 방법을 제공합니다. 연결 끊김은 일반적으로 라우터나 방화벽으로 인한 네트워크 결함이나 네트워크 카드 또는 네트워크 드라이버 문제로 인해 발생합니다.

• - 연결 재시도: 두 캐시 서버 간의 연결이 끊어진 경우 NCache 서버는 이 연결을 설정하기 위해 자동으로 여러 번 재시도합니다. 이러한 재시도는 "시간 초과" 기간이 다 될 때까지 수행됩니다. 대부분의 경우 이렇게 하면 연결이 다시 설정됩니다.
• - 연결 유지 하트비트: NCache 또한 각 캐시 서버가 다른 모든 서버에 하트비트로 일부 작은 데이터 패키지를 계속 보내도록 하는 기능이 있습니다. 이렇게 하면 네트워크 소켓 파손 문제가 있는 경우 캐시 서버가 이를 인식하고 재시도를 통해 문제를 해결할 수 있습니다.
• - 부분적으로 연결된 서버: 재시도에도 불구하고 시간 초과 기간 내에 연결이 복원되지 않고 캐시 서버에서 다른 캐시 서버 중 하나 이상이 다운된 것으로 가정하는 경우가 있습니다. 따라서 그것들 없이도 계속 작동합니다. 그러나 실제로는 다른 서버가 다운되지 않았으며 실제로 클러스터의 다른 서버에서 볼 수 있습니다. 이를 부분적으로 연결된 서버라고 합니다. 이런 일이 발생하면 클러스터 조정자는 이를 기록하고 클러스터에서 "부분적으로 연결된" 서버를 강제로 제거합니다. 이렇게 하면 클러스터가 다시 건강해집니다. 또한 제거된 서버는 수동 개입을 통해 클러스터에 다시 참여할 수 있습니다.

클라이언트와의 연결 장애 조치

모든 캐시 클라이언트는 캐싱 토폴로지에 따라 TCP를 통해 클러스터에 있는 하나 이상의 캐시 서버에 연결됩니다. Partitioned / Partition-Replica Cache의 경우 각 클라이언트는 모든 캐시 서버에 연결됩니다. 복제된 캐시의 경우 각 클라이언트는 일반적으로 캐시 서버에서 사용하는 로드 밸런싱 알고리즘을 통해 캐시 서버 중 하나에만 연결됩니다. 그리고 Mirrored Cache의 경우 모든 클라이언트는 Active Node에만 연결되며 Active Node가 다운되어 Passive Node가 Active Node가 될 때만 Passive Node에 연결됩니다.

• - 연결 재시도: 클라이언트와 캐시서버의 연결이 끊어진 경우 NCache 클라이언트가 자동으로 여러 번의 연결 재시도 이 연결을 설정합니다. 이러한 재시도는 "시간 초과" 기간이 소진될 때까지 수행됩니다. 대부분의 경우 클라이언트 응용 프로그램이 알아차리지 못한 채 연결을 다시 설정합니다. 연결을 설정할 수 없으면 클라이언트 응용 프로그램에서 처리할 수 있도록 예외가 throw됩니다.
• - 연결 유지 하트비트: NCache 또한 각 클라이언트가 다음과 같이 작은 데이터 패키지를 계속 보내도록 하는 기능이 있습니다. 심장 박동 연결된 모든 캐시 서버에 이렇게 하면 네트워크 소켓 파손 문제가 있는 경우 클라이언트가 이에 대해 알고 연결 재시도를 통해 문제를 해결할 수 있습니다.
• - 부분적으로 연결된 클라이언트(파티션됨/파티션-복제 캐시): 재시도에도 불구하고 제한 시간 내에 연결이 복원되지 않고 캐시 클라이언트가 다른 캐시 서버 중 하나 이상에 도달할 수 없다고 가정하는 경우가 있습니다. 따라서 Partitioned / Partition-Replica Cache의 경우 분산 맵에서 통신할 수 없는 서버에 데이터가 있다고 알려지더라도 모든 데이터를 읽거나 쓰기 위해 다른 서버와 상호 작용합니다. 이 경우 다른 캐시 서버가 중개자 역할을 하여 해당 작업을 성공적으로 수행하게 됩니다.
• - 서버와의 연결 끊기(복제/미러링 캐시): Replicated Cache의 경우 클라이언트는 하나의 서버에만 연결되며, 이 연결이 끊어지면 클라이언트는 자동으로 다른 캐시 서버 중 하나로 연결됩니다. 미러 캐시의 경우 클라이언트가 Active Node에 연결할 수 없으면 해당 클라이언트가 다운된 것으로 가정하고 Passive Node에 연결을 시도합니다.

캐싱 토폴로지(선형 확장성)

NCache 데이터 일관성과 신뢰성을 유지하면서 선형 확장성을 가능하게 하는 다양한 캐싱 토폴로지를 제공합니다. 이것의 목표는 수십 또는 수백 개의 캐시 서버로 구성된 초대형 캐시 클러스터에 이르기까지 매우 작은 XNUMX-서버 캐시로 실행되는 애플리케이션의 요구 사항을 해결하는 것입니다. 캐싱 토폴로지는 기본적으로 여러 캐시 서버에 걸쳐 있는 클러스터된 캐시의 데이터 저장, 데이터 복제 및 클라이언트 연결 전략입니다.

참조 데이터와 거래 데이터

참조 데이터는 자주 변경되지 않는 데이터이며 계속해서 도달하고 가끔 업데이트하기 위해 캐시합니다. 반면 트랜잭션 데이터는 매우 자주 변경되는 데이터이며 읽을 때마다 업데이트할 수 있습니다.

초기에는 캐시가 주로 참조 데이터용으로 좋은 것으로 간주되었습니다. 자주 변경되는 데이터는 오래되고 데이터베이스의 최신 데이터와 동기화되지 않기 때문입니다. 하지만, NCache 이제 캐시가 캐시된 데이터를 데이터베이스와 동기화된 상태로 유지할 수 있는 매우 강력한 기능을 제공합니다.

모든 캐싱 토폴로지는 참조 데이터에 적합하지만 일부 캐싱 토폴로지는 특히 트랜잭션 데이터에 더 좋습니다. 어떤 토폴로지가 자신에게 가장 적합한지 파악하려면 수행할 읽기 및 쓰기 횟수를 결정해야 합니다. 또한 일부 캐싱 토폴로지는 특히 업데이트에 대해 그다지 확장되지 않으므로 이 점을 염두에 두십시오.

다음은 읽기 대 쓰기에 미치는 영향과 함께 캐싱 토폴로지 목록입니다.

• - 분할된 캐시(복제 없음): 아주 좋아요. 읽기 및 쓰기 모두에 대해 초고속이며 서버를 추가하여 선형적으로 확장됩니다. 가장 빠른 토폴로지이지만 데이터를 복제하지 않으므로 캐시 서버가 다운되면 데이터가 손실됩니다.
• - 파티션 복제본 캐시 (가장 인기 많은): 아주 좋아요. 읽기와 쓰기 모두 매우 빠르며 서버를 추가하여 선형적으로 확장할 수도 있습니다. 두 번째로 빠른 토폴로지이지만 선형 확장성을 저하시키지 않고 안정성을 위해 데이터를 복제합니다. 속도/확장성 및 데이터 안정성의 최상의 조합입니다.
• - 복제된 캐시: 소규모 환경에 매우 적합. 매우 빠르고 선형적으로 확장 가능한 읽기 기능을 제공합니다. 2노드 클러스터의 쓰기 속도는 약간 빠르지만 모든 캐시 서버에서 쓰기가 동기식으로 수행되므로 서버를 추가해도 확장되지 않습니다.
• - 미러링된 캐시: 소규모 환경에 매우 적합합니다. 읽기 속도가 매우 빠릅니다. 2노드 액티브/패시브의 경우 복제 캐시보다 쓰기가 더 빠릅니다. 그러나 이 이상으로 확장되지는 않습니다.
• - 클라이언트 캐시: 읽기 집약적인 사용에 매우 좋습니다. 모든 캐싱 토폴로지를 사용합니다. 분산 캐시를 사용하여 InProc 속도를 달성할 수 있습니다.

파티션된 캐시

Partitioned Cache는 읽기 및 쓰기 모두에 대해 가장 빠르고 확장 가능한 캐싱 토폴로지입니다. 더 큰 캐시 클러스터를 위한 것이며 최대 로드에서도 읽기 및 쓰기 성능이 매우 우수합니다. 그러나 데이터를 복제하지 않으므로 캐시 서버가 다운되면 데이터가 손실됩니다.

다음은 파티션된 캐시의 몇 가지 특징입니다.

• - 동적 파티션: 캐시는 런타임 시 파티션으로 나누어지며 각 캐시 서버는 하나의 파티션을 갖습니다. 모든 파티션에 균등하게 배포되는 클러스터형 캐시당 총 1000개의 버킷이 있습니다. 캐시 서버를 추가/제거하면 런타임 시 파티션이 생성/삭제됩니다. 데이터가 캐시에 추가될 때 파티션에 대한 버킷 할당은 변경되지 않습니다. 대신 파티션이 추가 또는 삭제되거나 데이터 밸런싱이 발생할 때만 변경됩니다(아래 참조).
• - 분포도: 캐시 클러스터는 어떤 버킷이 어떤 파티션에 있는지에 대한 정보가 포함된 분포 맵을 생성합니다. 분산 맵은 파티션이 추가되거나 삭제될 때마다 또는 데이터 밸런싱이 발생할 때 업데이트됩니다(아래 참조). 배포 맵은 모든 서버와 클라이언트에 전파됩니다. 클라이언트는 이를 사용하여 특정 캐시된 항목을 읽거나 쓰기 위해 통신할 캐시 서버를 파악합니다.
• - 동적 데이터 밸런싱: 모든 버킷은 실제로 키의 해싱 알고리즘을 기반으로 데이터가 저장되는 HashMap 버킷이므로 사용된 키에 따라 일부 버킷이 다른 버킷보다 더 많은 데이터를 가질 가능성이 있습니다. 불균형이 구성 가능한 임계값을 초과한 경우, NCache 이 부하의 균형을 맞추기 위해 자동으로 버킷을 이동합니다.
• - 클라이언트는 모든 파티션에 연결: 클라이언트는 모든 캐시 서버에 연결되므로 서버의 한 요청으로 데이터를 직접 읽거나 쓸 수 있습니다. 클라이언트와 캐시 서버의 연결이 끊어지면 클라이언트는 액세스할 수 없는 서버에 존재하는 캐시된 항목을 읽거나 쓰도록 다른 서버 중 하나에 요청합니다. 그리고 해당 서버는 클라이언트가 이를 달성하도록 돕습니다.

파티션 복제본 캐시

참고: 분할 캐시에 언급된 모든 내용은 여기에서도 마찬가지입니다.

처럼 파티션된 캐시, Partition-Replica Cache는 읽기와 쓰기 모두에 대해 매우 빠르고 선형적으로 확장 가능한 캐싱 토폴로지입니다. 더 큰 캐시 클러스터를 위한 것이며 최대 로드에서도 읽기 및 쓰기 성능이 매우 우수합니다. 또한 Partition-Replica Cache도 데이터를 복제하므로 캐시 서버가 다운되어도 데이터 손실이 없습니다.

파티션 복제본 캐시는 가장 인기 있는 캐싱 토폴로지 성능/선형 확장성 및 데이터 안정성의 두 가지 장점을 모두 제공하기 때문입니다.

다음은 Partition-Replica Cache의 몇 가지 특징입니다.

• - 동적 파티션: 분할된 캐시와 동일합니다.
• - 동적 복제본: 런타임 시 파티션이 생성되거나 삭제되면 해당 복제본도 생성되거나 삭제됩니다. 복제본은 항상 다른 캐시 서버에 있으며 파티션당 하나의 복제본만 있습니다.
• - 비동기 복제: 기본적으로 파티션에서 복제본으로의 복제는 비동기식입니다. 이는 클라이언트가 파티션의 모든 데이터를 추가, 업데이트 또는 삭제할 수 있으며 이러한 모든 작업이 대기열에 추가된다는 의미입니다. 그런 다음 복제본에서 BULK로 복제되었습니다. 이렇게 하면 성능이 향상되지만 파티션이 작동하고 모든 업데이트가 복제본에 복제되지 않은 경우 데이터 손실 위험이 약간 있습니다. 그러나 대부분의 상황에서는 이는 완벽하게 괜찮습니다.
• - 동기화 복제: 데이터가 매우 중요하고(예: 금융 데이터) 오래된 데이터를 보유할 수 없는 경우 구성에서 "동기화 복제" 옵션을 선택할 수 있습니다. 선택하면 모든 쓰기 작업이 완료된 것으로 간주될 때까지 파티션과 복제본 모두에서 동기적으로 수행됩니다. 이렇게 하면 복제본에서 작업이 실패하면 파티션에서도 실패합니다. 또한 캐시(파티션과 복제본 모두)의 모든 데이터가 항상 일관된다는 것을 보장할 수 있습니다. 그러나 이는 비동기 복제보다 느리기 때문에 성능에 영향을 미칩니다.
• - 분포도: 분할된 캐시와 동일합니다.
• - 동적 데이터 밸런싱(파티션 및 복제본): 분할된 캐시와 동일합니다. 그러나 파티션-복제본 캐시에서는 파티션이 데이터 밸런싱될 때 복제본에서도 데이터 밸런싱이 발생합니다.
• - 클라이언트는 모든 파티션에 연결: 분할된 캐시와 동일합니다. 또한 파티션-복제본 캐시에서 클라이언트는 복제본이 아닌 파티션과만 통신합니다. 이는 복제본이 수동적이며 데이터를 복제할 때 파티션만 복제본과 통신하기 때문입니다.

복제된 캐시

복제된 캐시는 두 개 이상의 캐시 서버에 복제를 통해 데이터 신뢰성을 제공합니다. 매우 빠르고 읽기 확장성이 뛰어납니다. 그러나 쓰기는 클러스터의 모든 서버와 동기식이므로 쓰기에 맞게 확장되지 않습니다. 2노드 클러스터의 경우 쓰기 속도는 데이터베이스보다 빠르지만 파티션 복제본 캐시만큼 빠르지는 않습니다. 3개 이상의 서버 클러스터의 경우 쓰기 성능이 저하되어 결국 매력이 없게 됩니다.

다음은 복제된 캐시의 몇 가지 특징입니다.

• - 동적 복제 노드: 캐시나 애플리케이션을 중지하지 않고도 런타임 시 기존 캐시에 캐시 서버를 추가하거나 제거할 수 있습니다. 새로 추가된 서버는 전체 캐시의 복사본(복제본)을 자신에게 만듭니다. 그리고 제거된 서버는 클러스터 구성원을 업데이트하고 모든 클라이언트는 다른 서버로 이동합니다.
• - 각 노드의 전체 캐시: 전체 캐시가 클러스터의 모든 서버에 복사됩니다.
• - 읽기는 확장 가능합니다.: 서버를 더 추가하면 읽기가 매우 빠르고 확장 가능합니다. 그러나 새로 추가된 서버는 전체 캐시의 또 다른 복사본이므로 서버를 더 추가해도 캐시 크기는 늘어나지 않습니다.
• - 쓰기는 동기식입니다.: 2노드 클러스터의 경우 쓰기 속도가 매우 빠르고 데이터베이스보다 빠릅니다. 그러나 쓰기는 동기식입니다. 즉, 모든 캐시 서버가 동기식으로 업데이트될 때까지 각 쓰기 작업이 완료되지 않습니다. 이로 인해 쓰기 속도가 다른 토폴로지만큼 빠르지 않으며 클러스터 크기를 2노드 이상으로 늘리면 성능이 저하됩니다.
• - 클라이언트는 하나의 서버에만 연결됩니다.: 각 캐시 클라이언트는 캐시 서버에 의해 결정된 로드 밸런싱 알고리즘을 기반으로 클러스터의 하나의 서버에만 연결됩니다. 이 캐시 서버가 다운되면 클라이언트는 목록의 다음 서버에 연결됩니다. 로드 밸런싱을 사용하지 않으려면 캐시 구성 파일에서 연결할 서버를 수동으로 지정할 수도 있습니다.

미러링된 캐시

미러링 캐시는 소규모 환경을 위한 2노드 액티브/패시브 캐시 클러스터입니다. Active Node에서 Passive Node로의 비동기 복제/미러링을 통해 데이터 신뢰성을 제공합니다. 읽기와 쓰기 모두 매우 빠르지만(실제로 쓰기는 복제된 캐시보다 빠릅니다) 이 2노드 액티브/패시브 클러스터 이상으로 확장되지는 않습니다.

다음은 Mirrored Cache의 몇 가지 특징입니다.

• - 활성 서버 1개 및 수동 서버 1개: 미러링 캐시에는 서버가 두 개만 있습니다. 하나는 능동형이고 다른 하나는 수동형입니다. 둘 다 전체 캐시의 복사본을 가지고 있습니다. Active 서버가 다운되면 Passive 서버는 자동으로 Active 서버가 됩니다. 그리고 이전에 다운된 Active Server가 다시 작동하는 경우 런타임 시 관리 도구를 통해 이 지정을 변경하지 않는 한 Passive Server로 처리됩니다.
• - 장애 조치 지원을 통한 클라이언트 연결: 각 캐시 클라이언트는 읽기 및 쓰기 작업을 수행하기 위해 클러스터의 Active Server에만 연결합니다. 이 Active Server가 다운되면 모든 클라이언트는 현재 Active가 된 Passive Server에 자동으로 연결됩니다. 이 장애 조치 지원을 통해 서버가 다운되더라도 미러 캐시가 항상 가동되어 실행됩니다.
• - 비동기 미러링: Active Server에서 수행된 모든 쓰기는 Passive Server에 비동기식으로 미러링/복제됩니다. 이렇게 하면 Active Server가 다운되어 Passive Server가 Active로 전환되어야 하는 경우 Passive Server가 항상 최신 데이터와 동기화됩니다. 또한 비동기 미러링은 수동 서버에서 여러 쓰기가 대량 작업으로 수행되므로 성능이 더 빨라진다는 것을 의미합니다.

클라이언트 캐시(InProc 속도)

클라이언트 캐시는 웹/앱 서버에 로컬이며 애플리케이션과 매우 가깝고 분산 캐시(모든 캐싱 토폴로지)에서 읽고 있는 데이터를 캐시할 수 있습니다. 이것을 "캐시 위의 캐시"로 볼 수 있으며 애플리케이션 성능과 확장성을 훨씬 더 크게 향상시킵니다. InProc 모드에서 Client Cache를 사용하면 InProc 속도를 얻을 수 있습니다.

애플리케이션에 로컬인 동안 클라이언트 캐시는 독립 실행형이 아닙니다. 대신 항상 클러스터된 캐시와 동기화됩니다. 이렇게 하면 클라이언트 캐시의 데이터가 오래되지 않습니다.

다음은 Mirrored Cache의 몇 가지 특징입니다.

• - 읽기 집약적인 사례에 적합: 클라이언트 캐시는 읽기 횟수가 쓰기 횟수보다 몇 배 더 많은 읽기 집약적 사용 사례의 경우에만 유용합니다. 쓰기 횟수가 읽기 횟수와 동일한 경우 쓰기에는 두 위치에서 업데이트가 포함되므로 클라이언트 캐시가 실제로 느려집니다.
• - 로컬 캐시처럼 빠른 속도(InProc / OutProc): 클라이언트 캐시는 애플리케이션 프로세스 내부(InProc 모드) 또는 웹/앱 서버 로컬(OutProc 모드)에 존재합니다. 두 경우 모두 클러스터 캐시에서 이 데이터를 가져오는 것보다 애플리케이션 성능이 크게 향상됩니다. InProc 모드를 사용하면 "응용 프로그램 힙"에 개체를 캐시할 수 있으며, 이는 분산 캐시와 일치할 수 없는 "InProc 속도"를 제공합니다.
• - 독립형 캐시가 아님: 클라이언트 캐시는 로컬 캐시일 수 있지만 독립형 캐시는 아닙니다. 대신 클러스터된 캐시와 동기화된 상태를 유지합니다. 이것이 의미하는 바는 다른 클라이언트가 클라이언트 캐시에 있는 클러스터 캐시의 데이터를 업데이트하는 경우 클러스터 캐시는 해당 데이터의 최신 복사본으로 자체 업데이트하도록 클라이언트 캐시에 알린다는 것입니다. 그리고 이는 비동기식이지만 즉시 수행됩니다.
• - 낙관적/비관적 동기화: 기본적으로 클라이언트 캐시는 낙관적 동기화를 사용합니다. NCache 클라이언트는 클라이언트 캐시에 있는 모든 데이터가 최신 복사본이라고 가정합니다. 클라이언트 캐시에 데이터가 없으면 클라이언트는 클러스터된 캐시에서 데이터를 가져와 클라이언트 캐시에 넣은 다음 클라이언트 응용 프로그램에 반환합니다. 비관적 동기화는 캐시 클라이언트가 먼저 클러스터된 캐시에 최신 버전의 캐시된 항목이 있는지 확인하는 것을 의미합니다. 그렇다면 클라이언트는 이를 가져와 클라이언트 캐시에 넣은 다음 클라이언트 응용 프로그램에 반환합니다. 그렇지 않으면 클라이언트 캐시에 있는 모든 것을 반환합니다.
• - 코드 변경 없이 플러그인: 클라이언트 캐시의 가장 좋은 점은 애플리케이션에서 코드 변경이 필요하지 않다는 것입니다. 대신 구성 변경을 통해 간단히 연결하면 됩니다. 그리고, NCache 백그라운드에서 클라이언트 API는 클라이언트 캐시 사용에 대해 무엇을 해야 하는지 알고 있습니다.

다음에 무엇을할지?

• NCache 세부 정보
• 다운로드 NCache
• 판 비교