Live 360 Orlando 2016에서 토크
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
트랜잭션 로드 증가로 인해 .NET 응용 프로그램에서 데이터베이스 또는 저장소 병목 현상이 발생할 수 있습니다. 분산 캐싱을 사용하여 병목 현상을 제거하고 .NET 애플리케이션을 확장하는 방법을 알아보십시오. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
확장성이란
이제 몇 가지 정의부터 시작하겠습니다. 여러분 대부분이 이것을 이미 알고 있을 것이라고 확신하지만 우리는 완전성을 목적으로 그것을 검토할 것입니다. 첫 번째 정의는 확장성입니다. 그렇다면 확장성이란 무엇입니까? 사람들은 종종 확장성과 성능을 혼동합니다. 성능은 응용 프로그램별로 정말 빠른 응답 시간이지만 50,000명의 사용자만 있을 수 있고 XNUMX명의 사용자에서 XNUMX천 또는 XNUMX명의 사용자로 가져가도 성능이 양호하면 응용 프로그램을 확장할 수 있습니다. 이것이 바로 우리가 달성하고자 하는 것의 핵심입니다.
어떤 애플리케이션을 사용하든 XNUMX명의 사용자 또는 매우 낮은 트랜잭션 부하로 동일한 성능을 달성할 수 있다면 높은 트랜잭션 부하로 동일한 성능을 달성할 수 있다면 확장 가능합니다. 사용자가 XNUMX명일 때 성능이 좋지 않다면 다른 문제가 있는 것입니다.
선형 확장 성
선형 확장성은 인프라 정의에 가깝습니다. 즉, 응용 프로그램 서버 또는 데이터베이스 서버를 더 추가하든 관계없이 배포에 더 많은 서버를 추가하는 방식으로 응용 프로그램을 설계한 경우 선형 방식으로 트랜잭션 용량을 늘릴 수 있다면 선형 확장 가능한 응용 프로그램 아키텍처를 갖게 됩니다.
그러나 그렇게 할 수 없다면, 서버를 더 추가해도 아무런 가치도 추가되지 않는다면 근본적으로 잘못된 것이 있고 응용 프로그램을 선형 방식으로 확장할 수 없습니다. 여기서 목표는 물론 선형 방식으로 확장할 수 있는 것입니다.
비선형 확장성
비선형은 더 많은 서버를 추가함에 따라 증가하는 것을 볼 수 있지만 그 후 특정 시점에서 더 이상 증가하지 않는 경우가 있습니다. 사실 애플리케이션의 아키텍처와 배포로 인해 극복할 수 없는 병목 현상이 있기 때문에 더 많은 서버를 추가하더라도 성능이 저하됩니다.
어떤 애플리케이션에 확장성이 필요합니까?
이들은 일반적으로 웹 응용 프로그램입니다.
따라서 이들은 ASP.NET for.NET 사용자, 웹 서비스, 매우 강력한 신흥 공간인 사물 인터넷의 백엔드 및 빅 데이터 처리입니다. 빅 데이터 처리는 Java 측에서 더 일반적입니다. .NET 쪽에서 하는 사람은 많지 않지만 빅 데이터 처리도 또 다른 영역입니다. 그리고 다른 모든 서버 응용 프로그램은 일괄 처리 응용 프로그램일 수 있습니다. 당신은 금융 서비스 회사이고 수백만 명의 고객이 있고 그들은 전화를 걸어 주소를 변경하거나 한 계좌에서 다른 계좌로 자금을 이체하고 있을 수 있습니다. 특정 규정 준수 요구 사항이 있으므로 한밤중 또는 무언가까지 처리를 완료해야 하며 백엔드, 워크플로, 방식에서 일부 일괄 처리가 발생합니다. 따라서 특정 수의 트랜잭션을 완료하기 위해 시간 제약이 있는 다른 모든 서버 응용 프로그램에는 확장성이 필요합니다.
확장성 문제
그렇다면 확장성 문제는 어디에 있습니까? 우리는 선형 및 비선형 확장성에 대해 이야기했습니다. 따라서 확장성 문제는 응용 프로그램 계층이 매우 좋은 선형 방식으로 확장된다는 것입니다. 웹 애플리케이션이나 웹 서비스, 애플리케이션 계층이 있는 경우 문제 없이 서버를 추가하기만 하면 됩니다. 병목 지점은 데이터 스토리지입니다. 그리고 데이터 스토리지라는 단어는 관계형 데이터베이스와 메인프레임 레거시 데이터를 의미합니다. 나는 의미하지 않는다 NoSQL database. NoSQL database훌륭합니다. 우리는 또한 NoSQL 라는 제품 NosDB 그러나 SQL 데이터베이스가 항상 정답은 아닙니다. 더 많은 데이터를 옮길수록 옮길 수 있다면 답이다 NoSQL database 더 많은 확장성 솔루션을 얻을 수 있습니다. 그러나 문제는 모든 데이터를 옮길 수 없다는 것입니다. NoSQL. 기술적 및 비즈니스적 이유로 인해 관계형으로 유지되어야 하는 많은 데이터가 있습니다.
따라서 관계형 데이터베이스가 여기에 있습니다. 그들은 이 문제와 관련하여 아무데도 가지 않을 것입니다. 따라서 이러한 현실을 피하거나 관계형 데이터베이스로 작업하게 될 현실과 함께 작업해야 하며 여전히 이 문제를 해결해야 합니다. 그리고 이 문제를 해결해야 하는 이유는 확장성이 필요한 모든 응용 프로그램이 있기 때문입니다.
분산 캐시 배포
물론 대답은 응용 프로그램 계층과 데이터베이스 계층 사이에 분산 캐시를 연결하는 것입니다.
따라서 분산 캐시는 본질적으로 매우 강력하면서도 매우 단순한 개념입니다. 두 개 이상의 저비용 서버가 있고 함께 클러스터링되며 해당 클러스터는 모든 서버의 메모리와 CPU 리소스를 하나의 논리적 용량으로 함께 풀링합니다. 병목 현상과 확장성은 세 가지 영역에서 나타납니다. 하나는 메모리, 두 번째는 CPU, 세 번째는 네트워크 카드입니다.
예를 들어 여기에 하나의 데이터베이스 서버가 있고 하나의 데이터베이스 서버에 20개의 응용 프로그램 계층 상자가 있다고 가정해 보겠습니다. 하드웨어 강도 측면에서 이를 차지할 수 있고 더 많은 메모리와 훨씬 더 많은 CPU를 추가할 수 있지만 여기에는 한계가 있습니다. 따라서 대답은 고급형이 아닌 서버를 점점 더 많이 보유할 수 있다는 것입니다. 그리고 지난 10년 이상 이러한 작업을 수행하면서 가장 일반적인 구성은 듀얼 CPU 쿼드 코어 유형의 동급 구성입니다. 예를 들어, 8코어 상자와 16코어 상자는 실제로 캐싱 서버를 위한 꽤 고급 구성입니다. 8코어는 거의 일반적입니다.
메모리는 물론 메모리가 많이 필요하고 메모리가 싸기 때문에 큰 요인은 아닙니다. 많은 메모리가 필요합니다. 왜 캐시는 메모리 내 저장소이므로 모든 것을 메모리에 저장하고 일반적인 구성은 각 캐시 서버에 약 16~32기가의 메모리가 될 것이며 2개의 캐시 서버가 중복 목적을 위해 최소로 있어야 합니다. 따라서 이 아키텍처를 사용하면 이제 애플리케이션 계층에 더 많은 서버를 추가하는 상황에 처하게 됩니다. 캐싱 계층에 더 많은 서버를 비례적으로 추가합니다. 따라서 일반적으로 4:1 또는 5:1 비율이 가장 실용적인 비율입니다. 어떤 경우에는 5대 1보다 훨씬 더 많이 갈 수 있습니다. 5개의 응용 프로그램 서버 대 1개의 캐싱 서버를 의미하지만 보유할 수 있는 서버 수에는 제한이 없습니다. 2개, 4개, 10개, 20개, 30개의 서버가 있을 수 있지만 여기에 20개의 서버가 있으려면 로드 밸런서 환경에 XNUMX개의 서버가 필요할 것입니다.
따라서 어떤 단계에서는 온라인 비즈니스 시나리오의 웹 또는 전자 상거래에서 본 모든 응용 프로그램의 거의 최고급이 됩니다. 따라서 여기에 더 많은 서버를 추가하면 더 이상 병목 현상이 발생하지 않습니다. 따라서 분산 캐싱은 실제로 모범 사례가 되고 있습니다. 필요에 따라 확장성이 있는 경우. 이제 자체 목적을 위해 존재하는 데이터베이스가 있을 뿐만 아니라 모든 애플리케이션 데이터에 대한 영구적인 데이터 저장소 지속성이 필요하지만 현재 애플리케이션 아키텍처의 일부인 정말 빠르고 확장 가능한 인프라도 있기 때문입니다. 따라서 프로그래밍할 때 더 이상 데이터베이스에 대한 프로그래밍만 하는 것이 아닙니다. 캐시는 이제 최고 부하에서도 애플리케이션이 결코 느려지지 않도록 보장하기 때문에 항상 캐시를 생각하고 있습니다. 데이터베이스가 동일한 방식으로 확장되도록 설계되지 않았지만. 그래서 이것은 전형적인 그림입니다.
트래픽의 약 80%가 갇히거나 캐시로 이동하는 시간의 80%, 데이터베이스로 이동하는 시간의 20%, 그리고 그 20%는 대부분 업데이트이며 물론 데이터를 캐시로 가져와야 하기 때문에 일부 읽기이지만 캐시를 미리 채울 수도 있으며 이를 수행하는 다른 많은 방법이 있습니다. 그러나 데이터베이스 계층에서 트래픽을 극적으로 줄임으로써 성능과 확장성을 달성할 수 있습니다.
분산 캐시를 사용하는 경우입니다. 애플리케이션 아키텍처의 일부로 유지해야 하는 이유.
일반적인 사용 사례
이제 우리는 분산 캐시 사용에 대한 사례를 만들었으므로 다음 질문은 어떻게 사용합니까? 어디서 쓰나요? 어떤 유형의 분산 캐시를 사용해야 합니까?
애플리케이션 데이터 캐싱
음, 가장 일반적인 용도는 애플리케이션 데이터 캐싱입니다. 이것은 내가 방금 이야기한 것처럼 데이터베이스에 있는 데이터가 무엇이든 캐시합니다. 그래서 당신은 데이터베이스에 갈 필요가 없습니다. 염두에 두어야 할 사항은 후속 슬라이드에서 이 점에 대해 자세히 설명하겠습니다. 애플리케이션 데이터 캐싱 사용 사례에서 데이터는 두 위치에 존재합니다. 하나는 항상 있어야 하는 데이터베이스에 있고 두 번째는 캐시입니다. 따라서 데이터가 두 곳에 존재할 때마다 가장 먼저 떠오르는 문제는 무엇입니까? 동기화 중! 응.
따라서 이러한 상황을 처리할 수 없는 캐시는 읽기 전용 데이터를 캐시하도록 강제합니다. 데이터는 절대 변경되지 않을 것입니다. 사실, 대부분의 사람들은 캐시에 대해 이야기할 때 왜 읽기 전용 데이터를 위한 것인지에 대해 얼빠진 생각을 하게 됩니다. 고객과 계정, 그리고 30초마다 변경되는 데이터를 캐시하고 싶지 않습니다. 그러나 연구에 따르면 캐시의 가장 큰 사용은 트랜잭션 데이터에 있으며 일단 캐시하면 해당 활동이 무엇이든 사용의 이동 기간이 무엇이든 다음 XNUMX분 또는 XNUMX분 안에 캐시가 필요할 것입니다. 이때 동일한 데이터가 다시 필요하고 캐시에서 데이터를 가져올 수 있으면 데이터베이스로의 이러한 이동을 줄이고 애플리케이션에서 발생하는 수백만 건의 트랜잭션을 곱하면 상당한 향상이 됩니다. 따라서 좋은 캐시는 이를 매우 효과적으로 처리해야 한다는 점을 염두에 두십시오.
ASP.NET 특정 캐싱
두 번째 사용 사례는 ASP.NET 애플리케이션이 있는 경우 임시 데이터가 많다는 것입니다. 임시는 임시를 의미하며 캐시에 넣을 수 있으며 이 데이터는 실제로 데이터베이스에 속하지 않습니다. 예를 들어 데이터베이스는 영구적입니다. 상설매장입니다. 그것이 당신의 마스터 레코드입니다. 그래서, 세션 상태, 사용자가 로그인한 후 약 20분 동안만 유지해야 할 수도 있습니다. 그렇다면 왜 데이터베이스에 보관해야 할까요? 데이터베이스가 빠르지 않습니다. 관계형 데이터베이스는 Blob을 저장하도록 설계되지 않았으며 세션은 일반적으로 Blob으로 저장됩니다. 따라서 데이터베이스에 세션을 저장할 때 성능이 크게 저하됩니다. 따라서 세션 상태는 ASP.NET이 분산 캐시에 저장하는 매우 좋은 사용 사례입니다.
그리고 MVC 프레임워크를 사용하지 않는 경우 포스트백 시 브라우저로 다시 돌아오기 위해 단 하나의 목적으로 웹 서버에서 브라우저로 흐르는 상당히 무거운 데이터 조각인 보기 상태도 있습니다. 그래서 그들이 말하는 것처럼 아무것도 아닌 꽤 긴 여행입니다. 따라서 서버 측에 보관하고 작은 키만 보내면 훨씬 더 좋을 것입니다. 따라서 캐싱에 대한 매우 좋은 사용 사례입니다.
세 번째 사용 사례는 페이지 출력입니다. 많은 페이지에서 출력이 매번 변경되지 않습니다. 따라서 변경되지 않는 경우 페이지를 실행할 때 CPU와 메모리 및 기타 모든 리소스를 사용하기 때문에 페이지를 실행하는 이유는 무엇입니까? 마지막 실행에서 출력을 가져 와서 표시하지 않는 이유는 무엇입니까? 따라서 Microsoft 또는 ASP.NET에는 분산 캐시를 연결할 수 있는 출력 캐시 프레임워크가 있습니다. 따라서 이제 이 사용 사례, ASP.NET의 세 가지 사용 사례에서 문제의 본질이 완전히 바뀌었습니다. 더 이상 캐시와 데이터베이스 간의 동기화가 아닙니다. 왜? 데이터베이스가 없기 때문입니다. 캐시는 데이터베이스입니다.
지금 문제의 본질은.. 캐시가 메모리에 있다는 것입니다. 이것이 모든 성능을 얻는 방법입니다. 따라서 데이터를 메모리에 보관하고 메모리에 저장하는 유일한 저장소일 때 가장 큰 관심사는 무엇입니까? 당신은 그것을 잃을 수도 있습니다! 해당 상자가 재부팅되면 어떻게 됩니까? Windows는 작업자 프로세스를 재부팅하거나 재활용하는 것으로 알려져 있습니다. Linux 상자가 재부팅되어야 하지만 상자가 재부팅되면 어떻게 될까요? 해당 데이터를 잃을 준비가 되셨습니까? 당신이 항공사이고 그 고객이 5,000달러 상당의 가족 휴가 티켓을 제출하는 마지막 페이지에서 하와이로 갈 가족 휴가 티켓을 가지고 있는데 갑자기 다시 시작해야 해서 미안하다고 말하는 경우 어떻게 하시겠습니까? 알다시피 그들은 모든 종류의 비행 조사 및 확인 시간을 거쳤고 Google 비행도 수행했으며 일치하는 항목과 기타 모든 항목을 확인했습니다. 좋은 경험은 아닙니다.
비즈니스로서 고객, 장바구니, 그것을 잃고 싶지 않을 것입니다. 이에 대한 답은 분산 캐시입니다. 안정성을 보장할 수 있는 경우 세션 또는 모든 일시적인 데이터만 유지해야 합니다. 해당 데이터를 절대 잃지 않도록 보장하고 복제를 수행하도록 보장해야 합니다. 따라서 좋은 분산 캐시는 여러 서버에서 데이터 복제를 수행합니다. 이제 복제는 실제로 시간 낭비입니다. 우리가 방금 이야기한 우발적 상황을 위해서만 수행하는 추가 작업입니다. 따라서 복제의 부정적인 측면은 성능 저하가 있다는 것입니다. 따라서 캐시가 지능적으로 수행하지 않고 많은 캐시가 수행하지 않으면 복제를 켤 때 성능이 저하되는 것을 보게 될 것입니다.
이벤트를 통한 런타임 데이터 공유
따라서 이 두 가지 사항을 염두에 두고 세 번째 사용 사례는 대부분의 사람들이 실제로 알지 못하는 것입니다. 일단 환경에 해당 인프라가 있으면 분산 캐시는 매우 강력한 이벤트 기반 데이터 공유 플랫폼입니다. 따라서 작업 흐름에서 데이터를 공유해야 하는 여러 응용 프로그램이 있을 수 있습니다. 메시지 버스, 엔터프라이즈 서비스 버스 또는 메시지 큐를 사용할 상황의 게시/구독 유형이 있을 수 있습니다. 분산 캐시는 이를 위한 매우 강력한 플랫폼입니다. 이미 사내에 있기 때문에 성능을 위해 설계된 반면 다른 응용 프로그램은 공유 전용으로 설계되었기 때문에 다른 옵션보다 실제로 더 빠르고 확장 가능합니다.
따라서 이벤트 기반 게시/구독 유형의 여러 애플리케이션 간의 공유입니다. 한 응용 프로그램은 일부 데이터를 생성하고 캐시에 저장하고 이벤트를 발생시킵니다. 해당 이벤트에 관심을 등록한 다른 애플리케이션이 있으며, 이 데이터가 가능할 때마다 이 데이터를 사용하고 싶습니다. 따라서 그들은 이벤트를 수신하고 다시 하나의 애플리케이션이 여기에 있을 수 있습니다. 하나의 애플리케이션이 여기에 있을 수 있습니다. 이것은 그들이 모두 활용할 수 있는 매우 강력한 확장 가능한 이벤트 엔진이 됩니다.
이것이 세 번째 사용 사례입니다. 이벤트, 런타임 데이터 공유 기능 또는 사용 사례에서도 대부분의 데이터는 일시적입니다. 영구 데이터에서 파생되고 있으며 아마도 해당 영구 데이터에서 다시 생성할 수 있지만 이를 수행하는 데 많은 작업이 필요하고 해당 데이터는 일반적으로 임시 데이터를 사용하기 때문에 이 임시 데이터에 있습니다. 일반적이지 않으며 데이터베이스에 저장할 필요가 없습니다. 섭취할만 합니다. 따라서 캐시는 다시 유일한 저장소이므로 세션 및 다른 것과 마찬가지로 안정성이 시작되어야 하는 문제는 동일합니다. 따라서 분산 캐시를 사용하는 세 가지 일반적인 방법이 있습니다.
따라서 이 세 가지 사용 사례의 좋은 점은 이를 수행하는 데 프로그래밍이 필요하지 않다는 것입니다..NET framework 타사 공급자를 연결할 수 있습니다. 예를 들어 세션의 경우 웹 구성과 ASP로 이동하는 간단한 샘플을 보여 드리겠습니다..NET core, 그 패러다임은 약간 바뀔 것이지만 아이디어는 동일합니다.
ASP.NET 세션 캐싱 구성
따라서 Web.config로 이동하면 이것은 단순한 ASP.NET 응용 프로그램일 뿐입니다. Web.config로 이동하여 다음과 같은 경우에 사용할 캐시의 어셈블리를 먼저 추가해야 합니다. NCache에서 추가 어셈블리를 수행할 것입니다. NCache 세션 저장소 공급자와 복사 붙여넣기만 하면 됩니다. 두 번째로 실제로 해야 할 일은 여기에서 변경하는 것입니다.
따라서 웹에는 모드가 사용자 지정이고 제한 시간이 제한 시간이 무엇이든 확인해야 하는 구성을 구성하는 세션 상태 태그가 있습니다. 그리고, NCache, 그런 다음 실제로 이 줄을 추가해야 하고 거기에 내가 들어가지 않을 것이라고 지정할 수 있는 다른 많은 매개변수가 있지만 그 중 하나는 캐시의 이름입니다. 의 경우 NCache, 모든 캐시에는 이름이 지정되어 있으며 실제로 이에 대한 데모도 제공하겠습니다. 따라서 캐시 이름을 지정하기만 하면 됩니다. 캐시가 이미 생성되었습니다. 세션용 캐시, 애플리케이션 데이터용 캐시 등 여러 캐시가 있을 수 있기 때문에 연결할 캐시를 알려주는 연결 문자열과 같습니다. 그게 전부입니다. 내 말은 당신이 그 변경을 하고 온전한 테스트를 하고 애플리케이션의 모든 일반적인 사용 사례를 거치면 애플리케이션이 갑자기 세션을 저장할 준비가 된다는 것입니다. 다음과 같은 분산 캐시 NCache. 따라서 이익을 얻는 가장 쉬운 방법이자 가장 큰 이득은 실제로 세션입니다.
따라서 다음과 같은 분산 캐시에서 세션 상태 사용을 위해 수행해야 하는 작업의 전부입니다. NCache 또는 보기 상태 출력 캐시도 마찬가지입니다. 모든 구성 기반 변경입니다. 나는 그들 각각에 들어 가지 않을 것입니다. 저는 이것을 예시로 보여드리고 싶었습니다.
앱 데이터 캐싱
이제 분산 캐시의 핵심으로 가보겠습니다. 대부분의 시간을 여기서 보낼 것이기 때문에 저는 핵심이라고 말합니다. 분산 캐시를 통합하기로 선택한 경우 애플리케이션 데이터 캐싱을 수행하는 데 대부분의 시간을 할애하게 됩니다. 그렇다면 일반적인 API는 어떤 모습일까요?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");ASP.NET 캐시 개체를 알고 있다면 NCache 우리는 상위 집합이므로 더 많은 것이 있지만 가능한 한 가깝게 모방하려고 합니다. 모든 캐시에는 자체 API가 있습니다. 이것은 무엇 NCache API는 다음과 같습니다. 캐시에 연결하면 명명된 캐시입니다. 캐시 핸들을 얻고, 그 캐시 핸들을 유지하고 유지하는 애플리케이션 내에서 Cache.Get을 수행합니다. 가져오기, 포함, 추가, 삽입, 제거, 비동기 추가, 비동기 삽입도 있습니다. 삽입은 존재하지 않는 경우 추가하거나 이미 존재하는 경우 업데이트를 의미합니다. 이는 ASP.NET 캐시 개체에서 사용하는 것과 동일한 용어이므로 우리도 사용했습니다. 그리고 Async 메서드는 기본적으로 해당 작업이 완료될 때까지 기다릴 필요가 없음을 의미합니다. 실제로 콜백을 지정할 수 있는 세 번째 매개변수가 있습니다. 따라서 콜백은 무언가 잘못되었거나 모든 것이 잘 되었다고 가정할 수 있는 경우에 호출됩니다.
캐시를 최신 상태로 유지
그래서 우리가 여기 있을 때 애플리케이션 데이터 캐싱에 대해 이야기했는데 가장 큰 관심사는 캐시를 최신 상태로 유지해야 한다는 것입니다. 따라서 좋은 분산 캐시는 이를 허용해야 합니다. 그렇지 않은 경우 읽기 전용 데이터를 캐시하도록 강제하기 때문입니다. 어쨌든 읽기 전용 데이터는 데이터의 약 10~15%입니다. 따라서 캐싱해야 하는 것의 10~15%만 캐싱하는 경우 이 캐시에서 실제로 이점을 얻을 수 있는 방법은 무엇입니까? 따라서 원하는 것은 모든 데이터, 실질적으로 모든 데이터를 캐시하는 것입니다. 캐시하는 것이 실제로 의미가 없다고 말하는 데이터는 거의 없습니다. 그러나 거의 모든 데이터. 일부 데이터는 잠시 동안 캐시합니다. 따라서 해당 데이터를 캐시하면 이것은 모든 애플리케이션 데이터이며 가장 어려운 캐시는 캐시가 최신 상태인지 확인합니다. 가장 중요한 것은 만료입니다.
시간 기반 만료 사용
만료는 절대 만료이며 슬라이딩 만료가 있습니다. 둘 다 만기일지라도 둘은 매우 다른 의미를 가집니다. 절대 만료는 캐시를 최신 상태로 유지하기 위해 수행해야 하는 작업입니다. 캐시에 이 고객 개체를 저장하고 있다고 추측하기 때문입니다. 2분에 캐시하는 것이 안전하다고 생각합니다. 당신은 단지 추측을 하고 있을 뿐입니다. 그것은 교육받은 추측이지만 그것은 추측입니다. XNUMX분 안에 아무도 데이터베이스에서 그것을 수정하지 않기를 바라지만 만약 수정한다면 당신의 캐시는 데이터베이스와 일치하지 않게 될 것입니다. 반면 슬라이딩 만료는 캐시 동기화 유지와 관련이 없습니다. 제거와 관련이 있거나 캐시의 자동 정리와 관련이 있습니다.
따라서 세션은 로그인한 사람이 없을 때 20분 동안 활동이 없으면 세션을 제거한다고 말하는 것입니다. 그래서, 당신은 청소처럼하고 있습니다. 당신은 캐시가 그것을 청소해 주세요, 나를 위해 그것을 청소해 주세요라고 말하는 것입니다. 이 모든 것을 추적하고 싶지 않습니다. 나는 그것을 캐시에 넣었고, 아무도 그것을 건드리지 않더라도 캐시에 남아 있어야 하는 기간을 지정했고, 그 후에 그것을 정리했습니다. 따라서 영구 만기와 슬라이딩 만기의 목표는 매우 다릅니다. 따라서 슬라이딩 만료는 임시 데이터의 세션에 사용합니다. 절대 만료, 영구 데이터에 사용합니다.
내가 사용하고 싶은 또 다른 용어는 참조 데이터 대 트랜잭션 데이터입니다. 참조 데이터는 자주 변경되지는 않지만 변경되는 데이터이며 읽기 전용이 아닙니다. 가격이 매일 또는 매주 변경될 수 있지만 고객 개체, 활동 개체 또는 주문 개체만큼 빈번하지는 않은 제품 테이블입니다. 따라서 트랜잭션 데이터는 우리가 캐시하려는 것입니다. 물론 참조 데이터는 우리가 그것을 캐시하기를 원하지만 트랜잭션 데이터는 우리가 모든 데이터를 얻을 수 있는 곳이기도 합니다. 따라서 만료 시간이 충분하지 않아 캐시를 최신 상태로 유지할 수 없다면 더 많은 기능이 필요합니다.
데이터베이스 종속성 사용
따라서 다음 기능, 좋은 분산 캐시가 가져야 하는 매우 강력한 기능은 사용자의 개입 없이, 사물을 모니터링하지 않고도 캐시를 데이터베이스와 동기화할 수 있어야 한다는 것입니다. 그래서, 당신은 내가 이 객체를 캐싱하고 있다고 캐시에게 말할 수 있어야 합니다. 이는 데이터베이스의 이 데이터 세트와 관련이 있습니다. 따라서 데이터베이스에서 이 데이터 세트를 모니터링하십시오. 변경되었는지 확인하고 한두 가지 작업을 수행하십시오. 캐시에서 이 항목을 제거하십시오. 제거는 다음에 응용 프로그램이 원할 때 캐시에서 찾을 수 없음을 의미합니다. 캐시에서 찾지 못하면 어떻게 됩니까? 데이터베이스에서 가져옵니다. 따라서 새 사본을 가져오는 것과 같거나 두 번째로 새 사본을 자동으로 다시 로드할 수 있습니다. 새 복사본을 자동으로 다시 로드하려면 read-through라는 또 다른 기능이 필요합니다.
그래서, 나는 그것에 대해 다시 올 것이지만 데이터베이스 동기화 매우 매우 강력한 기능입니다. 이것은 캐시가 최신 상태로 유지되도록 안심할 수 있는 것입니다. 캐싱하는 데이터에 대해 걱정할 필요가 없으며 캐시를 데이터베이스와 동기화하는 다양한 방법이 있습니다. 가장 일반적인 것은 실제로 ADO.NET 또는 SQL 서버 기능인 SQL 종속성입니다. NCache 사용합니다.
그래서, 예를 들어, 제가 보여주어야 할 코드를 실제로 보여드리겠습니다. 그래서 빨리 가겠습니다.. 코드가 어떻게 생겼는지 빠르게 보여드리겠습니다. 그게 어디 갔어? 따라서 .NET 애플리케이션이 있는 경우 이것이 NCache, 물론 당신은 두 가지를 참조합니다 NCache 라이브러리. NCache.런타임 및 NCache.편물. 따라서 다시 말하지만 ASP.NET 캐시 개체 네임스페이스에 가까운 이름을 지정하려고 했습니다. NCache.편물. 우리가 2005년에 다시 나왔을 때 ASP.NET 캐시 개체는 주변의 유일한 캐시였기 때문에 우리는 공간에서 가장 오래된 것이므로 사람들이 쉽게 사용할 수 있도록 그 이름을 선택한 것입니다. 따라서 응용 프로그램 내에서 몇 가지를 포함합니다. NCache 네임스페이스. 그런 다음 캐시에 연결하고 캐시 핸들을 얻었고 이제 캐시 핸들이 있으므로 개체를 만들고 Cache.Add를 수행하려고 한다고 가정해 봅시다. 따라서 Cache.Add는 키를 사용합니다. 키는 실제로 문자열이므로 이를 따랐습니다. 글쎄, 이것은 명명 규칙을 따르지 않지만 일반적으로 Customer:CustomerID: 해당 고객의 ID가 무엇이든 관계없이 Cache.Add를 수행한 다음 이 경우 XNUMX분 절대 만료를 지정합니다. 슬라이딩 만료 및 기타 모든 작업을 수행하지 마십시오. 따라서 캐시가 어떻게 생겼는지에 대한 맛보기를 제공하기 위한 것입니다.
ADO.NET 또는 다른 프로그래밍을 수행하는 것보다 훨씬 사용하기 쉽고 매우 간단한 API입니다.
캐시는 어떻게 생겼나요?실제로 캐시가 어떻게 생겼는지 실제 캐시와 함께 보여드리겠습니다. 따라서 이러한 VM과 Azure가 있습니다. 그래서 데모 1과 2가 있습니다. 이것들은 내가 사용할 두 개의 캐시 서버입니다. 이들은 캐시 VM이며 애플리케이션 서버를 갖게 됩니다. 데모 클라이언트라고 부르겠습니다. 따라서 내 애플리케이션은 데모 클라이언트에서 실행될 것입니다. 좋아요! 그래서 여기에 원격 데스크톱이 있습니다. 나는 경우에 간다. NCache 라는 도구를 실행하겠습니다. NCache 매니저님, 사실 여기 있어요. 그리고 계속해서 만들겠습니다. 해당 이름의 캐시가 이미 없는지 신속하게 확인하겠습니다. 좋아요! 그래서 계속해서 새 캐시를 만들겠습니다. 내 캐시를 데모 캐시라고 부르겠습니다. 다른 모든 것을 기본값으로 사용하겠습니다. 캐싱 토폴로지를 선택하겠습니다. 자세히 설명하지는 않겠지만 이 캐싱 토폴로지는 파티셔닝과 복제를 동시에 수행합니다. 따라서 이 토폴로지를 수행하면 캐시가 다음과 같이 표시됩니다.
따라서 이들은 캐시 서버입니다. 따라서 일부 데이터, 이 1 2 3 4는 데이터 요소입니다. 따라서 일부 데이터는 파티션 1에 있고 일부 데이터는 파티션 2에 있으며 모든 파티션은 다른 서버에 백업됩니다. 따라서 여기에 3개의 서버가 있는 경우.
파티션 1, 2, 3이 있고, 서버 2에는 파티션 1의 복제본이 있고, 서버 3에는 파티션 2의 복제본이 있고, 서버 1에는 파티션 3의 복제본이 있다고 가정해 보겠습니다. 따라서 캐시는 실제로 서버입니다. 실제로 클러스터에 있는 둘 이상의 서버입니다. 그들은 서로를 알고 있고 나는 지금 당신을 이것으로 빨리 데려갈 것입니다. 따라서 파티션 복제본 토폴로지를 선택했다고 가정해 보겠습니다. 첫 번째 캐시 서버로 데모 1을 선택하겠습니다. 왜 그렇게 느립니까? 내 두 번째 캐시 서버로 데모 2. 아마 인터넷이 느려서 그런 것 같아요. 모르겠습니다. 따라서 7802노드 캐시 클러스터가 있습니다. 따라서 데모 XNUMX과 XNUMX는 이제 서로에 대해 알고 있습니다. 그래서 그들은 이 포트에서 서로 대화할 것입니다. 변경할 수 있는 포트 XNUMX에서. 왜 그렇게 느립니까? 확실하게 하다.
좋아요! 그래서 다음에는 캐시에 얼마나 많은 메모리가 있어야 하는지 지정하겠습니다. 그래서, 그것은 하나의 공연을 가지고 있습니다. 제가 말했듯이 여러분은 아마도 13 공연 또는 그 이상을 갖게 될 것입니다. 그런 다음 가장 최근에 사용되지 않은 퇴거 정책을 지정하겠습니다. 15%는 아껴둘게.. 미안해 캐시 5%를 없애버려. 이것은 정말 느리고 무슨 일이 일어나고 있는지 모르겠습니다. 이 상자 전체가 느려요. 클릭 한 번만 해도, CPU도 느려요, 예! 그런 것 같습니다. 그래!
좋아요! 따라서 기본적으로 논리적으로 캐시라고 하는 서버 클러스터가 있고 데모 캐시로만 알 수 있습니다. 예를 들어 애플리케이션 서버 상자에 NCache 여기에 설치됩니다. 해당 캐시 이름과 이를 나타내는 서버 목록을 포함하는 구성 파일을 갖게 됩니다. 따라서 이것은 시작점일 뿐이지만 전체 클러스터가 캐시 이름일 뿐이라는 것을 다시 한 번 알게 될 것입니다. 클러스터에 연결하면 클라이언트 API가 이 그림의 모든 캐시 서버에 연결됩니다. 파티션 복제본의 경우 모든 클라이언트는 모든 서버와 통신하므로 데이터가 있는 파티션 부분으로 직접 이동할 수 있습니다.
계속해서 데모 클라이언트인 클라이언트를 추가하겠습니다. 계속해서 캐시 도우미를 클릭하겠습니다. 클릭하는 데 시간이 오래 걸리므로 캐시를 시작합니다. 따라서 두 상자 모두에서 캐시가 시작된다고 말하면 됩니다. NCache Windows 기반 캐시이므로 우수한 Windows 기반 제품의 사용하기 쉬운 모든 기능을 갖추고 있습니다. 따라서 중앙 위치에서 이 모든 작업을 수행할 수 있으며 스크립팅을 통해서도 이 모든 작업을 수행할 수 있습니다.
데이터베이스 동기화 - 데모이제 데이터베이스 동기화가 어떤 것인지 보여드리겠습니다. 예를 들어, 다시 같은 유형의 애플리케이션이고 캐시가 있고 캐시에 데이터를 추가하려고 할 때 캐시를 수행한다고 가정해 보겠습니다. 여기에 추가하면 물론 이것은 NCache 코드에서 SQL 캐시 종속성을 지정합니다. NCache 클래스이지만 백엔드에서 SQL 서버 SQL 종속성 클래스에 매핑됩니다. 그리고 다음에서 사용하는 SQL 문자열을 전달합니다. NCache 데이터베이스에 연결하면 캐시 서버가 이제 데이터베이스의 클라이언트가 됩니다. 예를 들어, 애플리케이션이 여기에 있고 코드가 여기에서 실행 중이라면 방금 이 호출을 실행했습니다. 앗 미안 해요! 이 캐시 해당 광고 호출을 실행하고 이 SQL 캐시 종속성을 전달했습니다. 클라이언트는 이 모든 것을 캐시 서버로 보냅니다.
따라서 캐시 서버 중 하나 또는 여러 개입니다. 또한 여기에서도 연결 문자열을 지정했기 때문에 이제 캐시 서버가 데이터베이스에 대한 연결을 엽니다. 그리고 이 연결 강도는 당연히 풀입니다. 그래서. 동일한 연결 문자열을 여러 번 지정하면 백엔드에 연결 풀이 있습니다. 따라서 다른 캐시가 이제 데이터베이스의 클라이언트가 되었습니다. 데이터베이스를 모니터링하여 데이터베이스가 NCache 모니터링을 요청한 이 데이터가 변경된 서버와 NCache 이때 서버는 캐시에서 해당 항목을 제거할지 또는 데이터베이스에서 다시 로드할지 여부를 결정할 수 있습니다. 그리고 다시 로드하려면 실제로 읽기 기능을 거쳐야 합니다.
좋아요! 그래서, 그것은 그것을 하는 한 가지 방법입니다. 정말 강력합니다. 이벤트 중심입니다. 변경이 발생하는 즉시 데이터베이스는 캐시에 알리고 캐시는 즉시 조치를 취합니다. 그러나 SQL 캐시 종속성을 수행할 때마다 해당 데이터 세트를 모니터링하기 위해 SQL 서버 내에서 데이터 구조를 만들어야 하기 때문에 이 데이터베이스 서버 측에는 오버헤드가 있습니다. 이제 이 중 백만 개가 있다면 SQL 서버가 충돌할 것이라고 장담할 수 있습니다. 다시 말하지만, 우리는 확장성에 대해 이야기하고 있기 때문에 정말 큰 수의 관점에서 생각해야 합니다. 따라서 수천 또는 수만 개가 있으면 문제가 없습니다. 그러나 수십만 또는 수백만 개가 있다면 다른 전략이 더 나은 전략이 될 것입니다.
데이터베이스 종속성또 다른 전략은 우리 자신의 DB 의존성이라고 합니다. NCache 폴링 기반 종속성인 기능입니다. 우리는 이것을 구현했습니다. 특별한 테이블이 있고 해당 행에 대해 해당 테이블의 플래그를 업데이트할 수 있도록 트리거를 수정하도록 요청한 다음 캐시에서 DB 종속성을 수행할 때마다 캐시는 해당 테이블에 항목을 생성한 다음 한 번의 가져오기에서 캐시가 플래그가 true인 수천 개의 행을 가져올 수 있으며 업데이트가 발생했습니다. 따라서 추적하는 우리만의 방식과 같습니다. 폴링 기반이므로 즉각적이지 않습니다. 기본적으로 약 15초 지연되지만 다시 구성할 수 있습니다. 너무 자주 당기는 것도 원하지 않습니다. 그래서, 그것은 다른 것이지만 거기에도 한계가 있습니다. 만약 그 테이블에 참과 거짓 플래그가 있는 1만 행이 있다면 인덱스는 꽤 커 보일 것입니다. 맞습니까? 참과 거짓 색인이 있습니다. 이들은 트리의 두 노드입니다. 따라서 DB 종속성은 SQL 종속성보다 효율적이지만 실시간은 아니지만 한계가 있습니다.
CLR 절차세 번째는 데이터베이스의 트리거에서 CLR 프로시저를 실제로 호출할 수 있는 CLR 프로시저로, 항목이 추가, 업데이트 또는 삭제될 때마다 프로시저를 호출합니다. 프로시저는 캐시에 대한 비동기 호출을 수행합니다. 캐시에서 이 항목을 추가 또는 업데이트 또는 삭제하십시오. 비동기가 중요한 이유는 트랜잭션, 즉 데이터베이스 트랜잭션을 지연시키고 싶지 않기 때문입니다. 그렇지 않으면 시간 초과가 시작됩니다. 따라서 Async 호출은 즉시 반환되며 최소한 데이터베이스 트랜잭션이 커밋되고 캐시가 업데이트될 수 있습니다. 따라서 데이터베이스와 캐시의 동기화는 중요한 기능입니다.
비관계형으로 캐시 동기화
비관계형이거나 메인프레임, 레거시 또는 기타 데이터 소스가 있거나 클라우드 데이터 소스가 있거나 웹 메서드 호출을 통해 해당 데이터가 업데이트되었는지 여부를 확인하고 싶을 수도 있습니다. NCache 모니터링할 수 있는 코드가 있는 이 사용자 지정 종속성 기능을 사용할 수 있습니다. NCache, 작은 간격마다 코드를 호출하고 데이터 소스로 이동하여 해당 데이터가 변경되었는지 확인하고 알림이 있는 경우 모니터링합니다. NCache 과 NCache 제거하거나 같은 방식으로 다시 로드합니다.
관계형 데이터 처리
따라서 캐시를 최신 상태로 유지하는 것이 중요합니다. 그렇게 하지 못하게 하는 캐시는 혜택을 받을 수 있는 능력을 제한합니다. 관계형 데이터의 처리는 건너뛸 것입니다. 비록 그렇지 않다 하더라도 일대다 관계, 일대일 관계가 있습니다. 따라서 캐시에 하나의 항목이 있고 캐시에도 많은 항목이 있는 경우 캐시에서 한 항목을 제거하면 논리적으로 많은 항목도 제거되어야 합니다. 따라서 캐시는 이 모든 것을 추적할 수 있어야 합니다. 당신은 당신의 응용 프로그램에서 그렇게 할 수 있지만 그것은 단지 당신의 응용 프로그램 신용 원인을 복잡하게 할 뿐입니다. 이제 당신은 캐시에 대해 많은 장부 기록을 하고 있습니다. 애플리케이션의 작업이 아닌 애플리케이션 내에서 데이터베이스 동기화 또는 데이터 무결성 코드를 구축하는 것과 같습니다. 당신은 데이터베이스에 대해 그렇게하지 않습니다. 데이터베이스가 이를 수행하므로 캐시도 이를 수행해야 합니다.
리드스루 및 라이트스루
따라서 read-through, write-through는 캐시에 있어야 하는 또 다른 매우 강력한 기능입니다. Read-through는 기본적으로 개념이 매우 간단합니다.
다음과 같은 경우 인터페이스를 구현합니다. NCache 바로 여기에서 read-through 제공자라는 인터페이스를 구현합니다. 당신은 그것을 볼 수 있습니까?
예, 세 가지 방법이 있습니다. 데이터 소스에 연결할 수 있도록 캐시가 시작될 때 호출되는 Init가 있습니다. 캐시가 중지되면 정리가 가능하며 대부분의 경우 소스에서 이 로드를 호출합니다. 따라서 키를 전달합니다. 키는 알아야 할 키입니다. 데이터 소스에서 어떤 항목을 가져와야 하는지, 다음과 같은 경우 다시 돌려줘야 합니다. NCache 공급자 캐시 항목. 그리고 만료를 지정하고 만료 시 재동기화, 모든 종류의 플래그를 여기에서 지정한 다음 다음으로 전달할 수 있습니다. NCache. NCache 캐시합니다.
그렇다면 read-through는 어떻게 작동할까요? 우리가 작동하는 방식은 애플리케이션이 항상 캐시를 요청하는 것입니다. Cache.Get이라고 되어 있습니다. 캐시에 데이터가 없으면 내가 없다고 말하는 대신 데이터베이스에서 데이터를 가져옵니다. 따라서 애플리케이션이 갑자기 훨씬 단순해집니다. 많은 지속성 코드가 애플리케이션에서 방금 제거되었습니다. 따라서 read-through의 한 가지 이점은 코드를 단순화하고 모든 코드를 캐싱 계층으로 캡슐화했다는 것입니다. 캐싱 계층에는 이제 점점 더 많은 지속성 계층이 있습니다. 모든 코드가 read-through를 통해 수행될 수 있는 것은 아니지만 많은 코드가 수행될 수 있습니다.
만료 시 다시 로드
read-through의 두 번째 이점은 앞에서 언급한 다시 로드 기능입니다. 이제 전자 상거래 애플리케이션이 있고 가격이 변경되고 가격이 변경될 때마다 해당 항목을 캐시에서 제거하고 다시 로드해야 하지만 트래픽이 너무 많아서 제거하는 동안 많은 클라이언트 요청이 데이터베이스에 도달한다고 상상해 보십시오. 첫 번째는 캐시를 가져와서 캐시에 넣지만 그 때까지 캐시는 갑자기 많은 불필요한 트래픽을 갖게 됩니다. 이러한 일이 계속 발생하면 데이터베이스에 불필요한 히트가 많이 발생하게 됩니다. 만료 시 다시 로드라고 하면 피할 수 있습니다. 만료를 다시 로드하면 어떻게 됩니까? 만료 시 항목을 제거하지 않습니다. 만료가 발생하면 캐시가 읽기를 호출하고 이동하여 데이터 소스에서 가져와서 업데이트하도록 다시 로드합니다. 따라서 업데이트 작업만 발생합니다. 제거 및 추가 작업이 없으므로 데이터 또는 항목이 항상 캐시에 있습니다. 그래서 갑자기 캐시가 됩니다. 자체적으로 처리할 수 있으며 데이터를 다시 로드해야 할 때마다 스스로 이동하고 다시 로드할 수 있습니다.
연속 기입
그래서, 그것은 read-through의 정말 강력한 능력입니다. 따라서 이를 만료와 결합하면 데이터베이스 동기화에서도 이를 수행할 수 있습니다. 데이터베이스 동기화가 발생하면 다시 제거해야 하는 이유는 무엇입니까? 새로고침하세요. 다른 기능은 write-through로, 쓰기를 수행하는 것을 제외하면 read-through와 동일하게 작동합니다. 그것이 하는 일이 하나 더 있는데, 대량 쓰기도 할 수 있습니다. 대량 쓰기를 수행하는 이유는 잠시 후에 설명하겠습니다. 따라서 Init이 있는 것과 같은 방식으로 dispose가 있고 이제 데이터 소스에 대한 쓰기가 있습니다. 쓰기는 추가 또는 삽입만을 의미하지 않습니다. 또한 삭제가 될 수 있으므로 쓰기에는 추가, 업데이트 또는 제거가 될 수 있는 작업 유형이 있습니다. 그리고 그것은 캐시 작업이 무엇인지에 따라 다릅니다. 그런 다음 일괄 처리할 수도 있습니다. 따라서 write-through는 코드를 단순화한다는 측면에서 read-through와 동일한 이점이 있지만 또 다른 이점이 있습니다. 따라서 read-through는 다시 로드할 수 있는 이점이 있습니다. write-through는 나중에 쓸 수 있는 이점이 있습니다.
후기 쓰기
그리고 write-behind는 매우 강력한 기능입니다. 왜? 데이터베이스 업데이트가 병목 현상이기 때문입니다. 다시 말하지만, 데이터베이스는 함께 살아가야 하는 필요악입니다. 그것 없이는 살 수 없지만 응용 프로그램에서 모든 종류의 병목 현상을 일으키고 있습니다. 따라서 의존도가 낮을수록 응용 프로그램이 더 좋아집니다. 당신이 그것 없이는 살 수 없다는 사실 당신은 여전히 그것을 가져야합니다. 그렇다면 write-behind는 무엇을 할까요? 데이터베이스보다 적어도 XNUMX배 이상 빠른 초고속 캐시를 업데이트하면 캐시가 데이터베이스 업데이트를 처리한다고 합니다. 따라서 비동기 쓰기가 있습니다. 즉, 쓰기 뒤에 있습니다. 따라서 캐시를 업데이트하고 돌아와서 작업을 계속하면 캐시가 이동하고 데이터베이스를 업데이트합니다.
물론 캐시가 해결해야 할 많은 문제가 있습니다. 캐시가 데이터베이스를 업데이트해야 한다고 말하자마자 캐시 서버가 충돌하면 어떻게 될까요? 해당 대기열은 어떻게 됩니까? 그래서, NCache, 대기열 자체는 서버가 다운되더라도 대기열을 잃지 않고 여러 서버에 복제됩니다. 그런 다음 재시도도 있습니다. 해당 업데이트가 실패하면 다시 시도할 수 있습니다. 일괄 업데이트도 할 수 있습니다. 따라서 일괄 업데이트를 수행할 수 있는 항목이 많이 있습니다. 따라서 더 최적화할 수 있습니다. 따라서 write-through 및 read-through는 매우 강력한 기능입니다. 이를 서버 측 코드라고 합니다. 이것은 캐시 클러스터에 있는 코드입니다. 여기에 존재하며 해당 코드를 서버에 유지하면 앱이 간소화됩니다. 따라서 푸시다운하는 코드가 많을수록 애플리케이션이 더 간단해집니다.
데이터 그룹화
좋아요! 이제 캐싱을 사용해야 한다고 확신했습니다. 많은 데이터를 캐싱할 수 있는 다양한 사용 사례가 있습니다. 이제 캐시가 데이터베이스처럼 보이기 시작했습니다. 캐시에 수백만 개의 항목이 있을 것입니다. 그렇다면 캐시에 수백만 개의 항목이 있을 때 키를 기반으로 항목을 읽는 것이 좋을까요? 아니요! 키를 기반으로 캐시에서 항목을 읽을 수 있는 유일한 방법이라면 이 검색 기준에 따라 모든 것을 제공할 수 있는 경우에 비해 애플리케이션이 매우 어려울 것입니다.
따라서 검색 및 그룹화는 캐시의 매우 매우 강력한 요구 또는 매우 중요한 요구가 됩니다. 다시 말하지만, 내가 말했듯이 목적은 귀하가 이점이 무엇인지 이해하는 것입니다. 이점은 점점 더 많은 데이터를 캐시할 수 있다는 것입니다. 더 많은 데이터를 캐시할수록 더 많이 보거나 더 많은 데이터베이스 유형의 기능이 필요합니다. 이러한 기능 중 하나는 메타데이터를 수행할 수 있다는 것입니다. 데이터베이스에서 다양한 속성에 대한 인덱스를 가질 수 있습니다. 여기에서 태그, 명명된 태그를 수행할 수 있으며 실제로 객체를 캐시할 때, NCache 또한 색인을 생성할 수 있습니다. 따라서 개체를 인덱싱할 수 있습니다. 도시를 검색할 예정이므로 고객이 도시 특성에 대해 색인을 생성할 수 있다고 가정해 보겠습니다. 인덱싱되지 않으면 검색이 정말 고통스러울 것입니다. 올랜도에 어떤 고객이 있는지 알기 위해 모든 개체를 검사하기 위해 먼저 역직렬화해야 하는 수백만 개의 항목을 상상해 보십시오. 좋은 그림이 아니라 예쁜 광경이 아닙니다.
따라서 코딩 관점에서 하위 그룹화 태그와 이름 태그를 다시 그룹화하는 것은 매우 간단합니다. 이것만 빨리 보여드리겠습니다. 녹음 관점에서 매우 사용하기 쉽습니다. 많은 항목을 추가하고 태그를 지정한 다음 죄송합니다! 그룹 및 하위 그룹, 그룹 하위 그룹 그리고 그룹 데이터 가져오기라고 말하거나 SQL 검색을 수행하고 그룹 이름이 전자 제품인 모든 제품 개체를 제공한다고 말할 수도 있습니다. 따라서 그룹화 및 하위 그룹화 태그와 태그도 AppFabric 그건 그렇고 제공 AppFabric XNUMX월에 중단됩니다. 우리는 더 많은 시간을 얻었습니다. 속도를 높일 것입니다.
데이터 찾기
다시 말하지만, 데이터 찾기는 SQL을 기반으로 데이터를 검색할 수 있도록 데이터를 그룹화하는 것과 관련이 있습니다. 그래서 제 생각에는… 객체 쿼리 언어는 어디에 있습니까? 거기는. 그래서 기본적으로 많은 데이터가 있고 SQL 문을 발행할 수 있으며 여러 속성을 지정하고 매개변수를 전달할 수 있습니다. NCache SQL 서버와 마찬가지로 전체 SQL의 하위 집합입니다. 관절은 하지 않지만 결합을 하는 대신 그룹화 및 태깅을 할 수 있으며 이것이 여러 개체를 함께 그룹화할 수 있는 방법입니다.
그래서 LINQ의 경우, NCache LINQ 공급자를 구현하여 Iqueryable 인터페이스를 구현했습니다. 당신은 가서 그 컬렉션을 얻을 NCache 그런 다음 다른 개체 컬렉션에 대해 수행하는 것과 마찬가지로 LINQ 쿼리를 수행하면 이러한 개체의 컬렉션인 제품 개체를 다시 가져올 것입니다. 따라서 LINQ가 검색 측면에서 정말 편안한 영역이라면 LINQ를 사용하여 검색하십시오. 이 쿼리를 실행하면 동일한 쿼리가 모든 서버로 전송되고 결과가 병합되어 사용자에게 표시되는 클러스터로 이동하게 됩니다. 따라서 여기서는 매우 단순해 보이지만 뒤에서는 많은 작업이 수행되고 있습니다. NCache.
따라서 SQL과 LINQ가 있습니다. 우리는 또한 대량을 가지고 있으며 내가 말했듯이 인덱싱을 할 수 있습니다.
런타임 데이터 공유
매우 빠르게 진행하겠습니다. 키 기반 이벤트, 캐시 수준 이벤트, 게시 하위 이벤트, 연속 쿼리가 있습니다.
연속 쿼리는 캐시에 있다는 점을 제외하면 SQL 종속성 기능과 유사한 기능입니다. 데이터 세트를 모니터링하도록 캐시에 요청하고 있습니다. 따라서 우리가 SQL 종속성을 사용하고 SQL 서버에 이 데이터 세트를 모니터링하도록 요청하고 이 데이터 세트가 변경되면 알려달라고 말한 것과 같습니다. 지금, 당신은 묻는다 NCache, 여기 내 SQL 문이 있습니다. Customer.City가 New York과 같은 고객을 선택하고 이 기준과 일치하는 고객이 캐시에서 추가, 업데이트 또는 삭제되면 저에게 알려주십시오. 그러면 네트워크의 모든 위치, 캐시 클러스터의 모든 위치가 될 수 있으며 다른 클라이언트가 될 수 있습니다. 알림을 받게 됩니다. 이제 이러한 유형의 기능을 사용함으로써 갑자기 캐시에 발생하는 상황을 모니터링하고 폴링하는 대신 알림을 받을 수 있습니다. 캐시가 정말 강력한 런타임 데이터 공유 플랫폼이 된다는 것입니다.
고 가용성
좋아요! 이것도 건너뛰겠습니다. 사용하는 모든 캐시는 동적이어야 합니다. 다음과 같은 경우에 고가용성을 제공해야 합니다. NCache, PXNUMXP 아키텍처가 있습니다.
클라이언트 캐시
당신이 알고 싶은 한 가지 기능이 있습니다. 클라이언트 캐시. 어떤 사람들은 캐시 근처라고 부릅니다.
이것은 실제로 응용 프로그램 서버 상자에 로컬로 있는 캐시입니다. 독립형이 아닌 것을 제외하면 독립형 캐시와 같습니다. 따라서 InProc일 수도 있습니다. 응용 프로그램 프로세스 내에 있을 수 있습니다. 즉, 개체 힙에서 실제로 항목을 가져오고 있음을 의미합니다. 힙에는 개체 형식의 데이터가 있습니다. 그 성능을 능가하는 것은 없겠죠? 힙에서 해당 데이터를 얻을 수 있고 캐시 로컬 상자 OutProc으로 이동할 수 있다면 프로세스를 통과할 때 IPC를 거쳐야 하고 직렬화, 역직렬화를 수행해야 하기 때문에 네트워크를 통해 이동할 때 훨씬 더 많고 데이터베이스로 이동할 때 비교적 비용이 많이 듭니다.
따라서 이것은 응용 프로그램 프로세스 내의 로컬 캐시 또는 상자의 로컬 캐시입니다. 그러나 동기화된 상태를 유지합니다. 클라이언트 캐시에 대해 특별한 API 프로그래밍을 수행하지 않습니다. 다음과 같은 경우 캐시를 호출하기만 하면 됩니다. NCache, 구성 변경에 연결하고 호출을 가로채고 무엇을 가져오든 복사본을 로컬에 보관합니다. 따라서 다음에 가져올 때 자동으로 로컬 캐시에서 가져옵니다. 성능이 크게 향상되었습니다. 이것은 단지 NCache .NET 측에 있습니다. Java 측에는 클라이언트 캐시가 있는 다른 제품이 있지만 .NET에서는 이것이 유일한 것이라고 말했습니다. 이것은 캐시 위에 있는 캐시와 같으며 이것이 많은 사람들이 독립 실행형 InProc 캐시에서 분산 캐시로 이동할 때 불평하는 이유입니다. 내 성능이 실제로 떨어졌고 애플리케이션이 더 느리다고 불평합니다. 저는 분산 캐시가 내 성능을 높여야 한다고 생각했고 우리는 그들에게 그것이 확장성을 높여야 한다고 말하지 않았습니다. 로컬 InProc 캐시와 일치하는 것은 없으며 아무도 할 수 없습니다. 나는 이것이 우리가 발명하고 무언가를 할 수 있는 것이 아니라는 것을 의미합니다. 여러 프로세스를 거치게 되면 그에 따른 비용이 발생합니다.
따라서 이러한 문제를 극복할 수 있는 한 가지 방법은 클라이언트 캐시를 사용하는 것입니다. 따라서 클라이언트 캐시는 다시 하위 집합입니다. 일반적으로 각 캐시 서버에는 16~32기가가 있습니다. 따라서 XNUMX~XNUMX개의 서버가 있는 경우 잠재적으로 약 XNUMX기가 이상의 캐시된 데이터가 있고 클라이언트 캐시는 각각 최대 XNUMX기가, XNUMX기가, XNUMX~XNUMX기가이고 작업자 프로세스 수에 따라 달라집니다. 작업자 프로세스가 하나만 있는 경우 XNUMX기가로 만드십시오. 많은 하이엔드 고객이 웹 계층에 가지고 있는 XNUMX개의 작업자 프로세스가 있는 경우 클라이언트 캐시에만 XNUMX 곱하기 XNUMX이 있는 것을 원하지 않을 것입니다. 따라서 캐싱 계층으로 이동하는 것보다 여전히 더 나은 프로세스 캐시에서 XNUMX기가를 사용하는 것이 좋습니다. 여전히 더 빠르거나 더 작은 XNUMX기가 또는 InProc인 XNUMX기가 미만의 캐시를 가질 수 있습니다. 이제 복사본이 XNUMX개 있지만 동기화되어 있습니다. 따라서 클라이언트 캐시는 캐시에서 가치를 얻으려는 경우 사용을 고려해야 하는 것입니다.
이제 제 목표는 캐시 기능을 판매하는 것이 아니라 좋은 캐시가 갖추어야 할 기능과 Java 측에서 찾을 수 있는 많은 기능을 말하는 것입니다. Java는 캐싱 측면에서 훨씬 더 성숙한 시장입니다. 분산 캐시 대신 메모리 내 데이터 그리드라는 단어를 사용하지만 어떤 기능을 사용하든 NCache, Java 쪽에서도 많이 볼 수 있지만 .NET 쪽에서도 볼 수 있습니다. NCache 유일한 것입니다.
WAN 복제
또 다른 기능은 여러 데이터 센터가 있는 경우 데이터베이스를 복제하고 싶은데 캐시는 왜 안 됩니까? 무엇을 할 건가요? 전체 캐시를 재구축하시겠습니까? 장바구니는 어떻습니까? 세션은 어떻습니까? 따라서 여러 데이터 센터가 현실이며 클라우드 덕분에 사용자가 노력할 필요가 없기 때문에 더욱 쉬워졌습니다. 지역 XNUMX, 지역 XNUMX라고 하면 데이터 센터가 두 개 있습니다. 맞습니까? 그러나 근본적인 문제는 사라지지 않습니다. 즉, WAN 복제를 지원하지 않는 분산 캐시를 사용하면 문제가 발생합니다. 캐시가 복제되지 않으면 활성-활성 또는 활성-수동 다중 데이터 센터 솔루션을 가질 수 없으므로 매우 중요한 기능입니다.
NCache 물론 이것을 가지고 있습니다. 이미 실습 데모를 제공했습니다. NCache 시장에서 가장 오래된 .NET 캐시입니다. 우리는 훨씬 오래된 2005년에 출시되었습니다.
NCache vs Redis
그럼 빠르게 넘어가도록 하겠습니다 NCache 대 Redis, 매우 매우 높은 수준이고 그 이유는 Redis 많은 사람들이 와서 우리와 비교할 때 어떤지 묻습니다. Redis Microsoft가 Azure를 위해 선택했기 때문입니다.
Redis, 훌륭한 제품입니다. 초고속입니다. 주로 Linux 측에서 제공됩니다. 그것은 많은 기능을 가지고 있지 않습니다. 그것은 기능에서 이기지 않습니다. Linux 쪽에서 나왔고 Microsoft는 .NET 솔루션을 채택할 수 없도록 AWS 시장을 확보하기를 원했습니다. 그들은 멀티플랫폼을 채택해야 했습니다. 따라서 그들의 Linux 버전은 매우 안정적이고 훌륭하지만 Microsoft가 자체적으로 수행한 Windows 포트는 일종의 고아 포트입니다. Microsoft는 자체적으로 사용하지 않습니다. Azure에 있고 사용할 때 Redis의 Windows 포트를 사용하고 있지 않습니다. Redis, Linux 버전을 사용하고 있습니다. 따라서 하늘빛에 있지 않고 다음의 Windows 포트를 사용하려는 경우 Redis, 조심하세요. 아무도 그것을 소유하지 않는다는 뜻입니다. Redis 연구실 웹사이트에 가면 Windows 다운로드도 없습니다. 나는 그들이 제작자 인 Linux 다운로드 만 가지고 있음을 의미합니다. Redis. 마이크로소프트는 내가 스스로 말했듯이 약속을 사용한다는 측면에서 입이 있는 곳에 돈을 넣지 않았습니다.
그래서, NCache 는 유일한 실행 가능한 옵션이며 오픈 소스이므로 돈이 없으면 무료 오픈 소스 버전을 사용하십시오. 프로젝트가 중요하고 엔터프라이즈 기능인 지원 및 더 많은 기능을 원하는 경우. 기업 NCache 오픈 소스 위에 구축됩니다. 별개의 것이 아닙니다. 오픈 소스는 고아가 아닙니다. 내 말은 우리가 그것을 소유하고 유지하며 기업이 그 위에 구축된다는 것을 의미합니다. 따라서 오픈 소스는 안정적이어야 하지만 지원과 더 많은 기능을 원하면 Enterprise Edition을 구입하면 됩니다.
우리는 기본 .NET입니다. 우리는 c-sharp에서 개발했으며 Windows Server 2012 r2 인증을 받았습니다. 다음편도 곧 올리도록 하겠습니다. 따라서 우리는 Microsoft에 관한 한 우리가 게임의 선두에 있지 않다는 것을 의미합니다. 우리는 거의 .NET입니다. 우리는 Java 클라이언트를 보유하고 있지만 구매하는 고객이 거의 모든 Java를 사용합니다. NCache .NET용이며 사내에 있기 때문에 Java에서도 사용합니다. 따라서 우리의 빵과 버터는 우리의 전체 생존이 .NET에 있습니다. 그래서 우리는 항상 가장 최신의 것, 가장 위대한 것, 최초의 것, 가장 쉬운 것입니다.