분산 영구 캐시
NCache 필요에 따라 귀중한 데이터를 안정적으로 검색할 수 있도록 키-값 분산 영구 캐시를 제공합니다. 지속성 저장소에 캐시 데이터의 복사본을 유지하고 나중에 캐시를 다시 시작할 때(계획되었거나 계획되지 않은) 지속된 데이터를 로드합니다. 캐시 서버가 보유할 수 있는 만큼의 데이터를 저장하고 로드합니다. 지속성은 높은 데이터 가용성을 보장하는 동시에 메모리 내 데이터는 고성능을 제공합니다. 이 문서에서는 지속성을 갖춘 분산 캐시를 영구 캐시라고도 합니다.
주의 사항
지속성을 지원하는 분산 캐시만 지원 분할된 토폴로지 및 로컬(OutProc) 캐시.
다음을 사용하여 지속성을 갖춘 분산 캐시를 생성할 수 있습니다. NoSQL 데이터 백업을 위한 지속성 저장소인 문서 저장소입니다. 캐시는 모든 쓰기 API, 메타 정보, 스트림, 데이터 구조및 동적 인덱스 백엔드 저장소로 이동합니다.
주의 사항
Pub/Sub 메시지는 지속되지 않지만 NCache 지원 게시/구독 API 전용 Pub/Sub 메시징 캐시.
데이터 무효화 또는 명시적 제거로 인해 캐시에서 제거된 데이터는 기본 지속성 저장소에서도 제거됩니다. 만료 및 키 종속성이 있는 항목 추가가 지원됩니다. 그러나 이러한 영구 캐시 내부에 저장된 데이터는 영구 데이터이므로 이 방법은 권장하지 않습니다. 한편, 데이터 데이터베이스에 대한 종속성 외부 소스에 대한 종속성은 지속되도록 설정되지 않습니다.
주의 사항
휘발성 분산 캐시와 유사하게 지속성이 있는 분산 캐시에 대해 지원 소스가 지원됩니다.
영구 캐시: 데이터를 유지하는 이유
NCache 더 빠른 액세스를 위해 데이터를 RAM에 저장합니다. 캐시 메모리는 휘발성이므로 다음 시나리오에서는 데이터 손실이 불가피합니다.
- 분할된 토폴로지에서 노드 다운.
- 파티션-복제본 토폴로지에서 둘 이상의 노드가 동시에 작동 중지되었습니다.
- 유지 관리 이유 또는 치명적인 오류로 인해 클러스터가 다운됩니다.
영구 캐시를 사용하면 다음을 달성할 수 있습니다.
높은 데이터 가용성: 앞에서 언급한 이유로 인해 메모리 오류가 발생한 경우, NCache 기본 지속성 저장소에서 데이터를 로드하여 데이터를 빠르게 복구합니다. 캐시는 치명적인 오류가 발생한 후에도 클라이언트 작업에 영향을 주지 않고 작동됩니다.
결함 허용: 캐시 데이터의 실시간 사본을 유지하면 가동 중지 시간이 최소화되고 단일/다중 노드가 클러스터를 떠날 때 내결함성이 제공됩니다.
중대한
지속성을 위해 키 길이는 1023바이트를 초과하면 안 됩니다.
영구 캐시: 작동 방식
여기서 우리는 지속성이 있는 분산 캐시의 작동 및 동작을 설명합니다. 아래 다이어그램은 기본 아키텍처를 보여줍니다. 백엔드에서 지속성 저장소를 사용하여 지속성이 있는 분산 캐시를 생성할 수 있습니다. 저장소는 중앙 집중식이며 모든 노드에서 액세스할 수 있습니다. NCache 유지 가능한 시간 간격으로 캐시에 추가된 데이터를 백엔드 저장소에 기록합니다. 캐시 재시작 또는 노드 탈퇴/가입 시 캐시 서버가 보유할 수 있는 만큼 지속 데이터가 메모리에 로드됩니다.
데이터 지속성 및 로드에 대한 자세한 프로세스는 아래에서 설명합니다.
영구 캐시의 데이터 지속성
지속성이 있는 분산 캐시를 생성하면 모든 쓰기 작업이 먼저 메모리에서 수행된 다음 백엔드 저장소에 지속됩니다. 부터 NCache 분산 아키텍처가 있으므로 각 서버 노드는 모든 서버 노드가 저장소에 액세스할 수 있는 동안 데이터를 유지합니다. 게다가 파티션으로 인해 데이터 분포가 버킷 기반이기 때문에 데이터도 마찬가지로 유지됩니다.
영구 캐시의 비동기 지속성
NCache 비동기 지속성을 통해 메모리의 데이터를 지속성 저장소에 유지합니다. 여기에서는 작동 방식을 설명합니다. 각 파티션에는 수행된 클라이언트 작업을 기록하는 지속성 대기열이 있습니다. 클라이언트가 수행한 모든 쓰기 작업은 성공하면 대기열에 추가됩니다. 지속성은 비동기식으로 작동하므로 클라이언트는 작업을 대기열에 넣은 후 기다리지 않습니다. 대기 중인 작업은 구성 가능한 시간에 주기적으로 확인됩니다. persistence-interval
그리고 결국 지속성 스레드에 의해 백엔드 저장소로 복제됩니다. 각 대기열은 독립적으로 작성됩니다.
주의 사항
기본값 persistence-interval
is 1초 그리고 그것은에서 구성 가능합니다 NCache 관리 센터.
일반적으로 배치는 이후에 적용됩니다. persistence-interval
, 그러나 지속성 일괄 처리가 연속적으로 실패하면 이후 persistence-retries
배치 간격이 다음으로 이동합니다. persistence-interval-longer
. 성공하면 배치 간격이 다음으로 재설정됩니다. persistence-interval
.
중대한
비동기 복제로 인해 클라이언트 작업이 평소와 같이 발생하므로 캐시 성능이 저하되지 않습니다.
문제로 인해 캐시가 지속성 큐 내부에 데이터를 유지할 수 없는 경우 캐시가 가득 찰 때까지 쓰기 작업을 계속 수행합니다. 대기 중인 작업이 지속되지 않으면 실패한 버킷에 대한 정보가 캐시 로그에 기록됩니다.
주의 사항
파티션-복제본 토폴로지는 복제본의 대기열을 통해 대기열 오류를 복구합니다. 그러나 노드와 복제본이 동시에 다운되면 데이터 손실은 불가피합니다.
영구 캐시에 데이터 로드
데이터가 저장소에 있으면 캐시는 캐시 재시작 시 지속된 데이터를 RAM에 자동으로 다시 로드합니다. 영구 저장소는 항상 캐시 노드에서 사용할 수 있어야 합니다. 저장소에 액세스할 수 없으면 캐시가 시작되지 않습니다. 데이터 로딩은 분산 방식으로 발생합니다. 데이터 저장은 버킷 기반 절차이므로 각 노드는 데이터 분포 맵을 기반으로 할당된 버킷을 로드하기 위해 중앙 집중식 저장소에 액세스할 수 있습니다. 또한 캐시에서 데이터를 쿼리하기 위한 인덱스를 구성한 경우 쿼리 인덱스는 캐시 재시작 시 다시 생성됩니다.
중대한
지속성 저장소는 항상 모든 캐시 노드에서 사용할 수 있어야 합니다.
데이터 로드 중 작업 동작
데이터 로드 및 지속성 프로세스는 동시에 실행됩니다. 한편, 요청된 데이터가 로드되면 키 기반 가져오기가 캐시에서 제공됩니다. 캐시에 없으면 이러한 작업은 지연 로딩을 통해 저장소에서 직접 제공됩니다. 이 경우 성능은 Get
운영에 영향을 받게 됩니다.
키 기반이 아닌 또는 기준 기반 검색 작업은 다음과 같습니다. GetGroupKeys
, GetKeysByTag
, SQL 쿼리는 데이터가 저장소에서 메모리로 완전히 로드될 때까지 제공되지 않습니다.
경고
데이터 로드 중에 키 기반이 아닌 검색 작업이 발생하고 요청된 데이터가 완전히 로드되지 않으면 응용 프로그램은 다음과 같은 예외를 발생시킵니다. 지속성 저장소에서 완전히 로드되지 않은 데이터.
데이터 로딩 시나리오
다음 시나리오에서 지속성 저장소의 데이터 로드:
캐시 시작 시: 캐시 시작 시 코디네이터 노드는 모든 버킷을 로드합니다. 다른 노드가 클러스터에 가입하는 즉시 버킷 배포가 업데이트됩니다. 각 노드는 로컬 환경에서 할당된 버킷을 찾습니다. 캐시에 로드된 버킷은 국가 이전. 노드에 할당된 버킷이 완전히 로드되지 않으면 해당 버킷은 해당 노드에 의해 저장소에서 직접 로드됩니다. 캐시에 있는 경우 각 노드는 저장소에 액세스하여 할당된 버킷을 로드할 수 있습니다.
지속성이 있는 분산 캐시가 처음 시작되면 다음을 구성하여 채울 수 있습니다. 캐시 시작 로더 그 당시에는 지속성 저장소에 데이터가 없기 때문입니다. 저장소가 채워지면 데이터는 캐시 로더를 구성한 경우에도 항상 캐시 시작 시 저장소에서 로드됩니다. 그러나 주기적으로 더 많은 데이터를 추가해야 하는 경우 다음을 사용할 수 있습니다. 캐시 리프레셔. 캐시 새로 고침은 캐시와 저장소에 이미 데이터가 있는지 여부와 관계없이 주기적으로 실행됩니다.
노드 조인 시: 새 노드가 클러스터에 합류할 때 이미 로드된 경우 상태 전송을 통해 기존 클러스터 노드에서 할당된 버킷을 가져옵니다. 할당된 버킷이 캐시에 완전히 로드되지 않으면 새 노드에 의해 저장소에서 로드됩니다.
노드를 떠날 때: 노드/노드가 클러스터를 떠날 때 데이터 손실을 방지하기 위해 저장소에서 데이터가 로드됩니다. 노드 이탈 시 로드 동작은 토폴로지에 따라 다릅니다.
분할된 토폴로지: 노드가 떠나면 해당 버킷이 기존 클러스터 노드에 분산되고 새 소유자가 지속성 저장소에서 로드합니다.
파티션-복제본 토폴로지: Partition-Replica는 복제본의 상태 전송을 통해 손실된 버킷을 복구하여 최대 한 수준까지 노드 오류를 허용합니다. 그러나 노드와 해당 복제본이 동시에 다운되면 손실된 데이터는 백업 저장소에서 계속 복구할 수 있습니다.
중대한
캐시는 노드 다운/이탈 시 데이터를 수용할 수 있는 용량이 있어야 합니다.
지속성이 있는 분산 캐시에 대한 용량 관리
영구 캐시는 캐시에 출발된 노드의 데이터를 수용할 만큼 충분한 쿠션이 있는 경우에만 노드 종료 또는 종료 시 데이터 손실로부터 복구할 수 있습니다. 캐시가 가득 찼거나 다른 이유로 인해 지속성 저장소의 모든 데이터를 수용할 수 없는 경우 추가 또는 업데이트 작업이 실패하기 시작합니다. 한편 일부 버킷에는 완전한 데이터가 없습니다. 이러한 불완전한 버킷은 두 가지 경우에 저장소에서 다시 로드됩니다.
- 새 노드가 클러스터에 합류합니다.
- 핫 적용을 통해 캐시 크기가 증가합니다.
주의 사항
캐시가 꽉 찼지만 지속성 저장소와 100% 동기화된 경우 새로 추가된 항목만 차단됩니다. 다른 모든 작업은 아무 문제 없이 캐시에서 발생할 수 있습니다.
메모리의 일부 데이터로 인해 캐시가 가득 차면 캐시는 비키 기반 또는 기준 기반 작업(예: GetGroupKeys
, GetKeysByTag
, SQL 쿼리). 반면 키 기반 가져오기는 항상 캐시 또는 저장소를 통해 제공됩니다. 특히 캐시 미스의 경우 캐시는 불완전한 버킷에 대한 모든 키 기반 가져오기를 지연 로드하려고 시도합니다.
경고
기준 기반 검색 작업이 캐시가 가득 찬 상태에서 수행되고 요청된 데이터가 캐시에 없으면 예외가 발생합니다. 캐시에 메모리에 모든 데이터가 없기 때문에 작업을 수행할 수 없습니다..
캐시 가득 참에 대한 용량 계획
캐시가 꽉 찼을 때 발생하는 문제를 피하려면 사용을 시작하기 전에 영구 캐시의 용량을 계획해야 합니다. 지속성이 있는 분산 캐시에 대한 용량 계획을 수행할 때 노드당 캐시 크기를 계획하여 노드가 다운될 경우 나머지 노드가 손실된 노드의 모든 데이터를 수용할 수 있도록 하는 것이 좋습니다.
캐시 가득 참 시 캐시 크기 확장
중대한
NCache 크기 확장을 통한 지속성을 갖춘 파티션-복제본 기반 분산 캐시에서 단일 노드 휴가에 대한 높은 데이터 가용성을 보장하려고 합니다. 그러나 높은 데이터 가용성이 약속되거나 보장되지는 않습니다.
Partition-Replica의 경우 노드가 클러스터를 떠나면 클러스터의 나머지 노드는 떠나는 노드가 소유한 데이터를 수용합니다. 그러나 노드에서 나가는 데이터는 크기 문제로 인해 공간이 없을 가능성이 있습니다. NCache 노드가 지속성으로 파티션 복제본 기반 분산 캐시를 떠날 때 자동 캐시 크기 확장을 지원합니다. 확장 모드는 단일 노드가 다운된 경우에만 지원됩니다. 목적은 캐시의 부분 데이터를 방지하고 전체 캐시에서 기준 기반 작업을 제공하는 것입니다.
확장 프로세스는 내부적으로 발생합니다. 실행 중인 노드가 구성된 노드보다 크거나 같은 상태에서 단일 노드가 클러스터를 떠날 때 확장 모드가 트리거됩니다. 확장된 크기는 구성된 노드 또는 클러스터에서 실행 중인 노드(둘 중 더 높은 것)를 기준으로 계산됩니다. 캐시가 확장 모드에 있을 때 클러스터의 각 노드는 노드를 떠날 때 상태 전송을 통해 수신된 데이터를 수용하기 위해 자동으로 크기가 커집니다.
중대한
확장은 노드 다운 후 남은 노드의 수가 다음과 같을 때만 발생합니다. 최대 {구성된 노드/실행 중인 노드}-1. 확장된 크기는 구성된 노드 또는 클러스터에서 실행 중인 노드(둘 중 더 높은 쪽)를 기반으로 계산됩니다.
확장 모드에서는 키 기반 작업과 기준 기반 작업이 모두 제공됩니다. 그러나 캐시 크기가 구성된 캐시 크기를 한 번 넘으면 여전히 추가 작업을 차단합니다.
새 노드가 클러스터에 합류하거나 핫 적용을 통해 캐시 크기가 증가하면 캐시가 확장 모드에서 나옵니다. 그런 다음 분포 맵이 업데이트되고 상태 전송이 트리거됩니다. 상태 전송이 완료되면 각 노드는 확장 모드에서 벗어나고 캐시 크기는 구성된 캐시 크기로 줄어듭니다.
주의 사항
캐시가 확장 모드에 들어가고 존재할 때 캐시 로그와 이벤트 로그 모두에 항목이 기록됩니다.
접근 불가 행동
캐시 시작 시 지속성 저장소에서 데이터가 로드되므로 캐시 노드에서 저장소를 일관되게 사용할 수 있어야 합니다. 여기서는 지속성 저장소에 액세스할 수 없을 때의 동작에 대해 설명합니다.
- 캐시 생성 시: 저장소에 대한 연결은 캐시 생성 시 확인됩니다. 액세스할 수 없는 경우 캐시를 만들 수 없으며 오류 알림을 받게 됩니다. 마찬가지로, 클러스터 노드에서 저장소를 사용할 수 없는 경우 캐시가 시작되지 않습니다.
경고
캐시 생성 시 모든 서버 노드가 지속성 저장소에 액세스할 수 있을 때까지 캐시가 시작되지 않습니다.
데이터 로드 시: 네트워크 장애로 인해 데이터 로드 중에 저장소에 액세스하지 못할 수 있습니다. 이 경우 캐시는 로드 상태의 나머지 데이터 버킷 로드를 다시 시도합니다. 한편 키 기반이 아닌 검색 작업은 실패합니다. 당신은 할 수 있습니다 데이터 로드 재시도 구성 서비스 구성 파일에서.
캐시 실행 시: 짧은 기간 또는 무한한 시간 동안 네트워크 오류로 인해 실행 중인 캐시에 대해 저장소에 액세스할 수 없게 될 수 있습니다. 이러한 연결 손실 시 캐시는 계속 쓰기 작업을 수락하고 큐에 넣습니다. 한편, NCache 지속성 저장소에 대한 연결이 다시 설정될 때까지 배치 간격으로 대기 중인 작업을 지속하려고 계속 시도합니다.
연결이 무한히 끊어지면 캐시 메모리가 가득 찰 때까지 쓰기 작업이 발생합니다. 캐시가 가득 차면 후속 쓰기 작업이 실패합니다. 그러나 키 기반 가져오기 작업은 앞에서 설명한 대로 제공됩니다.
영구 캐시 생성 및 모니터링
주의 사항
지속성이 있는 분산 캐시에는 JSON 직렬화 캐시만 지원됩니다.
새 저장소 또는 기존 저장소(다음을 사용하여 만든 NCache) 다음 중 하나를 통해 NCache 관리 센터 또는을 통해 PowerShell 도구.
NCache 다른 제공 성능 카운터 지속적으로 분산 캐시의 통계를 모니터링합니다. 게다가, 당신은 할 수 있습니다 지속성으로 분산 캐시 모니터링 를 통해 NCache 모니터, PowerShell 및 PerfMon 도구.