애플리케이션과 데이터베이스 사이에 캐시 서버를 배치하여 애플리케이션을 더 빠르게 만들 수 있습니다. 하지만 애플리케이션을 확장해야 할 때는 그것만으로는 충분하지 않습니다. 더 나은 성능을 위한 두 가지 캐싱 패턴과 방법을 살펴보겠습니다. NCache 구현합니다.
데이터 파티셔닝을 통한 확장성
데이터 파티셔닝을 통해 대규모 데이터 집합을 더 작은 데이터로 나누고 노드 간에 배포합니다. 이러한 방식으로 노드 간에 읽기 및 쓰기를 분할하여 애플리케이션의 전반적인 성능을 향상시킵니다. NCache 다른 지원 캐싱 토폴로지. 이 컨텍스트에서 토폴로지는 데이터 스토리지, 복제 및 클라이언트 연결 전략입니다. 데이터 파티셔닝을 구현하는 두 가지 토폴로지가 있습니다. 분할 및 분할 복제 토폴로지. 이 두 토폴로지에서 NCache 데이터를 버킷으로 나누고 해당 버킷을 클러스터의 노드에 배치합니다.
NCache 1000개의 버킷을 사용하고 클러스터의 노드 간에 균등하게 나눕니다. 예를 들어 단일 노드로 캐시 클러스터를 시작하면 NCache 모든 버킷을 단일 노드에 할당합니다. 다른 노드를 추가하면 NCache 1000개 버킷을 500개 버킷 노드 XNUMX개로 나눕니다. 또한 노드를 제거하면 NCache 버킷을 나머지 노드에 배포합니다.
이후 NCache 데이터를 버킷과 노드로 나누고 캐시 클라이언트는 모든 노드에 연결하지만 항목이 포함된 노드에서 직접 읽기 및 쓰기 작업을 수행합니다. 노드를 사용할 수 없더라도 캐시 클라이언트는 활성 노드를 사용하여 요청을 다시 라우팅하여 작업을 완료합니다. NCache 모든 노드의 데이터 크기를 거의 동일하게 유지하면서 노드 간에 버킷을 분산합니다. 이러한 방식으로 우리는 노드 간에 읽기 및 쓰기를 분할할 뿐만 아니라 추가하는 모든 노드로 클러스터의 스토리지 용량을 늘립니다.
데이터 파티셔닝 덕분에 Partition 및 Partition-Replica 토폴로지는 트랜잭션 로드 및 스토리지 용량을 확장합니다. 물론 Partition과 Partition-Replica는 지원되는 토폴로지 중 두 가지에 불과합니다. NCache 더있다 토폴로지 데이터 저장 및 복제 전략이 다릅니다. 예를 들어, 그 중 일부는 읽기 또는 쓰기가 더 많은 애플리케이션에 적합합니다.
캐싱 전략
데이터 파티셔닝을 사용하면 단일 서버보다 클러스터에서 더 많은 항목을 캐시할 수 있으므로 애플리케이션의 가용성과 성능이 향상됩니다. 또한 캐시를 채우는 방법을 선택하여 애플리케이션의 성능을 향상시킬 수 있습니다. 캐시를 채우는 두 가지 전략이 있습니다: 캐시 배제 및 Read-Through/Write-Through.
캐시 배제 전략을 사용하면 캐시 서버가 데이터베이스 옆에 있습니다. 캐시에 항목이 없으면 애플리케이션이 데이터베이스에서 항목을 읽어 캐시에 저장합니다. 이 전략을 사용하면 캐시 서버가 데이터베이스와 직접 상호 작용하지 않습니다. 아마도 캐시 배제 전략은 캐싱에 대해 생각할 때 가장 먼저 떠오르는 것입니다.
Read-Through/Write-Through 전략을 사용하는 캐시 배제 전략과 달리 캐시는 데이터의 주요 소스처럼 작동합니다. 여기에서 캐시는 데이터베이스에서 데이터를 읽고 씁니다. 따라서 이러한 전략은 우리가 자주 읽고 주기적으로 변경하는 참조 데이터와 캐시 항목에 쉽게 매핑할 수 있는 데이터베이스 행에서 더 잘 작동합니다.
Read-Through/Write-Through를 사용하면 일부 데이터 액세스 코드를 애플리케이션에서 캐시로 이동하여 애플리케이션 코드를 더 간단하고 작게 만듭니다. NCache Read-Through 및 Write-Through 캐싱 전략을 지원합니다.
전체 읽기 캐싱
NCache 캐시 누락이 있는 경우 사용자 지정 Read-Through 공급자를 사용하여 기본 데이터베이스를 호출합니다. 또한 우리는 강제로 NCache 캐시 미스가 없더라도 항상 데이터베이스를 읽을 수 있습니다. 우리의 Read-Through 공급자는 다음을 구현해야 합니다. IReadThruProvider 인터페이스. 그것은 다음과 같은 방법을 포함합니다 소스에서 로드 과 로드 데이터 유형에서 소스.
우리가 일단 Read-Through 공급자 다음을 통해 캐시 서버에 배포됩니다. NCache 관리자 또는 PowerShell 스크립트, 다음과 같이 ReadThruOptions 개체를 매개 변수로 Get 메서드에 전달하는 클라이언트 응용 프로그램에서 사용할 수 있습니다.
1 2 3 4 5 6 7 8 9 10 11 |
// After having NCache up and running... var key = $"Product:123456"; var readThruOptions = new ReadThruOptions { Mode = ReadMode.ReadThru }; // Retrieve a cached item with Read-Thru enabled var data = cache.Get<Product>(key, readThruOptions); // Do something with the cached product here... |
연속 기입 캐싱
반면에 Write-Through 전략에서는 NCache 캐시를 먼저 업데이트한 다음 데이터베이스를 업데이트합니다. NCache 동기식 또는 비동기식으로 데이터베이스를 업데이트할 수 있습니다. NCache 비동기 Write-Through 업데이트를 호출합니다: Write-Behind.
Write-Through 공급자는 다음을 구현해야 합니다. IWriteThruProvider 인터페이스. 여기에는 단일 항목 및 여러 항목에 대한 오버로드가 있는 WriteToDataSource 메서드가 포함되어 있습니다. 데이터 구조. Write-Through 공급자는 항목을 추가, 삭제 및 업데이트하는 쓰기 작업을 지원해야 합니다.
Read-Through 공급자를 배포하는 것과 유사하게 우리는 Write-Through 공급자 우리 캐시에. 공급자를 배포한 후에는 클라이언트 애플리케이션에서 다음을 통과해야 합니다. 쓰기 옵션 다음과 같이 항목을 캐시에 삽입할 때 개체
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// After having NCache up and running... var product = BuildProduct(); var key = $"Product:{product.ProductId}"; var cacheItem = new CacheItem(product); var writeThruOptions = new WriteThruOptions { Mode = WriteMode.WriteThru; } // Add an item with Write-Thru enabled cache.Insert(key, cacheItem, writeThruOptions); |
Read-Through 및 Write-Through는 애플리케이션의 확장성과 성능을 개선하는 데 도움이 됩니다. Read-Through를 사용하면 캐시된 항목을 항상 사용할 수 있습니다. NCache 만료된 항목을 자동으로 읽을 수 있습니다. 그리고 Write-through를 사용하면 애플리케이션이 데이터베이스 쓰기를 기다릴 필요가 없습니다. NCache 데이터베이스를 비동기식으로 업데이트할 수 있으며 제한 메커니즘을 사용하여 데이터베이스에 대한 부담을 줄일 수 있습니다.
결론
더 나은 성능과 확장성을 위한 두 가지 캐싱 패턴인 데이터 파티셔닝과 캐싱 전략입니다. 우리는 사용할 수 있습니다 NCache 우리의 응용 프로그램에서 구현합니다. 데이터 파티셔닝을 통해 노드 간에 읽기 및 쓰기를 분할하고 캐시의 저장 용량을 늘립니다. 우리는 NCache 이를 위한 파티션 및 파티션 복제 토폴로지. Read-Through/Write-Through를 사용하면 캐시 서버를 데이터 소스로 만들어 데이터베이스의 부담을 덜 수 있습니다.
데이터 파티셔닝 및 Read-Through/Write-Through에 대한 자세한 내용은 다음 두 가이드를 확인하십시오. 분할 및 분할 복제본 토폴로지 과 데이터 소스 공급자 캐시용. 애플리케이션을 확장하기 위해 이 두 가지 캐싱 패턴의 이점을 얻으려면 NCache 해볼.