올랜도 코드 캠프
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
트랜잭션 로드 증가로 인해 .NET 응용 프로그램에서 데이터베이스 또는 저장소 병목 현상이 발생할 수 있습니다. 분산 캐싱을 사용하여 병목 현상을 제거하고 .NET 애플리케이션을 확장하는 방법을 알아보십시오. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
오늘의 얘기는 아니다. NCache, 분산 캐싱에 관한 것입니다. 참고하겠습니다 NCache 예를 들지만 개념은 전반적이므로 모든 캐시에 적용됩니다.
확장성이란
좋아요! 먼저 몇 가지 정의를 살펴보겠습니다. 첫 번째 정의는 확장성입니다. 확장성은 애플리케이션 성능이 아닙니다. 사용자가 XNUMX명이고 애플리케이션이 초고속으로 실행되는 경우 애플리케이션은 XNUMX명, XNUMX만 또는 XNUMX명의 사용자와 동일한 우수한 성능을 가질 수 있을 때까지 확장할 수 없습니다. 따라서 확장성은 최대 부하에서 고성능에 관한 것입니다. 사람들은 때때로 성능과 확장성을 혼동합니다. 캐싱이 도움이 되지 않는 경우 사용자가 XNUMX명일 경우 애플리케이션의 성능이 좋지 않을 수 있으며 해결해야 할 다른 문제가 있습니다.
선형 확장 성
선형 확장성은 애플리케이션이 더 많은 서버를 추가할 수 있는 방식으로 설계되고 더 많은 서버를 추가하여 트랜잭션 용량을 늘릴 수 있는 경우입니다. 다시 말하지만, 애플리케이션이 처리할 수 있는 초당 트랜잭션 수의 사용자 수 측면에서 트랜잭션 용량 측면에서 정의하는 확장성입니다. 따라서 애플리케이션이 더 많은 서버를 추가함에 따라 선형적으로 더 많은 트랜잭션을 처리할 수 있다면 선형 확장 가능하며 우리의 목표는 애플리케이션에서 선형 확장성을 갖는 선형 확장이 되는 것입니다.
비선형 확장성
그리고 우리는 비선형 확장성을 원하지 않습니다. 즉, 특정 지점 이후에 서버를 더 추가해도 응용 프로그램이 증가하지 않고 사실상 떨어질 수 있는 방식으로 응용 프로그램이 설계되는 방식입니다. 이는 어딘가에 해결되지 않은 병목 현상이 있음을 의미합니다.
어떤 앱에 확장성이 필요합니까?
그렇다면 확장성을 원하는 이유는 무엇이며 확장성이 필요한 애플리케이션은 무엇입니까?
일반적으로 이들은 서버측 애플리케이션인 애플리케이션입니다. 이들은 ASP.NET 이제 ASP입니다..NET core, 웹 서비스, IOT 백엔드, 빅 데이터 처리. 빅 데이터 처리는 .NET 측에서 일반적이지 않지만 Java 현상에 더 가깝지만 .NET에서도 가능해야 하지만 빅 데이터 처리 앱에는 확장성과 다른 서버 애플리케이션도 필요합니다. 예를 들어 은행에서 수백만 명의 고객이 전화를 걸어 주소를 변경하거나 새 카드를 발급하거나 요청하거나 자금을 이체할 수 있으며 이러한 모든 요청을 밤에 배치 모드로 처리해야 하고 다음 영업일 이전에 완료해야 하는 규정 준수 요구 사항이 있습니다. 따라서 이들을 점점 더 많이 사용함에 따라 다른 배치 처리 애플리케이션도 확장 가능해야 합니다. 따라서 이러한 응용 프로그램만 있는 것은 아닙니다. 압축된 시간에 많은 트랜잭션을 처리해야 하는 다른 애플리케이션과 이러한 경우 압축된 시간은 초당 트랜잭션이며 이 경우 압축된 시간은 해당 규정 준수 요구 사항 내에 있을 수 있습니다. 따라서 트래픽이 많거나 트랜잭션이 많은 이러한 응용 프로그램이 있는 경우 올바른 대화에 온 것입니다.
확장성 문제
그렇다면 확장성 문제는 어디에 있습니까? 우리는 왜 이런 대화를 나누는 걸까요? 응용 프로그램 계층이 매우 훌륭하게 확장되고 로드 밸런서가 있으며 점점 더 많은 서버를 추가할 수 있는 것은 확실히 응용 프로그램 계층이 아닙니다. 모든 것이 아주 멋져 보입니다. 문제는 실제로 데이터베이스, 데이터 저장소에 있습니다. 그리고 그것은 관계형 데이터베이스 또는 메인프레임 레거시 데이터를 의미합니다. 그리고 애플리케이션 계층을 확장할 수 있는 것과 동일한 방식으로 확장할 수 없습니다. 그 이유는 여기에 있는 데이터가 배포되지 않기 때문입니다. 데이터베이스의 특성은 모두 함께 넣어야 한다는 것입니다. 그리고 메인프레임도 마찬가지입니다. 따라서 데이터베이스가 매우 빠를 수 있습니다. 서버 쪽에서 메모리 캐싱을 수행할 수 있지만 확장되지 않고 NoSQL databases.
사람들이 사용하는 이유 중 하나이지만 NoSQL 하나는 트랜잭션의 확장성을 위한 것이고 다른 하나는 데이터의 확장성을 위한 것입니다. NoSQL 그것에 훨씬 더 적합합니다. 그리고 사람들이 JSON 문서를 사용하는 세 번째 이유는 스키마의 유연성을 제공하기 때문입니다. 하지만, NoSQL databases가 항상 도움이 되는 것은 아니며 그 이유는 데이터를 관계형 데이터베이스에서 다른 데이터베이스로 옮겨야 하기 때문입니다. NoSQL database. 기술적으로나 사업적으로나 여러 가지 이유로 그렇게 할 수 없다면 어떻게 하시겠습니까? 일부 데이터는 관계형 데이터베이스와 레거시 메인프레임 데이터에 남아 있어야 합니다. 하지만, NoSQL databases는 훌륭하고 우리는 NoSQL database 우리가 작년에 출시한 NosDB, 내가 언급했듯이 데이터를 넣을 수 없다면 문제를 해결할 수 없습니다. 따라서 관계형 데이터베이스로 작업해야 하는 경우 관계형 데이터베이스가 제기하는 확장성 문제를 해결해야 하며 이것이 바로 분산 캐시가 필요한 곳입니다.
분산 캐시 배포
기본적으로 분산 캐시는 메모리 내 분산 저장소입니다.
논리적으로 말하면 애플리케이션 계층과 데이터 계층 사이에 있습니다. 물리적으로 그것은 여러 개의 별도 VM이거나 애플리케이션과 같은 상자에 있을 수 있습니다. 그러나 논리적으로 애플리케이션 계층과 데이터베이스 계층 사이에 있습니다. 그리고 기본적인 주장은 데이터를 캐시하면 데이터베이스에 자주 가지 않는다는 것입니다. 데이터베이스로 이동하지 않기 때문에 모든 로드가 발생하지 않으므로 병목 현상이 발생하지 않습니다. 시간의 80%를 캐싱 계층으로 이동할 수 있고 캐싱 계층은 마치 데이터베이스처럼 분산되어 있기 때문에 데이터베이스가 병목 현상을 일으키지 않는 경우 NoSQL database 캐싱 계층도 배포됩니다. 키/값입니다. 실제로 분산 캐시의 또 다른 단어는 인 메모리입니다. NoSQL 배포 캐시에 넣은 모든 항목에는 키가 있고 객체인 값이 있기 때문에 키 값 저장소가 있습니다. 그래서, 여기로 가는 시간의 80%를 그렇게 함으로써 데이터베이스로 가는 시간의 20%를 차지하게 됩니다. 그 20%는 대부분 업데이트입니다.
물론 일부 읽기가 있으며 읽기 트랜잭션과의 경쟁이 없고 더 이상 병목 현상이 없기 때문에 이러한 업데이트도 더 빠르게 수행됩니다. 왜? 분산 캐시는 둘 이상의 서버로 구성된 클러스터를 형성하기 때문입니다. 이것은 값비싼 상자가 아니며 데이터베이스 서버 유형의 상자도 아닙니다. 이것은 메모리가 많은 16개 또는 32개의 코어 상자와 같은 일반적인 웹 서버 구성입니다. 많은 것은 우리가 고객에게 권장하는 32~64기가를 의미합니다. 일부 고객은 16개 이상을 사용하지만 32개 이상을 권장하는 경우는 거의 없습니다. 여기에 더 많은 상자를 추가한 다음 다른 상자를 추가하는 것이 좋습니다. 메모리를 추가하면 처리 능력을 업그레이드해야 하기 때문입니다. 왜? .NET 응용 프로그램에는 가비지 수집이라는 기능이 있고 수집해야 하는 메모리가 많을수록 더 많은 가비지 수집기 또는 GC가 작동해야 하고 이 경우 CPU에 병목 현상이 발생하여 응용 프로그램에 문제가 발생하기 시작합니다. 따라서 스위트 스폿은 이러한 VM 또는 물리적 상자의 8~XNUMXGB 메모리이며 대부분의 고객이 여기에서 VM을 사용합니다. 그리고 하드웨어 구성으로 약 XNUMX개의 코어와 일반적으로 두 개의 네트워크 카드, 하나의 네트워크 카드는 클러스터링용이고 다른 하나는 클라이언트가 통신하기 위한 것입니다. 클라이언트라는 단어는 응용 프로그램 서버를 의미하므로 클라이언트가 아닙니다. 캐시 클라이언트는 애플리케이션 서버입니다.
따라서 최소 40개의 캐시 서버와 애플리케이션 계층과 캐싱 계층 간의 비율이 50:XNUMX 또는 XNUMX:XNUMX입니다. 그리고 그 비율은 우리가 지난 몇 년 동안 보았고 XNUMX년 넘게 이 공간에서 있었던 것을 기반으로 합니다. 더 많은 활동을 추가하기 위해 여기에 더 많은 서버를 추가하는 경우 XNUMX:XNUMX 또는 XNUMX:XNUMX 이상의 비율은 매우 좋은 용량을 제공할 것입니다. 물론 세 가지 이유 중 하나로 서버를 추가합니다. 방금 이야기한 것처럼 메모리가 필요하기 때문에 더 많은 스토리지가 필요하거나 시작할 서버가 두 대 있고 폐기가 최대가 될 때까지 여기에 상자를 계속 추가했기 때문에 더 많은 트랜잭션 용량이 필요합니다. 관계형 데이터베이스에서 그런 일이 발생하면 막히게 됩니다. 당신은 푹 빠졌습니다. 이 경우 세 번째 상자의 용량이 최대가 될 때까지 세 번째 상자를 추가한 다음 네 번째 상자를 추가하는 식으로 진행됩니다. 따라서 여기에 원하는 만큼 많은 상자를 가질 수 있습니다. 평균적으로 여기에 XNUMX~XNUMX개의 상자가 있는 고객이 있고 일부 고객은 여기 애플리케이션 계층에 XNUMX~XNUMX개의 상자가 있고 그에 따라 있습니다. 따라서 XNUMX개의 상자 또는 XNUMX개의 서버 응용 프로그램 계층의 경우 캐싱 계층에 약 XNUMX개의 서버가 있습니다. 그래서, 그것이 당신이 당신의 계획을 수행하는 방법입니다.
따라서 지금까지의 대화의 목표는 캐싱 계층이 있으면 더 이상 확장성 병목 현상이 발생하지 않는다는 점을 확신시키는 것입니다. 따라서 어떤 제품을 사용하든 캐싱 솔루션을 사용하든 응용 프로그램에 캐싱 계층을 통합해야 합니다. 따라서 사진에 캐시를 포함하도록 응용 프로그램을 설계해야 병목 현상이 발생하지 않습니다.
분산 캐시 사용 사례
이제 .NET 개발자로서 캐시를 사용해야 한다고 확신했으므로 다음 질문은 캐시를 어디에 사용해야 하느냐입니다. 어떻게 사용해야 합니까?
첫 번째 사용 사례는 내가 지금까지 이야기한 애플리케이션 데이터 캐싱으로, 데이터베이스에 애플리케이션 데이터가 있고 여기에 캐시하므로 데이터베이스로 이동할 필요가 없습니다. 이와 동일합니다.
앱 데이터 캐싱
이 사용 사례에서 염두에 두어야 할 한 가지는 데이터가 이제 두 위치에 존재한다는 것입니다. 하나는 데이터베이스인 마스터이고 다른 하나는 그렇지 않은 캐시입니다. 따라서 데이터가 두 곳에 존재한다면 무엇이 잘못될까요? 두 개의 복사본이 있는 경우 가장 큰 문제는 캐시가 최신 상태인지, 캐시가 동일한 버전의 데이터를 가지지 않을 경우 읽기 전용 데이터를 캐시해야 하기 때문에 캐시가 데이터베이스와 동일한 버전의 데이터를 갖게 되는 것입니다. 그리고 읽기 전용 데이터는 전체 데이터의 약 10-15%입니다. 그래서, 당신은 실제로 잘 이익을 얻지 못하고 있습니다. 당신은 혜택을 받고 있지만 실제로 응용 프로그램을 확장 가능하게 만드는 데 필요한 만큼의 혜택을 받지 못하고 있습니다.
그래서 사실 평범한 사람에게 캐시가 무엇을 위해 사용되는지 묻는다면 너무 그렇습니다. 그들은 읽기 전용 데이터를 여기에 넣을 것이라고 말할 것입니다. 모두가 트랜잭션 데이터 캐싱을 두려워합니다. 30초마다, XNUMX분마다, XNUMX분마다 또는 예측할 수 없는 방식으로 변경되는 고객, 계정 또는 활동 데이터. 따라서 사람들은 두 개의 복사본이 있고 데이터베이스에서 변경한 것을 캐시가 알지 못하기 때문에 이러한 이유로 캐시하는 것을 두려워합니다. 따라서 계속 진행하면서 이 점을 염두에 두도록 합시다.
ASP.NET 특정 캐싱
두 번째 사용 사례는 ASP.NET 응용 프로그램이 있는 경우 가장 일반적으로 알려진 세션 상태. 그리고 그것은 또한, 이것의 무엇이든, 첫 번째 예는 세션 상태입니다. 세션은 기본적으로 두 가지 저장 옵션이 있습니다. 하나는 InProc이고 다른 하나는 Microsoft에서 제공하는 SQL입니다. 온프레미스에는 상태 서버도 있지만 세 가지 옵션 모두 확장성 문제가 있습니다. SQL 서버에 성능 문제가 있습니다. 처음부터 캐싱을 사용하지 않는 것과 같은 이유입니다. SQL에 세션을 저장하면 Blob으로 저장됩니다. 관계는 모든 관계형 데이터베이스가 Blob 저장소용으로 설계된 것이 아니라 구조화된 데이터용인 SQL과 같습니다. 따라서 수행하지 않습니다. 많은 문제가 있습니다. 저희 고객님들이 방문하시면 대부분 NCache, 첫 번째 사용 사례는 세션 상태입니다. 그것은 즉각적인 이익을 얻기 때문입니다. 그리고 세션 상태에 대한 정말 좋은 점은 다음과 같은 타사 캐시를 허용하는 Microsoft가 제공하는 프레임워크가 있기 때문에 프로그래밍이 없다는 것입니다. NCache 플러그인하고 여기에 있는 모든 것이 캐시에 저장됩니다.
ASP.NET의 다른 측면은 MVC 프레임워크가 없는 경우, 많은 ASP.NET 응용 프로그램이 여전히 존재하는 사전 MVC 프레임워크에 있는 경우 보기 상태라는 것이 있습니다. 그리고 뷰 상태가 무엇인지 모르는 분들을 위해 설명드리자면, 이는 웹 서버에서 브라우저로 보내어 게시물을 다시 가져올 때만 암호화된 문자열입니다. 따라서 수백 킬로바이트의 암호화된 강도가 그냥 갔다가 돌아올 수 있습니다. 그리고 여기에 애플리케이션이 처리할 수백만 건의 트랜잭션을 곱하면 최소한 많은 대역폭이 됩니다. 그리고 대역폭은 꽤 비싸다는 점에서 무료가 아닙니다.
그리고 두 번째는 물론 그 정도의 무거운 페이로드를 보내야 할 때 응답 시간이 느려집니다. 따라서 서버 측에서 보기 상태를 캐시할 수만 있다면 작은 키를 보내서 포스트백이 발생하면 키가 반환되고 보기 상태가 캐시에서 가져와서 페이지에 표시된다면 훨씬 더 좋을 것입니다. 이것이 두 번째 사용 사례입니다. 다시 말하지만 프로그래밍이 필요하지 않습니다. 다음과 같은 타사 캐시를 연결하기만 하면 됩니다. NCache.
세 번째 사용 사례는 ASP.NET 출력 캐시. 이 캐시는 페이지 출력입니다. 페이지 출력이 변경되지 않으면 Microsoft는 이미 로컬 독립 실행형 InProc에 캐시하는 프레임워크를 가지고 있습니다. 웹 팜에서 페이지 출력이 처음 캐시될 때 모든 웹 서버가 자체 복사본을 캐싱하는 대신 전체 웹 팜에서 사용할 수 있도록 대신 세 번째 분산 캐시를 배치하는 것이 좋습니다.
따라서 응용 프로그램 데이터 캐싱 외에 ASP.NET 응용 프로그램에 대한 세 가지 사용 사례가 있습니다.
이제 여기서 문제의 본질은 여기서 완전히 다릅니다. 여기에는 두 개의 데이터 사본이 있습니다. 여기서 캐시는 마스터 저장소입니다. 따라서 더 이상 데이터베이스에 세션을 저장하지 않습니다. 더 이상 다른 곳에 보기 상태를 저장하지 않습니다. 따라서 캐시는 마스터 저장소이며 메모리 내 저장소입니다. 그렇다면 메모리 내 저장소가 마스터 저장소일 때 무엇이 잘못될 수 있습니까? 메모리는 휘발성입니다! 응. 그래서 끈기가 없습니다. 따라서 우수한 분산 캐시는 데이터 안정성을 제공하기 위해 여러 서버에 걸쳐 데이터를 복제해야 해당 세션을 잃지 않습니다. 왜냐하면 당신은 항공사이고 하와이에서 이 특별 주말 프로모션을 수행했으며 웹사이트 트래픽이 XNUMX~XNUMX배 증가했고 그들은 모든 종류의 검색을 수행한 사람들이 제출 버튼을 누르려고 하고 세션을 잃게 되기 때문입니다. 각 고객에 대해 수천 달러의 판매로 해당 고객을 잃을 수 있습니다. 따라서 세션을 잃고 싶지 않을 것입니다. 따라서 복제를 수행하지 않는 한 세션을 캐시에 넣지 마십시오.
런타임 데이터 공유
세 번째 사용 사례는 런타임 데이터 공유입니다. 이것은 많은 사람들이 오랫동안 몰랐던 것입니다. 사람들은 여러 애플리케이션에서 이벤트를 공유하기 위해 메시지 대기열을 사용합니다. 그러나 분산 캐시는 매우 간단하고 강력한 데이터 중심 이벤트 메커니즘을 제공합니다. 이제 이를 서비스 버스 또는 메시지 버스와 같은 것으로 생각하면 이를 통해 서로 통신할 수 있는 애플리케이션입니다. 따라서 고유한 이점이 있는 MSMQ 또는 RabbitMQ를 사용하는 대신 캐시가 이를 대체할 수 없습니다. 그러나 데이터와 관련된 요구 사항이 더 많거나 메시징 요구 사항이 데이터와 동일한 데이터 센터 내에서 더 많이 필요한 경우 분산 캐시는 더 간단한 인터페이스를 제공하지만 더 중요하게는 더 확장 가능합니다. 따라서 더 높은 트랜잭션 애플리케이션이 있는 경우 이 모든 이야기는 확장성에 관한 것입니다.
따라서 이 일반 메시지 대기열을 사용하여 이 모든 작업을 수행할 수 있습니다. 매우 높은 트랜잭션 환경에 들어가면 분산 캐시와 같은 방식으로 분산되지 않습니다. 따라서 분산 캐시를 사용하면 이 모든 작업을 수행할 수 있습니다. Pub/Sub 유형의 데이터 공유라고 가정하면 이벤트 알림이 있고 연속 쿼리 기능이 있습니다. NCache Java 캐시에도 있는 것이 있습니다. Redis 매우 원활한 방식으로 애플리케이션 간에 데이터를 공유할 수 있습니다. 그리고 여기서도 문제는 ASP.NET 특정 캐싱 응용 프로그램과 유사합니다. 왜냐하면 이 데이터는 아마도 데이터베이스에 존재하지만 공유하는 형식이 아니기 때문입니다.
따라서 공유를 시도하기 전에 변환된 양식이 캐시에 보관되도록 일부 양식으로 변환했을 수 있습니다. 따라서 캐시가 데이터를 복제해야 하므로 해당 데이터가 손실되는 것을 원하지 않습니다. 실제로 응용 프로그램 데이터 캐싱의 경우에도 기술적으로는 하나의 캐시 서버가 다운되고 복제하지 않아 일부 데이터가 손실되는 경우 가능합니다. 기술적으로 데이터베이스에서 해당 데이터를 다시 로드할 수 있습니다. 성능 저하가 있다는 점을 제외하고는 문제가 없습니다. 왜냐하면 16기가의 데이터를 손실했다면 이제 원하지 않는 16기가의 데이터베이스 히트를 거쳐야 하기 때문입니다. 따라서 대부분의 고객은 애플리케이션 데이터 캐싱의 경우에도 메모리가 매우 저렴하기 때문에 복제를 선택합니다. 그들은 그 성능 저하를 원하지도 않습니다. 물론 이 두 가지를 가지고 있어야 하지만 이 두 가지는 가지고 있으면 좋은 것입니다.
실습 데모
좋습니다. 이 작업을 수행하는 방법에 대해 진행하기 전에 먼저 캐시가 어떻게 생겼는지 보여드리고 싶습니다. 나는 사용할 것이다 NCache 여기에 예를 들어.
환경 설정
하늘색에는 demo1, demo2 및 demo-client라는 1개의 VM이 있습니다. demo2과 XNUMX는 내 캐시 서버 VM이 되고 demo-client는 내 애플리케이션 서버 VM이 됩니다. 귀하의 경우 두 개의 캐시 VM이 있고 클라이언트 VM의 비율이 XNUMX:XNUMX, XNUMX:XNUMX 또는 XNUMX:XNUMX이라고 가정해 보겠습니다.
그래서 저는 데모 클라이언트에 로그인하고 이 도구를 사용할 것입니다. NCache 라고했다 NCache 관리자. 그래서 여기에서 시작했습니다. 여기에 와서 새 클러스터 캐시를 생성한다고 말할 것입니다.
클러스터형 캐시 생성
모든 캐시 NCache 이름이 지정되었으므로 이름을 democache로 지정하겠습니다. 각각의 의미에 대해 자세히 설명하지는 않겠습니다. 잠시 후에 이에 대해 이야기하겠지만 파티션된 복제본 토폴로지. 의 경우 NCache, 토폴로지는 데이터가 어떻게 저장되고 복제되는지를 의미합니다. 분할된 복제본 토폴로지는.. 여기로 돌아오면 생성하려고 하는 XNUMX노드 캐시 클러스터라고 생각하면 됩니다.
분할된 복제본인 경우 모든 서버에 하나의 분할 영역이 있습니다. 따라서 총 두 개의 파티션이 있습니다. 의 경우 NCache, 전체 캐시에는 약 천 개의 버킷이 있으므로 그 중 약 절반은 파티션 XNUMX로 이동하고 절반은 파티션 XNUMX로 이동합니다.
각 파티션은 복제본이라고 하는 다른 서버에 백업됩니다. 복제품의 경우 NCache 수동적입니다. 즉, 클라이언트가 복제본과 통신하지 않고 파티션만 복제본과 통신합니다. 그리고 복제본은 기본 파티션 또는 파티션이 다운된 경우에만 활성화됩니다.
즉, 이 서버가 중단되면 1노드 클러스터와 파티션이 있는 경우 서버 2이 다운되고 파티션 XNUMX이 지금 다운되었다고 가정해 봅시다. 따라서 복제본 XNUMX은 자동으로 파티션 XNUMX이 되므로 데이터가 손실되지 않습니다. 따라서 분할된 복제본은 이러한 스토리지 및 복제 전략을 제공합니다. 본질적으로 데이터가 복제되어야 함을 알려줍니다. 동기 및 비동기 복제도 있습니다. 그래서, 어쨌든, 그래서 나는 이것으로 다시 돌아올 것이지만 그것이 무엇을 의미하는지 보여주고 싶었습니다. 따라서 파티션과 복제본 간의 비동기 복제를 선택하겠습니다. 그런 다음 내 캐시 서버를 지정하므로 첫 번째는 demoXNUMX이고 두 번째는 demoXNUMX입니다. 자, 내가 말하는 모든 것은 NCache, 완전히 스크립팅할 수 있으므로 자동화할 수 있습니다. 모두 기본값으로 두겠습니다. 캐시 클러스터가 형성된 TCP 포트입니다. 이 서버에서 캐시가 사용할 메모리 양을 지정하고 캐시는 이 메모리 이상을 사용하지 않습니다. 그래서 제가 여기서 지정하는 것은 무엇이든 이 곱하기 XNUMX이기 때문입니다. 파티션이 있고 복제본이 있습니다.
그래서 이것은 파티션의 크기입니다. 따라서 캐시 서버에 16기가가 있는 경우 운영 체제 및 기타 프로세스를 위해 약 2~2.5기가를 남겨두고 나머지를 할당해야 하기 때문에 귀하의 경우에는 물론 이것보다 훨씬 더 많을 것입니다. 예를 들어 16기가에서 13기가 남았지만 13를 2로 나눈 파티션 크기는 다음과 같습니다. NCache 이 메모리 이상을 사용하지 않도록 합니다. 따라서 많은 메모리가 소비되면 다음과 같은 경우 캐시가 가득 찬 것으로 간주됩니다. NCache. 그런 다음 NCache 두 가지 옵션 중 하나가 있습니다. 하나, 당신은 말할 수 있습니다 NCache 일부 데이터가 자동으로 만료되거나 제거라고 하는 작업을 수행할 수 있을 때까지 데이터의 새로운 추가를 거부합니다. 그래서, NCache 세 가지 제거 알고리즘 LRU, LFU 및 우선 순위 FIFO를 제공합니다. 따라서 이 경우 캐시의 5%를 제거한다고 말할 수 있습니다.
이제 저는 이것에 대해 조금 이야기하고 싶습니다. 유스 케이스 여기. 응용 프로그램 데이터 캐싱을 수행하는 경우 제거가 완벽합니다. 문제 없다. 가장 최근에 사용되지 않은 일부 메모리를 제거한 다음 새 데이터를 위한 공간을 마련한 메모리를 모두 사용했습니다. 그럼 움직이는 창문처럼 되겠죠? 따라서 점점 더 많은 데이터를 사용함에 따라 이전 데이터가 제거되고 새 데이터가 생성됩니다. 그래서 가장 많이 사용하는 방법입니다. 하지만 세션이라면 어떨까요? 캐시가 세션을 저장하는 데 사용되는 경우 제거를 원하지 않습니다. 퇴거를 원하지 않는 이유는 무엇입니까? 세션이 여전히 활성 상태일 수 있기 때문입니다. 20분이나 시간 제한이 무엇이든 간에 진행되지 않았을 수 있습니다. 이 경우에도 여전히 세션을 제거하면 사용자가 로그아웃하지 않았지만 사용자가 쫓겨나는 것과 같은 동일한 문제를 강제하는 것입니다. 따라서 해야 할 일은 용량 계획을 세우는 것입니다. 의 경우 NCache, 매우 쉽게 할 수 있고 평균 세션이 소비하는 메모리 양을 확인한 다음 용량 계획을 세울 수 있습니다. 사용할 메모리 양을 추정합니다. 이 다른 세션 스토리지가 절대 제거되지 않는 용량을 수행하십시오. 응용 프로그램 데이터 저장소 또는 응용 프로그램 데이터 캐시를 제거할 수 있습니다. 문제 없습니다. 그러나 세션 캐시를 제거하면 안 됩니다. 사용자가 더 이상 세션을 사용하지 않는 경우에만 만료되어야 합니다.
이제 완료라고 하면 XNUMX노드 캐시 클러스터가 있습니다. 여기로 와서 클라이언트 노드를 추가하겠습니다. 내 경우에는 내가 말했듯이 클라이언트 노드가 하나만 있습니다. 캐시가 없을 것 같아서 시작했습니다. 나는 그 서비스가 필요하므로 NCache 관리자는 이것과 대화하고 구성을 수행할 수 있습니다. 좋아요! 이제 이 작업을 완료했으므로 여기로 와서 캐시를 시작하라고 말할 것입니다. 이제 캐시를 시작하여 NCache 이 두 상자 사이에 해당 TCP에 대한 클러스터를 구축합니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
따라서 실제로 어떤 상자에 어떤 데이터가 있고 클러스터인지 여부에 대한 세부 정보를 얻을 수 없습니다. 데모 캐시가 있다는 것을 알고 있습니다. 해당 캐시에 연결할 때마다 응용 프로그램은 분할된 복제본의 경우 모든 서버에 자동으로 연결됩니다. 그래서, NCache 모든 세부 사항을 처리하고 여기에 와서 통계 보기라고 말하면 몇 가지 PerfMon 카운터가 켜져 있어 무엇을 볼 수 있는지 알 수 있습니다. NCache 하지만 일단 사용하기 시작하면 됩니다. 나는 또한이 도구를 시작합니다 NCache 감시 장치. 그리고 대시보드 스타일 도구와 같습니다. 그리고, NCache, 프로그래밍 없이 응용 프로그램 사용을 매우 빠르게 시뮬레이션할 수 있는 스트레스 테스트 도구를 사용하는 옵션이 있습니다.
예를 들어 스트레스 테스트 도구인 democache를 사용하여 one get one put과 같은 작업을 수행할 것입니다. 그리고 갑자기 이제 이 도구가 두 캐시 서버와 통신하고 각 상자에서 초당 약 700개의 요청을 수행하는 것을 볼 수 있습니다. 약 7~800개에서 최대 XNUMX개까지 가능합니다. 부하를 늘리고 싶다고 가정해 보겠습니다. 그래서 스트레스 테스트 도구를 하나 더 출시하려고 합니다.
이는 응용 프로그램에서 수행하는 것과 같습니다. 내 말은, 애플리케이션을 테스트하고 싶을 때 스트레스 테스트 도구를 사용하여 애플리케이션을 실행한 다음 점점 더 많은 스트레스를 추가한 다음 전체 시스템이 작동하는지 확인하고 싶을 것입니다. 따라서 지금은 캐시 구성 요소를 테스트하고 있습니다. 대부분의 고객이 평가할 때 수행하는 작업 NCache, 그들은 이 벤치마킹을 합니다. 따라서 우리가 벤치마크를 게시했지만 환경의 모든 것을 구성한 후에는 그렇지 않습니다. 나는 그들이 자신의 환경에서 모든 것을 검증한다는 것을 의미합니다. 따라서 이것을 점점 더 추가하면 이 로드가 두 배가 되는 것을 볼 수 있습니다.
스트레스 테스트 도구를 하나 더 사용하겠습니다. 계속 올라가는 것을 볼 수 있습니다. 바로 거기, 봐! 따라서 클라이언트 CPU를 최대로 사용할 수 있을 때까지 계속해서 더 많은 스트레스 테스트 도구를 추가할 수 있습니다. 그래서 저는 애플리케이션 서버에서 약 50%를 사용했습니다. 따라서 더 많은 스트레스 테스트 도구를 추가할 수 있습니다. 해당 클라이언트를 최대한 활용하면 클라이언트를 한 명 더 추가합니다. 그래서 제가 할 수 있는 방법입니다. 예를 들어 지금도 단 5,000개의 스트레스 테스트 도구로 초당 약 XNUMX건의 요청을 처리하고 있습니다. 따라서 이것으로 예를 들어 여기에서 이 모든 것을 모니터링할 수도 있습니다. 따라서 이를 통해 실제로 캐시가 어떻게 생겼는지 확인할 수 있습니다. 이제 개발자 관점에서 자세히 살펴보겠습니다.
ASP.NET 특정 캐싱
이제 캐시가 어떻게 생겼는지 알았으니 애플리케이션 내에서 캐시를 사용하는 방법을 살펴보겠습니다. 따라서 ASP.NET의 경우 내가 말했듯이 가장 먼저 해야 할 일은 세션에 대한 캐시를 사용하는 것입니다. 왜? 가장 쉽기 때문입니다. 프로그래밍도 없고 할 수 있는 노력도 없습니다. 관심 있는 캐시를 얼마나 빨리 구성할 수 있는지 보여 드렸습니다. NCache, 예를 들어 내가 여기에 와서 일부 샘플 코드로 들어가면 이미 열렸어야 하는데 그렇지 않습니다. 따라서 사용할 수 있는 ASP.NET 응용 프로그램은 다음과 같습니다. NCache 세션용 ASP.NET 사용. web.config로 이동하여 수정하면 됩니다. 그래서 web.config가 있습니다. 가장 먼저 해야 할 일은 조립 시 이 조립 라인을 추가하는 것입니다. NCache, 이 세션 저장소 공급자는 NCache ASP.NET 세션 저장소 공급자 인터페이스를 구현한 어셈블리입니다. 그래서 이것이 허용하는 것입니다 NCache 따라서 여기에 줄을 복사하면 바로 여기에 있는 세션 상태 태그로 이동합니다. 의 경우 NCache, 해당 태그를 복사하기만 하면 됩니다. 이 모드가 사용자 지정인지 확인하세요. 그래야 타사 캐시를 연결할 수 있기 때문입니다. NCache 캐시 이름이 지정되었는지 확인하는 것입니다.
그래서 일단 설치하고 NCache 그런 다음 캐시 서버에 서버 부분을 설치하고 응용 프로그램 서버에 클라이언트 부분을 설치합니다. NCache, 방금 했던 것처럼 캐시를 만들고 이것을 업데이트하면 됩니다. 사용을 시작하는 데 필요한 모든 노력입니다. NCache 그런 다음 모든 세션은 캐시에 있는 하나의 개체입니다. 해당 PerfMon 카운터에서 그렇게 하면 보고 있는 세션 수를 확인할 수 있습니다. 일반적으로 고객은 세 개의 캐시를 생성합니다. 그래서 우리는 여기에 하나의 캐시를 만들었습니다. 맞습니까? 따라서 고객은 세 개의 캐시를 만들 것입니다. 캐시 중 하나는 세션용입니다. 따라서 세션에 대해 별도의 캐시가 있습니다. 캐시 중 하나와 두 개의 캐시는 애플리케이션 데이터용입니다. 하나는 그들이 참조 데이터라고 부르는 것입니다. 다른 하나는 트랜잭션 데이터입니다. 트랜잭션 데이터는 매우 자주 변경되는 데이터입니다. 그리고 그들이 그렇게 하는 이유는 제가 살펴볼 다른 기능 때문입니다. 그러나 동일한 VM에서 둘 이상의 캐시를 생성할 수 있습니다. 따라서 세션 상태 저장을 위해 해야 할 일은 이것이 전부입니다. 매우 쉽고 프로그래밍이 필요하지 않습니다.
앱 데이터 캐싱
그러나 애플리케이션 데이터 캐싱을 수행하려는 경우 불행히도 .NET 공간에서 EF 코어는 마침내 타사 캐시를 연결할 수 있는 아키텍처를 제공합니다.
NCache 또한 그것을 지원합니다. 그러나 EF6을 포함한 EF6까지 아키텍처는 타사 캐시 연결을 실제로 지원하지 않았습니다. NHibernate는 오랫동안 그 아키텍처를 지원했습니다. 따라서 NHibernate의 경우 NCache 프로그래밍 없이 연결할 수 있습니다. 따라서 최소한의 기능으로 애플리케이션 데이터를 캐싱하더라도 API 호출 없이 그냥 할 수 있습니다. 그러나 대부분의 경우 애플리케이션 데이터 캐싱을 위해 정신적으로 준비해야 하며 프로그래밍을 해야 합니다. 하지만 매우 간단한 API입니다. 이 API는 ASP.NET 캐시 개체와 매우 유사합니다. 캐시 이름으로 캐시에 연결합니다.
이것이 어떻게 생겼는지 빠르게 보여드리겠습니다. 열어 보겠습니다. Azure VM 문제가 몇 가지 발생했습니다. 나는 이 모든 것이 열린 상태에서 이 다른 것들을 시작합니다. 정말 기본적인 콘솔 응용 프로그램이 있다고 가정해 보겠습니다. 가장 먼저 해야 할 일은 두 개를 연결하는 것입니다. NCache 어셈블리, 하나는 NCache.런타임, 다른 하나는 NCache.편물. NCache.Web은 호출하는 실제 API입니다. 그런 다음 이 둘을 연결하거나 이 두 네임스페이스를 다시 사용합니다. NCache.Runtime 그리고 .Web.Caching. 애플리케이션 시작 시 이름을 기반으로 캐시에 연결하고 데이터베이스와 마찬가지로 캐시 핸들을 얻습니다. 물론 ASP.NET 응용 프로그램에서는 응용 프로그램 시작 또는 InIt 메서드의 global.ASAX에서 이를 수행할 것입니다. 그런 다음 개체를 만들고 Cache.Add를 수행합니다. Cache.Add는 일종의 문자열인 키를 사용합니다. 이것은 좋은 키가 아닙니다. 귀하의 키는 훨씬 더 구체적이어야 하며 여기에 귀하의 개체가 있습니다. 당신은 그 전화를 걸고 이제 이것이 진행되고 있습니다. 분할된 복제본 토폴로지가 있는 경우 발생하는 상황은 애플리케이션이 연결되는 것입니다. 따라서 모든 상자는 모든 캐시 서버에 연결됩니다. 그래서 방금 Cache.Add를 했습니다. 맞습니까? 따라서 Cache.Add는 버킷 맵과 같은 분포 맵을 살펴봅니다. 모든 버킷에는 이 버킷에 들어갈 수 있는 키와 관련하여 해시 키 값 범위 측면에서 키 값 범위가 있습니다. 그래서 버킷 맵을 사용하여 모든 서버에 연결되어 있기 때문에 어떤 서버로 이동하고 통신해야 하는지 알 것입니다. 맞습니까?
그리고 여기에 세 번째 항목을 추가한다고 가정해 보겠습니다. 여기로 이동하여 항목 번호 XNUMX을 추가하고 비동기 복제를 활성화한 경우 응용 프로그램이 돌아가고 응용 프로그램이 완료됩니다. 캐시는 이제 이 파티션이 여기에 복제해야 한다는 것을 알고 있습니다. 따라서 대량 작업에서 비동기식으로 이것을 다른 상자에 복제하면 해당 항목이 즉시 두 위치에 있게 됩니다. 이것이 바로 Cache.Add가 내부에서 수행한 작업입니다.
알겠습니다. 저는 앞뒤로 갈 것입니다. 왜냐하면 저는 일종의 개요를 제공하고 싶었기 때문에 캐시는 어떻게 생겼는지, 어떻게 생성하는지, API가 어떻게 생겼는지 등을 보여주고 싶었기 때문입니다.
앱 데이터 캐싱 기능
이제 애플리케이션 데이터 캐싱을 위해 캐시를 사용할 때 해결해야 하는 문제가 무엇인지 살펴보겠습니다.
캐시를 최신 상태로 유지
우리는 캐시를 최신 상태로 유지하는 것에 대해 이야기했습니다. 맞습니까? 그렇다면 캐시를 어떻게 최신 상태로 유지합니까? 캐시가 최신인지 어떻게 확인합니까?
가장 일반적이고 모두가 지원하는 것 Redis 만료입니다. 절대 만료입니다. 따라서 캐시에 무언가를 추가할 때 여기에서도 여기에 만료를 지정한다고 가정해 봅시다. 즉, XNUMX분 후에 만료를 지정한다고 가정해 봅시다. 경우에 이렇게 말하면 NCache, NCache 서버에 인덱스를 만들고 해당 데이터를 모니터링하고 XNUMX분 후에 만료됩니다. 따라서 실제로는 지금부터 XNUMX분 후의 절대 날짜 시간 값을 실제로 지정합니다. NCache 해당 날짜의 시간 값에 해당 항목을 만료해야 한다는 것을 알고 있습니다. 따라서 캐시가 자동으로 데이터가 제거되었는지 확인하는 방법입니다. 그리고 그게 무슨 뜻인가요? 즉, 누군가가 데이터베이스에서 데이터를 변경할 것이라고 생각하기 때문에 이 데이터를 20분 이상 또는 XNUMX분 이상 유지하는 것이 정말 불편하다고 캐시에 말하고 있는 것입니다. 따라서 오랫동안 캐시에 보관하는 것이 안전합니다. 슬라이딩 만료라고 하는 또 다른 만료가 있습니다. 소리는 같지만 그 목적은 완전히 다릅니다. 슬라이딩 만료는 주로 정리에 사용됩니다. 따라서 세션이 있는 경우 이 세션을 사용하는 사람이 없으면 슬라이딩 만료를 사용하여 정리합니다. 따라서 누군가가 XNUMX분 동안 활동이 없으면 로그아웃하면 세션이 만료된 것으로 간주됩니다. 따라서 자동으로 제거됩니다.
데이터베이스 종속성 사용그러나 캐시를 최신 상태로 유지하는 것과는 아무런 관련이 없습니다. 절대 만료는 캐시를 최신 상태로 유지하는 것입니다. 그러나 절대 만료에는 큰 문제가 있습니다. 그리고 문제는 해당 데이터를 캐시에 오랫동안 보관하는 것이 안전하다고 추측하고 있으며 그 추측이 항상 정확하지는 않다는 것입니다. 그래서, 그 경우에 당신은 무엇을 합니까? 그런 다음 이 경우 캐시가 자체적으로 동기화할 수 있는 기능이 있어야 합니다. 데이터베이스에서 변경 사항을 발견하면 캐시가 데이터베이스가 무엇인지 알아야 한다는 의미입니다. 즉, 캐시는 캐시된 항목과 캐시에 알려야 하는 데이터베이스의 일부 데이터 사이에 관계가 있어야 하며 ADO.NET에서 SQL 캐시 종속성이라는 것이 있는 곳입니다. NCache 이는 SQL 종속성이며 Oracle 종속성이라고도 하며 실제로 매우 간단한 방식으로 작동합니다. 하지만 정말 강력한 기능입니다. 그리고, 우리는 여기로 옵니다. SQL 종속성을 사용하겠습니다. 따라서 캐시에 무언가를 추가할 때 동일한 Cache.Add를 수행합니다. 맞습니까? 캐시 키가 있습니다. 이제 캐시 항목을 지정하는 값 대신 NCache의 자체 데이터 구조이며 거기에는 값이 포함되어 있지만 SQL 캐시 종속성이라는 것도 포함되어 있습니다.
이 SQL 캐시 종속성은 NCache의 자체 클래스이지만 ADO.NET SQL 캐시 종속성에 매핑됩니다. 여기에 연결 문자열이 있고 SQL 문이 있습니다. 따라서 이 경우 SQL 문은 제품 테이블의 한 행에 매핑됩니다. 그래서, 여기서 실제로 무슨 일이 일어나고 있는 걸까요? 내 말은, 당신은 실제로 바로 여기에서 이 코드를 실행하고 있다는 뜻입니다. 귀하의 데이터베이스가 여기에 있으므로 방금 전달한 연결 문자열을 기반으로 캐시 클러스터에 데이터베이스에 연결하도록 요청하고 있으며 해당 연결 문자열을 기반으로 SQL 서버를 전달하고 있으며 내 SQL 서버 데이터베이스에 연결하십시오. 그리고 SQL 서버를 모니터링하여 이 데이터 세트에 변경 사항이 발생하면 캐시 서버인 사용자에게 알려줍니다. 즉, 이 행이 업데이트되거나 삭제되었는지 여부를 의미합니다. 이 경우 SQL 서버는 이 경우 캐시 서버인 클라이언트에 데이터베이스 알림을 보냅니다. 이 중 하나입니다. 그러면 캐시 서버는 무엇을 할까요? 캐시 서버는 캐시에서 해당 항목을 제거합니다. 제거는 더 이상 캐시에 없기 때문에 애플리케이션이 강제로 이동하여 현재 최신 복사본이 있는 데이터베이스에서 가져와야 함을 의미합니다. 따라서 만료는 교육적인 추측이지만 이것은 추측이 아닙니다. 이것은 캐시가 항상 데이터베이스와 일치하는지 확인하는 실제 예측 가능한 동기화입니다.
이제, NCache, 이를 수행할 수 있는 세 가지 방법이 있습니다. 하나는 실시간과 같은 데이터베이스 이벤트를 사용하는 SQL 종속성입니다. 다른 하나는 NCache그가 폴링을 사용하는 자체 DB 종속성은 이벤트 알림 메커니즘이 없는 데이터베이스 또는 SQL 서버에 대한 것입니다. SQL 종속성이 너무 많고 모든 SQL 종속성에 대해 추가 데이터 구조인 SQL 서버에서 SQL 캐시 종속성이 생성된다고 생각하는 경우입니다. 수십만 개가 생성되면 SQL 서버가 질식할 것이라고 생각해 보십시오. 따라서 이러한 동기화 방법을 사용하기 위해 많은 SQL 종속성이 있는 경우 좋은 생각이 아닐 수 있습니다. 그러면 모니터링하는 폴링 테이블이 있기 때문에 한 번의 호출에서 수천 개의 행을 동기화할 수 있는 DB 종속성이 훨씬 더 좋을 수 있습니다.
그리고 실제로 CLR 저장 프로시저를 작성하여 트리거에서 호출하도록 하는 세 번째 방법이 있습니다. 따라서 업데이트, 삽입, 업데이트 또는 삭제 트리거가 있는 경우 이 CLR 프로시저를 호출하십시오. 그리고 CLR 프로시저는 해당 행에서 데이터를 가져오고 응용 프로그램에서 사용 중인 .NET 개체를 구성하여 캐시에 저장합니다. 이제 캐시가 업데이트될 때까지 데이터베이스 트랜잭션 내에서 기다리기를 원하지 않기 때문에 비동기 API가 매우 유용한 곳입니다. 매우 빠르게 시간 초과되는 경향이 있는 데이터베이스 트랜잭션의 속도를 늦출 뿐입니다. 따라서 이 메커니즘을 구현하려는 경우 비동기 메서드를 사용하여 데이터를 이동하고 업데이트하는 것이 좋습니다.
이것이 캐시를 동기화할 수 있는 세 가지 방법입니다. 이 기능은 정말 중요합니다. 추측만 하지 않아도 캐시가 항상 최신 상태인지 확인할 수 있기 때문입니다. 그리고 동일한 방법으로 캐시를 비관계형 데이터베이스와 동기화할 수 있습니다. 사용자 지정 종속성 기능이 있습니다. NCache 당신의 코드는 무엇입니까 NCache 사용자 지정 데이터 저장소로 이동하여 모니터링할 수 있는 호출입니다. 사용자 정의 데이터 소스는 클라우드 저장소일 수 있습니다. 그것은 무엇이든 될 수 있습니다. 그것은 당신이 가서 확인할 수 있는 모든 코드입니다. 따라서 캐시를 최신 상태로 유지하는 것이 정말 중요하며 이를 보장할 수 있는 방법은 다음과 같습니다.
Read-through 및 Write-through
따라서 다음 기능은 read-through 및 write-through입니다.
Read-through는 기본적으로 다시 코드입니다. 이제 제가 말씀드리는 이 모든 기능은 NCache 가지고 있지만 그렇지 않다 NCache 오직. Java 캐시에는 모두 있습니다. Redis 가질 수도 있고 없을 수도 있습니다. 따라서 자세한 작업을 수행하려는 경우 수행해야 하는 작업입니다. Redis 있든 없든, 경우에 NCache 그냥 여기 와서 비교하러 가세요. Redis 대 NCache 기능 비교. 이것은 그들의 문서와 캐시 문서를 기반으로 합니다. 따라서 실제로 이것을 다운로드하고 이러한 모든 기능을 살펴볼 수 있습니다. 따라서 read-through는 기본적으로 캐시 서버에 있는 코드입니다. 그래서 이렇게 보입니다. 따라서 구현하는 것입니다. 그래서 그 인터페이스를 보여드리겠습니다. 읽기 인터페이스는 다음과 같습니다. 자, 여기에 읽기 인터페이스가 있습니다. 맞습니까? 손 모양 커서 NCache 그리고 데이터 소스에 연결하는 InIt이 있고, 처분하고 로드 방법이 있습니다. 따라서 load는 키를 제공하고 얻은 데이터를 기반으로 객체를 반환합니다. 그런 다음 만료 시간과 내용을 지정할 수 있습니다. write-through도 마찬가지입니다. InIt과 dispose가 있고 소스에 쓰기가 있다는 것입니다. 따라서 쓰기는 추가, 업데이트 또는 삭제일 수 있습니다. read-through write-through를 사용하는 위치는 어디이며 왜 그렇게 중요한가요?
우선 Read-through는 작동 방식을 통해 Cache.Get을 가질 수 있으며 캐시에는 데이터가 없습니다. 캐시는 읽기를 호출하여 데이터베이스에서 가져옵니다. 그것은 하나의 이점입니다. 두 번째 이점은 read-through를 만료 및 데이터베이스 동기화와 결합할 수 있다는 것입니다. 따라서 캐시에서 제거하는 대신 다시 로드합니다. Write-through는 캐시가 데이터베이스를 업데이트한다는 점에서 캐시만 업데이트한다는 것을 의미하는 write-behind가 있다는 점을 제외하면 동일한 방식으로 작동합니다. 따라서 업데이트도 매우 빨라집니다. 따라서 데이터베이스 성능이 병목 현상이 되는 곳마다 캐시를 통해 구제 조치를 받을 수 있습니다. 읽기 및 쓰기가 구현되면 모든 지속성 코드 또는 대부분을 캐싱 계층에 통합할 수 있으며 방금 언급한 이 두 기능의 이점을 모두 누릴 수 있습니다.
데이터 그룹화 및 데이터 검색
따라서 캐시를 최신 상태로 유지하고 연속 읽기 쓰기도 수행하면 이제 많은 데이터를 캐시하기 시작합니다. 따라서 캐시는 더 이상 단순한 키 값 저장소가 아닙니다. 모든 것을 키로 가져오는 것이 편리하지 않다는 뜻입니다.
검색할 수 있어야 합니다. SQL 검색을 할 수 있어야 합니다. 따라서 데이터베이스에서 익숙한 작업을 수행할 수 있어야 합니다.
캐시가 SQL 검색을 허용하지 않는 경우 분산 캐시이기 때문에 캐시에서 조인을 수행할 수 없기 때문에 매우 제한적이고 동일한 방식이 됩니다. 다른 기능 그룹화 및 하위 그룹화와 데이터를 그룹화하고 한 번의 호출로 가져올 수 있는 태그가 있습니다.
따라서 많은 데이터를 캐시하려는 경우 캐시에서 데이터를 쉽게 찾을 수 있도록 하는 것이 매우 중요합니다. 따라서 이러한 기능은 매우 중요합니다.
분산 캐시 기능
몇 가지만 빠르게 살펴보겠습니다. 제가 정말 손보고 싶었던 한 가지 기능은 Near Cache 또는 Client Cache입니다.
독립 실행형 InProc 캐시에 익숙한 사람들이 분산 캐시로 이동하면 네트워크를 통해 이동하기 때문에 갑자기 성능이 떨어집니다. 직렬화를 거쳐야 하고 갑자기 성능이 더 이상 빠르지 않습니다. 많은 고객들이 불만을 토로합니다. 성능이 올라갈 것으로 예상했지만 실제로는 떨어졌습니다. 그리고 그 이유는 힙에 객체가 저장된 독립형 InProc 캐시와 경쟁할 수 없기 때문입니다. 따라서 본질적으로 해당 개체를 로컬로 유지하지만 클러스터된 캐시에 연결되는 정확히 로컬 캐시인 클라이언트 캐시 기능이 있는 경우.
다시한번 말씀드리지만 이 기능은 NCache 대부분의 Java 캐시에는 손실 없이 동일한 빠른 성능을 실제로 제공하는 기능이 있습니다.
럭셔리 NCache, 우리 웹 사이트로 이동하여 오픈 소스 캐시를 다운로드할 수 있습니다. 따라서 오픈 소스 캐시 또는 Enterprise Edition을 다운로드할 수 있으며 앞서 말했듯이 NCache 과 Redis 그걸로.