DEV교차로 2016
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
트랜잭션 로드 증가로 인해 .NET 응용 프로그램에서 데이터베이스 또는 저장소 병목 현상이 발생할 수 있습니다. 분산 캐싱을 사용하여 병목 현상을 제거하고 .NET 애플리케이션을 확장하는 방법을 알아보십시오. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
살펴보기
모두들 안녕. 제 이름은 이크발 칸입니다. 저는 기술 전도사입니다. Alachisoft. 우리는 샌프란시스코 베이 지역에 본사를 둔 소프트웨어 회사입니다. NCache 는 분산 캐시인 우리의 주력 제품이며 이것이 오늘 제 주제입니다. 내 주제는 NCache 오늘날 일반적으로 캐싱입니다. NosDB 우리가 가지고 있는 또 다른 제품인 오픈 소스입니다. NoSQL database .NET용. 여러분이 실제로 어떻게 사용되는지 볼 수 있도록 분산 캐시를 시연하기 위해 Azure를 사용할 것입니다.
따라서 오늘의 주제는 분산 캐싱을 위한 .NET 애플리케이션 확장입니다. 나는 더 많은 대화식 토론을 선호합니다. 그러니 제가 이야기하는 동안 질문이 있으시면 손을 들어 주십시오. 따라서 끝까지 기다리지 않고 그 시점에서 바로 이야기할 수 있습니다. 나는 그것이 훨씬 더 의미있는 대화를 만든다는 것을 알았습니다.
시작하겠습니다. 좋아요! 그래서 우리는 몇 가지 정의를 살펴볼 것입니다. 많은 분들이 이미 알고 계시리라 확신하지만 이것은 완성을 위한 것입니다.
확장성
첫 번째 정의는 확장성입니다. 확장성은 최대 부하에서 높은 애플리케이션 성능입니다. 예를 들어 5,000명의 사용자와 함께 초고속으로 수행되는 ASP.NET 응용 프로그램이나 .NET 응용 프로그램이 있다면 반드시 확장 가능한 것은 아닙니다. 물론 50,000명의 사용자가 빠르게 작동하지 않는다면 다른 문제가 있는 것입니다. 그러나 대부분의 애플리케이션은 사용자가 500,000명일 때 초고속으로 실행되지만 사용자가 XNUMX명, XNUMX명 또는 XNUMX명이 되면 문제가 발생하기 시작합니다. 따라서 응용 프로그램을 확장 가능하게 하려면 최고 부하에서 수행해야 합니다.
선형 확장 성
선형 확장성은 서버를 추가하면 선형 확장 가능한 것보다 더 많은 트랜잭션을 처리할 수 있는 증분 용량을 제공하는 방식으로 수행되는 경우 응용 프로그램 아키텍처, 배포 전략을 의미합니다.
즉, 두 개의 서버가 있고 추가하는 경우 세 개의 서버에 천 명의 사용자가 있다고 가정하면 1500명의 사용자가 있어야 합니다.
비선형 확장성
그러나 앱의 아키텍처 또는 배포가 선형적으로 확장 가능하지 않은 경우 위아래로 이동하는 로그 곡선처럼 보일 것입니다. 즉, 특정 지점 이후에는 서버를 더 추가해도 상관이 없습니다.
속도가 느려집니다. 더 많은 거래가 있으면 나갈 수 없습니다. 당신은 그 문제에서 당신 자신을 살 수 없습니다. 따라서 확장성뿐만 아니라 선형 확장성도 필요합니다.
어떤 애플리케이션에 확장성이 필요합니까?
다음 응용 프로그램은 일반적으로 이러한 유형의 문제가 있는 응용 프로그램입니다. 이들은 ASP.NET 웹 응용 프로그램, 이들은 웹 서비스, 이들은 일반적으로 웹 서비스이기도 한 인터넷 IOT 백엔드입니다. 일반적으로 .NET에서는 일반적이지 않은 빅 데이터 처리가 있을 수 있지만 빅 데이터 처리는 또한 무언가입니다. 확장 또는 기타 서버 응용 프로그램이 필요합니다. 특정 수의 거래를 처리해야 하는 규정 준수 요구 사항이 있는 금융 기관일 수 있습니다.
따라서 준수 요구 사항이 있는 서버 애플리케이션이 있을 수 있습니다. 예를 들어 은행 송금 애플리케이션인 경우 다음 영업일 또는 특정 시간까지 자금을 송금해야 합니다. 따라서 점점 더 많은 트랜잭션을 처리할 수 있어야 합니다. 따라서 이러한 응용 프로그램 중 하나가 있는 경우 올바른 대화에 온 것입니다.
확장성 문제
따라서 확장성 문제를 정의해 봅시다. 대부분의 사람들은 오늘날 애플리케이션 아키텍처가 ASP.NET 또는 웹 서비스 애플리케이션이 있는 경우 애플리케이션 계층의 아키텍처가 선형적으로 확장된다는 것을 알고 있습니다. 따라서 일반적으로 문제가 없는 서버를 더 추가할 수 있습니다. 문제는 실제로 데이터 스토리지에 있으며 데이터 스토리지라는 단어를 사용할 때는 관계형 데이터베이스와 메인프레임을 의미합니다. 레거시 데이터가 있습니다. 기존에 사용했던 모든 데이터 저장소는 병목 현상이 발생하고 병목 현상이 발생하면 이 문제가 발생합니다. 그만큼 NoSQL databases, 나는 그것들이 항상 답은 아니라고 말해야 했습니다. 하지만 NoSQL 운동은 부분적으로 이것 때문에 시작되었습니다. 관계형 데이터베이스는 확장성이 없었기 때문에 NoSQL databases는 확장 가능하지만 모든 상황에서 좋은 것은 아닙니다. 기존 데이터베이스의 모든 데이터를 NoSQL database 많은 새로운 데이터에 대해 그렇게 할 수 있지만 기존 비즈니스 데이터, 고객, 계정, 모든 데이터는 비즈니스 목적상의 이유와 기술적인 이유로 관계를 유지해야 합니다. 물론 기술적인 이유는 관계형 데이터베이스가 그 어떤 것과도 비교할 수 없는 생태계를 가지고 있기 때문입니다. NoSQL database 비즈니스 이유는 물론 동일한 성격을 띤다.
그래서, NoSQL database 항상 답은 아니며 우리가 가지고 있더라도 NoSQL database 판매하는 제품의 이름은 NosDB, 이는 관계형 데이터베이스의 확장으로만 사용됩니다. 따라서 관계형 데이터베이스에서 벗어날 수 없습니다. 관계형 데이터베이스는 여기에 있습니다. 그래서 그 현실과 함께 살아야 합니다. 따라서 여전히 그림에 있는 관계형 데이터베이스로 확장성을 해결해야 합니다.
확장성 솔루션
물론 해결책은 메모리 내 분산 캐시를 사용해야 한다는 것입니다. NCache 그러한 솔루션 중 하나입니다. 오픈 소스 분산 캐시입니다. 우리는 시장에서 가장 오래된 .NET 분산 캐시입니다. 우리는 지난 10년 동안 주변에 있었고 실제로는 이제 11년이 되었습니다. 그리고 우리는 유일한 진정한 네이티브 .NET 캐시입니다.
대부분 들어보셨을 Redis, 오른쪽? 그래서 2년 전에는 우리가 들어본 적이 없었습니다. Redis 그들은 그것에 집중하지 않았기 때문입니다. Microsoft가 Azure를 위해 그들과 파트너십을 맺을 때까지는 그렇지 않았습니다.
분산 캐시 배포
메모리 내 분산 캐시의 이점은 기존 데이터베이스와 함께 사용할 수 있다는 것입니다. 따라서 관계형 데이터베이스가 메모리 내 분산 캐시를 통해 제공하는 문제를 해결할 수 있습니다. 그렇다면 그 문제를 어떻게 해결합니까? 이 문제를 해결하면 여기 이 사진을 봅시다.
따라서 웹 애플리케이션, 웹 서비스, 기타 서버 애플리케이션인 애플리케이션 계층이 있으며 여기에 더 많은 서버를 추가할 수 있습니다. 웹 애플리케이션 및 웹 서비스의 경우 일반적으로 여기에 그리지 않은 로드 밸런서가 있습니다. 따라서 이 계층에 더 많은 서버를 추가할 수 있습니다. 데이터베이스 계층에 서버를 더 추가할 수 없습니다. 예! 에서 더 많은 서버를 추가할 수 있습니다. NoSQL 하지만 제가 말했듯이 항상 정답은 아닙니다. 따라서 이 두 상자를 해결해야 합니다. 따라서 애플리케이션 계층과 데이터베이스 사이에 메모리 내 분산 캐시를 배치합니다.
분산 캐시는 일반적으로 클러스터를 형성합니다. 따라서 모든 분산 캐시가 클러스터를 형성하는 것은 아닙니다. Memcached 분산 캐시 임에도 불구하고 클러스터링을 형성하지 않았습니다. Redis 클러스터를 형성하고, NCache 확실히 클러스터를 형성합니다. 분산 캐시는 여기서 두 개 이상의 서버로 구성된 클러스터를 형성합니다. 내가 두 가지라고 말한 이유는 중복성 목적과 복제, 기타 많은 목적과 확장성 목적 때문입니다. 캐시 서버가 하나만 필요한 경우 분산 캐시가 필요하지 않을 수 있습니다. 따라서 여기에 최소 두 개의 캐시 서버가 있어야 하며 이 캐시 클러스터는 실제로 모든 캐시 서버의 메모리와 CPU 리소스를 하나의 논리적 용량으로 풀링합니다. 이것이 의미하는 바는 서버를 더 많이 추가할수록 더 많은 메모리, 더 많은 CPU 처리 및 네트워크 카드 용량을 얻게 된다는 것입니다. 이것이 확장성에 대한 세 가지 병목 현상입니다. 메모리, CPU 및 네트워크 카드. 요즘 네트워크 카드는… XNUMX기가비트 또는 XNUMX기가비트가 거의 표준입니다. 개체 크기가 크지 않은 한 XNUMX기가비트 카드 또는 XNUMX기가비트를 최대로 사용하는 것은 매우 어렵습니다. 그러나 개체 크기가 큰 경우 큰 개체당 수백 킬로바이트를 의미하므로 트래픽이 많은 경우 네트워크 카드를 최대한 활용하기가 매우 쉽습니다. 그러나 더 많은 서버가 있고 당연히 더 많은 네트워크 카드가 있다면 메모리도 마찬가지입니다.
메모리 내 분산 캐시인 이유는 메모리가 디스크보다 훨씬 빠르기 때문에 실제로 가치를 추가하는 것입니다. 더 빠르고 확장 가능합니다. 따라서 여기서 목표는 분산 캐시로 가는 애플리케이션 액세스의 약 80%를 캡처하는 것입니다. 따라서 20%만 데이터베이스로 이동하도록 남게 됩니다.
많은 사람들이 처음에 캐싱을 성능 향상으로 보았습니다. 예! 인 메모리가 이것보다 빠르기 때문에 성능 향상입니다. 그러나 더 중요한 것은 확장성이 필요하다는 것입니다. 인프라에서 이와 같은 것이 없이는 확장할 수 없기 때문입니다. 실제로 점점 더 많은 회사들이 이제 애플리케이션 환경에 데이터베이스가 있는 것처럼 분산 캐시도 있는 것을 거의 표준으로 만들고 있습니다. 어떤 사람들은 Java 측에 있는 메모리 내 데이터 그리드라고 부릅니다. 이것이 용어입니다. 어떤 사람들은 이를 약간의 데이터 패브릭이라고 부르지만 분산 캐시는 .NET 에코시스템의 가장 일반적인 이름입니다. 그래서 이것은 인프라입니다. 일단 제자리에 있으면 정말 강력한 도구로 사용할 수 있습니다. 응용 프로그램 서버와 캐싱 계층 사이의 비율은 일반적으로 약 4:1, 5:1이며 트랜잭션 측면에서 꽤 로드된 서버라고 가정합니다. 이들의 특성에 따라 5:1 이상으로 갈 수도 있습니다. 그리고 일반적인 캐시 서버는 메모리가 약 16~32기가이고 듀얼 CPU 쿼드 코어 유형의 구성입니다. 따라서 매우 고급 상자가 아닙니다. 사실, 이 레이어에는 매우 고급스러운 상자가 필요하지 않습니다. 고급 상자 몇 개보다 더 많은 상자를 원합니다. 더 많은 메모리를 추가하면 최대 128 또는 256기가 메모리까지 올라갈 수 있지만 메모리가 더 많다는 것은 더 강력한 CPU가 필요하다는 것을 의미합니다. 왜 그런 겁니까? 메모리가 더 많으면 힙이 더 크고 가비지 수집이 훨씬 더 큰 작업이 될 것이고 가비지 수집은 .NET에서 가장 빠른 것이 아니며 CPU를 소모할 것이기 때문입니다. 따라서 점점 더 데이터베이스처럼 보입니다. 따라서 캐시 서버당 16~32기가가 가장 적합합니다. 지금까지 질문이 있습니까?
NCache 확장성 수치
다음은 확장성 수치입니다. NCache. 다른 캐시는 다른 숫자를 가지지만 목표는 이것을 확장 가능한 것으로 만드는 것입니다. 따라서 이러한 방식으로 읽기 확장이 이루어지고 쓰기가 확장됩니다. 복제가 읽기와 함께 발생하기 때문에 읽기가 쓰기보다 느립니다. 그 능력에 대해 이야기하겠습니다.
복제가 필요한 이유는 메모리가 휘발성이기 때문입니다. 따라서 하나의 서버가 다운되면 해당 데이터를 잃게 됩니다. 따라서 많은 경우에 해당 데이터를 잃어버리고 싶지 않을 것입니다.
분산 캐시의 일반적인 사용
지금까지 이야기의 목표는 분산 캐싱이 필요한 이유를 보여주는 것이었습니다. 이제 해당 사례를 설정했으므로 분산 캐시를 사용할 용도에 대해 이야기해 보겠습니다.
앱 데이터 캐싱
가장 일반적인 사용 사례는 제가 말씀드린 애플리케이션 데이터 캐싱입니다. 데이터베이스에 존재하는 데이터를 바로 여기에 캐시합니다. 따라서 가능한 한 많이 캐시한 다음 성능과 확장성을 향상시킵니다.
애플리케이션 데이터 캐싱 사용 사례에서 주목해야 할 주요 사항은 데이터가 두 위치에 존재한다는 것입니다. 데이터베이스에 하나, 캐시에 하나. 그런 일이 있을 때마다 두 곳에 존재한다면 무엇이 잘못될 수 있느냐는 가장 먼저 떠오르는 우려는 무엇입니까? 예, 일관성!
따라서 우수한 분산 캐시가 이를 처리하는 것이 정말 중요합니다. 캐시가 두 위치에서 데이터가 일치해야 한다는 사실을 처리할 수 없는 경우 더 많은 읽기 전용 데이터를 캐시해야 하기 때문입니다. 읽기 전용 데이터는 데이터의 약 10% ~ 15% 또는 20%입니다. 대부분의 데이터는 내가 트랜잭션 데이터라고 부르는 것입니다. 이들은 고객의 계정입니다. 그것은 변화하는 데이터입니다. 대부분의 경우 30분마다 변경될 수 있지만 몇 초마다 변경될 수 있습니다. 따라서 XNUMX분 또는 XNUMX초 동안 캐시할 수 있어도 여러 번 읽을 수 있다는 이점이 있으며, 이를 특정 날짜에 발생하는 총 트랜잭션 수로 곱하면 수백만 개의 트랜잭션이 발생합니다. 더 이상 데이터베이스로 가지 않습니다. 따라서 응용 프로그램 데이터 캐싱의 경우 우수한 분산 캐시가 이러한 일관성을 처리해야 한다는 것이 정말 중요합니다. 이러한 일관성을 유지하는 데 정말 중요한 기능에 대해 살펴보겠습니다. 따라서 애플리케이션 데이터 캐싱은 영구 데이터를 캐시합니다. 영구 데이터는 이것이 데이터베이스에 영구적으로 존재함을 의미합니다.
ASP.NET 특정 캐싱
두 번째 사용 사례는 ASP.NET 응용 프로그램이 있는 경우 물론 다른 웹 응용 프로그램에도 적용되지만 .NET에 중점을 둡니다. MVC 프레임워크를 사용하지 않는 경우 세션 상태, 뷰 상태를 캐시할 수 있고 페이지 출력인 출력을 캐시할 수 있습니다. 이러한 모든 데이터는 본질적으로 일시적입니다. 영구적이지 않습니다. 영구적이지 않은 데이터는 데이터베이스에 실제로 존재하지 않아야 합니다. 임시 데이터입니다.
데이터가 일시적인 경우, 일시적인 경우 데이터베이스에 존재하지 않고 캐시에만 존재합니다. 무엇이 잘못될 수 있는지에 대한 가장 큰 우려는 무엇입니까? 끈기… 아니면 부족합니다. 따라서 지속하지 않으면 데이터가 손실됩니다. 이 캐시 서버가 다운되고 이 장바구니 같은 것이 있고 예를 들어, 당신이 항공사이고 이 고객이 방금 항공편 검색을 수행했으며 최소 10달러 상당의 티켓 5,000장 또는 XNUMX장을 구매하려고 한다고 가정해 보겠습니다. 그들이 말하는 마지막 페이지 또는 마지막 페이지가 무엇이든 갑자기 캐시 서버가 다운되어 다시 시작해야 하기 때문에 세션이 사라졌습니다. 전체 활동이 손실됩니다. 그 고객을 잃을 수도 있습니다. 그다지 좋은 경험은 아닙니다.
따라서 일시적인 캐시는 무엇이든 캐시가 복제해야 합니다. 복제를 수행하지 않는 캐시는 실행 가능한 캐시가 아닙니다. 그리고 복제에는 비용이 들기 때문에 캐시는 효과적이고 효율적인 복제를 수행해야 합니다. 세션 상태는 ASP.NET에서 매우 일반적이기 때문에 분산 캐시의 매우 일반적인 사용 사례입니다.
이벤트를 통한 런타임 데이터 공유
실제로 잘 알려지지 않은 세 번째 일반적인 사용 사례는 런타임 데이터 공유라고 합니다. 이것은 공유해야 하는 여러 응용 프로그램이 있는 경우입니다. 한 응용 프로그램은 다른 응용 프로그램 또는 해당 응용 프로그램의 다른 인스턴스가 사용해야 하는 무언가를 생성하거나 업데이트합니다. 일반적으로 이를 위해 전통적으로 메시지 대기열을 사용하거나 해당 데이터를 데이터베이스에 넣으면 다른 응용 프로그램이 가져옵니다. 그러나 분산 캐시는 해당 사용 사례에 매우 적합합니다. 메시지 큐를 대체하기 위한 것이 아닙니다. 메시지 대기열은 다른 용도로 사용되지만 응용 프로그램이 동일한 데이터 센터에서 실행 중이고 모든 인스턴스와 메시지 대기열이 데이터를 공유해야 하는 경우 모든 응용 프로그램이 동일한 플랫폼에 연결되어 있기 때문에 훨씬 더 확장 가능한 데이터 또는 데이터 공유 플랫폼입니다. 플랫폼은 Pub/Sub 모델에서 이벤트를 실행할 수 있습니다. Pub은 하나의 응용 프로그램이 게시자임을 의미하며 게시자는 무언가를 게시하고 이벤트를 발생시킵니다. 모든 구독자에게 알림이 전송되고 해당 데이터를 소비하게 됩니다.
다른 유형의 알림도 있습니다. 특정 항목이 수정되면 응용 프로그램이 특정 항목에 관심을 보일 수 있으며 이 항목이 변경되면 알려줍니다. 아니면 연속 쿼리 그 특징 NCache 는 다음과 같습니다. SQL 종속성 SQL 서버의 기능, 여기서 NCache 다음과 같은 SQL 유형의 쿼리를 말할 수 있습니다. SELECTS Customers WHERE Customers.City = "뉴욕". 따라서 이 기준을 가진 고객이 캐시에 추가, 업데이트 또는 제거된 적이 있는 경우 알림을 받습니다.
따라서 캐시에 대한 변경 사항을 모니터링하는 훨씬 더 지능적인 방법입니다. 따라서 이러한 모든 기능을 통해 런타임 시 매우 빠르고 확장 가능한 방식으로 애플리케이션 간에 데이터를 공유할 수 있습니다. 그리고 이것은 또한 일시적인 데이터입니다. 비록 많은 데이터가 데이터베이스에 존재하지만 공유하는 형식은 아마도 그렇지 않을 것입니다. 그래서 일시적입니다. 따라서 이것도 복제해야 합니다. 지금까지 질문이 있으십니까? 여러분이 이미 이 내용을 완전히 알고 있거나 제가 매우 훌륭하거나 둘 중 하나입니다.
앱 데이터 캐싱 개요
그럼 어떻게... 어떤 기능을 사용해야 하고 어떻게 사용해야 하는지에 대한 몇 가지 소스 코드를 살펴보겠습니다. 나는 사용할거야 NCache 예를 들지만 제가 말했듯이 제 초점은 실제 기능에 더 있습니다.
다음은 캐시를 사용하는 일반적인 방법입니다.
Customer Load(string customerId)
{
// Key format: Customer:PK:1000
string key = "Customers:CustomerID:" + customerId;
Customer cust = (Customer) _cache[key];
if (cust == null)
{
// Item not in cache so load from db
LoadCustomerFromDb(cust);
// Add item to cache for future reference
_cache. Insert(key, cust);
}
return cust;
}데이터베이스에서 고객을 로드합니다. 데이터베이스로 이동하기 전에 캐시를 확인하고 문자열 기반 키인 키를 사용합니다. 말하자 고객:고객 ID 실제 고객 ID는 1000 정도일 수 있으며 캐시를 확인하라고 말합니다. 캐시에 있는 경우 데이터베이스로 이동할 필요가 없습니다. 캐시에 없는 경우 데이터베이스로 이동하여 해당 고객을 로드하고 캐시에 넣습니다. 캐시에 넣으면 다음에 올 때 당신이나 다른 사람이 올 때 캐시에서 찾을 수 있습니다. 이것은 매우 간단한 패러다임입니다. 이렇게 하면 모든 사람이 캐시보다 더 가치 있는 것을 찾을 수 있습니다.
물론 어쨌든 필요하다고 생각하는 많은 데이터로 캐시를 미리 채울 수 있는 다른 많은 기능이 있습니다. 따라서 많은 데이터베이스 히트를 사전에 저장한 다음 캐시에서 찾을 수 없는 데이터를 캐시에 점진적으로 계속 추가하게 됩니다. 예를 들어 다음은 Visual Studio 프로젝트입니다. 당신이 사용한다면 NCache 이러한 어셈블리 중 두 개를 연결합니다. 하나는 NCache.실행 시간 그리고 하나는 NCache.편물. 여기서 두 개의 네임스페이스를 유사하게 사용합니다. NCache.실행 시간 과 NCache.웹.캐싱. 네임스페이스 이름은 ASP.NET 캐시에 상당히 가깝도록 지정했습니다. 그래서, 언제 NCache 나온 ASP.NET 캐시는 사용 가능한 유일한 캐시였습니다. 그래서, 당신은 이것을 얻었고 당신의 애플리케이션의 시작 부분에서, 이것은 물론 콘솔 애플리케이션이고, 당신의 것은 다른 것이 될 것입니다. 캐시에 연결하고 캐시 핸들을 얻습니다. 모든 캐시에 이름이 지정되고 캐시 핸들이 있는 다음 객체를 캐시에 추가합니다. 예를 들어 방금 추가했다고 가정해 보겠습니다. 캐시.추가 여기. 키를 지정합니다. 그러나 이것은 아마도 David Jones가 아니어야 합니다. 일종의 고객 ID여야 하며 실제 개체가 있고 만료를 지정했습니다. 그리고 XNUMX분의 절대 만료를 지정합니다. 캐시에서 이 항목이 XNUMX분 후에 만료된다고 말씀하셨습니다. 다른 모든 것은 기본값으로 유지했습니다. 그리고 나중에 할 수 있습니다. 캐시.가져오기 다른 곳에서 같은 고객을 얻습니다. 따라서 간단한 캐시 작업입니다.
using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;
namespace BasicOperations
{
public class BasicOperations
{
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...실습 데모
의 경우 NCache, 모든 캐시의 이름이 지정됩니다. 이제 캐시가 어떻게 생겼는지 빠르게 보여주고 코드로 다시 돌아오겠습니다. Azure에서 여러 VM을 설정했습니다. 그래서, 당신은 실행할 수 있습니다 NCache Azure, Amazon, 온프레미스에서. 모든 경우에 캐시 서버 자체는 VM일 뿐입니다. 이것은 단지 Windows 2008, 2012 VM입니다. Azure의 캐시 클라이언트는 VM일 수도 있고, 웹 역할일 수도 있고, 작업자 역할일 수도 있고, 웹 사이트일 수도 있습니다.
클러스터형 캐시 생성
여기에서 데모 클라이언트에 로그인했습니다. 이제 빨리 가서 캐시를 생성하겠습니다. 그래서 캐시가 어떻게 생겼는지 보여줄 수 있습니다. 라는 이 도구를 사용하십시오. NCache 매니저, 그래픽 도구를 사용하면 … 여기 와서 '새 클러스터 캐시'를 생성한다고 말할 것입니다.
모든 캐시 NCache 명명됩니다. 그래서 캐시 이름을 지정하겠습니다. 지금은 다른 모든 항목을 기본값으로 사용하겠습니다.
Partitioned Replica의 토폴로지를 선택하겠습니다. 이 이야기의 마지막 부분에서 빠르게 살펴보겠습니다. 분할된 복제본 내 토폴로지입니다.
비동기 복제를 사용하겠습니다.
첫 번째 캐시 서버인 demo2를 선택하겠습니다. 그래서 그것들은 두 개의 내 캐시 노드입니다.
다음을 누르겠습니다. 모든 기본값을 사용하겠습니다. 이 캐시에 할당할 메모리 양을 지정하겠습니다. 따라서 캐시는 이보다 더 많은 메모리를 소비하지 않습니다. 나는 방금 한 번의 공연을 제공했지만 물론 당신의 공연은 훨씬 더 커질 것입니다. 그것이 파티션의 크기입니다.
따라서 캐시가 그만큼의 메모리를 사용하면 캐시가 가득 차게 됩니다. 따라서 새 항목을 거부하거나 기존 항목 중 일부를 제거합니다. 그래서 저는 이것에 대한 캐시의 5%를 제거한다고 말할 것입니다. 가장 최근에 사용된 것이 사용할 알고리즘이고 방금 캐시를 생성했다고 말할 것입니다.
계속해서 여기에 클라이언트를 추가하겠습니다.
그래서 방금 캐시를 만들었고 캐시를 시작하겠습니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
통계를 선택하므로 일부 PerfMon 통계를 사용할 수 있습니다. 또한 클러스터를 모니터링할 것입니다. 그래서 방금 캐시를 시작했습니다. 이 캐시를 데모 캐시라고 합니다. 그냥 빨리 테스트 해봐야겠습니다. 그래서 방금 함께 제공되는 스트레스 테스트 도구를 실행했습니다. NCache 자신의 환경에서 캐시를 빠르게 테스트할 수 있습니다.
이제 이 캐시가 작동합니다. 그래서 무슨 일이 일어나고 있는지, 클라이언트 상자에서 클라이언트는 자신의 응용 프로그램 서버 상자를 의미합니다. 바로 여기에 구성 파일이 있습니다. 그래서 방금 캐시를 만들었고 이제 캐시 서버가 무엇인지 알고 있습니다. 이제 코드로 돌아가겠습니다. 따라서 실제로 이 캐시 이름을 선택했을 때 이것이 실제로 일어난 일입니다. 내 애플리케이션은 이제 클러스터의 모든 캐시 서버에 연결되고 캐시 핸들을 제공했습니다. 캐시.추가, 실제로 캐시의 적절한 위치에 추가하고 나를 위해 모든 복제를 수행할 것입니다. 모든 작업이 완료됩니다.
따라서 API는 모든 세부 정보를 숨기지만 캐시가 보이지 않는 모습과 사용이 얼마나 쉬운지 보여드리고 싶었습니다. NCache 그 상황에서. 자, 메인으로 돌아갑시다. 다음은 API의 모습입니다.
- 캐시 연결
ICache cache = CacheManager.GetCache(“myDistributedCache”); cache.Dispose(); - 데이터를 가져 오는 중
Employee employee = cache.Get<Employee>("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); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
당신은 cache.Get, cache.Contains, cache.Add, 삽입, 제거. 삽입은 존재하지 않으면 추가하고 그렇지 않으면 업데이트를 의미합니다.
앱 데이터 캐싱 기능
이제 캐시가 어떻게 생겼는지, 간단한 API가 무엇인지 알았습니다. 우리가 이야기한 기능으로 갑시다. 분산 캐시에 중요합니다.
캐시를 최신 상태로 유지
따라서 우리가 가장 먼저 말한 것은 분산 캐시가 데이터를 최신 상태로 유지하고 캐시를 최신 상태로 유지해야 한다는 것입니다. 그렇게 할 수 있는 네 가지 방법이 있습니다. 첫 번째는 만료, 많은 캐시가 거의 모든 캐시를 가지고 있어 사물을 만료시킬 수 있습니다.
그래서, 거기에 절대 만료 거기에는 슬라이딩 만료. Absolute Expiration은 제가 방금 보여드린 것입니다. 즉, 어떤 일이 발생하든 지금부터 24분 후에 이 항목이 만료된다고 합니다. 그리고 제가 이렇게 말하는 이유는 제가 말했듯이 이 데이터는 데이터베이스에 존재하고 데이터베이스에서 변경되지 않을 것이라고 XNUMX분 동안만 신뢰할 수 있기 때문입니다. 데이터베이스에서 변경될 수 있으므로 캐시에 그 이상 보관하고 싶지 않습니다. 따라서 데이터의 특성에 대해 추측하고 있습니다. 일부 데이터는 몇 시간 또는 며칠 동안 캐시할 수 있습니다. 이것이 조회 테이블일 수 있습니다. 하루에 한 번 가격이 변경될 수 있습니다. 따라서 이것을 XNUMX시간 동안 캐시할 수 있습니다.
기타 데이터는 거래 데이터입니다. 30초 또는 XNUMX분 동안만 캐시할 수 있습니다. 따라서 절대 만료는 영구 데이터용이며 데이터를 캐시에 보관하는 것이 안전한 기간을 예측하거나 추측하는 한 가지 방법입니다. 매우 중요합니다. 절대 만료와 슬라이딩을 구별하고 싶습니다.
슬라이딩 만료는 기본적으로 이 간격 동안 아무도 더 이상 만지지 않을 때 캐시에서 이 항목을 제거하는 것을 의미합니다. 터치는 가져오기 또는 업데이트를 의미합니다. 예를 들어 세션 상태입니다. 로그아웃하면 세션 상태는 더 이상 누구도 건드리지 않습니다. 따라서 20분 정도 지나면 캐시에서 제거해야 합니다.
슬라이딩 만료는 일반적으로 임시 데이터에 사용됩니다. 청소 작업에 가깝습니다. 데이터를 최신 상태로 유지하는 것과는 아무런 관련이 없습니다. 더 이상 필요하지 않기 때문에 제거하는 것과 관련이 있습니다. 그러나 절대 만료는 데이터를 최신 상태로 유지하는 데 필요한 것입니다. 둘째, 만료는 매우 중요한 것입니다. 모든 캐시에는 반드시 있어야 하며 대부분의 캐시에는 적어도 절대 만료가 있어야 한다고 생각합니다.
캐시를 데이터베이스와 동기화
두 번째 특징은 그들 대부분이 하지 않는 것입니다. 그리고 여기에서 캐시를 데이터베이스와 동기화할 수 있습니다.
데이터베이스 종속성 사용
아시다시피 데이터베이스에서 이것이 얼마나 자주 또는 언제 업데이트될지 정말 예측할 수 없습니다. 데이터가 데이터베이스에서 언제 업데이트될지 알 수 없습니다. 업데이트하는 여러 응용 프로그램이 있기 때문입니다. 다른 사람들이 데이터를 직접 만지고 있을 수 있습니다. 따라서 캐시가 데이터베이스를 모니터링하기를 원합니다. 따라서 캐시는 데이터베이스의 이러한 변경 사항을 인식해야 합니다. 이것은 기능입니다 NCache 가지다. 이를 SQL 종속성이라고 합니다. 실제로 SQL 종속성이라는 SQL 서버 기능을 사용합니다. NCache 데이터베이스의 클라이언트가 됩니다.
어떤 모습인지 빠르게 보여드리겠습니다. 그래서 여기에 캐시가 있으면. 다시, 우리가 라이브러리를 만든 것과 같은 방식으로 캐시에 연결합니다. 이제 항목을 캐시에 추가할 때 바로 여기입니다. 내가 여기 와서 ''라고 하면AddProductToCacheWithDependency', 정의로 이동합니다. 그래서, 여기 당신은 이 캐시에 대해 말하고 있습니다. 여기 내 SQL 문이 있습니다.
private static void AddProductToCacheWithDependency (Product product)
{
// Any change to the resulset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.ProductID);
//Let's create SQL depdenency
CacheDependency sqlserverDependency = new SqlCacheDependency(connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlserverDependency;
//Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
cache.Add(cacheKey, cacheItem);
}
private static string GenerateCacheKey (Product product)
{
string cacheKey = "Product#" + product.productID;
return cachekey;
}따라서 SQL 문은 일반적으로 테이블의 해당 행을 반영합니다. 따라서 제품을 추가하는 경우 제품 ID가 this인 SQL 문이어야 합니다. 따라서 SQL Server용으로 이 SQL 문을 만들고 있습니다. 이것은 SQL Server에 대한 SQL 종속성의 일부로 전달하는 것이기 때문입니다. 당신은 그것을 전달합니다 NCache. 따라서 클라이언트 상자에 있는 당신은 이것을 다음으로 전달합니다. NCache. 따라서 이것을 SQL 문으로 지정합니다. '캐시 항목' 개체를 만들고 캐시 항목 내에서 'SQLServer 종속성'을 지정합니다. 그래서, SQLCacheDependency 의 클래스입니다 NCache, 실제로. 이것은 SQL 서버 종속성과는 다릅니다. 이것은 SQL 캐시 종속성을 제외하고 동일한 이름의 종류를 가집니다. 이것은 해당 SQL 문을 유지하고 이를 지정하고 항목을 캐시에 추가합니다. 자, 여러분은 이것을 했고 지금 이 시간에 바로 여기 이 상자에 앉아 있습니다.
그래서, 당신은 이것을 전달합니다 NCache. 캐시 서버 중 하나로 이동합니다. 이 캐시 서버는 이제 데이터베이스의 클라이언트가 됩니다. 연결 문자열 정보도 지정했기 때문입니다. 여기 어딘가에 연결 문자열을 지정합니다. 그래서, NCache 서버는 데이터베이스의 클라이언트가 됩니다. 이제 데이터베이스는 SQL 서버가 될 수 있고 Oracle이 될 수 있으며 NCache SQL 종속성 연결을 설정합니다. SQL 서버는 데이터 세트를 모니터링할 SQL 서버 내에 데이터 구조를 생성합니다.
그래서, 마치 NCache 런타임 데이터 공유에 대해 언급한 연속 쿼리 기능이 있었습니다. NCache 고객이 있는 모든 고객을 모니터링하고 있었습니다. 도시 = "뉴욕". 이제 SQL 서버는 SQL 서버 내에서 이 데이터 세트를 모니터링하고 해당 기준과 일치하는 행이 SQL 데이터베이스에서 추가, 업데이트 또는 제거되면 SQL 서버는 캐시 서버에 알립니다. 이제 캐시 서버는 이 데이터가 데이터베이스에서 변경되었음을 알고 있습니다. 따라서 두 가지 옵션이 있습니다. 기본 동작인 캐시에서 제거하거나 새 복사본을 다시 로드할 수 있습니다.
Read-Through/Write-Through 사용
새 복사본을 다시 로드하는 방법은 다음과 같습니다. NCache 라는 통독. 이 부분은 건너뛰고 이 부분으로 다시 돌아와야 합니다. 따라서 코드인 read-through라는 기능이 있습니다. read-through 핸들러를 구현하면 read-through 핸들러를 보여드리겠습니다. 그래서, 여기에 IReadThrough 제공됨.
{
// <summary>
// Contains methods used to read an object by its key from the master data source.
// </summary>
public class SqlReadThruProvider : Alachisoft.Ncache.Runtime.DatasourceProviders. IReadThruProvider
{
private SqlDatasource sqlDatasource;
// <summary>
// Responsible for loading the object from the external data source.
// Key is passed as parameter.
// <param name="key">item identifier; probably a primary key</param>
// <param name="exh">Current expiration hint; you can modify the value and attach a new hint</param>
// <param name="evh">Current eviction hint; you can modify the value and attach a new hint</param>
// <returns></returns
public void LoadFromSource(string key, out ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncItemonExpiration = true;
cacheItem.ResyncProviderName = sqlDatasource.ConnString;
}
// <summary>
// Perform tasks like allocating resources or acquiring connections
// </summary>
...당신은 이것을 구현합니다. 초기화하는 Init 메소드가 있습니다. Dispose 메서드이며 실제로 Get 메서드와 비슷합니다. 따라서 get은 키를 전달하고 캐시 항목을 돌려줍니다. 따라서 자신의 데이터 소스로 이동하여 해당 항목을 로드하고 만료 또는 기타 사항을 지정하고 다시 전달합니다. NCache. 이 코드는 캐시 서버에서 실행됩니다. 이것은 명심해야 할 중요한 사항입니다.
따라서 read-through는 실제로 캐시 서버 자체에서 실행됩니다. 사실 다른 다이어그램이 있습니다.
따라서 read-through는 캐시 서버 자체에서 실행됩니다. 따라서 .NET 코드가 실행되려면 캐시 서버가 .NET에서 개발되어야 합니다. 맞습니까? 따라서 귀하의 .NET 상점, 귀하의 응용 프로그램이 .NET에 있다면 이러한 모든 이점을 위해 귀하의 전체 스택이 .NET이어야 한다고 말한 이유입니다.
예를 들어 Redis, Redis Linux 기반 캐시입니다. 따라서 훌륭한 캐시입니다. 저는 그들에게 반대할 것이 없지만 .NET 상점이라면 이러한 모든 작업을 수행해야 하며 캐시가 자체적으로 동기화할 수 있도록 캐시 서버에서 코드를 실행해야 합니다. 데이터베이스에서 해당 항목을 자동으로 다시 로드합니다. 따라서 read-through 핸들러는 원하는 경우 SQL 종속성이 실행될 때 호출되는 것입니다. 원하지 않으면 캐시에서 해당 항목을 제거합니다. 그리고 캐시에서 제거되면 다음에 응용 프로그램에서 찾을 때 찾지 못하고 데이터베이스에서 가져올 것입니다. 이제 특정한 경우에 예를 들어 캐시에 저장한 제품 카탈로그이고 방금 가격을 업데이트했습니다. 캐시에서 제품을 제거하고 방금 가격을 업데이트한 이유는 무엇입니까? 이제 응용 프로그램은 데이터베이스에서 가져오기 위한 논리를 가져야 하기 때문입니다. 자동으로 다시 로드하는 것이 좋습니다.
따라서 많은 데이터가 만료되거나 데이터베이스 동기화가 발생할 때 계속해서 필요할 것이라고 생각되는 경우 제거하는 것보다 다시 로드하는 것이 좋습니다. 그러면 응용 프로그램에서 이 작업을 수행할 필요가 없기 때문입니다. 캐시가 더 많이 수행할수록 애플리케이션이 더 쉬워집니다. 따라서 캐시가 데이터베이스와 동기화할 수 있는 또 다른 방법입니다. 그래서 SQL 서버나 Oracle이 없다면, 예를 들어 MySQL이나 DB2가 있다면 이 두 가지 기능이 존재한다면 DB 종속성을 사용할 수 있습니다. NCache 그 곳 NCache 특정 테이블을 풀링하고 해당 행에서 플래그를 업데이트하도록 데이터베이스 트리거를 수정합니다. NCache 그것을 집어 들고 이 항목이 변경되었다고 말합니다. 따라서 제거하거나 다시 로드해야 합니다.
CLR 저장 프로시저 사용
CLR 프로시저는 캐시를 데이터베이스와 동기화하는 또 다른 방법입니다. 실제로 쓰는 곳 CLR 절차. 테이블 트리거에서 호출합니다. 따라서 추가 또는 업데이트 트리거 또는 삭제가 있는 경우를 가정해 보겠습니다. 이 CLR 프로시저를 호출하면 NCache 또는 캐시를 호출합니다.
CLR 절차의 경우 캐시가 비동기 메서드를 지원하는지 확인해야 합니다. NCache 하다. 따라서 삽입 비동기 호출과 같은 캐시를 만들 수 있으며 컨트롤이 즉시 반환됩니다. 비동기 호출을 수행하지 않으면 데이터베이스 트랜잭션이 시간 초과되기 시작하기 때문입니다. 캐시에서 여러 서버를 업데이트하고 있기 때문에 데이터베이스 트랜잭션이 설계한 네트워크가 아닌 네트워크를 통과하게 됩니다. 따라서 비동기 호출이 필요합니다.
이것이 캐시를 동기화할 수 있는 세 가지 방법입니다. 따라서 지불한 모든 캐시는 데이터를 최신 상태로 유지할 수 있는지 확인해야 합니다. 두 가지 방법입니다.
비관계형과 캐시 동기화
비관계형 데이터 소스가 있는 경우에도 같은 방식으로 데이터가 클라우드에 있거나 다른 위치에 있다고 가정해 보겠습니다. 웹 메서드 호출을 원할 수도 있습니다. 실제로 캐시 서버에서 등록하고 실행하는 코드인 사용자 지정 종속성을 구현할 수 있습니다. NCache 전화를 걸어 데이터 소스가 변경되었는지 여부를 확인하십시오. 데이터 소스를 확인하고 변경된 경우 알림 NCache 해당 데이터와 데이터 소스가 변경되었습니다. 그래서, NCache 제거하거나 다시 로드할 수 있습니다.
다시 관계형 데이터베이스를 사용하여 NCache 당신을 위해 모두 않습니다. 비관계형의 경우 사용자 지정 종속성을 수행해야 합니다.
관계형 데이터 처리
캐시를 최신 상태로 유지하는 마지막 측면은 종속성 기능입니다. 고객과 주문 간에 일대다 관계가 있고 둘 다 캐싱하는 경우를 가정해 보겠습니다. 고객 개체가 캐시에서 제거되면 어떻게 됩니까? 주문을 캐시에 보관해야 합니까? 실제로 데이터베이스에서 고객을 삭제했다면 어떻게 될까요? 음, 제가 일대다라고 말할 때 일반적으로 고객을 삭제하지 않습니다. 캐시에서 제거한 한쪽이 실제로 데이터베이스에서도 제거했을 수 있음을 의미한다면 어떻게 될까요? 이는 많은 쪽이 더 이상 유효하지 않음을 의미합니다. 그렇다면 누가 이 모든 것을 추적해야 할까요? 캐시가 당신을 위해 그것을 할 수 있다면 그것은 당신의 삶을 훨씬 더 단순하게 만듭니다.
예를 들어 ASP.NET 캐시 개체에는 다음과 같은 기능이 있습니다. 캐시 종속성. NCache 그것을 구현했으며 내가 아는 한 다른 .NET 캐시에는 이 기능이 없습니다. 다만, 기본적으로는 항목간 관계를 등록하고 이 항목에 따라 다르다고 하여 혹시라도 이 항목이 업데이트되거나 제거되면 자동으로 제거해 주시기 바랍니다. 따라서 캐시가 정리 작업을 수행합니다.
캐시가 더 많은 작업을 수행할수록 데이터가 최신 상태임을 확신할 수 있으므로 더 좋습니다. 이러한 확신이 생기면 거의 모든 데이터를 캐시할 수 있습니다. 데이터를 최신 상태로 유지하기 위해 어떤 전략을 사용할 것인지가 중요합니다.
데이터 찾기
이제 데이터가 최신 상태라는 확신이 있으므로 많은 데이터를 캐싱하기 시작합니다. 음, 일단 모든 데이터를 캐싱하기 시작하면 다음으로 오는 일은 캐시가 이제 점점 더 데이터베이스처럼 보이기 시작한다는 것입니다. 데이터베이스가 아니라 항상 임시 저장소입니다. 그러나 특히 많은 참조 데이터의 경우 거의 전체 데이터 세트를 캐시에 저장합니다. 그런 일이 발생하면 검색할 수 있기를 원합니다. 항상 키를 기반으로 찾는 대신 매우 불편합니다. 키를 기반으로 항목을 찾는 것이 항상 편리한 것은 아닙니다. 다른 수단을 통해 검색할 수 있기를 원합니다.
한 가지 방법은 SQL 검색. 다시, SELECT Customers WHERE customers.City = "뉴욕". 당신이 하는 것처럼 또는 당신은 나에게 이 범주의 모든 제품을 제공한다고 말할 것입니다. 따라서 데이터베이스가 아닌 캐시에서 해당 개체의 컬렉션을 다시 가져옵니다. 캐시에서 나온다는 것은 물론 데이터베이스가 더 이상 히트를 받을 필요가 없고 모두 인메모리라는 것을 의미합니다. 동시에 여러 서버에서 오는 것이 훨씬 빠릅니다.
따라서 이러한 모든 쿼리는 병렬 쿼리입니다. 그리고 이를 수행하려면 캐시가 인덱싱을 지원해야 합니다. NCache 하다. 다른 제품이 지원하는지 여부는 확실하지 않지만 캐시가 인덱싱을 지원하는지 확인하십시오. 그렇지 않으면 정말 정말 느린 쿼리가 될 것입니다.
데이터 그룹화
캐시에서 할 수 없는 한 가지는 관계형 데이터베이스에서 할 수 있는 여러 개체 또는 여러 테이블을 조인하는 것입니다. 따라서 사물을 그룹화하고 특정 방식으로 태그를 지정하여 다시 가져올 수 있으며 캐시에 있는 일부 논리적 연결 또는 그룹화를 기반으로 데이터를 가져올 수 있는 방법이 있습니다. 따라서 모든 것을 캐시하면 예를 들어 보겠습니다. 예를 들어, 고객 컬렉션을 되찾았다고 가정해 봅시다. 따라서 개체 태그 모음이 있고 모든 개체를 캐시에 개별적으로 캐시하려고 합니다. 그러나 나중에 한 번의 호출로 모든 것을 가져올 수 있기를 원합니다.
//Caching Query Results (Collection)
//Cache Collection Objects Separately
static void CacheSupplierProducts(NorthwindEntities context, int supplierId)
{
Tag[] productTags = new Tag[1];
productTags[0] = new Tag("SupplierProducts:" + supplierId);
IQueryable<Product> products = context.Products;
var result = from product in products
where product.SupplierID == supplierId
select product;
foreach (Product p in result)
{
String key = "Products:ProductId:" + p.ProductID;
_cache.Insert(key, p, productTags);
}
}
...
ICollection productList = _cache.GetByAnyTag(productTags).Values;따라서 동일한 쿼리, SQL 쿼리를 실행하고 모든 것을 돌려준다고 합니다. 하지만 데이터베이스에서 이러한 개체를 얻었고 캐시에서 가져오지 않았습니다. 그리고 그것들은 전체 데이터 세트가 아닙니다. 그 당시에 가져오고 싶었던 세트가 무엇이든 간에 말입니다. 따라서 개별적으로 액세스해야 하는 모든 개체를 개별적으로 캐시했습니다. 그러나 나는 그것을 모두 하나의 컬렉션으로 다시 가져올 수 있기를 원합니다. 그래서 저는 태그라는 개념을 사용합니다. 모두 같은 태그로 태그를 지정했습니다. 그리고 그 태그는 임의의 고유한 문자열일 수 있으며 이 태그가 있는 모든 항목을 제공합니다. 따라서 전화 한 번으로 전체 컬렉션을 다시 가져올 수 있습니다. 따라서 태그를 사용하여 수행할 수 있는 유형의 작업이며 캐시에 조인이 부족하다는 점을 보완합니다.
따라서 그룹핑을 할 수 있습니다. 그만큼 그룹 및 하위 그룹. 넌 할 수있어 태그. 명명된 태그를 수행할 수 있습니다. 명명된 태그 본질적으로 키와 값이 있습니다. 예를 들어 텍스트, 자유 형식 텍스트를 캐싱하는 경우. 텍스트이기 때문에 해당 텍스트를 자체적으로 인덱싱할 방법이 없습니다. 따라서 태그를 직접 구성해야 하며 태그 자체만으로는 충분하지 않을 수 있습니다. 모든 태그의 이름을 지정할 수 있기를 원합니다.
따라서 개체에 속성 이름이 있는 것과 같습니다. 그래서 이름표는 사물의 속성과 같습니다. 따라서 이름은 도시일 수 있고 이 텍스트의 값은 New York 또는 Las Vegas일 수 있습니다. 따라서 모든 작업을 수행한 다음 나중에 이러한 작업을 가져올 수 있으며 다음과 같은 경우 NCache 최소한 API를 통해 또는 SQL 쿼리. 따라서 SQL을 기반으로 무언가를 가져올 때 …
첫 번째 질문, 훌륭합니다! 계층적 분류를 사용할 수 있습니까? 실제로 할 수 있는 것은... 그룹과 하위 그룹이 한 수준의 계층 구조만 제공한다는 것입니다. 따라서 그룹 내에서 여러 하위 그룹을 가질 수 있지만 그 이상으로 이동할 수는 없습니다.
하나의 항목에 여러 태그를 할당할 수 있으므로 다른 유형의 태그를 사용하여 나타낼 수 있습니다. 예를 들어 여러 계층이 있는 경우 아래로 내려가는 모든 수준에 할당할 수 있고 모든 상위 수준을 별도의 태그로 할당할 수 있습니다.
질문이 하나 더 있습니다. 캐시의 내부 표현을 제어할 수 있습니까? 인덱스는 해시 테이블의 조합을 기반으로 구축됩니다. NCache, 그리고 레드 블랙 트리. 인덱스를 선택할 수 있지만 내부적으로 사용할 데이터 구조는 선택할 수 없습니다. 단, 인덱스는 사용 특성에 따라 작성됩니다. 예를 들어 해시 테이블은 특정 유형의 액세스에 적합하며 범위 유형의 검색을 수행하려는 경우 레드 블랙 트리가 훨씬 좋습니다. 그래서 NCache 한다. 다른 제품은 어떨지 모르겠지만 NCache 꽤 많이 색인을 생성합니다.
읽기 및 쓰기
빨리 지나가게 해줘 통독, 통독. 그렇다면 왜 read-through와 write-through를 원하십니까? Read-through, 우리는 자동으로 내용을 다시 로드할 수 있는 한 가지 예를 보았습니다.
read-through의 또 다른 이점은 물론 캐시 자체에 대한 데이터 액세스의 많은 부분을 통합한다는 것입니다. 더 많이 액세스할수록 캐시 또는 캐싱 계층에 더 많이 들어갈수록 응용 프로그램에 더 적게 들어가고 응용 프로그램은 더 단순해집니다. 응용 프로그램은 단지 캐시.가져오기 물론 그것의 또 다른 이점은 자동으로 물건을 로드할 수 있다는 것입니다.
연속 쓰기도 같은 방식입니다. 한 가지 이점은 모든 쓰기를 통합할 수 있다는 것입니다. 두 번째 이점은 실제로 쓰기 속도를 높일 수 있다는 것입니다. 예를 들어 write-behind는 캐시를 동기식으로 업데이트하고 캐시는 데이터베이스를 비동기식으로 업데이트하는 기능입니다. 따라서 데이터베이스 업데이트가 캐시만큼 빠르지 않은 경우 캐시와 캐시 업데이트 데이터베이스만 업데이트하므로 애플리케이션 성능이 갑자기 향상됩니다.
따라서 read-through, write-through 및 write-behind는 실제로 활용해야 하는 매우 강력한 기능입니다. 이것은 또한 캐시 클러스터에서 실행되는 작성하는 서버 측 코드이며 삶을 단순화합니다. 따라서 애플리케이션은 캐시에 더 많은 데이터를 보유하고 캐시를 통해 업데이트할 수 있습니다.
빨리 훑어보고 이야기하겠습니다. 자세한 내용은 다루지 않겠습니다 ASP.NET 세션 상태 캐싱. 코드를 변경하지 않고 연결하고 web.config를 변경하기만 하면 자동으로 처리되며 동일한 작업이 진행됩니다. 보기 상태 과 출력 캐싱.
고가용성(가동 시간 100%)
몇 가지를 빠르게 살펴보겠습니다. 먼저 이야기하고 싶었던 것은... 여러분이 사용하는 모든 캐시는 데이터베이스와 같기 때문에 프로덕션 환경의 인메모리 데이터베이스입니다. 따라서 캐시는 가용성이 높아야 합니다. 고가용성 캐시가 있어야 합니다.
동적 캐시 클러스터
NCache 몇 가지 작업을 통해 가용성이 높습니다. 먼저 그것은 동적 캐시 클러스터. 런타임에 서버를 추가하거나 제거할 수 있으며 자동으로 클러스터를 재조정합니다. 클라이언트는 자동으로 구성에 서버 이름을 하드 코딩할 필요가 없습니다. 클라이언트가 캐시 서버와 통신하면 클러스터 구성원 정보를 얻습니다. 런타임 시 구성원이 변경되면 새 노드를 추가하거나 노드를 삭제한다고 가정하면 업데이트된 구성원이 클라이언트에 전파됩니다.
그래서 거기에 있어야 할 첫 번째 부분입니다. 그렇게 보는 것이 정말 중요합니다.
캐싱 토폴로지
두 번째는 캐싱 토폴로지입니다. 따라서 다양한 방법이 있습니다. NCache예를 들어 XNUMX개의 캐싱 토폴로지를 제공합니다. 첫 번째는 미러링된 캐시. 2노드 능동/수동입니다.
초라고 합니다 복제된 캐시, 캐시의 모든 서버에는 전체 캐시의 복사본이 있습니다. 따라서 서버가 많을수록 더 많은 캐시 복사본을 갖게 됩니다. 읽기용으로 확장할 수 있지만 업데이트용으로 확장할 수는 없습니다. 그러나 케이스와 함께 자체적으로 사용됩니다.
세 번째 토폴로지는 파티션된 캐시, 전체 캐시가 파티션으로 나뉩니다. 모든 서버는 하나의 파티션입니다. 그리고 이러한 파티션은 자동으로 생성됩니다.
그래서 예를 들어 다음과 같은 경우 NCache 각 파티션에는 내부에 여러 개의 버킷이 있습니다. 따라서 총 클러스터에는 1,000개의 버킷이 있습니다. 따라서 세 개의 파티션이 있는 경우 XNUMX/XNUMX, XNUMX/XNUMX의 버킷이 있습니다.
분할된 복제본 파티션과 동일하지만 모든 파티션이 다른 서버에 백업되며 모든 작업이 자동으로 수행됩니다. 따라서 XNUMX노드 클러스터를 생성하면 XNUMX개의 파티션, 즉 XNUMX개의 복제본을 갖게 됩니다. 세 번째 서버를 추가하면 자동으로 세 번째 파티션이 생성되고 세 번째 파티션이 생성되면 일부 버킷이 기존 파티션에서 이동해야 합니다.
따라서 모든 작업이 자동으로 수행됩니다. 새 복제본이 자동으로 생성됩니다. 사실, 이것에서 그것을 본다면, 여기에서 그것을 보여드리겠습니다. 1개의 서버 파티션이 있다고 가정해 보겠습니다. 하지만 1개의 서버 클러스터링만 있는 경우 2개의 파티션이 있다고 가정해 보겠습니다. 파티션 2이 여기에 있고 레플리카 2이 있습니다. 파티션 3, 레플리카 XNUMX. 이제 세 번째 서버를 추가했습니다. 갑자기 세 번째 파티션이 있어야 하며 여기에서 일부 버킷을 가져오고 여기에서 일부 버킷을 가져옵니다. 두 번째 복제본 XNUMX는 더 이상 여기에 있지 않고 여기로 이동할 것입니다. 이제 파티션 XNUMX의 복제본이 여기에 있어야 하기 때문입니다.
따라서 모든 조정은 다음을 통해 자동으로 수행됩니다. NCache. 그래서 그것은 한 가지입니다. 둘째, 라는 기능이 있습니다. 클라이언트 캐시 어떤 사람들은 그것을 Near Cache라고 부르는데, 이것은 꼭 사용해야 할 만큼 정말 강력합니다. 기본적으로 클라이언트 애플리케이션 내의 로컬 캐시입니다. 그러나 이것에 대한 한 가지 특별한 점은 이 로컬 캐시가 캐시 클러스터와 연결이 끊어지지 않는다는 것입니다. 캐시 클러스터에 연결되어 있습니다. 자체 동기화를 유지합니다.
따라서 다음의 경우에는 NCache, 예를 들어 클라이언트 캐시는 구성에 자동으로 연결됩니다. 이러한 각 애플리케이션에서 무엇을 가져오든 서버는 자동으로 클라이언트 캐시에 보관됩니다. 따라서 다음에 필요할 때 클라이언트 캐시에서 찾을 수 있습니다. 그리고 캐시 클러스터는 어떤 데이터가 어떤 클라이언트 캐시에 있는지 알고 있습니다. 따라서 해당 데이터가 다른 클라이언트에 의해 변경되면 클러스터는 해당 데이터가 있는 모든 클라이언트 캐시에 알리고 스스로 업데이트하도록 합니다. 따라서 클라이언트 캐시는 연결된 상태를 유지하지만 로컬 캐시입니다. In-Proc일 수도 있습니다. In-Proc은 지원 프로세스 내를 의미합니다. 따라서 실제로 성능이 향상되는 동시에 전체 연결된 분산 캐시의 일부가 됩니다.
WAN 복제
나는 많은 것들을 건너뛸 것입니다, 우리는 시간이 없습니다. 그래서, 또한있다 WAN 복제. 여러 데이터 센터가 있는 경우 캐시가 WAN을 통해 자체 복제되도록 할 수 있어야 하며 WAN을 통해 클러스터를 구축할 수 없습니다. 이 소켓이 끊어지기 때문에 그냥 죽을 것입니다. 대기 시간이 매우 높습니다. 따라서 두 데이터 센터 간에 캐시를 연결하는 방법이 있어야 합니다.
의 경우 NCache 여러 데이터 센터를 연결하는 브리지 토폴로지라는 것이 있습니다. 이제 활성-활성, 활성-수동 또는 둘 이상의 데이터 센터 센터를 가질 수 있습니다. 그리고 이것은 모두 비동기식으로 수행되며 충돌 해결도 수행됩니다. 보시다시피 캐시는 단순한 키 값 저장소가 아닙니다. 따라서 무대 뒤에서 염두에 두어야 할 것이 많이 있습니다.
NCache 대 Redis
내가 빨리 다루고 싶었던 한 가지는 NCache 대 Redis, 그냥 높은 수준, 나는 이것에 대해 이야기하고 싶었습니다. NCache 네이티브 .NET 캐시입니다. Windows에서 실행되며 클라이언트 측과 서버 측 캐싱을 모두 수행할 수 있다는 이점이 있습니다. 반면, Redis 주로 Linux 기반 캐시입니다. Microsoft가 그들과 파트너십을 맺기 전에는 .NET 측의 대부분의 사람들이 Unix와 PHP 및 기타 환경에서 매우 인기 있는 캐시였음에도 불구하고 존재조차 몰랐습니다.
둘째, Linux 버전의 NCache Azure에서 사용 가능, 서비스로서의 캐시로. 따라서 캐시를 서비스로 사용하는 이유는 .NET 애플리케이션의 경우 실제로 Linux 기반 캐시에서 서버 측 코드를 실행할 수 없기 때문입니다. 실행하려면 .NET 기반 캐시가 있어야 합니다. 그래서 그것은 당신이 얻게 될 하나의 큰 제한입니다.
셋째, Azure 외부에서 무엇이든 하려는 경우, Redis Linux 기반 캐시로만 사용할 수 있습니다. Microsoft가 한 창 지원은 그들이 사용하지 않는 것입니다. Azure에서도 Windows에서 사용하도록 선택하지 않습니다. 그다지 안정적이지 않습니다. 더 자세한 내용을 보고 싶으시면 더 자세한 내용도 있습니다. 비교 NCache 과 Redis, 여기로 와서 비교를 볼 수 있습니다. 그래서 우리는 비교 왜냐하면 우리는 우리에 대해 매우 확신하기 때문입니다.
보시다시피 이것은 완전한 비교입니다. 그냥 통과하십시오. 분산 캐시 사용에 대해 생각하고 있다면 필요한 모든 확장성이 있습니다. 숙제를 하고 무엇을 사용하든 필요에 맞는지 확인하세요. 그리고, 어디까지나 NCache 걱정되시면 쉽게 비교하실 수 있도록 하겠습니다. NCache 다른 사람들과. 저희 웹사이트에 오셔서 다운로드 NCache. 오픈 소스입니다. 따라서 Enterprise Edition 또는 Open Source 중 하나를 여기에서 다운로드하거나 다음으로 이동할 수 있습니다. GitHub의 그리고 당신은 할 것이다 NCache 여기를 클릭해 문의해주세요.
이것이 제 발표의 끝입니다. 질문이 있으십니까? 저장 프로시저 호출을 전달할 수 있습니다. SQL 서버 자체 내에서 실행되는 트랜잭션 SQL 항목과 같이 모든 SQL이어야 합니다.
예. 따라서 캐시는 애플리케이션과 동일한 서버에 있을 수 있습니다. 권장하지 않습니다. 좋은 배포 전략은 아니지만 구성이 작은 경우에는 물론 그렇습니다.
파티셔닝을 수행하면 모든 파티셔닝이 자동으로 수행됩니다. 따라서 전체 아이디어는 트랜잭션 측면에서 데이터 크기 측면에서 모든 파티션의 가중치가 동일해야 한다는 것입니다.
당신은 파티션을 제어하지 않고 파티션이 존재한다는 것을 알고 있습니다.
항목 테이블을 업데이트할 때 데이터베이스에서 캐시로 직접 호출할 수 있는 CLR 프로시저가 있는 경우 데이터베이스 자체 내에서 캐시를 업데이트하도록 선택할 수 있습니다. 또한 캐시를 업데이트할 수 있는 별도의 코드를 작성할 수 있으며 캐시에 보관하고 있는 캐시의 양에 따라 달라집니다.
원하신다면 오프라인에서 더 많은 이야기를 나눌 수 있습니다. 하지만 액세스해야 하는 모든 데이터가 캐시에 최신 상태로 유지되도록 할 수 있는 여러 가지 방법이 있습니다.
예, 실제로 슬라이드를 사용할 수 있도록 하겠습니다. 그것이 우리가 모든 사람의 이메일을 스캔한 이유입니다. 그래서 우리는 그렇게 할 수 있고 비디오도 녹화하고 업로드할 것입니다. 그래서 여러분도 볼 수 있고 동료들도 볼 수 있습니다.
실제로, 응용 프로그램별로 또는 ... 실제로 여러 응용 프로그램에 걸쳐 있습니다. 따라서 모든 것은 트랜잭션 부하에 따라 달라집니다. 클러스터를 갖기 위해 최소 2개의 캐시 서버를 가질 수 있으며 서버 수는 보유한 응용 프로그램 서버의 수 또는 기본적으로 활동량에 따라 달라집니다. 얼마나 많은 데이터가 캐시될 예정입니까? 당신은 얼마나 많은 읽기와 쓰기를 하고 있습니까?
상관없어요. 예, 모든 것이 계속 작동합니다. 감사합니다.