사우스 플로리다 코드 캠프 2017
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
트랜잭션 로드 증가로 인해 .NET 응용 프로그램에서 데이터베이스 또는 저장소 병목 현상이 발생할 수 있습니다. 분산 캐싱을 사용하여 병목 현상을 제거하고 .NET 애플리케이션을 확장하는 방법을 알아보십시오. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
오늘은 분산 캐싱을 사용하여 .NET 앱을 확장하는 방법에 대해 이야기하겠습니다. 이 이야기는 이것에 관한 것이 아닙니다. NCache. 참고하겠지만 NCache 하지만 주요 목적은 문제가 무엇인지, 캐싱을 사용하여 문제를 해결할 수 있는 방법을 교육하는 것입니다.
확장성이란
좋아요! 완전성을 위해 이미 알고 계시리라 확신하는 몇 가지 정의를 살펴보겠습니다. 먼저 확장성이 무엇인지 정의해 보겠습니다. 확장성은 고성능이 아닙니다. 고성능은 사용자가 XNUMX명이라면 응답 시간이 정말 좋은 것, 즉 고성능입니다. 확장성은 최대 부하에서도 동일한 고성능을 유지할 수 있는지 여부입니다. 따라서 애플리케이션이 XNUMX명의 사용자를 대상으로 높은 성능을 발휘하지 못한다면 다른 문제가 있는 것입니다. 우리가 해결할 수 있는 것보다 더 많은 것이 있습니다.
선형 확장 성
둘째, 선형 확장성이란 무엇입니까? 선형 확장성은 배포 정의에 가깝습니다.
다중 서버 환경에 애플리케이션을 배포할 때 로드 밸런싱된 환경이 있는 경우 추가 트랜잭션 용량을 얻기 위해 서버를 더 추가하기만 하면 애플리케이션이 선형적으로 확장 가능하다고 가정해 보겠습니다. 따라서 두 개의 서버에 1500명의 사용자가 있는 경우 세 번째 서버를 갖게 되면 사용자는 500명이 되고 서버를 더 추가하면 각각 XNUMX명의 사용자가 있게 됩니다. 나는 단지 가설적으로 말하고 있지만 그것은 선형 확장성입니다. 만약 당신이 그것을 달성할 수 있다면 그것이 목표입니다. 왜냐하면 당신은 결코 문제에 부딪히지 않을 것이기 때문입니다. 나는 당신이 이 문제를 해결하기 위해 여기에 있었을 것이라고 확신합니다.
비선형 확장성
비선형 확장성은 문제를 해결하기 위해 더 비싼 하드웨어나 더 많은 서버를 구입할 수 없는 애플리케이션 아키텍처를 갖고 있다는 것과 정반대입니다.
몇 가지 근본적인 병목 현상이 발생하므로 특정 시간 동안 서버, 애플리케이션을 추가하면 성능이나 트랜잭션 용량이 증가하지만 이후에는 서버를 추가하더라도 실제로 속도가 느려집니다. 따라서 비선형 확장성을 원하지는 않습니다.
확장성이 필요한 애플리케이션 유형은 무엇입니까?
이는 일반적으로 서버측 애플리케이션입니다.
이는 웹 애플리케이션, ASP.NET, 웹 서비스 WCF, 모든 IOT 애플리케이션의 백엔드일 수 있습니다. 일종의 백엔드와 통신하는 다양한 IOT 장치가 있습니다. 이는 빅 데이터 처리 애플리케이션일 수 있지만 빅 데이터 처리는 Java 활동에 가깝습니다. Hadoop으로 인해 .NET은 그다지 큰 빅 데이터 처리가 아니지만 빅 데이터 처리를 수행하는 경우 이 범주에 맞지 않는 다른 서버 애플리케이션을 반드시 확장해야 합니다. 일괄 처리 작업이 많을 수 있다는 의미입니다. 대기업인 경우 자정이나 다음 영업일 이전까지 특정 수의 항목을 업데이트해야 할 수 있으며, 고객이 점점 더 많아짐에 따라 물론 이를 확장하려면 수백만 명의 고객이 필요합니다.
따라서 이러한 백엔드 애플리케이션에서도 좋은 예는 고객, 은행 및 고객이 한 계좌에서 다른 계좌로 자금을 이체하는 것입니다. 이는 일반적으로 밤에 백엔드에서 일괄 모드로 처리됩니다. 따라서 계약을 통해 특정 기간 내에 해당 작업을 완료해야 합니다. 따라서 이러한 모든 애플리케이션에 확장성이 없으면 심각한 문제가 발생합니다.
확장성 문제는 무엇입니까?
다행스럽게도 애플리케이션 계층에는 문제가 없습니다. 이러한 애플리케이션이 대부분 있는 경우 애플리케이션 계층에 서버를 더 추가할 수 있으므로 별 문제가 되지 않습니다. 문제는 데이터 저장 공간이다. 그리고 제가 데이터 스토리지라는 단어를 사용할 때는 관계형 데이터베이스, 즉 메인프레임 레거시 데이터를 의미합니다. 대부분의 데이터가 여기에 있으며 애플리케이션과 동일한 방식으로 확장할 수 없습니다. 지금, NoSQL database사용 사례 중 하나는 확장하는 것이지만 문제는 NoSQL databases, 그리고 다시, 우리는 NoSQL database 우리 자신의 전화 NosDB. 오픈 소스 데이터베이스입니다. 따라서, NoSQL database 기술적, 비즈니스적 이유로 인해 메인프레임이나 관계형 데이터베이스에서 데이터를 이동해야 하기 때문에 모든 데이터를 메인프레임으로 이동할 수 없다는 것입니다.
따라서 관계형 데이터베이스는 계속해서 주요 마스터 데이터 소스가 될 것입니다. 새로운 데이터를 많이 넣을 수 있는 사용 사례가 많이 있습니다. NoSQL database그리고 그렇게 하면 확장성 병목 현상이 해결됩니다. 그러나 대부분의 경우 데이터의 하위 집합에 대해서만 이 작업을 수행할 수 있습니다. 데이터의 대부분은 여전히 관계형 데이터베이스나 레거시 메인프레임 데이터 소스에 유지되어야 합니다. 따라서 해결해야 할 문제가 무엇이든 관계형 데이터베이스나 레거시 메인프레임을 사용하여 계속 작업하면서 확장성을 해결해야 합니다. 그리고 분산 캐시가 실제로 문제를 해결하는 곳이 바로 여기입니다. 이를 통해 모든 병목 현상을 제거하면서 관계형 데이터베이스 메인프레임 데이터를 계속 사용할 수 있습니다.
분산 캐시 배포
그림은 다음과 같습니다. 관계형 데이터베이스의 레거시 데이터인 경우 애플리케이션과 데이터베이스 사이에 캐싱 계층을 배치할 수 있습니다.
그렇게 하면 자주 사용할 데이터를 캐싱하기 시작합니다. 그리고 약 80%의 시간은 데이터베이스에 접근할 필요조차 없습니다. 그리고 캐시는 분산 캐시이기 때문에 점점 더 많은 서버를 추가할 수 있으며 애플리케이션 계층과 동일한 방식으로 확장됩니다. 따라서 여기에는 최소 XNUMX개의 캐시 서버가 있고 응용 프로그램 계층과 캐싱 계층 간에 XNUMX:XNUMX 또는 XNUMX:XNUMX 비율을 유지합니다. 이제 해당 비율은 작업 성격에 따라 변경될 수 있습니다. 예를 들어 웹 애플리케이션이 있는 경우 각 사용자 클릭에 대해 수백 번의 캐시 호출이 수행된다면 물론 비율은 변경되지만 대부분의 경우 수백 번의 캐시 호출을 수행하지 않습니다.
일반적인 캐시서버는 그냥 저가형 서버일 뿐입니다. 웹서버 형태의 구성이고, 듀얼 CPU, 쿼드코어 형태의 박스형으로 메모리만 넉넉합니다. 메모리가 많다는 것은 16~32GB가 꽤 표준적이라는 의미이며 일반적으로 32GB 이상은 필요하지 않습니다. 하지만 최대 64GB까지 구매하는 고객이 많지만 각 상자에 더 많은 메모리를 추가하는 대신 상자를 더 추가하는 것이 좋습니다. 그리고 그 이유는 각 상자에 더 많은 메모리가 있을수록 더 강력한 프로세서를 가져야 하기 때문입니다. 그러면 상자가 의도하지 않은 데이터베이스처럼 보이기 시작합니다. 당신은 이것을 가능한 한 낮은 비용으로 유지하고 싶습니다.
이제 분산 캐시는 모든 애플리케이션에 적용하려는 인프라입니다. 따라서 거의 공통 인프라인 데이터베이스가 있는 것처럼 새로운 모범 사례는 메모리 내 분산 캐시를 보유하는 것입니다. 인메모리라고도 불린다. NoSQL 키값 저장소. 그리고 이를 인프라 및 아키텍처 애플리케이션의 일부로 포함하여 항상 이 매장을 방문하게 됩니다. 따라서 데이터베이스로 이동하기 전에 매장을 확인하세요. 해당 인프라가 있으면 모든 애플리케이션이 자동으로 확장 가능해집니다. 따라서 데이터베이스가 병목 현상을 일으키는 것에 대해 걱정할 필요가 없습니다. 그리고 확장성 또는 확장 불가능과 관련된 가장 큰 문제는 바로 이때 비즈니스가 많은 활동을 하고 있다는 것입니다.
당신이 항공사이고 방금 하와이에 대한 특별 프로모션을 진행했다고 가정해 보겠습니다. 잘 모르겠습니다. 수요일에 모두가 귀하의 웹사이트에 로그인하여 티켓 구매를 시작합니다. 그래서 그들은 항공편을 검색하고 티켓을 구매할 것입니다. 그리고 이전보다 트래픽이 XNUMX배나 많아졌고 갑자기 사이트 속도가 느려지고 충돌이 발생할 수 있습니다. 물론 물론이죠. , 데이터베이스가 압도당하고 허용 가능한 한도 이상으로 속도가 느려지더라도 사람들이 떠나기 때문에 비즈니스 비용이 매우 높습니다. 따라서 비즈니스에서 더 많은 활동을 원하고 비즈니스를 창출할 수 있지만 애플리케이션 내에서 처리할 수 없는 상황이 발생하지 않도록 확장성을 계획해야 합니다. 그리고 올바른 인프라가 있다면 그런 문제는 결코 발생하지 않을 것입니다.
분산 캐싱을 사용해야 하는 이유에 대한 사례를 설정하는 중입니다. 어떤 문제가 해결되고 실제로 어떻게 사용하는지 자세히 살펴보겠습니다. 더 많은 메모리를 갖는 것 외에도 일반적으로 앞서 말했듯이 듀얼 CPU, 쿼드 코어 구성, 각각 2기가비트 이상의 네트워크 카드 XNUMX개를 갖습니다. 다음의 경우 NCache 이는 Windows 상자입니다. Redis .NET 또는 Java 애플리케이션이 있는지 여부에 따라 Linux 상자입니다. 여기서는 .NET에 중점을 두지만 Java의 경우 분산 캐시도 있습니다. 이를 인메모리 데이터 그리드라고 부르며, .NET에서는 분산 캐시라고 합니다.
분산 캐시의 일반적인 사용 사례
좋아요! 이제 IT 관점에서 뿐만 아니라 더 중요하게는 개발 관점에서 모범 사례 인프라의 일부로 분산 캐시를 보유해야 하는 이유에 대한 사례를 구축했으므로 애플리케이션을 설계하려고 합니다. 가장 먼저 떠오르는 질문은 이 캐시를 어떻게 사용합니까? 사용 사례는 무엇입니까? 어디서 사용하나요? 즉, 어떤 유형의 애플리케이션을 사용할지 알고 있지만 어떤 유형의 데이터를 캐시할 것인가?
따라서 세 가지 주요 범주가 있습니다. 첫 번째는 모두가 이해하는 애플리케이션 데이터 캐싱입니다.
애플리케이션 데이터 캐싱
따라서 애플리케이션 데이터 캐싱에서는 데이터베이스에 존재하는 데이터를 캐싱하는 것입니다. 이를 캐싱하는 것입니다. 이것이 바로 우리가 방금 이야기한 것입니다. 따라서 그렇게 하면 실제로 두 개의 데이터 복사본이 생성됩니다. 하나는 마스터 데이터베이스에 있고 다른 하나는 임시 복사본인 캐시에 있습니다. 그런 일이 일어날 때, 가장 큰 관심사는 무엇입니까? 사본이 두 개 있으면 무엇이 잘못될 수 있나요? 동기화되지 않을 수 있습니다. 사실, 사람들의 마음 속에 가장 큰 두려움은 캐싱을 무엇에 사용하는지 물을 때 대부분의 사람들이 읽기 전용 데이터에 좋다고 대답하고 트랜잭션 데이터, 그것이 잘못되면 어떻게 됩니까? 고객이 동일한 계좌에서 해당 금액을 두 번 인출하면 어떻게 되나요?
음, 트랜잭션 데이터를 캐시할 수 없는 경우 참조 데이터가 데이터의 80% 또는 70%에 불과하기 때문에 분산 캐시의 가치가 상당히 감소합니다. 데이터의 80% 또는 30~XNUMX%는 고객, 계정, 활동, 거래 데이터, XNUMX초, XNUMX분마다 변경되는 데이터, 캐시에 보관할 수 있는 데이터입니다. 아주아주 짧은 시간. 따라서 트랜잭션 데이터에 캐시를 사용할 수 없다면 실제로 제한을 받은 것입니다. 따라서 좋은 분산 캐시는 캐시와 데이터베이스가 항상 동기화되도록 보장해야 합니다. 따라서 캐시가 항상 데이터베이스와 동기화되어 있다는 마음의 평화를 얻으면 거의 모든 것을 캐시할 수 있으며 그렇게 하면 실제로 많은 게임을 볼 수 있습니다.
그리고 그것에 대해 더 자세히 설명하겠습니다.
ASP.NET 특정 캐싱
두 번째 사용 사례는 ASP.NET 애플리케이션이 있고 캐시할 수 있는 특정 ASP.NET 관련 항목이 있는 경우입니다. 그리고 이 범주의 좋은 점은 Microsoft가 캐시를 연결하는 프레임워크를 갖고 있기 때문에 사용자가 프로그래밍할 필요가 없다는 것입니다. 첫 번째는 세션 상태입니다. 모든 ASP.NET 응용 프로그램에는 거의 세션 상태가 있어야 합니다. 어떤 사람들은 그것을 사용하지 않도록 특별히 프로그램되어 있는데 이는 좋은 생각이 아닙니다. 세션을 사용하면 인생이 훨씬 쉬워집니다.
세션은 캐싱을 위한 매우 좋은 후보입니다. 왜냐하면 세션을 데이터베이스에 저장하면 데이터베이스가 세션인 blob 저장용으로 설계되지 않은 것과 동일한 문제에 직면하게 되기 때문입니다. 따라서 성능이 정말 느리고 더 중요한 것은 확장성이 사라집니다. 애플리케이션 데이터 캐싱을 수행하려는 것과 같은 이유로 세션도 데이터베이스에 넣지 않으려고 합니다. 분산 캐시에 저장하려고 합니다.
두 번째는 보기 상태입니다. MVC 프레임워크를 사용하지 않는 경우, 아직 이전 ASP를 사용하고 있는 경우.NET framework 그런 다음 상태를 봅니다. 뷰 상태가 무엇인지 모르는 분들을 위해 설명하자면, 뷰 상태는 암호화된 문자열로, 작을 수도 있고 수백 바이트일 수도 있으며 생성되어 브라우저로 전송되어 다시 돌아올 수도 있습니다. 포스트백을 할 때. 그래서 꽤 돈이 많이 드는 여행이에요. 물론 더 많은 데이터가 이동하기 때문에 성능이 저하됩니다. 또한 애플리케이션을 호스팅할 때 이 위의 파이프가 무료가 아니기 때문에 대역폭 비용도 증가합니다. 따라서 고객이 웹 애플리케이션에 액세스하면 여기에서 대역폭에 대한 비용을 지불하게 됩니다. 따라서 뷰 상태에 수백만 건의 요청이나 사용자 또는 고객이 수행할 트랜잭션을 곱하면 발생하고 싶지 않은 추가 비용이 많이 발생합니다. 따라서 이는 캐싱에 매우 적합한 후보입니다. 따라서 서버에 캐시하고 다음번에 잘못된 게시가 발생할 때 키가 다시 나타나고 페이지가 실행되기 전에 보기 상태를 캐시에서 가져오는 작은 키를 보냅니다.
세 번째는 ASP의 또 다른 부분인 출력 캐시입니다..NET framework 페이지 출력이 변경되지 않으면 다음에 실행하는 이유는 무엇입니까? 페이지를 실행할 때마다 CPU, 메모리 및 데이터베이스를 포함한 기타 모든 리소스를 소비하게 되기 때문입니다. 따라서 전체 페이지일 수도 있고 페이지의 일부일 수도 있는 마지막 실행의 출력을 반환하는 것이 훨씬 더 좋습니다. 따라서 이 세 가지 모두에 대해 프로그래밍 없이 분산 캐시를 연결하기만 하면 됩니다. 이제 그것을 보여드리겠습니다. 그러나 이 문제의 성격은 응용 프로그램과 매우 다릅니다.
애플리케이션 데이터에는 두 개의 데이터 복사본이 있었습니다. 그렇죠? 그래서 문제는 동기화였습니다. 여기에는 복사본이 하나만 있으며 해당 복사본은 메모리 내 저장소에 보관됩니다. 따라서 메모리 내 저장소에 이와 같은 것을 보관할 때 가장 큰 관심사는 무엇이며 그것이 유일한 복사본입니다. 그것도! 또는 서버가 다운되면 해당 캐시가 손실됩니다. 따라서 이 중 하나가 캐시에 저장됩니다. 제가 방금 겪은 동일한 항공사를 상상해 보십시오. 완벽한 항공사 조합을 찾는 데 XNUMX분을 소비했는데 제출 버튼을 누르려고 하는데 세션이 손실되었습니다. 웹 서버가 방금 다운되었기 때문에 좋은 경험이 아니었습니다.
그렇다면 인메모리가 있고 그런 우려가 있을 때 어떻게 문제를 해결할 수 있을까요? 중복성이 있습니다. 데이터 사본이 두 개 이상 있습니다. 따라서 좋은 분산 캐시를 사용하면 데이터 복제가 가능해야 합니다. 지능적이고 고성능 방식으로 데이터를 복제하지 않으면 캐시의 유용성이 다시 크게 떨어집니다.
이벤트를 통한 런타임 데이터 공유
세 번째 사용 사례는 대부분의 사람들이 알지 못하거나 더 대중화되기 시작하면서 확장성이 뛰어난 인메모리 인프라를 사용할 수 있다는 것입니다. 이벤트를 통한 런타임 데이터 공유에 사용할 수 있습니다. 메시징과 비슷하지만 훨씬 단순화된 버전이며 여러 애플리케이션이 캐시를 사용하도록 할 수 있는 환경의 단일 데이터 센터 유형에 있습니다. Pub/Sub 유형의 데이터 공유입니다. 따라서 하나의 애플리케이션이 캐시에 무언가를 넣고 이벤트를 발생시키면 해당 데이터에 관심이 있는 소비자가 해당 이벤트를 수신하고 해당 데이터를 소비할 수 있습니다.
따라서 데이터베이스에 넣거나 자체 목적이 있는 상황의 MSM 대기열 유형에 넣는 대신. 캐시는 MSM 대기열을 대체할 수는 없지만 많은 상황에서 이벤트 기반 데이터 공유를 수행하는 것이 훨씬 더 간단하고 특히 훨씬 빠르고 확장성이 뛰어난 인프라입니다. 따라서 런타임에 서로 데이터를 공유해야 하는 여러 애플리케이션이 있는 경우 이 기능을 매우 중요한 기능으로 고려해야 합니다.
ASP.NET 특정 캐싱
ASP.NET 캐싱과 이를 수행하는 방법을 빠르게 보여 드리겠습니다. 매우 간단하고 실제로 사용하겠습니다. 그래서 샘플 코드가 있습니다. 예를 들어, 제가 한다면... 저는 ASP.NET 응용 프로그램을 가지고 있습니다. 다음과 같은 경우에는 web.config로 이동하기만 하면 됩니다. NCache 다시 말하지만 모든 캐시에 대해 거의 동일할 것입니다. 가장 먼저 해야 할 일은 어셈블리를 추가하는 것입니다. 따라서 이 어셈블리는 세션 상태 공급자입니다. 그래서 ASP는.NET framework 분산 캐시가 구현해야 하는 세션 상태 공급자 인터페이스가 있습니다. NCache 이를 구현했으며 어셈블리가 애플리케이션에 로드됩니다.
따라서 이 작업을 완료하고 나면 다음으로 해야 할 일은 세션 상태 태그로 이동하는 것입니다. 실제로 모드가 사용자 정의인지 확인하고 시간 초과가 원하는 대로 설정되었는지 확인하세요. 다음의 경우 NCache 그런 다음 이 줄을 입력하면 됩니다. 다른 캐시에도 비슷한 유형의 정보가 있습니다. 그래서, 당신은 단지 .. 경우에 NCache 당신이 해야 할 일은 캐시의 이름을 확인하는 것뿐입니다. 그러면 실제로 그것이 무엇을 의미하는지 보여드리겠습니다. 그러나 애플리케이션에서 이 정도의 변경만으로 기본적으로 세션 저장을 시작할 수 있습니다. 따라서 애플리케이션 계층의 모든 web.config에서 해당 변경을 수행하고 캐시가 존재하는지 확인합니다. 그런 다음 해당 작업을 완료하고 나면 실제로 세션을 캐시에 넣기 시작할 수 있습니다.
실습 데모
캐시 클러스터를 빠르게 보여드리겠습니다. 예를 들어 저는 다음과 같은... 어, 캐시 서버 VM과 마찬가지로 데모1과 데모2가 있는 Azure VM이 있고 데모 클라이언트는 애플리케이션 서버와 같습니다. 그래서 그것은 고객입니다. 캐시 클라이언트는 응용 프로그램 서버 상자입니다. 그래서 나는…
캐시 클러스터 생성
그리고 저는 로그인했습니다. 예를 들어 데모 클라이언트에 로그인했고 다음과 같은 경우에 이것을 사용할 것입니다. NCache 다시 한 번 이 도구를 사용하겠습니다. NCache 관리자. 그래픽 도구입니다. 한 곳에서 캐시를 구성해 보겠습니다. 여기로 와서 새로운 클러스터 캐시를 생성하라고 말씀드리겠습니다. 모든 캐시의 이름은 다음과 같습니다. NCache. 그래서 내 캐시의 이름을 데모 캐시로 지정하겠습니다. 이러한 속성에 대해 자세히 설명하지는 않겠습니다.복제 전략을 분할된 복제본으로 선택하겠습니다. 그리고 비동기식 복제를 선택하겠습니다. 처음으로 캐시 서버를 수행합니다. 여기서 두 번째 캐시 서버를 수행하겠습니다. 그래서 XNUMX노드 캐시 클러스터를 구축하겠습니다. 그냥 다 고르겠습니다. 즉, 캐시 클러스터가 형성되는 TCP 포트이므로 포트 충돌이 있는 경우 이를 변경할 수 있습니다. 캐시 서버가 캐시에 사용할 메모리 양을 지정하겠습니다. 나는 그것을 하나의 공연으로 갖고 있지만, 당신의 공연은 훨씬 더 많을 것입니다.
예를 들어 이것이 무엇을 의미하는지 빠르게 보여드리겠습니다. 이 부분만 짚고 넘어가겠습니다.
따라서 이것을 캐시 서버라고 생각하면 여기에 또 다른 캐시 서버가 있습니다. 따라서 여기에 파티션 1이 존재합니다. 파티션 1은 기본적으로 버킷 모음입니다. 파티션 2에는 자체 상자가 있습니다. 그래서 다음과 같은 경우가 있습니다. NCache 가지고 있는 파티션 수 사이에 분산되는 버킷은 약 천 개입니다. 모든 서버에는 하나의 파티션이 있으며 모든 서버의 파티션은 다른 서버에 복제됩니다. 따라서 1개의 서버가 있는 경우 여기에 파티션 2이 백업된 것을 볼 수 있습니다. 파티션 3가 여기에 백업됩니다. 파티션 XNUMX이 여기에 백업됩니다. 다음과 같은 경우에는 복제본이 활성화되지 않습니다. NCache. 기본 파티션이 다운된 경우에만 활성화됩니다.
그래서 제가 지정하는 것은 파티션의 크기입니다. 따라서 파티션 복제본의 경우 여기서 1GB를 지정하면 실제로는 파티션에 1GB, 복제본에 1GB가 사용됩니다. 그러니까 총 2공연이군요. 따라서 16GB의 메모리가 있는 경우 운영 체제와 기타 프로세스를 위해 16~13GB 정도를 남겨두고 나머지는 사용할 수 있도록 하려는 것입니다. 따라서 32기가의 경우 29기가를 쉽게 사용할 수 있습니다. 그러니 반반씩 하세요. 따라서 파티션 크기는 14GB이고, 물론 XNUMXGB를 가질 수 있으며, XNUMXGB를 빼면 XNUMXGB, XNUMXGB, XNUMXGB 파티션 크기가 됩니다. 그리고 더 많은 스토리지를 원할 경우 서버를 추가하기 위해 메모리를 추가하는 대신 관리가 더 쉽기 때문입니다. 훨씬 더 확장 성을 유지합니다. 그래서 저는 여기서 다음으로 넘어가겠습니다.
다음은 퇴거 정책입니다. 자세한 내용은 다루지 않겠습니다. 이제 클라이언트 노드를 추가하겠습니다. 이 작업을 완료한 후에는 캐시를 시작하겠습니다. 저는 캐시를 시작할 예정인데 이 부분을 보여드리고 싶었습니다. 그것이 나머지 강연에서 이해가 될 것이기 때문입니다. 따라서 이 두 캐시 노드가 시작됩니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
그래서 저는 여러 모니터링 도구를 열고 실제로 스트레스 테스트 도구라고 불리는 이 도구를 실행해 보겠습니다.
명령줄입니다. 실제로 캐시에서 활동을 시작하는 콘솔입니다. 이제 이는 애플리케이션을 시뮬레이션하는 것과 같습니다. 따라서 이를 살펴보면 애플리케이션이 세션을 캐시에 저장하는 경우 모든 세션은 하나의 개체입니다. 그래서 당신은 추가하고 있습니다. 따라서 캐시 수는 177이고 이 상자에서는 172와 35입니다. 따라서 거의 균등해질 것이며 다른 곳에 백업하는 것이 좋습니다…
이것은 여기에 백업되었습니다. 이것은 여기에 백업되었습니다. 보시다시피 복제가 자동으로 발생합니다. 귀하의 신청서는 걱정할 필요가 없습니다. 여러분이 한 일은 이 클러스터를 생성하고 애플리케이션 계층에서 Web.config를 수정하기만 하면 나머지 모든 작업이 자동으로 수행됩니다. 물론 이 내용을 모니터링할 수 있지만 캐시 이름이 지정됩니다. 그래서 우리의 경우 캐시 이름을 데모 캐시로 지정했습니다. 이름을 지정할 수 있으며 실제로 여러 캐시를 가질 수 있습니다. 고객에게서 본 가장 일반적인 구성은 세 개의 캐시가 있다는 것입니다. 하나의 캐시를 객체 캐시라고 부르겠습니다. 따라서 이것이 주요 트랜잭션 캐시입니다. 하나의 캐시를 세션 캐시라고 부릅니다. 따라서 모든 세션을 해당 캐시에 저장합니다. 세 번째 캐시는 참조 캐시라고 합니다. 따라서 그들은 참조 캐시에 더 많은 참조 데이터를 넣을 것입니다.
그리고 트랜잭션 데이터와 참조 데이터에 대해 별도의 캐시를 생성하는 이유는 참조 데이터에 대해 캐시하려는 클라이언트 캐시라는 기능을 사용하기 때문입니다.
더 나은 성능을 위한 클라이언트 캐시
사실 횡설수설하고 있으니 헷갈리더라도 양해 부탁드립니다. 참조 데이터가 있다면 실제로 한 단계 더 뒤로 물러서겠습니다. 분산 캐시를 사용하기 전에는 ASP.NET 캐시 개체가 있었습니다. ASP.NET 캐시 개체는 로컬 InProc 캐시였습니다. 신청 절차 중에 초고속으로 진행됐죠? 자신의 힙에 물건을 보관하고 있다면 그 성능에 필적할 수 있는 것은 없습니다. 분산 캐시에 들어가자마자 다릅니다. 자동 프로세스 캐시입니다. 사람들이 깨닫지 못하는 것은 당신의 성과가 실제로 떨어진다는 것입니다.
처음에는 성능이 향상되어야 하는데 ASP.NET 캐시에서 성능이 떨어졌는데 개체를 직렬화해야 하기 때문에 지금은 훨씬 느려진다고 당황스러워하는 고객이 많이 있습니다. 큰 개체가 있는 경우 직렬화는 상당히 상당한 비용이며 특정 캐시와 관계없이 발생해야 하는 비용입니다. 그리고 프로세스 캐시를 벗어나면 성능이 로컬 InProc 캐시보다 훨씬 느려집니다. 그러나 여전히 데이터베이스보다 빠릅니다. 데이터베이스보다 거의 10배 빠르지만 InProc 캐시보다 거의 10배 느리다고 할 수 있습니다.
그래서 사람들은 InProc 캐시의 이점을 얻고 싶어합니다. 자주 변경되지 않는 데이터의 경우 클라이언트 캐시라는 기능이 있습니다. 어떤 사람들은 특히 Java 측에서 이를 Near Cache라고 부릅니다.
이 기능은 본질적으로 로컬 캐시입니다. 이는 InProc ASP.NET 캐시와 같습니다. 이는 애플리케이션 프로세스 내에 위치하거나 InProc만큼 빠르지는 않지만 캐싱 계층으로 이동하는 것보다 여전히 빠른 로컬 OutProc 캐시일 수 있습니다. 그러나 차이점은 이 캐시가 캐싱 계층에 대해 알고 있다는 것입니다. 이 클라이언트 캐시는 캐시 위에 있는 캐시이며 동기화됩니다. 따라서 우리가 이야기한 가장 큰 문제인 캐시를 데이터베이스와 동기화하는 방법에 대해 걱정할 필요가 없습니다. 이제 세 개의 데이터 복사본이 생겼습니다. 하나는 데이터베이스에, 하나는 캐싱 계층에, 다른 하나는 클라이언트 캐시에 있습니다. 물론 클라이언트 캐시는 캐싱 계층의 하위 집합입니다. 캐싱 계층은 데이터베이스의 하위 집합입니다. 그러나 그것이 무엇이든 동기화되어야 합니다. 따라서 클라이언트 캐시를 가짐으로써 다시 InProc이 되며 직렬화된 형식 대신 개체 형식으로 항목을 유지합니다. 그것은 당신의 힙에 보관됩니다. 따라서 로컬 InProc ASP.NET 캐시 개체와 동일한 이점을 얻을 수 있지만 이 클라이언트 캐시는 작은 하위 집합이기 때문에 확장성의 다른 모든 이점도 함께 얻을 수 있습니다. 얼마나 큰지 지정할 수 있습니다. 결코 그 문턱을 넘지 못할 것입니다.
따라서 각 클라이언트 캐시에 하나의 기가가 있을 수 있고 캐싱 계층에 32기가가 있을 수 있으며 데이터베이스에는 아마도 그보다 훨씬 더 많은 것이 있을 수 있습니다. 아무튼 무빙윈도우니까 공연 한 번만 해도 그렇겠죠? 그러니 무엇을 하든 계속하세요. 일부 데이터는 오랫동안 유지되고 일부 데이터는 몇 분 동안 유지되지만 그 시간 내에 수백 건의 호출을 수행하므로 캐싱 계층으로 이동할 필요가 없습니다. 데이터베이스로 이동합니다. 따라서 클라이언트 캐시를 켜면 정말 강력한 기능이 됩니다. 더 많은 참조 데이터를 얻으려면 그렇게 합니다. 따라서 다음의 경우에는 NCache, 구성 변경을 통해 클라이언트 캐시를 지정할 수 있습니다. 추가 프로그래밍은 없지만 특정 캐시에 매핑됩니다. 이것이 바로 우리 고객이 일반적으로 XNUMX개의 캐시를 보유하는 이유입니다. 객체 캐시, 세션 캐시, 참조 캐시. 참조 캐시의 경우 클라이언트 캐시를 사용하지만 다른 두 캐시의 경우에는 사용하지 않습니다.
클라이언트 캐시 구성이 용이함
이제 세션 캐시로 클라이언트 캐시를 수행하지 않는 이유는 무엇입니까? 실제로 성능이 저하되기 때문입니다. 그 이유는 더 많은 읽기 및 쓰기를 수행하는 경우에만 더 좋기 때문입니다. 왜냐하면 쓰기의 경우에는 어떻게 되나요? 여기에 쓰고, 여기에 쓰고, 그런 다음 데이터베이스에 씁니다. 따라서 세 곳에서 쓰기를 수행하고 있습니다. 따라서 더 많은 쓰기 작업을 수행해야 해도 아무런 가치가 추가되지 않습니다. 복사본을 업데이트한 다음 이것만 업데이트하면 다른 모든 클라이언트 캐시에 가서 스스로 업데이트하도록 알립니다. 지연된 업데이트입니다. 단지 XNUMX~XNUMX밀리초 정도 지연된 것은 아니지만 클라이언트 캐시의 경우 여전히 지연된 업데이트입니다. 클라이언트 캐시 간에는 복제가 없습니다. 클라이언트 캐시는 캐싱 계층 및 캐싱 계층과만 동기화한 다음 업데이트를 다른 클라이언트 캐시에 전파합니다. 다른 캐시에 해당 데이터가 있는 경우에만 가능합니다. 클라이언트 캐시의 경우 모든 클라이언트 캐시에는 사용 패턴에 따라 다른 데이터가 있기 때문입니다.
클라이언트 캐시 사용 위치
다시 한 걸음 물러서서 참조 데이터의 경우 모든 클라이언트 캐시에는 고유한 데이터 세트가 있습니다. 따라서 1부터 1000까지, 500부터 1500까지라고 가정해 보겠습니다. 따라서 각각 사이에 약간의 중복이 있지만 동일한 사본은 아닙니다. 공통점은 모두 이 캐시의 하위 집합이라는 것입니다. 따라서 이 캐시에서 항목 번호(예: 700)를 업데이트하면 캐시에서 업데이트가 진행되고 캐시는 해당 항목이 있는 다른 클라이언트 캐시가 무엇인지 알게 되며 즉시 다른 캐시에서 업데이트됩니다. 그러나 모두가 그것을 가지고 있는 경우에만 가능합니다. 따라서 클라이언트 캐시의 경우 동일한 복사본이 아니기 때문에 실제로 복제되지 않습니다. 세션의 경우 제가 실제로 설명하려고 했던 것은 세션의 경우 클라이언트 캐시와 클러스터 캐시를 업데이트해야 한다는 것입니다. 세션에서는 읽기와 쓰기를 각각 한 번씩 수행하기 때문에 부가 가치가 없는 두 곳입니다. 따라서 웹 요청 시 쓰기를 수행하는 페이지 끝에서 읽기를 수행합니다.
따라서 이제 쓰기는 두 곳에서 수행되어야 하며 읽기는 클라이언트 캐시에서 수행됩니다. 따라서 클라이언트 캐시를 세션이나 기타 쓰기 집약적인 작업과 함께 사용하면 성능이 실제로 떨어지지만 읽기 집약적인 작업에 사용하면 성능이 엄청나게 향상됩니다. 그게 말이 되나요?
따라서 분산 캐시의 가장 큰 가치는 가장 빠르며 가장 큰 것은 세션 상태입니다. 거의 모든 응용 프로그램에 이 기능이 있습니다. 방금 XNUMX노드 캐시 클러스터를 생성했는데, 캐시 클러스터가 실행되는 경우 시간이 얼마나 걸리는지 보셨을 겁니다. 아마도 XNUMX분 정도 걸릴 겁니다. NCache. 따라서 캐시 클러스터를 생성하는 것은 정말 쉽습니다. 물론 테스트 등을 수행하고 싶을 수도 있습니다. 하지만, 정말 쉽습니다. 엔지니어링 노력이 없습니다. 엔지니어링 노력이 없으면 일정을 처리하기가 훨씬 쉽습니다. 통과하려면 온전성 테스트만 수행하면 됩니다. 분산 캐시 사용을 시작하려면 첫 번째 단계로 처음에 세션 상태에 대해 사용한 다음 잠시 후에 설명할 객체 캐싱으로 뛰어들기를 강력히 권장합니다.
애플리케이션 데이터 캐싱
지금까지 세션 캐싱에 대해 이야기했습니다. 애플리케이션 데이터 캐싱에 대해 빠르게 살펴보겠습니다. 다음은 전형적인 NCache API는 ASP.NET 캐시와 매우 유사해 보입니다. 연결이 있다는 것을 알 수 있습니다.
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");그래서 이름을 기준으로 캐시를 연결하고 그 이름으로 캐시를 생성하면 됩니다. 그것이 바로 내가 여러분에게 그것이 의미하는 바를 이해할 수 있도록 그 시연을 준 이유입니다. 그리고 이 캐시 핸들은 데이터베이스 핸들을 보존하기 위해 보존하는 것입니다. 그런 다음 해당 캐시 핸들을 사용하여 Cache.Get을 수행합니다. 모든 Get, 모든 작업에는 키가 있습니다. 다음의 경우 키는 문자열입니다. NCache 그런 다음 수행 중인 작업에 따라 키 형식을 지정합니다. 따라서 개별 개체의 경우 클래스 이름(속성 이름과 값)만 지정하는 것이 좋습니다. 그러면 당신은 그것을 얻을 수 있습니다. 따라서 Get 및 Get.Contains, Add, AddAsync가 있습니다. 비동기는 기다리지 않는다는 뜻입니다.
글쎄요, 그 아래에서는 클라이언트 측에서 역직렬화가 일어나고 있습니다. 클라이언트에서는 Cache.Add를 수행할 것입니다. 예를 들어 개체를 제공한다고 가정해 보겠습니다. 직원 개체이고 표준 .NET 직렬화 또는 사용자 지정을 기반으로 직렬화합니다. NCache 직렬화. 그런 다음 이를 바이트 배열로 생성하고 바이트 배열을 캐시로 보냅니다. NCache 특정 속성을 색인화해야 할 수도 있기 때문에 그 이상을 수행합니다. 그 값을 추출합니다. 응, 그럴 거야. 그럴 것이다. 즉시입니다. 응! 캐시하는 모든 개체는 직렬화를 거쳐야 합니다.
따라서 애플리케이션을 켜자마자 예외가 발생합니다. ASP.NET 캐시 개체를 사용하는 경우 직렬화할 필요가 없습니다. 따라서 거의 모든 것을 캐시할 수 있으며 자신의 객체가 직렬화하기가 더 쉬울 수 있지만 일부 타사를 사용하는 경우가 많이 발생합니다. 이전에는 데이터 테이블 개체가 직렬화되지 않았지만 지금은 직렬화되어 있다고 가정해 보겠습니다. 따라서 직렬화할 수 없는 타사 개체를 사용하는 경우 제어할 수 없습니다. 따라서 분산 캐시를 사용하려는 경우 이를 잡을 수 없습니다. 다음의 경우 NCache, 우리는 해당 객체를 식별할 수 있는 자체 사용자 정의 직렬화를 가지고 있습니다. NCache 그런 다음 런타임에 직렬화 코드를 생성하고 메모리에서 컴파일합니다. 따라서 직렬화할 수 없는 객체도 사용할 수 있습니다. 그러나 이 직렬화는 즉시 발생합니다. 따라서 적절한 직렬화를 사용하지 않으면 애플리케이션이 작동하지 않습니다.
Async는 기본적으로 캐시가 업데이트될 때까지 기다리지 않는다고 말합니다. 그래서 계속할 수 있습니다. 나는 캐시가 이것을 추가할 것이라고 믿습니다. 따라서 데이터 무결성 문제로 인해 업데이트가 실패할 수 있는 데이터베이스의 잠금을 해제하지 않습니다. 캐시에는 데이터 무결성 문제가 없습니다. 충돌이 발생한 경우에만 실패합니다. 메모리가 부족하거나 다른 일이 발생했을 때. 따라서 추가하는 항목이 무엇이든 캐시에 추가될 가능성이 높으므로 안심할 수 있습니다. 따라서 Async는 여전히 추가 기능을 제공합니다. 따라서 API는 보시다시피 매우 간단해 보입니다.
캐시를 최신 상태로 유지
그렇다면 애플리케이션 데이터 캐싱을 수행할 때 캐시를 최신 상태로 유지하려면 어떻게 해야 할까요? 이것은 정말 정말 중요합니다. 캐시할 수 있는 방법에는 여러 가지가 있습니다.
시간 기반 만료 사용
만료, 거의 모든 캐시는 만료를 지원합니다. 모든 항목에 대해 이 지정을 받는 절대 만료가 있습니다. 캐시에 머무르는 것이 편안하다고 느끼는 기간은 다음과 같습니다. 이는 15초에서 몇 시간, 며칠, 몇 주가 될 수 있습니다. 이는 애플리케이션 데이터 캐싱을 위한 것입니다. 캐시를 데이터베이스와 동기화하지 않는 슬라이딩 만료라는 또 다른 만료가 있습니다. 청소용입니다. 그럼 ASP.NET, 우리가 얘기한 모든 임시 데이터, 음, 해당 데이터가 끝나면 어떻게 될까요? 청소하는 것에 대해 걱정할 필요가 없습니다. 따라서 슬라이딩 만료를 지정하고 이렇게 오랫동안 이 데이터를 아무도 사용하지 않는다고 말할 수 있습니다. 예를 들어 세션이 20분인 경우 아무도 해당 20분 동안 세션을 사용하지 않으면 캐시에서 해당 데이터를 제거하십시오. 그래서 그것은 더 많은 정리입니다.
만료 시 위험은 무엇입니까? 만료는 실제로 추측하는 것입니다. XNUMX분이면 괜찮다고 생각하지만, 특히 다른 애플리케이션이나 데이터베이스를 업데이트하는 다른 프로세스가 있는 경우 그 시간에 누구도 데이터베이스의 해당 데이터를 업데이트하지 않을 것이라는 보장은 없습니다. 따라서 만료는 제한된 사용 사례에만 적합합니다.
데이터베이스 종속성 사용
또 다른 매우 중요한 기능은 데이터베이스에 예기치 않거나 예측할 수 없는 업데이트가 있을 수 있다는 것입니다. 그렇다면 캐시에는 데이터베이스와 자체적으로 동기화할 수 있는 기능이 있어야 합니다. 따라서 캐시는 데이터베이스에 대해 알아야 합니다. 이는 데이터베이스의 클라이언트가 되어 데이터베이스의 변경 사항을 모니터링해야 합니다. ADO.NET에는 SQL 종속성이라는 기능이 있습니다. 그걸 본 사람 있나요?
따라서 SQL 종속성은 무엇입니까? NCache SQL 서버 또는 Oracle 데이터베이스의 클라이언트가 되는 데 사용됩니다. 따라서 SQL Server의 경우 SQL 종속성인 SQL Server ADO.NET 기능을 사용할 수 있습니다. NCache 데이터베이스에서 이벤트를 가져오는 데 사용됩니다. 캐시, NCache 데이터베이스의 클라이언트가 됩니다. 이벤트를 수신한 다음 이를 기반으로 자체 작업을 수행합니다. 어떤 경우에는 이벤트가 없습니다. 따라서 db2 또는 MySQL이 있는 경우 이벤트가 없다고 가정해 보겠습니다. 따라서 캐시는 폴링을 수행할 수 있어야 합니다. NCache 또한 폴링 기반을 지원합니다. 따라서 동일한 작업을 수행합니다. 이 항목을 캐시에 캐시하고 이것이 이 테이블의 이 행에 매핑된다고 말한 다음 NCache 폴링을 수행한 다음 해당 데이터가 변경되면 캐시에서 해당 데이터를 다시 제거하거나 새 복사본을 다시 로드합니다. 하지만 이 기능은 많은 편안함을 제공합니다.
다시 말하지만, 제가 얘기했던 것과 동일한 것은 캐시가 항상 데이터베이스와 동기화되도록 하려는 것입니다. 만료는 사용 사례의 작은 하위 집합에만 충분합니다.
따라서 자동 새로고침을 수행하지 않으면 캐시 누락이 발생합니다. 따라서 SQL 종속성이 실행되면 제거됩니다. NCache 캐시에서 항목을 제거합니다. 따라서 애플리케이션이 원할 경우 캐시 미스가 발생하고 데이터베이스에서 새 복사본을 가져와야 합니다. 많은 전자 상거래 애플리케이션에서 데이터를 너무 자주 읽어서 데이터베이스의 로드를 증가시키는 것을 원하지 않기 때문에 발생하는 캐시 누락을 원하지 않는 경우 실제로 SQL 종속성을 사용합니다. 연속 읽기라는 이 기능을 사용합니다.
사실, 몇 가지 코드를 보여줘야 합니다. 그렇지 않으면 매우 지루해지기 시작합니다. 그럼 빠르게 보여드리겠습니다. 그래서 저는 매우 간단한 콘솔 애플리케이션을 가지고 있습니다. 다음의 경우 NCache, 여기에 어셈블리를 추가하기만 하면 됩니다. 그래서 거기에 NCache.런타임 및 NCache.편물. 그런 다음 이 두 네임스페이스를 지정한 다음 캐시에 연결하고 캐시 핸들을 얻은 다음 개체를 만들고 Cache.Add를 수행합니다. 그리고 키를 지정합니다. 이것은 좋은 열쇠가 아닙니다. 변경하려고 했는데 키에 실제 값이 있어야 합니다. 따라서 Cache.Add를 수행하고 개체를 지정합니다.
이 경우에도 10분의 절대 만료를 사용하고 있습니다. 따라서 절대 만료를 지정하면 그게 전부입니다. 이것이 캐시에 추가하기 위한 전부입니다. 다음에 필요할 때 Cache.Get을 수행하고 동일한 키를 지정하면 개체를 다시 가져올 수 있습니다. 절대 만료에 대해서는 매우 매우 간단합니다. 슬라이딩 만료에 대해서도 동일한 작업을 수행할 수 있습니다. 그러나 절대값을 지정하는 대신 20분 또는 XNUMX분과 같은 간격을 지정해야 합니다. SQL 종속성은 제가 여러분에게 보여드리고 싶었던 것입니다. 어떻게 생겼는지. 거기! 따라서 동일한 유형의 응용 프로그램입니다. 여기에 이 두 개를 추가하고 네임스페이스를 지정한 다음 SQL 종속성을 지정할 때 해당 항목을 캐시에 추가하면 됩니다.
그 정의를 살펴보겠습니다. 그래서 저는 이것을 여기 캐시에 추가하겠습니다. 그래서 지난번에 보여드린 열쇠를 가지고 있어요. 이제 개체를 추가하는 대신 캐시 항목을 추가하겠습니다. 그건 NCache 구조. 따라서 실제 개체를 저장하고 SQL 종속성도 저장합니다. 그래서, NCache 캐시 종속성 개체가 있습니다. 그래서 새로운 SQL 캐시 종속성을 수행합니다. 그건 NCache 내부적으로 SQL 서버 SQL 종속성에 매핑되는 클래스입니다. 따라서 연결 문자열을 전달하고 연결 문자열은 SQL Server 연결 문자열이며 SQL 문을 전달합니다. 그래서 제 경우에는 제품 ID가 내 값이 무엇이든 선택하도록 지정했습니다. 그래서 저는 이를 제품 테이블의 한 행에 매핑합니다. 그리고 이것을 그렇게 많이 지정함으로써 나는 지금 방금 말했습니다. NCache SQL Server의 클라이언트가 됩니다. 그리고 데이터베이스에서 이 행이 변경되면 이 항목을 제거합니다.
따라서 SQL 문이 무엇인지에 따라 다릅니다. 따라서 시퀀스 메서드에 행이 하나만 포함되어 있으면 행 하나만 수행하도록 매핑되고 이것이 됩니다. 일반적으로 조인을 수행할 수 없으며 이는 ADO.NET의 SQL 종속성 기능의 제한 사항이지만 단일 테이블의 경우 쉽게 수행할 수 있습니다. 그래서, 그것이 당신이 할 방법입니다…
따라서 SQL 서버에는 SQL 브로커라는 것이 있습니다. 따라서 실제로 이러한 데이터 세트를 모니터링하기 위해 SQL Server 측에 데이터 세트 또는 데이터 구조를 생성합니다. 따라서 사용자가 생성하는 모든 SQL 종속성은 SQL 서버가 데이터 구조를 생성하여 데이터 세트를 모니터링합니다. 그리고 이를 기반으로 SQL 알림을 보냅니다.
따라서 보안 문제이므로 DB가 SQL 서버 구성에 참여해야 하기 때문에 SQL 서버 측에서 이를 구성해야 하지만 매우 간단합니다. 내 말은 서버에 프로그래밍이나 필요한 것이 없고 단지 구성만 필요하다는 뜻입니다. 모든 일은 클라이언트 측에서 처리합니다.
연속 읽기 및 연속 기입
좋아요! 따라서 우리는 SQL 종속성을 완료했습니다. 캐시에서 이 항목을 제거하고 싶지 않은 경우 읽기를 통해 다시 로드할 수 있다는 점을 보여드리고 싶었습니다. 따라서 읽기는 또 다른 매우 강력한 기능입니다.
읽기는 서버측 코드입니다. 실제로 읽기는 캐시 클러스터에서 실행되는 코드입니다. 따라서 실제로 코드를 등록하면 캐시 클러스터에서 실행됩니다. 비라고 하는데 NCache. 그리고, 낭독의 가치… 먼저 낭독이 어떤 모습인지 보여주고, 그 가치가 무엇인지 보여드리겠습니다. 제 말은 왜 낭독을 하고 싶은지 말씀드리겠습니다. 일반적인 읽기 방법은 다음과 같습니다. IReadThrough 인터페이스입니다. 데이터 소스에 연결할 수 있도록 InIt을 수행합니다. 물론 폐기를 수행하면 소스에서 로드가 발생합니다. 키를 전달하고 캐시 항목을 다시 기대합니다. 따라서 캐시 항목에는 개체와 만료 날짜를 지정할 수 있는 여러 가지 항목과 그 안에 있는 다른 항목이 포함됩니다. 매우 간단한 인터페이스.
이것은 다음에 의해 호출됩니다. NCache 따라서 이 인터페이스를 구현하고 어셈블리를 등록합니다. 다음의 경우 NCache, 어셈블리를 캐시에 등록하고 이제 Cache.Get을 수행할 때 해당 항목이 캐시에 없으면 캐시는 실제로 NCache 읽기를 호출하여 데이터 소스에서 가져옵니다. 데이터 소스는 데이터베이스일 수도 있고 메인프레임이나 모든 데이터 소스일 수도 있습니다. 따라서 연속 읽기를 통해 캐시에 항상 데이터가 있고 애플리케이션이 보는 데이터가 있는지 확인할 수 있습니다. 이것이 하나의 이점입니다.
두 번째 이점은 다시 로드하는 것입니다. 따라서 실제로 읽기를 결합할 수 있습니다. 따라서 만료 및 데이터베이스 동기화 시 항목이 캐시에서 제거될 예정이고 어쨌든 다시 로드하기 때문에 제거하지 않으려는 경우에 가능합니다. 그렇다면 캐시를 그런 식으로 다시 로드하는 것은 어떨까요? 생각해 보면 캐시에 수백만 개의 항목이 있고 모두 항상 만료되기 때문입니다. 그렇죠? 왜냐면 그렇게 구성하셨거든요. 그리고 전자 상거래와 트래픽이 매우 높은 응용 프로그램이 있고 무언가가 만료될 때마다 이에 대한 동시 요청이 많이 있습니다. 그들은 모두 데이터베이스로 이동합니다. 따라서 갑자기 아무 이유 없이 데이터베이스 트래픽이 증가했습니다. 캐시에 트래픽이 필요하지 않은 경우에도 마찬가지입니다.
따라서 이러한 일이 항상 발생하므로 캐시가 있음에도 불구하고 데이터베이스 트래픽이 많이 급증하는 것을 볼 수 있습니다. 따라서 다시 로드하면 캐시에서 절대 제거되지 않는다는 의미입니다. 방금 업데이트됩니다. 따라서 귀하의 애플리케이션은 데이터베이스로 이동하지 않습니다. 그들은 당신이 그것을 업데이트할 때까지 이전 사본을 계속해서 얻을 것입니다. 따라서 캐시가 있음에도 불구하고 만료 또는 데이터베이스 동기화로 인해 데이터베이스 트래픽이 많이 급증하는 문제를 갑자기 제거하거나 처리했습니다. 따라서 캐시가 읽기를 통해 이를 다시 로드하게 하면 실제로 매우 강력해집니다.
물론, 연속 읽기의 또 다른 이점은 점점 더 많은 데이터베이스 액세스가 캐시에 의해 수행되기 때문에 중앙 집중화하고 애플리케이션 계층을 단순화한다는 것입니다. 따라서 동일한 데이터에 액세스하는 여러 애플리케이션이 있는 경우 캐싱 계층 내에서 데이터 액세스를 중앙 집중화할 수 있습니다. 물론 모든 데이터에 대해 이를 수행할 수는 없지만 많은 데이터에 대해 수행할 수 있습니다.
연속 기입은 연속 읽기와 동일한 방식으로 작동합니다. 그냥 쓰기로 넘어가겠습니다. 같은 방식으로 작동합니다. 여기에는 연속 쓰기 공급자(다시 InIt)가 있고 삭제되었으며 이제는 로드하는 대신 데이터 소스에 대한 쓰기이고 또 다른 유형의 대량 쓰기가 있습니다. 연속 기록의 한 가지 이점은 모든 것을 중앙 집중화한다는 점에서 연속 읽기와 동일합니다. 두 번째 이점은 앞서 말했듯이 데이터베이스보다 XNUMX배 빠른 캐시를 업데이트한 다음 캐시에 데이터베이스를 업데이트하도록 요청하는 쓰기 작업을 수행할 수 있다는 것입니다. 그리고 write-behind는 write-through와 기본적으로 동일하지만 비동기 방식으로 수행됩니다. 생성되어 처리되는 대기열입니다. 해당 대기열은 다음과 같은 경우에도 복제됩니다. NCache. 따라서 서버 중 하나가 다운되더라도 업데이트가 손실되지 않습니다. 하지만 write-behind는 애플리케이션 속도를 실제로 향상시킵니다. 이미 모든 읽기 작업을 캐싱하여 더 빠르게 만들었기 때문입니다. 그렇죠? 따라서 현재 읽기의 약 70~80%가 이루어졌거나 어쨌든 트랜잭션이 캐시로 이동하고 있습니다. 쓰기 속도도 높이는 것은 어떨까요? write-behind 방식으로 수행할 수 있는 경우, 비동기 쓰기를 수행할 여유가 있는 경우. 감당할 수 없는 데이터가 너무 민감한 경우 연속 쓰기를 수행하면 코드의 중앙 집중화라는 첫 번째 이점만 얻을 수 있습니다. 더 빠른 성능의 두 번째 이점은 비동기식을 수행할 수 있는 경우에만 나타납니다.
결론
전체적인 아이디어는 캐싱을 시작할 때 여기서 단순한 키 값인 캐시를 생각하지 말라는 것입니다. 즉, 제 목적은 먼저 분산 캐시가 정말 필요하다는 점을 여러분에게 확신시키는 것이었습니다. 인프라와 애플리케이션 아키텍처. 애플리케이션을 확장하려면 사용하는 캐싱 제품에 관계없이 이 제품을 통합해야 합니다. 즉, 이 제품이 있어야 한다는 뜻입니다. 현재 .NET 사용자를 위한 시장 옵션은 다음과 같습니다. NCache 이는 오픈 소스이자 상업용입니다. 있다 Redis Microsoft가 최소한 Azure에서 사용할 수 있게 만든 것입니다. Azure에서는 관리형 캐시 서비스이므로 외부에서 설치해야 하며 지원되지 않는 오픈 소스 버전을 사용하지 않는 한 주로 Linux에 설치됩니다. Java 측에는 캐싱에 대한 더 많은 옵션이 있습니다. 그래서 그것이 우선이었습니다.
이해해야 할 두 번째 목표는 단순한 핵심 값이 아닙니다. 모든 종류의 데이터를 캐시하고 실질적인 이점을 얻을 수 있는 모든 종류의 상황을 처리할 수 있는지 확인하고 싶습니다. 그리고 실제로는 시간이 부족해서 다른 부분까지 가지도 못했습니다. 예를 들어 런타임 데이터 공유를 어떻게 수행하는지, 그리고 확인하고 싶은 아키텍처 사항은 무엇인지 등이 있습니다. 캐시는 항상 동적이므로 구성할 수 있습니다. 이는 데이터 센터의 일부이자 프로덕션 환경의 일부입니다. 따라서 런타임 시 변경을 허용하지 않는 캐시는 선택하기에 좋은 캐시가 아닙니다. 그러면 많은 가동 중지 시간을 겪게 될 것입니다. XNUMX년에 한 번 가동 중지 시간을 예약한 고객이 있습니다. 그래서 우리 고객 중 일부는 가용성이 매우 높기 때문에 이를 갖고 있지 않습니다.
그들은 가동 중지 시간 없이 캐시 자체를 새 버전으로 업그레이드하기를 원합니다. 즉, 비즈니스 요구 사항이 무엇인지에 따라 다릅니다. 그러나 이러한 모든 사항을 고려해야 하며 현재 많은 사람들이 여러 데이터 센터를 보유하고 있습니다. 최소한 DR 목적과 지리적 로드 밸런싱을 위해서라면 데이터베이스가 복제될 것으로 예상합니다. 그렇죠?
그렇다면 왜 캐시가 여러 데이터 센터를 지원할 수 없어야 할까요? 왜냐하면 캐시가 더 적게 수행할 수 있을수록 더 많은 작업을 수행해야 하기 때문입니다. 그것이 결론입니다. 애플리케이션 요구 사항은 변경되지 않으므로 캐시는 이를 수용해야 합니다. 그러므로 모든 것을 명심하십시오.
그래서 다음과 같은 비교가 있습니다. NCache 과 Redis.
둘 다 오픈 소스입니다. NCache Enterprise Edition도 있습니다. 따라서 기본적으로 .NET의 경우 NCache 아주 잘 어울립니다. 에서 NCache, N은 .NET을 의미합니다. 결론적으로 이것이 우리가 .NET에 얼마나 전념하고 있는지를 의미합니다.