Philly .NET 코드 캠프
ASP 최적화.NET Core 분산 캐시의 성능
이크발 칸
사장 및 기술 전도사
ASP.NET Core 트래픽이 많은 웹 애플리케이션 개발에 빠르게 인기를 얻고 있습니다. ASP 최적화 방법 알아보기.NET Core 오픈 소스 .NET 분산 캐시를 사용하여 속도 저하 없이 극단적인 트랜잭션 로드를 처리하는 성능. 이 강연에서는 다음을 다룹니다.
- ASP 개요.NET Core 성능 병목 현상
- 분산 캐싱 개요 및 성능 문제 해결 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 몇 가지 중요한 분산 캐시 기능
- 오픈 소스를 사용한 실습 예제 NCache 분산 캐시로
오늘의 주제는 ASP를 최적화하는 방법입니다..NET core 성능. 대화식 토론을 더 선호하므로 질문이 있는 경우 손을 들어 주십시오. ASP 때문에 여기 오신 것 같습니다..NET core 깨끗하고 가벼운 아키텍처를 가지고 있기 때문에 이제 새로운 .NET 응용 프로그램 또는 .NET 웹 응용 프로그램을 개발하는 데 널리 사용되는 기술입니다. 이미 ASP.NET에서 MVC를 사용하고 있을 것입니다. 그렇다면 ASP로 이동.NET core 꽤 쉬울 것입니다. ASP.NET core 가볍다. 크로스 플랫폼이고 오픈 소스이며 거대한 레거시 ASP.NET 사용자 기반이 있기 때문에 대부분의 사람들이 ASP로 이동할 가능성이 매우 높습니다..NET Core.
그래서 ASP.NET core 앞으로는 트래픽이 많은 웹 응용 프로그램 또는 트래픽이 많은 서버 응용 프로그램 및 웹 응용 프로그램을 개발하기 위한 .NET의 기술 선택이 될 것입니다. 그것은 ASP를 의미합니다.NET core 확장성이 필요하고 그것이 바로 여러분이 여기 있는 이유라고 확신합니다. 더 깊이 들어가기 전에 정의를 이해해 봅시다.
확장성이란 무엇입니까?
확장성이란 무엇입니까? 확장성은 본질적으로 XNUMX명의 사용자가 있는 애플리케이션이 있고 매우 빠르고 우수한 응답 시간을 수행하는 경우 XNUMX~XNUMX만 또는 XNUMX만 명의 사용자, 즉 동시 사용자가 있는 동일한 응답 시간과 동일한 성능을 유지할 수 있으면 애플리케이션이 확장 가능함을 의미합니다. 응용 프로그램이 XNUMX명의 사용자와 잘 작동하지 않는 경우 이것은 당신을 위한 이야기가 아닙니다. 당신은 아마도 당신이 데이터베이스에 액세스하고 전체 프로그래밍을 수행하는 방식을 살펴봐야 할 것입니다. 이것은 최소한 소수의 사용자를 위한 애플리케이션을 개발하는 작업을 잘 수행한 다음 이를 확장하는 방법을 알아야 한다고 가정하는 것입니다.
선형 확장성이란 무엇입니까?
선형 확장성은 프로덕션 환경에서 더 많은 서버를 추가할 수 있고 더 많은 서버를 추가할 때 선형 방식으로 트랜잭션 용량을 추가할 수 있음을 의미합니다.
이제 좀 더 자세히 설명하겠습니다. 두 대의 서버 웹 팜 로드 밸런싱으로 시작한다고 가정해 보겠습니다. 특정 수의 사용자가 지나면 이 두 서버가 최대치에 도달하고 성능이 느려지기 시작합니다. 그런 다음 세 번째 서버를 추가하면 갑자기 용량이 최소 XNUMX/XNUMX 또는 새 공식이 무엇이든 간에 증가해야 합니다. 그런 다음 세 개의 서버를 최대치로 만들면 다시 증분을 추가해야 합니다. 그렇게 할 수 있다면 선형적으로 확장 가능한 애플리케이션 아키텍처를 갖게 된 것입니다. 그렇게 할 수 없다면 비선형입니다.
비선형 확장성이란 무엇입니까?
비선형이란 기본적으로 몇 대의 서버 후에 서버를 추가해도 아무런 차이가 없다는 것을 의미합니다. 애플리케이션에 확장을 방해하는 병목 현상이 있기 때문입니다. 따라서 더 많은 부하를 추가하고 응용 프로그램이 충돌할 수 있는 정도까지 이야기하면 성능이 실제로 떨어질 것입니다. 따라서 기본적으로 특정 지점 이후에는 확장성이 없음을 의미하는 비선형 확장성을 원하지 않습니다.
확장성이 필요한 앱
그렇다면 어떤 유형의 애플리케이션에 확장성이 필요할까요? 이들은 모두 서버 응용 프로그램입니다. 이들은 ASP가 있는 웹 응용 프로그램입니다..NET core 웹 서비스, 다시 ASP.NET core. 마이크로서비스에서 개발한다면 마이크로서비스는 이제 큰 화두가 되고 있으며 컨테이너에서 실행할 수 있고 컨테이너화된 환경에서 실행할 수 있기 때문에 ASP도 실행할 수 있습니다..NET core 그러나 마이크로서비스는 확장성 또는 백엔드에서 많은 트랜잭션을 처리하는 다른 서버 애플리케이션에 대한 또 다른 매우 좋은 사용 사례입니다.
따라서 이러한 유형의 애플리케이션이 있는 경우 일반적으로 고객 대면, 출력 대면 애플리케이션이거나 최소한 출력 대면 애플리케이션의 일부입니다. 웹 서비스 응용 프로그램이 전체 웹 응용 프로그램의 일부일 수 있고 웹 서비스 계층이 있고 마이크로 서비스도 마찬가지지만 일반적으로 고객 대면 또는 출력 대면 애플리케이션이지만 항상 그런 것은 아니라고 가정해 보겠습니다. 대기업의 경우 수만 명의 내부 사용자가 있을 수 있지만 대부분 외부 사용자입니다.
확장성 문제 및 솔루션
따라서 확장성 문제가 있으며 이것이 오늘 이 대화를 나누는 이유이며 확장성 문제는 애플리케이션 계층에 없습니다. 따라서 부하 분산 환경이 있는 경우 애플리케이션 계층은 매우 선형적으로 확장됩니다. 더 많은 서버를 추가할 수 있습니다. 문제 없습니다. 데이터베이스 또는 데이터 저장소입니다. 저장하는 모든 유형의 데이터는 응용 프로그램 데이터일 수 있고 세션일 수 있으며 저장하거나 가져오는 다른 데이터일 수 있으며 병목 현상이 발생하기 때문에 그 이유 중 하나입니다. NoSQL databases 인기를 얻었습니다.
NoSQL Database
문제는 NoSQL databases는 관계형 데이터베이스에서 벗어나야 한다는 것입니다. 많은 상황에서 우리가 본 것 중 대부분의 경우를 말씀드리자면 다음을 사용할 수 있습니다. NoSQL databases 일부 데이터의 경우 그러나 많은 데이터가 여전히 관계형 데이터베이스에 상주해야 합니다. 따라서 여전히 Azure에서 SQL Server 또는 SQL 데이터베이스를 사용하게 됩니다. 따라서 관계형 데이터베이스로 이 확장성 문제를 해결해야 합니다. NoSQL databases는 사용할 수 없기 때문에 항상 답은 아닙니다. 관계형 데이터베이스를 NoSQL database 언제나. 그리고 교체할 수 없다면, 사용할 수 없다면 혜택을 받을 수 없습니다. 당신이 사용할 수 있더라도 NoSQL database, 그들은 여전히 메모리 분산 캐시가 제공하는 것보다 성능을 제공하지 않습니다. 그래서, 여러분은 여전히 제가 이야기하고 있는 많은 것들을 필요로 할 것입니다.
자, 실제로 무슨 일이 일어나는지 봅시다. 그리고 실제로 들어가 보겠습니다. 확장성 문제는 실제로 발생할 때까지 기다리기를 원하지 않는 문제입니다. 응용 프로그램을 개발 중이고 현재 성능이 좋고 천 명의 사용자에게 좋은지 또는 사용자 수에 관계없이 갑자기 비즈니스가 인기를 끌기 시작하면 훨씬 더 많은 고객이 찾아옵니다. 귀하가 마케팅을 하고 있거나 비즈니스 부서가 좋은 일을 하고 있는데 갑자기 귀하의 애플리케이션이 느려지기 시작하고 XNUMX초마다 느려지는 연구를 통해 문서화되었습니다. 웹 애플리케이션은 수익 손실을 초래합니다. 이러한 많은 온라인 비즈니스의 고객, 온라인 비즈니스 유형은 전자 상거래 비즈니스, 온라인 상점이 있는 소매 비즈니스이므로 건강 관리, 전자 정부, 소셜 미디어, 온라인 도박, 여행 산업이 될 수 있습니다. 많은 비즈니스가 온라인으로 전환하고 있습니다. 비즈니스를 수행할 소비자를 상대해야 하는 모든 비즈니스가 있기 때문입니다. 이들은 소비자 또는 수만 명이며 일반적으로 그들과 함께 온라인에 접속할 것입니다. 그리고 온라인이 항상 웹 애플리케이션인 것은 아닙니다. 백엔드와 통신할 모바일 애플리케이션이 있을 수 있기 때문에 웹 서비스 애플리케이션일 수도 있습니다.
따라서 확장성 문제가 발생할 때까지 기다리는 것은 좋은 생각이 아닙니다. 그럴 경우 비즈니스에 막대한 비용이 들게 되기 때문입니다. 더 많은 서비스를 추가하는 것이 도움이 되지 않을 때 비선형 곡선을 보았기 때문에 이러한 응용 프로그램은 느려질 것입니다. 따라서 이를 미리 계획해야 합니다. 애플리케이션 아키텍처가 올바르고 이를 활용하고 있는지 확인하십시오. 응용 프로그램 아키텍처에 분산 캐시를 통합하는 것이 모범 사례로서 필수 사항과 거의 같습니다.
분산 캐싱
그렇다면 분산 캐시는 어떻게 도움이 될까요? 나는 사용할 것이다 NCache 여기에 예를 들어 NCache .NET용 오픈 소스 분산 캐시입니다. GitHub에서 찾을 수 있고 우리 웹 사이트에서도 찾을 수 있으며 Enterprise Edition도 있습니다. 따라서 돈이 없거나 예산이 없다면 오픈 소스를 사용하십시오. 오픈 소스보다 더 많은 기능을 갖춘 더 많은 지원 버전을 원하는 경우 Enterprise를 사용하십시오. 그래서, 나는 사용할거야 NCache 예를 들어 하지만 나는 그것에 대해 이야기하지 않습니다 NCache. 전반적인 캐싱에 대해 이야기하고 있습니다. 그렇다면 분산 캐시는 어떻게 도움이 될까요? 자, 만약의 경우를 말하자면 NCache 두 개 이상의 서버로 구성된 클러스터를 생성하므로 캐싱 계층인 이 중간 계층이 두 개, 이 두 개의 서버, 여기에 있는 서버 수에 따라 두 개 이상이 될 수 있습니다. 여기에 얼마나 많은 짐이 있습니까?
따라서 분산 캐시가 없으면 데이터베이스는 실제로 관계형 데이터베이스를 배포할 수 없는 하나의 서버일 뿐입니다. 내 말은, SQL 서버 관계형 데이터베이스는 성능을 개선하려고 노력하고 있다는 것입니다. 예를 들어, 그들은 현재 메모리 테이블에 있습니다. SQL에는 데이터베이스의 읽기 전용 복제본도 있습니다. 따라서 읽기를 복제할 수 있지만 복제본의 문제는 업데이트할 때마다 다섯 곳 또는 네 곳에서 업데이트되기 때문에 모든 업데이트가 훨씬 느리다는 것입니다. 따라서 이를 해결하는 이상적인 방법은 아닙니다. 분산 캐시인 더 좋은 방법이 있습니다. 분산 캐시가 확장 가능한 이유는 분산이라는 단어 때문이고 분산될 수 있는 이유는 키 값 저장소이기 때문입니다. 모든 것은 키를 기반으로 저장됩니다. 키는 여러 파티션으로 쉽게 해시 매핑될 수 있으며 모든 파티션은 서버이며 이것이 배포를 달성하는 방법입니다.
따라서 최소 16개의 캐시 서버가 있으며 일반적인 구성은 메모리로 서버당 약 32~4기가입니다. 왜냐하면 다시 메모리 내 저장소이므로 많은 메모리가 필요하기 때문입니다. 그리고 클러스터를 형성합니다. 이 메모리와 CPU를 클러스터의 리소스로 가져오는 TCP 기반 클러스터입니다. 따라서 6개 또는 2개의 웹 서버가 있는 웹 응용 프로그램 지우기로 시작했다고 가정해 보겠습니다. 따라서 16개의 캐시 서버와 32~80GB의 메모리가 있고 이제 점점 더 많은 20%를 얻기 시작합니다. 캐시에 들어가는 시간 중 20%는 업데이트를 위해 데이터베이스로 갈 것입니다. 업데이트 횟수에 따라 2% 미만일 수도 있습니다. 일부 데이터의 경우 업데이트가 다른 데이터보다 많지만 여기서 다시 애플리케이션 계층에 더 많은 서버를 추가하고 데이터베이스에 수행한 작업을 다시 수행하게 됩니다. 캐싱 계층을 최대화할 것입니다. 따라서 서버가 8개뿐입니다. 여기 위의 웹 팜에서 약 XNUMX개의 서버에 도달했다고 가정해 보겠습니다. 내가 말했듯이 사용자가 많을수록 더 많은 애플리케이션 서비스를 사용할 수 있기 때문입니다. 그래서 이것은 최대가 될 것입니다. 최대치에 도달하자마자 세 번째 서버를 추가했습니다. 그리고 이들은 매우 고급 서버가 아닙니다. 이들은 저비용 서버입니다.
일반적으로 일반적인 서버는 약 8개의 코어입니다. 30기가 이상의 램을 얻는다면 RAM이 많을수록 더 많은 가비지 수집이 있기 때문에 16코어로 가야 합니다. 관리되는 메모리가 아니기 때문에 더 많은 처리 능력이 필요하기 때문입니다. 그러나 우리는 대부분의 고객에게 권장하며 이러한 권장 사항은 오픈 소스에도 적용되므로 고객에게 서버당 16~32기가 RAM을 권장합니다. 정말 고급 서비스를 받는 대신 서버를 추가하기만 하면 됩니다. 서버를 추가하는 서비스는 거의 없습니다. 따라서 20,000개의 서버가 최대가 되면 30,000번째 서버를 추가하고 같은 일이 진행되면 20,000번째 또는 XNUMX번째 서버를 추가할 수 있습니다. 필요한 트랜잭션 용량이 무엇이든 간에 최대치에 도달하지 못할 것입니다. 예를 들어 XNUMX XNUMX명의 동시 사용자가 있는 경우 대부분의 웹 응용 프로그램에서 거의 최고 수준입니다. 더 많은 서버가 있을 수 있으며 아마도 XNUMX만 명 이상의 동시 사용자가 있을 수 있지만 동시 사용자가 XNUMX명이라면 매일 수백만 명의 사람들이 웹 사이트를 방문한다는 의미입니다. 일. 그래서, 우리는 그 규모에 대해 이야기하고 있습니다.
이 때문에 이제 갑자기 데이터베이스가 더 이상 병목 현상이 아닙니다. 귀하의 캐싱 애플리케이션 데이터… 따라서 공통 캐시입니다. 공유 캐시입니다. 따라서 이 캐시를 여기에 넣으면 인메모리 캐시이기 때문에 인메모리는 하나의 캐시 서버가 다운되면 데이터를 잃게 된다는 것을 의미합니다. 즉, 캐시는 지능형 복제를 제공해야 하지만 NCache 하나의 서버가 다운되면 다른 서버에 해당 데이터의 복사본이 있는지 확인하지만 너무 많은 복사본을 만들면 전체 속도가 느려집니다. 그래서, NCache 데이터 사본을 하나만 만들고 파티션을 나눕니다. 모든 파티션에는 다른 서버에 백업이 있으며 한 서버가 다운되는 즉시 파티션이 다른 복사본을 만듭니다. 그리고 공유 캐시를 가짐으로써 이제 이러한 상자는 상태 비저장 상태가 됩니다. Stateless는 응용 프로그램 계층에 저장되는 데이터가 없음을 의미합니다.
따라서 해야 할 일은 응용 프로그램 계층이 상태 비저장이라는 목표를 달성할 수 있을 때입니다. 즉, 간섭을 일으키지 않고 응용 프로그램 서버를 중단할 수 있습니다. 패치, 운영 체제 패치 또는 응용 프로그램 업그레이드를 적용해야 한다고 가정해 보겠습니다. 모든 데이터가 데이터베이스 또는 이 계층에 있으므로 쉽게 도청될 수 있기 때문에 여기에서 계속 적용할 수 있습니다.
분산 캐시 사용 사례
이제 캐싱을 사용해야 하는 이유에 대한 사례를 설정했으므로 이점은 무엇입니까? 어떤 문제를 해결하고 그 문제를 어떻게 해결합니까? 첫 번째 질문은 무엇을 위해 사용합니까? 사용 사례는 무엇입니까? 응용 프로그램의 어디에 분산 캐시를 사용합니까?
앱 데이터 캐싱
첫 번째는 애플리케이션 데이터 캐싱입니다. 그것은 내가 이미 이야기한 유스 케이스입니다. 응용 프로그램 데이터가 있는 데이터베이스가 있고 이 데이터를 캐시에 저장하여 데이터베이스로 이동할 필요가 없다는 것입니다. 이제 염두에 두어야 할 한 가지 사항이 있습니다. 애플리케이션 데이터 캐싱에서 데이터에는 두 개의 복사본이 있습니다. 하나는 데이터베이스인 마스터에 있고 다른 하나는 캐시에 있습니다. 데이터가 두 곳에 상주하는 상황이 발생할 때마다 무엇이 잘못될 수 있습니까? 예, 두 복사본이 일치하지 않거나 동기화되지 않을 수 있습니다. 즉, 캐시가 오래될 수 있습니다. 따라서 여전히 캐시가 되는 모든 캐시는 정적 데이터, 읽기 전용 데이터만 캐시하도록 합니다. 그리고 읽기 전용 데이터는 전체 데이터의 20%에 불과하며 80%는 트랜잭션 데이터라고 합니다. 트랜잭션 데이터를 캐시할 수 없는 경우 해당 캐시는 사용자를 제한할 것입니다. NCache 몇 가지 정말 강력한 기능과 다시 모든 오픈 소스, 캐시를 항상 최신 상태로 유지하는 데 도움이 되는 정말 강력한 기능이 있습니다. 좋아요 그리고 그 순간으로 들어가겠습니다.
ASP.NET Core 특정 캐싱
두 번째 사용 사례는 다시 앱 데이터 캐싱이 ASP용이라는 것입니다..NET core 다른 응용 프로그램도 있지만 ASP.NET core, 적어도 두 가지 다른 용도가 있습니다. 하나는 다음과 같은 분산 캐시에서 세션을 복원할 수 있는 세션입니다. NCache 이를 수행하는 데 프로그래밍이 필요하지 않으므로 정말 빠릅니다. 애플리케이션에 가장 빠른 성능 이점을 얻고 싶고 애플리케이션이 이미 라이브 상태이거나 완료되었다고 가정하면 다음과 같이 분산 캐시에 세션을 표시하기 시작합니다. NCache. 그리고 프로그래밍이 없기 때문에 필요한 경우 수행해야 하는 테스트가 거의 없습니다. 물론 모든 것이 환경에서 제대로 작동하는지 확인하기 위한 몇 가지 기본적인 온전성 테스트가 있지만 관련된 개발 노력은 없습니다. 그 때문에 개발 일정과 릴리스 일정이 관련되어 있지 않습니다. 아주 아주 빨리요.
두 번째 ASP.NET core 특정 캐싱은 응답 캐싱 이는 ASP.NET에 있으며 ASP에서는 출력 캐시라고 불렀습니다..NET core 그들은 실제로 더 많은 표준 기반으로 만들었습니다. 이제 타사 에지 캐싱 솔루션에서 이해할 수 있는 HTTP 기반 캐싱 지시문을 사용하지만 본질적으로 페이지의 출력을 캐싱하므로 다음에 해당 페이지가 호출될 때 출력이 동일할 경우 페이지를 실행하는 이유는 무엇입니까? 출력물만 전달하면 안 되는 이유는 무엇입니까? 이제는 출력이 매우 자주 변경되지 않는 상황에서 좋은데 매우 동적인 응용 프로그램이 있는 경우 정적 접촉이 많지 않을 것입니다. 짧은 기간 동안 가질 수 있어도 여전히 저장됩니다. 그래서 ASP.NET core 응답 캐싱에는 미들웨어 개념이 있으며 다음과 같은 분산 캐시를 연결할 수 있습니다. NCache 기본적으로 ASP와 동일한 계층에 있는 미들웨어로.NET core 또는 동일하지만 미들웨어 캐시가 여기에 있을 수 있으며 여기에 실제 ASP가 있습니다..NET core 애플리케이션. 이것이 분산 캐싱에 대한 두 번째로 큰 일반적인 사용 사례입니다. 이에 대해 좀 더 자세히 살펴보겠지만 저는 단지 개요만 제공할 뿐입니다.
Pub/Sub 메시징 및 이벤트
세 번째 사용 사례는 많은 사람들이 무엇을 할 수 있는지 모르는 것입니다. 게시/구독 메시징 분산 캐시가 있는 이벤트. Pub/Sub 메시징을 사용하면 여러 애플리케이션 또는 애플리케이션의 여러 인스턴스가 비동기 이벤트 기반 방식으로 데이터 정보를 공유하여 서로 작업을 조정할 수 있습니다. 우리가 이것을 연결할 수 있는 몇 가지 예는 무엇입니까? 다시 말하지만 마이크로서비스는 독립적으로 분리된 서비스이지만 서로 조정해야 합니다. 내 말은 하나의 마이크로 서비스가 다른 마이크로 서비스에서 사용하는 무언가를 생성할 수 있다는 뜻입니다. 즉, 작업 흐름이 수행되는 방식이지만 서로 직접 의존하지 않으려고 합니다. 그렇지 않으면 전체 모델이 중단됩니다. 그래서 당신이 하는 일은 실제로 이것을 더 이상 데이터베이스를 위한 캐시가 아니라고 생각하는 것입니다. 하지만 이것을 생각하면 실제로 .. 잠시만 시간을 주세요. 한 장의 사진을 위해 회전할 것입니다. 생각해보세요. 이제 메시징 플랫폼으로 분산 캐시.
따라서 이제 응용 프로그램이 있다는 전체 패러다임 전환입니다. 마이크로 서비스 또는 기타 애플리케이션을 실행하는 여러 VM 또는 컨테이너일 수 있으며 게시/구독 방식으로 서로 통신할 수 있습니다. 따라서 주제가 있고 게시자와 구독자가 있으므로 애플리케이션이 정말 간단해집니다.
이제 토끼 및 MSMQ 메시징 대기열 요구 사항과 같은 다른 Pub/Sub 솔루션이 있습니다. 다음과 같은 분산 캐시의 특별한 점은 무엇입니까? NCache? 왜 이것을 저것보다 사용해야 합니까? 분산 캐시를 사용하는 이유는 이것이 매우 빠르기 때문입니다. 그것은 모두 기억 속에 있습니다. 메시지 큐가 가질 수 있는 모든 기능을 가지고 있지는 않습니다. 메시지 큐는 지속성이고 메시지를 장기간 저장하기 때문입니다. 그러나 많은 상황에서 모든 것이 동일한 데이터 센터 내에서 실행되고 실제로 트랜잭션 환경이지만 워크플로우에 더 많이 사용하고 있다면 복제가 충분합니다. 모든 데이터가 둘 이상의 서버에 보관되어 있다는 사실은 메시지와 이벤트가 손실되지 않도록 하는 데 충분합니다. 따라서 두 개의 데이터 복사본이 있어 문제의 성격이 다른 애플리케이션 데이터 캐싱과 달리 캐시를 최신 상태로 유지해야 합니다. 두 번째와 세 번째 경우에는 그 반대입니다. 캐시인 데이터 복사본이 하나만 있습니다. 따라서 이제 캐시 내에는 복제 목적으로 일관된 복사본이 두 개 이상 있어야 합니다. 복사본이 없으면 메모리에 있는 캐시가 데이터를 잃게 되기 때문입니다. 따라서 서버가 다운된 경우에만 메시지, 세션 및 페이지 출력을 잃고 싶지 않을 것입니다. 따라서 이벤트의 Pub/Sub 메시징은 일반적으로 분산 캐시의 매우 강력한 사용 사례이며 이 모든 것이 오픈 소스입니다.
그래서 다른 기능이 있습니다 NCache 실제로 다른 .NET 공간 캐시에는 없는 연속 쿼리라고 합니다. 일부 Java 캐시에는 있습니다. 연속 쿼리를 사용하면 캐시에 쿼리의 SQL 유형을 지정할 수 있습니다. 그래서. 이 속성을 가진 고객 개체가 캐시에서 추가, 업데이트 또는 삭제된 적이 있으면 알려주십시오. 따라서 이제 모든 개체를 직접 볼 필요가 없습니다. 어쨌든 확인할 수 없거나 확인해야 하는 경우 캐시가 자동으로 처리합니다. SQL 종속성의 SQL Server와 유사합니다. 데이터 세트를 모니터링하고 해당 데이터 세트가 변경될 때 알림을 받도록 서버에 요청할 수 있습니다. 테이블에 있는 하나 이상의 행을 제외하고 여기서는 분산 캐시에 있는 개체입니다. 이것이 세 가지 일반적인 사용 사례입니다.
ASP.NET Core – 앱 데이터 캐싱
따라서 가장 일반적인 사용 사례는 애플리케이션 데이터 캐싱이라고 생각합니다. 실제로 분산 캐시라는 단어는 Microsoft 생태계 단어에 가깝습니다. Java 측에서는 메모리 데이터 그리드에서 호출됩니다. 우리는 세 단어를 사용합니다. 우리는 분산 캐시를 사용하고 Java 사용자의 웹 이점을 위해 메모리 데이터 그리드에서 사용합니다. Microsoft 에코시스템에 속해 있지만 말입니다. 따라서 우리는 그렇게 많지 않으며 분산된 메모리 내 데이터 저장소가 있습니다. 따라서 애플리케이션 데이터 캐싱은 분산 캐싱 사용 사례입니다.
IDistributedCache 인터페이스
따라서 애플리케이션 데이터 캐싱을 사용하려는 경우 이를 수행할 수 있는 세 가지 방법이 있습니다. IDistributedCache 인터페이스가 있으며 ASP.NET 4에서 사용할 수 있습니다. 기본적으로 다음과 같습니다.
매우 간단한 인터페이스. Microsoft는 마침내 아래에 있는 모든 분산 캐시를 플러그인할 수 있는 인터페이스를 제공했습니다. 이것의 유일한 문제는 정말 간단하다는 것입니다. 따라서 이것을 통해 많은 것을 할 수 없습니다. 정말 기본만 하시면 됩니다. 그리고 그것이 하는 유일한 일은 당신에게 만료를 주는 것입니다. 만료되는 캐시 항목 옵션을 지정할 수 있습니다. 네! NCache 이를 구현하므로 IDistributedCache 인터페이스를 통해 프로그래밍하는 경우 플러그인만 하면 됩니다. NCache 코드를 변경하지 않고 추가 코드를 변경하고 프로그래밍을 완료했지만 이렇게 하는 것은 권장하지 않습니다. 특징? 왜 사용하면 안되나요? 이제 나는 그것과 함께 갈 것입니다.
Entity Framework Core Cache
다른 하나는 EF 코어를 수행하는 경우, 다시 작성하려는 코드를 최소화하려는 경우, NCache EF 핵심 확장 메서드 공급자를 제공하므로 이를 빠르게 보여드리겠습니다. 따라서 EF 핵심 확장 방법은 캐시를 사용하는 방식을 실제로 단순화합니다. 다시 말하지만 IDistributedCache와 마찬가지로 기능이 광범위하지 않습니다.
예를 들어 일반적인 EF Core 또는 EF LINQ 기반 쿼리를 보고 싶다고 가정해 봅시다. 팀 뒤에서 이 쿼리를 먼저 살펴보고 캐시에 저장합니다. 캐시에 있는 경우 캐시에서 가져오거나 그렇지 않으면 데이터베이스로 이동하여 가져오고 캐시하기 전에 캐시합니다. 따라서 프로그래밍을 상당히 단순화합니다. 그것이 당신이 원하는 것이라면 이미 EF 핵심 응용 프로그램이 있고 가능한 한 빨리 연결하고 싶다고 가정해 보겠습니다. NCache 거기에 보시다시피 이것이 있습니다.
NCache API
세 번째 옵션은 NCache 상당히 간단한 API이기도 한 API. NCache API는 ASP.NETcache 개체와 거의 동일해 보이지만 우리가 시도한 것 이상이지만 오래 전에 나왔습니다. ASP.NET Core 주변에 있는 개체에 대한 유일한 인터페이스이므로 가능한 한 가깝게 유지하려고 했습니다.
간단한 개념입니다. 캐시에 연결하고, 캐시 핸들을 얻고, cache.get을 수행하고, 인덱스가 있거나 잊어버리고, 포함을 수행하고, 추가, 삽입, 제거를 수행할 수 있으며 이러한 작업은 캐시가 업데이트될 때까지 기다릴 필요가 없도록 이들의 비동기 버전입니다. 분명히 그 이상이 있습니다. 따라서 이러한 종류의 정보는 캐시를 사용하는 것이 얼마나 간단한지 보여줍니다.
앱 데이터 캐싱 기능 – 캐시를 최신 상태로 유지
이제 제가 오고 싶었던 것은 이 페이지였습니다. 네, 캐시 사본 두 개를 말씀드린 것 같습니다. 캐시를 최신 상태로 유지할 수 없다면 사용을 실제로 제한하게 됩니다. 이해하는 것이 매우 중요합니다. 캐시는 무엇을 합니까?
만료(절대 + 슬라이딩)
대부분의 캐시는 만료를 제공합니다. 만료는 또한 TTL(Time to Live)이라고도 합니다. 우리는 이를 절대 만료라고 부릅니다. 왜냐하면 ASP.NET 캐시 개체가 이 용어를 사용하는 곳이기 때문에 그대로 유지했기 때문입니다. 무엇을합니까? 당신은 객체를 캐시에 추가하고 있습니다. 당신은 지금부터 10분 또는 지금부터 XNUMX분 동안 객체를 캐시하는 것이 안전하다고 생각하기 때문에 만료시키라고 말하고 있습니다. 일부 참조 데이터 사례에서 괜찮은 교육적 추측을 하고 있습니다. 예를 들어 제품 카탈로그가 있습니다. 아마 XNUMX분마다 바뀌지는 않을 겁니다. 가격은 거기에서 변하지 않을 것입니다. 따라서 일부 상황에서는 더 예측 가능한 변화입니다. 따라서 거기에 표현을 사용하는 것은 괜찮습니다. 그러나 고객이나 활동을 캐싱하는 경우 고객이 전화를 걸어 변경 사항을 적용할 것이기 때문에 언제 변경될지 알 수 없으므로 만료만으로는 살 수 없을 수도 있습니다. 그래서 캐시에 다른 기능이 필요한 곳이고 이 모든 기능이 캐시에 있는 곳입니다. NCache 오픈 소스로.
데이터베이스와 캐시 동기화
특징 중 하나는 NCache 데이터베이스와 동기화할 수 있습니다. 이제 데이터베이스는 SQL Server일 수도 있고 Oracle일 수도 있고 폴링의 경우 OLEdb일 수도 있지만 동기화는 다음을 의미합니다. NCache 클라이언트가 되면 캐시 서버는 데이터베이스의 클라이언트가 됩니다. 이제 내가 말한 SQL 종속성을 사용합니다. 연속 쿼리와 동일하지만 SQL 서버용입니다. 그것은 SQL 종속성을 사용할 것이고 이것이 어떻게 작동하는지 보여드리겠습니다.
예를 들어... 추가할 때 이 제품 개체를 캐시에 추가하여 키를 얻고 제품이 포함된 캐시 항목을 갖게 되었다고 가정해 봅시다. 원하는 것은 제품 테이블에서 특정 제품을 식별하는 SQL 문을 지정하려는 것이며 이 SQL 문은 SQL 서버용입니다. 당신은 이벤트 캐시를 전달, NCache SQL 서버에 전달합니다. NCache, 이 제품을 캐시할 때 이제 SQL 서버가 있는 레지스터에 SQL 종속성을 알리고 매핑을 유지합니다. 따라서 SQL 서버가 이벤트를 보내면 NCache 이 제품이 지금 데이터베이스에서 업데이트되었다고 말합니다. NCache 여전히 캐시에 있음을 알고 있습니다. 따라서 두 가지 중 하나를 수행합니다. 캐시에서 제거하기만 하면 됩니다. 내 말은 애플리케이션이 아무 것도 할 필요가 없다는 뜻입니다. 모든 것이 캐시에 의해 수행되고 있거나 read-through라는 이 기능을 구현한 경우 자동으로 항목을 다시 로드합니다. 그래서, 나는 조금 후에 데이터베이스에 올 것이다. 따라서 데이터베이스 동기화는 매우 강력한 기능입니다. 그것은 당신에게 마음의 평화를 제공하고 모든 데이터를 캐시합니다. 그것 없이는 탐색만 하는 경우에는 제한적이며 기본적인 방식으로 캐싱에 대해 알고 있는 일반 사람과 대화하면 캐싱에 대해 "아, 그건 읽기 전용 데이터입니다"라는 반응을 보일 정도로 안타깝습니다. 캐싱은 정적 데이터 전용입니다. 모든 사람이 트랜잭션 데이터를 만지는 것을 두려워하는데, 이는 만료가 제품 카탈로그 및 기타와 같이 보다 예측 가능한 경우에 유효할 수 있는 교육적인 추측에 지나지 않기 때문입니다. 하지만 트랜잭션 데이터에는 유효하지 않습니다.
비관계형으로 캐시 동기화
따라서 비관계형 데이터 저장소가 있는 경우에도 동일한 문제가 발생합니다. 클라우드에 있는 것일 수도 있고 레거시 데이터베이스일 수도 있고 메인프레임일 수도 있습니다. 해당 알림에 있지 않은 경우를 제외하고는 SQL 종속성과 동일한 목표를 달성할 수 있습니다. 사용자 지정 종속성은 사용자가 구현하는 것입니다. 이것이 서버 측 코드라는 것은 귀하의 코드이므로 NCache 이 서버 측 코드 개념이 있습니다. 사용자가 작성한 코드는 캐시 서버에 상주합니다.
Read-Thru 및 Write-Thru사용자 정의 의존성은 하나이고, 읽기를 통한 쓰기는 또 다른 것입니다. 방금 read-through에 대해 이야기했는데 데이터베이스 동기화에서 항목을 제거하는 경우 항목을 다시 로드할 수 있습니다. NCache 가서 다시로드 할 수 있습니다. 어떻게 다시 로드할 수 있습니까? 당신의 읽기 코드를 통해. 리드스루란 무엇입니까? 이리저리 뛰어다니는 것 같지만 이 .s를 연결하고 싶었습니다. 어떻게... 쓰기 및 읽기는 간단한 인터페이스이므로 여기에 읽기 인터페이스가 있습니다. 예 세 가지 방법에는 데이터 소스에 연결할 수 있는 초기화가 있습니다. Dispose는 연결 해제이며 LoadFromSource의 과부하입니다. 따라서 LoadFromSource는 키이며 캐시 항목을 반환하고 LoadFromSource에는 사전을 반환할 수 있는 오버로드가 있습니다. 따라서 LoadFromSource는 NCache read-through 핸들러를 호출합니다.
따라서 귀하의 애플리케이션이 Cache.Get을 수행하고 해당 항목이 캐시에 없다고 가정해 보겠습니다. NCache 캐시에 없으면 read-through 핸들러로 이동하여 요청하십시오. NCache Read-through 핸들러는 캐시 클러스터 내에 있는 코드이기 때문에 read-through 핸들러를 호출합니다. NCache 이 메서드를 호출합니다. 이 메서드는 코드이고, 데이터베이스로 이동하고, 무엇이든 될 수 있는 데이터 소스는 SQL이거나 메인프레임이라고 할 수 있으며 데이터를 가져온 다음 넣습니다. 이제 NCache 데이터베이스로 이동할 수 있는 기능이 있습니다. 이는 자동 재로드를 수행할 수 있음을 의미합니다. 그래서 그것은 편의 부분입니다. 따라서 관계형 데이터베이스 및 비관계형 데이터베이스와 동기화할 수 있습니다.
관계형 데이터 캐싱
마지막은 관계형 데이터를 캐싱하는 것입니다. 데이터 응용 프로그램으로 장부 관리를 수행하고 하나의 데이터와 다른 데이터와의 관계를 추적해야 합니다. 주문이 여러 개인 고객의 예를 들어 보겠습니다. 일반적으로 고객을 삭제하지는 않지만 캐시에서 이를 알지 못하므로 캐시에서 고객 개체를 삭제하고 캐시에 XNUMX개의 주문이 있다고 가정해 보겠습니다. 더 이상 유효하면 캐시에 보관하면 안 됩니다. 따라서 one-to-many가 있을 때마다 일반적으로 many는 one에 의존하므로 캐시에서 하나를 삭제하면 캐시에서도 many를 삭제해야 합니다. 이제 하나를 삭제할 때마다 추적하고 여러 개를 삭제해야 합니다. 따라서 대신 할 수 있는 것은 ASP.NET 캐시 개체에 종속성 개념이 첨부되었다는 것입니다. NCache 이 두 가지를 연관시킬 수 있도록 이를 구현한 다음 고객 개체가 업데이트되거나 이동되면 모든 주문이 자동으로 제거됩니다.
너무 많은 일대일에 대해 캐시 종속성을 사용할 수 있으며 컬렉션을 캐시하고 개별 개체를 별도로 저장하려는 경우에도 사용할 수 있습니다. 따라서 고객 컬렉션에 하나의 개체가 캐시되고 일부 고객도 개별적으로 캐시되었습니다. 캐시에 여러 복사본을 보관할 수 있기 때문입니다. 그것은 모두 귀하의 응용 프로그램에 의해 유지되고 있습니다. 따라서 정규화 및 데이터 무결성이 있어야 하는 데이터베이스와 달리 캐시는 성능에 관한 것이기 때문에 여러 복사본을 가질 수 있습니다. 여러 복사본이 있고 하나의 복사본이 업데이트될 때 정리할 수 있어야 하며 이것이 이 캐시 종속성을 통해 수행할 수 있는 것입니다. 이것이 캐시를 최신 상태로 유지하는 네 가지 방법입니다. 모두 다음의 일부로 사용할 수 있습니다. NCache open source.
앱 데이터 캐싱 기능 – Read-Thru 및 Write-Thru
나는 read-through write-through를 다시 통과했습니다. write-through는 read-through와 동일합니다. 단, 캐시를 업데이트할 때 캐시에 가서 데이터베이스를 업데이트하도록 요청합니다.
Read-through 및 Write-through
따라서 read-through는 캐시를 읽을 때 데이터가 없는 경우 데이터베이스에서 읽도록 캐시에 요청하는 것입니다. 이제 읽기 및 쓰기를 통해 지속성 코드를 하나의 캐싱 계층으로 통합할 수 있습니다. 그리고 캐시가 데이터베이스를 더 잘 인식하게 하면 애플리케이션이 더 단순해지고 간단해집니다.
후기 쓰기
write-through는 또한 데이터베이스를 업데이트할 때마다 쓰기(Write Behind)라는 추가적인 이점이 있습니다. 즉, 애플리케이션에서 가장 느린 작업이 데이터베이스를 업데이트하는 것입니다. 데이터베이스에서 데이터를 가져오는 것보다 훨씬 느리고 데이터를 가져오기 위해 캐시를 사용하는 경우 데이터베이스에 많이 갈 필요가 없습니다. 데이터가 그다지 중요하지 않은 경우 업데이트된 데이터에 캐시를 사용하지 않는 이유는 무엇입니까? 이는 비동기 업데이트를 위해 대기열에 올릴 수 있음을 의미합니다. 데이터가 매우 민감한 경우 분명히 비동기 업데이트를 위해 대기하고 싶지 않지만 많은 데이터는 비동기 업데이트를 위해 대기할 수 있습니다. 대기하고 기본적으로 쓰기 뒤에 기능을 수행할 때 NCache 비동기 방식으로 데이터베이스에 작성하려면 대기열이 구축되거나 여러 업데이트 요청이 있을 때 해당 대기열이 여러 서버에 복제되므로 서버가 다운되는 경우에도 손실되지 않습니다. 그리고 더 이상 데이터베이스가 업데이트되기를 기다리지 않기 때문에 애플리케이션의 속도가 확실히 빨라집니다. 따라서 write-through는 성능상의 이점이 있습니다. 그리고 뒤에 쓰기 .. Read-through에는 모든 이점이 있습니다.
아이템 자동 재장전
만료 시 자동으로 다시 로드할 수도 있습니다. 따라서 만료되면 해당 항목을 자동으로 다시 로드할 수 있습니다. 만료는 기본적으로 데이터베이스 서버에서 변경될 수 있습니다. 캐시에서 더 이상 유효하지 않으므로 제거하지 않습니다. 어쨌든 필요할 것이기 때문에 로드하지 않는 이유는 무엇입니까? 그런 다음 아마도 일종의 조회 데이터이므로 자동으로 읽습니다. 다시 말하지만, 캐시는 애플리케이션에서 점점 더 많은 작업을 대신합니다.
앱 데이터 캐싱 기능 - 데이터 그룹화
캐시를 최신 상태로 유지할 수 있고 확신이 들면 이제 많은 데이터를 캐시하기 시작합니다. 많은 데이터를 캐시하기 시작하면 이 키 값 쌍을 넘어서는 데이터를 검색할 수 있다면 정말 좋습니다. 어젯밤에 누군가와 이야기를 나눴는데 그들은 다른 유형의 데이터를 찾기 위해 키를 포맷하는 방법에 대한 기술을 생각해 내야 했습니다. 이것은 당신이 할 필요가없는 것입니다 NCache. 그룹, 하위 그룹, 태그 및 명명된 태그라는 메타 태그를 할당할 수 있습니다. 이것은 키 이름을 바꾸는 대신 개체에 할당할 수 있는 메타데이터입니다. 이것들은 더 나은 데이터가 될 수 있으며 이를 바탕으로 이 태그 또는 이 두 태그 또는 이 세 태그가 있는 모든 것을 제공하거나 이 그룹에 속한 모든 것을 제공한다고 말할 수 있습니다. 그게 하나야.
두 번째로 SQL 쿼리를 수행할 수 있습니다. 보여드리겠습니다. 따라서 캐시는 점점 더 데이터베이스처럼 보이기 시작합니다.
예를 들어 여기에서 이 이름을 가진 모든 제품을 선택한다고 말하면 이제 제품 개체의 속성을 기반으로 검색을 수행하게 됩니다. 이제 이것은 많은 NCache SQL Server처럼 execute.reader를 수행하도록 코드를 작성합니다. 그것은 매우 유사합니다. Icache 리더를 되찾고 그것을 통해 당신의 물건을 살펴보십시오. 이제 이것은 다시 캐시가 필요한 모든 작업을 수행하도록 만드는 것입니다. 한편으로는 많은 양의 데이터를 캐시에 넣었고 이제 캐시에서 데이터를 검색할 수 있습니다.
ASP.NET Core 세션 저장
ASP에 대해 이야기했습니다..NET core 세션. 나는 당신이 그것을 사용할 수있는 두 가지 방법이 있다는 것을 명심해야 할 주요 사항이라고 생각합니다.
IDistributedCache 저장소
하나는 연결하는 것입니다. NCache. NCache IDistributedCache 공급자를 구현했습니다. 그래서, 당신은 플러그인 NCache IDistributedCache 공급자 및 ASP로.NET core 자동으로 세션을 저장하기 시작합니다. NCache. 내가 여기 있는지 확인하십시오.
예를 들어 여기 ASP가 있습니다..NET Core 서비스 구성으로 이동하여 추가하기만 하면 됩니다. NCache IDistributedCache 공급자로서 이제 일반 ASP를 사용하고 있습니다..NET core 현재 연결되어 있는 공급자가 있다는 것을 알고 있기 때문에 IDistributedCache에 의존하는 것을 알고 있는 세션. 따라서 이렇게 하면 모든 세션이 다음 위치에 저장됩니다. NCache. 그리고 캐싱이 어떤 것인지 보여드리겠습니다. 실제 데모를 보여드리겠습니다. NCache. 그래서 그것은 한 가지 방법입니다.
NCache 세션 제공자
두 번째 방법은 실제로 사용하는 것입니다. NCache 자체 세션 제공자로서 IDistributedCache로 이동하는 대신 동일한 구성 서비스로 이동하여 추가라고 말합니다. NCache 세션 공급자.
이제 이 세션 공급자에는 일반 IDistributedCache보다 더 많은 기능이 있습니다. 더 많은 세션별 기능이 있습니다. 즉, 다음을 사용하는 것이 좋습니다. NCache IDistributedCache와 잘 어울리는 자체 세션 제공자에서. 그러나 두 옵션 모두 ASP로 이동할 수 있습니다..NET core 이것을 제공합니다. 내가 말했듯이 이것은 코드 변경에 필요한 것 이상입니다. 그게 다야. 다른 모든 것은 자동입니다. 따라서 다음과 같은 분산 캐시의 이점을 얻으려면 NCache, 이것을 응용 프로그램의 진입점으로 연결하십시오. 응용 프로그램 데이터 캐싱이 프로그래밍을 수행한 다음 개발 일정에 맞고 이보다 약간 더 긴 프로세스에 맞을 것이기 때문에 오늘 혜택을 받아야 합니다. 그러나 이것은 매우 빠르게 이루어지며 나는 확실히 이미 여기에서 이것을 알고 있습니다.
ASP.NET Core 응답 캐싱
그리고 이것은 구성이므로 응답 캐싱이 분산 캐시를 사용하는 것과 같은 방식으로 다시 살펴보겠습니다. NCache 그러면 자동으로 작동합니다.
분산 캐시에 대한 아키텍처 요구 사항
몇 가지 사항을 빠르게 살펴보겠습니다. NCache 할 것이다.
고 가용성
분산 캐시는 데이터베이스와 비슷하며 애플리케이션과 함께 프로덕션 환경에 있습니다. 따라서 아키텍처가 유연하고 가용성이 높은지 확인해야 합니다.
예를 들어 NCache 피어 투 피어 아키텍처를 가지고 있지만 다른 유형의 Redis 이 없습니다. 따라서 마스터 슬레이브를 갖는 대신 PXNUMXP를 원합니다. 내가 말했듯이 메모리 데이터 그리드에서 호출하는 많은 Java 캐시에는 피어 투 피어 아키텍처가 있습니다. 피어 투 피어의 좋은 점은 모두가 피어이므로 모든 노드가 다운될 수 있고 아무 일도 일어나지 않는다는 것입니다. 아마도 마스터 슬레이브는 슬레이브가 마스터가 될 수 없습니다. 주인이 죽으면 노예는 여전히 노예입니다. 따라서 복구하려면 수동 개입이 필요합니다. 피어 투 피어의 경우 자동으로 복구됩니다. 따라서 피어 투 피어로 인해 자가 치유 동적 클러스터가 자동으로 조정됩니다. 이것이 첫 번째 측면입니다.
선형 확장성 w. 복제
두 번째 측면은 파티션의 동적 조정을 통한 선형 확장성과 분할인 선형 확장성입니다.
물건들 NCache 두 개의 서버 구성이 있고 두 개의 파티션을 추가하려는 경우 이제 추가되는 세 번째 파티션이 되도록 세 번째 서버를 추가하려고 합니다. NCache 여기에서 두 개의 파티션이 있는 두 개의 서버가 있다고 가정해 봅시다. 다른 서버 및 파티션에 백업으로 사용되는 모든 파티션은 본질적으로 해시 맵 배포가 있는 버킷 모음입니다.
따라서 1,000개의 버킷이 있고 500개는 파티션 1에, 500개는 월드 파티션 2에 들어가고 모든 것이 잘 작동한다고 가정해 보겠습니다. 이제 세 번째 서버를 추가하려고 합니다. 세 번째 서버를 추가하면 세 개의 파티션을 가질 수 있으므로 한 번 더 NCache 응용 프로그램이 실행되는 동안 백그라운드에서 자동으로 수행되어 세 번째 파티션을 만들고 파티션 1과 2의 일부 데이터를 세 번째 파티션으로 옮깁니다. 다시, 삼분의 일, 삼분의 일 삼분의 일. 따라서 버킷은 실제로 움직이며 모두 동적으로 발생합니다. 버킷이 이동하면 복제본도 다시 조정되지만 복제본 3과 2는 더 이상 이전과 동일한 복제본이 아니며 빠르게 데이터가 줄어들고 복제본 XNUMX이라는 새 복제본이 있습니다. 복제본이 XNUMX개였던 서버는 더 이상 복제본 XNUMX가 아니라 XNUMX개를 갖게 되고 복제본 XNUMX개는 세 번째 서버에 생성될 것입니다. 모든 작업이 자동으로 수행됩니다.
그래서 그 역동성이 그것을 고가용성으로 만드는 것입니다. 따라서 서버를 추가할 때 수동 개입이 있지만 실제로는… 그래서 직접 가서 할 수 있다면 여전히 매우 편리합니다. 말 그대로 추가만 하면 모든 작업이 완료됩니다. 그러나 서버 충돌로 인해 드롭이 발생할 수도 있으므로 서버를 드롭할 때 더욱 중요합니다. 따라서 3개의 서버 구성에 있을 때 서버 3이 다운되고 이제 파티션 XNUMX이 손실됩니다. NCache 복제본 3은 파티션 1의 복사본을 가지고 있기 때문에 즉시 활성화됩니다. 이제 파티션 2은 임시로 파티션 3, 파티션 3 및 복제본 XNUMX이 있습니다. 따라서 중단이 없습니다. 일단 그렇게 되면 NCache 이제 3개의 서버만 1개의 파티션만 가질 수 있다는 사실을 깨닫고 복제본 2을 파티션 2과 XNUMX로 한 번에 모두 병합한 다음 병합이 완료되면 여기 이 위치에 복제본 XNUMX를 생성합니다. 따라서 이 사진으로 돌아갈 수 있습니다.
이제 이것은 다른 방식으로는 자동으로 할 수 없는 것입니다. 이것이 의미하는 바는 이 일이 발생하고 중간에 사망한 경우 IT 부서 직원이 수동으로 이동하여 재조정해야 하며 그렇게 될 때까지 하나의 캐시와 제한된 기능이라고 부르는 것입니다. NCache 자동으로 그렇게합니까? 따라서 고가용성이 실제로 캐시에 있는지 확인해야 합니다.
클라이언트 캐시
나는 이미 InProc 속도에 대해 이야기했습니다.
완 복제
또 다른 기능이 있으며 이제 이것은 Enterprise Edition의 기능입니다. 즉, 이제 많은 애플리케이션이 이동된 여러 데이터 센터가 있는 경우 클라우드로 인해 여러 지역에 애플리케이션을 배포하기가 더 쉬워집니다.
따라서 애플리케이션이 다중 데이터 센터인 경우 캐시도 여러 개로 복제해야 할 수 있으며 대기 시간이 많기 때문에 전체 클러스터가 여러 지역에 걸쳐 있을 수 없습니다. 따라서 클러스터에 클러스터가 있고 그 사이에 비동기식으로 복제하는 브리지가 있습니다. 따라서 활성-활성 양방향 복제 사례이며 브리지는 두 위치에 대해 동일한 키가 업데이트되기 때문에 충돌 해결을 수행합니다. 이제 당신은 그것을 추적했습니다.
NCache Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
무엇인지 빠르게 보여드리겠습니다 NCache 처럼 보인다. 그래서 저는 Azure를 가지고 있으므로 기본적으로 조달하거나 프로비저닝했습니다. 포털만 얻을 수 있다면 여기 있습니다! 그래서... 정말 느립니다. 어서 해봐요! 네 가지 예, 좋아요! 여기에는 XNUMX개의 VM이 있고 그 중 하나에 로그인되어 있습니다. 즉, 기본적으로 XNUMX개의 캐시 서버가 있고 모두 Windows이고 하나는 캐시 클라이언트 Windows이고 하나는 Linux인 캐시 클라이언트입니다. 왜냐하면 .NET core, 나는 모든 것을 할 수 있습니다. 캐시 서버도 살아 있을 수 있지만 NCache 내가 말했듯이 .net core 저희 웹사이트에 오시면 그냥 가실 수 있습니다. 선호도에 따라 .msi 또는 Tar.gz를 실제로 다운로드하실 수 있습니다. Windows 또는 Linux를 설치할 수 있습니다. 실제로 여기에서도 오픈 소스를 다운로드할 수 있습니다. 우리 기업은 오픈 소스 위에 구축되었으므로 우리는 오픈 소스의 소유자이자 엔터프라이즈 기업입니다.
클러스터형 캐시 생성
이제 빨리 말씀드리겠습니다. 죄송합니다. 2노드 캐시 클러스터를 만들겠습니다. 다시 말하지만 이 도구는 오픈 소스가 아니지만 오픈 소스에서 할 수 있는 모든 작업입니다. 그다지 예쁘지 않습니다. 실제로 이것은 이제 웹 기반 도구가 될 것입니다. 그래서 저는 이만 가보겠습니다. 이것은 내 첫 번째 캐시 서버입니다. 이것은 나의 두 번째 캐시 서버입니다. 그래서 두 개의 서버 캐시 클러스터를 할 것입니다. 다른 모든 기본값은 그대로 사용하겠습니다. 계속해서 두 개의 클라이언트를 추가하겠습니다. 하나는 Windows 클라이언트인 저 자신이고 두 번째 클라이언트는 10.0.0.7 클라이언트와 Linux 클라이언트를 추가하겠습니다. 캐시를 시작합시다. 이것은 캐시를 생성하고 구성하는 것이 얼마나 빠른지를 의미합니다.
스트레스 시뮬레이션 및 캐시 모니터링
이것에 대한 첫 번째 통계를 시작하겠습니다. NCache 로드를 시뮬레이션할 수 있는 스트레스 테스트 도구라는 이 프로그램과 함께 제공됩니다. NCache. 그래서 프로그램과 같습니다. 자체적으로 입력을 받습니다. 여기에 PowerShell이 열려 있으므로 test-stress를 수행하고 방금 여기에 지정한 캐시 이름인 캐시 이름을 입력하고 여기에 작성하면 바로 이 상자가 있습니다. 이것이 첫 번째 상자입니다. 그래서 저는 클라이언트 상자로 가서 이것을 실행하려고 하는데 갑자기 여기에서 활동이 시작되는 것을 볼 수 있습니다. 그래서 저는 지금 상자당 초당 약 500개의 작업을 수행하고 있습니다. 예를 들어, 로드를 늘리고 싶습니다. 어떻게 테스트하고 싶습니까? NCache 내 환경에서 수행할 예정이므로 동일한 상자에서 동일한 인스턴스의 다른 인스턴스를 시작하겠습니다. 갑자기 내 부하가 거의 두 배로 증가했고 이제 두 개의 Linux 상자가 있는 것을 볼 수 있습니다. 보시다시피 여기 Linux이고 이것은 . 바로 여기에 있는 60개의 상자입니다. 여기에서 먼저 PowerShell을 시작하겠습니다. 이 모듈을 빠르게 복사하고 동일한 스트레스 테스트 데모 캐시를 수행합니다. 이 작업을 수행하는 즉시 이 값이 갑자기 약 XNUMX으로 올라간 것을 볼 수 있습니다.
그래서 이렇게 할 때마다 상자당 초당 약 500개의 작업이 추가되고 있습니다. 한 번 더 하고 이만 마치도록 하겠습니다. 추가하겠습니다... 따라서 부하가 최대치에 도달하기 시작할 때까지 부하를 계속 추가한 다음 세 번째 서버를 추가할 수 있습니다. 물론 더 많은 클라이언트도 추가해야 합니다. 이 모든 것은 타사 도구에서도 쉽게 모니터링할 수 있는 perf-mon입니다. 이것은 그만큼 간단합니다. 추가하려는 캐시된 항목입니다.
오픈 소스를 다운로드할 수 있는 저희 웹 사이트로 이동하여 오픈 소스를 사용할 수 있습니다. 오픈 소스를 다운로드할 수 있는 MSI 설치 프로그램도 있습니다. 따라서 오픈 소스를 사용하거나 지원 환경에서 사용하려는 경우 바로 엔터프라이즈를 다운로드할 수 있습니다. 예를 들어 제가 오픈 소스로 와서 인스톨러를 다운로드할 수 있다면 소스 코드에 대한 비용을 청구할 필요가 없습니다. 다시 말하지만 모든 소스 코드는 GitHub에 있습니다.