NCache 아키텍처

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

NCache 클러스터는 피어 투 피어(P2P) 클러스터 아키텍처를 사용합니다. 즉, 마스터/슬레이브 노드가 없으며 각 서버가 피어 역할을 합니다. 그러나 고객 코디네이터는 클러스터에서 가장 오래된 노드입니다. 고객 코디네이터가 다운되면 다음으로 오래된 노드가 자동으로 코디네이터 역할을 수행합니다.

이 클러스터 코디네이터는 모든 클러스터 작업과 기타 캐시 구성 정보를 관리합니다. 또한 클러스터 상태를 관리하고 클러스터 내 다른 서버에 부분적으로만 연결된 캐시 서버를 강제로 제거합니다.

동적 클러스터링

핵심 NCache 고가용성은 동적 클러스터링을 통해 구현되며, TCP를 통해 실시간으로 멤버십 변경 사항을 전파하여 서버 추가 또는 제거 시 다운타임이 발생하지 않습니다. 앞서 논의한 바와 같이, NCache 있다 동적 클러스터링 아키텍처. 이것은 허용 NCache 이러한 변경 사항이 적용되는 경우에도 항상 가동 및 실행되도록 합니다.

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

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

분할 브레인 클러스터 처리

NCache 지능형 감지 알고리즘을 사용하여 분산된 하위 클러스터를 자동으로 조정하고 수동 개입 없이 데이터 무결성을 복원함으로써 스플릿 브레인 시나리오를 해결합니다. NCache 동적 클러스터링은 지능형 분할 뇌 감지 및 복구 기능. 스플릿 브레인(Split Brain)은 네트워크 문제로 인해 캐시 서버 간의 연결이 끊어질 때 발생합니다. 이로 인해 여러 개의 독립적인 하위 클러스터가 형성되고, 각 하위 클러스터는 다른 클러스터가 다운되어 자신만 남은 클러스터라고 가정합니다.

이러한 경우 캐시 서버가 클러스터를 갑자기 떠나면 나머지 NCache 서버는 계속해서 재연결을 시도합니다. 하지만 이 과정에서 각 하위 클러스터는 데이터를 독립적으로 업데이트하여 동기화되지 않은 여러 버전의 데이터를 생성합니다.

네트워크 문제가 해결된 후, NCache Split Brain을 자동으로 트리거합니다. 이는 어떤 캐시 서버가 데이터를 유지할지(승자)와 어떤 서버가 데이터를 포기할지(패자)를 자동으로 결정함으로써 수행됩니다. 이는 패배한 클러스터의 서버가 승리한 클러스터에 새로운 노드로 다시 합류해야 하기 때문에 필수적입니다. 일부 데이터 손실은 발생하지만, 결과적으로 사용자의 개입 없이 캐시 클러스터를 빠르게 복구할 수 있습니다.

동적 클라이언트 연결

NCache 또한 당신을 할 수 있습니다 추가 또는 제거 캐시나 다른 클라이언트를 중단하지 않고 런타임에 클라이언트를 연결합니다. 클라이언트를 추가하면 클러스터에 있는 캐시 서버 하나만 연결하면 됩니다. 해당 서버에 연결되면 필요한 클러스터 멤버십 및 캐싱 토폴로지 정보를 수신합니다. 그런 다음 연결할 다른 서버를 결정합니다.

• - 분할/파티션-복제 캐시: 클라이언트는 모든 캐시 서버 파티션에 연결합니다(레플리카는 해당 파티션과만 통신하므로 레플리카는 연결하지 않습니다). 이를 통해 클라이언트는 읽기 및 쓰기 작업에 적합한 파티션을 지정할 수 있습니다. 또한, 클러스터에 새 서버가 추가되면 클라이언트는 업데이트된 클러스터 멤버십 정보를 수신하고 새로 추가된 서버에도 연결합니다.
• - 복제된 캐시: 의 경우 복제된 캐시클라이언트는 클러스터 내 하나의 캐시 서버에만 연결하지만, 모든 캐시 서버에 동일한 수의 클라이언트가 할당되도록 부하 분산 방식으로 연결합니다. 따라서 모든 읽기 및 쓰기는 하나의 캐시 서버에서 가능합니다. 클러스터에 새 서버가 추가되면 클라이언트는 캐시 서버에서 이 정보를 가져오고 필요한 경우 새 서버에 다시 연결합니다.
• - 미러링된 캐시: 의 경우 미러링된 캐시클라이언트는 이 2노드 클러스터에서 유일한 활성 노드에만 연결합니다. 클라이언트가 패시브 노드에 연결하면, 패시브 노드는 클라이언트에게 활성 노드에 대한 정보를 제공하고, 클라이언트는 자동으로 활성 노드에 다시 연결합니다. 활성 노드가 다운되고 패시브 노드가 활성 노드로 전환되면 모든 클라이언트가 자동으로 새 활성 노드에 연결합니다.

동적 구성

동적 클라이언트 연결 및 동적 클러스터링 섹션에서 언급했듯이 NCache 캐시와 클라이언트의 동적 구성을 제공합니다. 이 섹션에서는 이 런타임 구성의 작동 방식을 설명합니다.

• - 캐시 구성: 관리 도구를 통해 캐시가 생성되면 이 구성 정보는 해당 시점에 알려진 모든 캐시 서버에 복사됩니다. 마찬가지로, 런타임에 클러스터에 추가되는 모든 새 서버는 업데이트된 전체 캐시 구성을 수신하여 로컬 디스크에 복사합니다.
• - 핫 적용 구성 변경 사항: "Hot Apply"를 통해 일부 캐시 구성을 런타임에 변경할 수 있습니다. 예를 들어, 캐시 크기 또는 활성화 압축이 경우, 업데이트된 구성 정보는 런타임에 모든 캐시 서버에 전파되어 디스크에 저장됩니다. 필요에 따라 이 정보의 일부가 모든 클라이언트에도 전송됩니다.
• - 배포 맵(파티션/파티션-복제 캐시): 캐시가 시작될 때 생성되어 모든 캐시 서버와 클라이언트에 복사됩니다. 이 배포 맵에는 클러스터링된 캐시에 있는 총 1000개의 버킷 중 어떤 버킷이 어떤 파티션에 있는지에 대한 정보가 포함되어 있습니다.

클러스터 내 연결 장애 조치

클러스터의 모든 캐시 서버는 TCP를 통해 연결됩니다. 또한, 모든 캐시 서버는 런타임에 추가된 새 서버를 포함하여 클러스터의 다른 모든 캐시 서버와 연결됩니다. NCache 클러스터 내의 모든 연결이 올바르게 유지되도록 다양한 방법을 제공합니다. 살아있게 하다 연결 실패에도 불구하고 발생합니다. 이러한 실패는 일반적으로 라우터, 방화벽 또는 네트워크 카드/드라이버 문제로 인한 네트워크 장애로 인해 발생합니다.

• - 연결 재시도: 두 캐시 서버 간의 연결이 끊어지면, NCache 이 연결을 다시 설정하기 위해 자동으로 여러 번 재시도를 시도합니다. 재시도 사용자가 지정한 시간 초과 기간 동안 발생합니다.
• - 연결 유지 하트비트: NCache 각 캐시 서버가 다른 모든 서버에 소량의 데이터 패키지를 하트비트로 계속 전송하는 기능도 있습니다. 이를 통해 네트워크 소켓 문제가 발생할 경우 캐시 서버가 이를 감지하고 재시도를 통해 문제를 해결할 수 있습니다.
• - 부분적으로 연결된 서버: 어떤 경우에는 네트워크 문제로 인해 클러스터가 하위 클러스터("스플릿 브레인"). NCache 네트워크가 복구되면 자동으로 이를 감지하고 해결하여 어느 클러스터가 데이터를 보관할지 결정하고 다른 클러스터는 다시 가입하도록 요구합니다.

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

클라이언트의 연결 장애 조치는 클러스터 장애 조치 재시도, 하트비트, 정상 서버에 대한 자동 재연결과 유사합니다.

• - 연결 재시도: 장애 조치 측면에서 연결 재시도는 클러스터 수준과 클라이언트 수준에서 동일합니다. 그러나 클라이언트와 캐시 서버 간의 연결이 끊어지면 NCache 클라이언트가 자동으로 여러 번의 연결 재시도 연결을 설정하기 위해. 이러한 재시도는 시간 초과 기간 동안 발생합니다. 연결을 설정할 수 없는 경우, 클라이언트 애플리케이션에서 처리할 수 있도록 예외가 발생합니다.
• - 연결 유지 하트비트: 클러스터 내 연결 장애 조치와 동일합니다.
• - 부분적으로 연결된 클라이언트(파티션됨/파티션-복제 캐시): 재시도에도 불구하고 연결이 제때 복구되지 않는 경우가 있어, 클라이언트는 다른 서버에 실제로 접속할 수 없는 것으로 간주합니다. 따라서 분할/분할 복제 캐시의 경우, Distribution Map에 해당 서버가 데이터를 가지고 있다고 표시되어 있음에도 불구하고 다른 서버와 상호 작용하여 모든 데이터를 읽거나 씁니다. 이 경우, 다른 캐시 서버가 중개자 역할을 하여 성공적으로 작동합니다.

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

NCache 데이터 일관성과 안정성을 유지하면서 선형 확장성을 구현하는 다양한 캐싱 토폴로지를 제공합니다. 목표는 소규모 2개 서버 캐시부터 수백 대의 서버로 구성된 대규모 클러스터까지 다양한 애플리케이션을 지원하는 것입니다. 캐싱 토폴로지는 기본적으로 여러 캐시 서버로 구성된 클러스터 캐시에서 데이터 저장, 데이터 복제 및 클라이언트 연결 전략을 구현하는 것입니다.

참조 데이터와 거래 데이터

참조 데이터는 자주 변경되지 않으므로, 빈번한 요청에 대응하고 비용이 많이 드는 데이터베이스 재시작을 방지하기 위해 캐시에 저장하고 가끔씩만 업데이트합니다. 반면, 트랜잭션 데이터는 매우 자주 변경되는 데이터이므로 읽는 빈도만큼 자주 업데이트할 수 있습니다.

초창기에는 캐시가 주로 참조 데이터에 사용되었습니다. 자주 변경되는 데이터는 오래되어 데이터베이스의 최신 데이터와 동기화되지 않기 때문입니다. 그러나 NCache 이제 캐시가 캐시된 데이터를 데이터베이스와 동기화된 상태로 유지할 수 있는 매우 강력한 기능을 제공합니다.

모든 NCache의 캐싱 토폴로지는 참조 데이터에 적합하지만, 일부는 트랜잭션 데이터에 특히 유용합니다. 따라서 어떤 토폴로지가 가장 적합한지 파악하려면 읽기와 쓰기의 양을 결정해야 합니다. 또한, 일부 캐싱 토폴로지는 특히 업데이트 시 확장성이 떨어지므로 이 점도 염두에 두어야 합니다.

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

• - 분할된 캐시(복제 없음): 이것은 가장 빠른 토폴로지이지만, 데이터를 복제하지 않으므로 캐시 서버가 다운되면 데이터가 손실됩니다.
• - 파티션 복제본 캐시 (가장 인기 많은): 이 토폴로지는 읽기와 쓰기 모두 매우 빠릅니다. 또한, 안정성을 위해 데이터를 복제하여 성능 저하 없이 데이터를 처리합니다. 속도/확장성과 데이터 안정성의 최적의 조합입니다.
• - 복제된 캐시: 소규모 환경에 매우 적합합니다. 각 서버는 캐시의 전체 백업을 유지하여 높은 데이터 안정성과 내결함성을 보장합니다. 읽기 속도는 매우 빠르고 선형적으로 확장 가능합니다. 2노드 클러스터에서는 쓰기 속도가 적당히 빠르지만, 모든 캐시 서버에서 쓰기가 동기적으로 수행되므로 서버를 추가해도 확장되지 않습니다.
• - 미러링된 캐시: 이 토폴로지는 소규모 환경에 매우 적합합니다. 2노드 액티브/패시브 환경에서 복제 캐시보다 쓰기 작업이 더 빠릅니다. 하지만 이 이상으로 확장할 수는 없습니다.
• - 클라이언트 캐시: 모든 캐싱 토폴로지를 사용하는 읽기 집약적인 사용 사례에 매우 적합합니다. 분산 캐시를 통해 InProc 속도를 달성할 수 있습니다.

파티션된 캐시

분할 캐시는 읽기와 쓰기 모두에서 가장 빠르고 확장성이 뛰어난 캐싱 토폴로지입니다. 대규모 클러스터용으로 설계되었으며, 최대 부하 상황에서도 빠른 읽기 및 쓰기를 제공합니다. 하지만 데이터를 복제하지 않으므로 서버 장애 발생 시 백업이 제공되지 않습니다.

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

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

파티션 복제본 캐시

참고: Partitioned Cache에서 언급된 내용은 여기에도 모두 해당됩니다.

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

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

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

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

복제된 캐시

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

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

• - 동적 복제 노드: 캐시나 애플리케이션을 중단하지 않고 런타임에 기존 캐시에 캐시 서버를 추가하거나 제거할 수 있습니다. 새로 추가된 서버는 전체 캐시의 복사본(복제본)을 자체에 생성합니다. 제거된 서버는 클러스터 멤버십을 업데이트하고 모든 클라이언트는 다른 서버로 이동합니다.
• - 각 노드의 전체 캐시: 전체 캐시가 클러스터의 모든 서버에 복사됩니다.
• - 읽기는 확장 가능합니다.: 서버를 추가하면 읽기 속도가 매우 빠르고 확장성이 뛰어납니다. 하지만 서버를 추가해도 캐시 크기는 늘어나지 않습니다. 새로 추가된 서버는 전체 캐시의 또 다른 복사본일 뿐이기 때문입니다.
• - 쓰기는 동기식입니다.: 2노드 클러스터의 경우 쓰기 속도가 매우 빠르며 데이터베이스보다 빠릅니다. 하지만 쓰기는 동기식이므로 모든 캐시 서버가 동기적으로 업데이트될 때까지 각 쓰기 작업이 완료되지 않습니다. 따라서 쓰기 속도가 다른 토폴로지만큼 빠르지는 않습니다.
• - 클라이언트는 하나의 서버에만 연결됩니다.: 각 캐시 클라이언트는 캐시 서버에서 결정한 부하 분산 알고리즘에 따라 클러스터 내 한 서버에만 연결합니다. 해당 캐시 서버에 장애가 발생하면 클라이언트는 목록의 다음 서버에 연결합니다. 부하 분산을 사용하지 않으려면 캐시 구성 파일에서 연결할 서버를 수동으로 지정할 수도 있습니다.

미러링된 캐시

Mirrored Cache는 소규모 환경을 위한 2노드 액티브/패시브 캐시 클러스터입니다. 액티브 노드에서 패시브 노드로의 비동기 복제/미러링을 통해 데이터 안정성을 제공합니다. 읽기와 쓰기 모두 매우 빠르지만(실제로 쓰기 작업은 Replicated Cache보다 빠름), 이 2노드 액티브/패시브 클러스터를 넘어 확장할 수는 없습니다.

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

• - 활성 서버 1개 및 수동 서버 1개: 미러 캐시에는 두 대의 서버만 있습니다. 하나는 활성 서버이고 다른 하나는 수동 서버입니다. 두 서버 모두 전체 캐시의 사본을 가지고 있습니다. 활성 서버가 다운되면 수동 서버가 자동으로 활성 서버로 전환됩니다. 이전에 다운된 활성 서버가 다시 활성화되면 런타임에 관리 도구를 통해 이 지정을 변경하지 않는 한 수동 서버로 처리됩니다.
• - 장애 조치 지원을 통한 클라이언트 연결: 각 캐시 클라이언트는 읽기 및 쓰기 작업을 위해 클러스터 내 활성 서버에만 연결합니다. 이 활성 서버에 장애가 발생하면 모든 클라이언트는 자동으로 활성 상태가 된 수동 서버에 연결합니다. 이러한 장애 조치 지원은 서버가 다운되더라도 미러링된 캐시가 항상 작동하도록 보장합니다.
• - 비동기 미러링: 액티브 서버에서 수행되는 모든 쓰기 작업은 패시브 서버에 비동기적으로 미러링/복제됩니다. 이를 통해 액티브 서버가 다운되어 패시브 서버가 활성화되어야 하는 경우에도 패시브 서버가 항상 최신 데이터와 동기화됩니다. 비동기 미러링은 패시브 서버에서 여러 쓰기 작업이 대량으로 수행되므로 성능 향상을 의미합니다.

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

클라이언트 캐시는 웹/앱 서버에 로컬로 존재하며 애플리케이션과 매우 가까이 위치하여, 캐싱 토폴로지에 관계없이 분산 캐시에서 읽는 데이터를 캐싱할 수 있습니다. 클라이언트 캐시는 애플리케이션에 로컬로 존재하지만, 독립형이 아닙니다. 대신 항상 클러스터형 캐시와 동기화됩니다. 이를 통해 클라이언트 캐시의 데이터가 최신 상태가 유지됩니다.

이를 "캐시 위의 캐시"라고 볼 수 있으며, 애플리케이션 성능과 확장성을 더욱 향상시킵니다. InProc 모드에서 클라이언트 캐시를 사용하면 InProc 속도를 얻을 수 있습니다. NCache 일반 및 전체 데이터 클라이언트 캐시, 두 가지 유형의 클라이언트 캐시를 제공합니다. 각 유형은 클러스터형 캐시와 동기화를 유지하면서 네트워크 호출을 줄여 성능을 향상시키도록 설계되었습니다.

일반 클라이언트 캐시

일반 클라이언트 캐시는 클라이언트 머신에서 로컬(L1) 캐시 역할을 하며, 자주 액세스하는 데이터의 하위 집합을 애플리케이션 가까이에 보관합니다. 이를 통해 클러스터형 캐시(L2)로의 반복적인 네트워크 접속을 줄일 수 있습니다. 일관성 유지를 위해 클라이언트 캐시는 변경 알림을 수신하여 클러스터형 캐시와 동기화 상태를 유지합니다. 전체 데이터 세트를 보관하지 않으므로 모든 쿼리는 클러스터형 캐시(L2)를 대상으로 실행됩니다.

전체 데이터 클라이언트 캐시

전체 데이터 클라이언트 캐시는 한 단계 더 나아가 전체 데이터 세트를 클라이언트 머신에 로컬로 캐싱합니다. 다음과 같은 이점과 옵션을 제공합니다.

• - 전체 데이터 세트를 로컬로 캐시합니다.: 선택된 .NET 클래스의 모든 항목을 캐시하여 전체 데이터 세트를 즉시 사용할 수 있도록 합니다.
• - 근접 인프로크 속도: 전체 데이터 클라이언트 캐시는 더 빠른 읽기 작업을 제공하고 전체 데이터 세트가 로컬에 존재하므로 SQL 쿼리가 클라이언트 캐시에서 전적으로 실행될 수 있습니다.
• - 클러스터형 캐시와의 동기화: 일관성을 보장하기 위해 클러스터된 캐시와 완전히 동기화됩니다.
• - 엄격한 질의 시행: 이 적용을 통해 전체 데이터 세트를 로컬에서 사용할 수 있을 때만 쿼리가 실행됩니다. 데이터 세트가 부분적으로 로드된 경우, 쿼리는 클러스터형 캐시로 돌아가지 않고 즉시 실패합니다.
• - 엄격한 지역 읽기: 이렇게 하면 모든 읽기 작업이 클라이언트 캐시에서만 처리됩니다. 로컬에서 키를 찾을 수 없으면 클러스터 캐시에서 가져오는 대신 캐시 미스를 반환합니다.

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

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

• - 읽기 집약적인 사례에 적합: 클라이언트 캐시는 읽기 작업이 많은 사용 사례에 적합합니다. 하지만 쓰기 횟수와 읽기 횟수가 같으면 쓰기 작업 시 두 곳에서 데이터를 업데이트해야 하므로 클라이언트 캐시가 실제로 더 느립니다.
• - 로컬 캐시처럼 빠른 속도(InProc / OutProc): 클라이언트 캐시는 애플리케이션 프로세스 내부(InProc 모드) 또는 웹/앱 서버 로컬(OutProc 모드)에 존재합니다. 두 경우 모두 클러스터형 캐시에서 데이터를 가져오는 것보다 애플리케이션 성능을 크게 향상시킵니다. InProc 모드를 사용하면 "애플리케이션 힙"에 객체를 캐시할 수 있어 어떤 분산 캐시도 따라올 수 없는 "InProc 속도"를 제공합니다.
• - 독립형 캐시가 아님: 클라이언트 캐시는 로컬 캐시일 수 있지만, 독립형 캐시는 아닙니다. 클러스터형 캐시와 동기화됩니다. 즉, 다른 클라이언트가 클라이언트 캐시에 있는 클러스터형 캐시의 데이터를 업데이트하면, 클러스터형 캐시는 클라이언트 캐시에 해당 데이터의 최신 복사본으로 업데이트하도록 알립니다. 이 작업은 비동기적으로 즉시 수행됩니다.
• - 낙관적/비관적 동기화: 기본적으로 클라이언트 캐시는 낙관적 동기화를 사용합니다. 즉, NCache 클라이언트는 클라이언트 캐시에 있는 모든 데이터가 최신 사본이라고 가정합니다. 클라이언트 캐시에 데이터가 없으면 클라이언트는 클러스터 캐시에서 데이터를 가져와 클라이언트 캐시에 저장한 후 클라이언트 애플리케이션으로 반환합니다. 비관적 동기화는 캐시 클라이언트가 먼저 클러스터 캐시에 캐시된 항목의 최신 버전이 있는지 확인합니다. 최신 버전이 있으면 클라이언트는 해당 항목을 가져와 클라이언트 캐시에 저장한 후 클라이언트 애플리케이션으로 반환합니다. 그렇지 않으면 클라이언트 캐시에 있는 모든 내용을 반환합니다.
• - 코드 변경 없이 플러그인: 클라이언트 캐시를 사용하면 애플리케이션 코드를 변경할 필요가 없습니다. 대신 간단한 구성 변경만 필요합니다.

다음에 무엇을할지?

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

자주 묻는 질문 (FAQ)

어떻게 NCache 선형 확장성을 달성할 수 있을까요?

NCache 1000개의 버킷으로 구성된 분산 맵을 사용하여 데이터를 여러 서버 노드에 분산함으로써 선형적인 확장성을 달성하며, 이를 통해 런타임에 새로운 하드웨어가 추가될 때 클러스터가 증가하는 트랜잭션 부하를 처리할 수 있습니다.

어떤 수 있습니다 NCache클러스터링의 "자가 치유" 기능?

NCache 모든 서버가 피어인 100% 피어 투 피어 아키텍처를 사용합니다. 클러스터 코디네이터를 포함한 어떤 노드라도 장애가 발생하면 나머지 노드들이 자동으로 새로운 코디네이터를 선출하고 TCP 기반 하트비트를 통해 클러스터의 균형을 재조정하여 100% 가동 시간을 유지합니다.

분할 토폴로지와 분할 복제 토폴로지의 차이점은 무엇입니까?

두 방식 모두 선형적인 확장성을 제공하지만, 파티션 캐시는 데이터 중복 없이 최고 속도를 제공하는 반면, 파티션 복제 캐시는 각 파티션의 수동 복제본을 생성하여 극한의 성능과 높은 가용성의 균형을 맞추기 때문에 가장 널리 사용되는 방식입니다.

어떻게 NCache "분리뇌" 현상을 해결할 수 있을까요?

NCache 지능형 감지 및 복구 알고리즘을 사용하여 스플릿 브레인 문제를 해결합니다. 이 알고리즘은 서로 다른 하위 클러스터를 자동으로 조정하고 수동 개입 없이 데이터 무결성을 복원합니다.

왜 사용해야 합니까? NCache 클라이언트 캐시(L1)?

An NCache 클라이언트 캐시(L1)는 자주 액세스되는 데이터의 하위 집합을 애플리케이션 서버에 직접 저장하여 1밀리초 미만의 InProc 속도를 제공하며, 이는 클러스터형 캐시(L2)까지의 네트워크 지연 시간을 크게 줄여줍니다.

다운타임 없이 런타임에 서버를 추가하거나 제거할 수 있습니까?

네! NCache 동적 클러스터링을 지원하여 서버 멤버십 확장 또는 제거 시 다운타임이 발생하지 않도록 클러스터 배포 맵을 모든 클라이언트에 실시간으로 자동 업데이트 및 전파합니다.