보스턴 코드 캠프 27
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
트랜잭션 로드 증가로 인해 .NET 응용 프로그램에서 데이터베이스 또는 저장소 병목 현상이 발생할 수 있습니다. 분산 캐싱을 사용하여 병목 현상을 제거하고 .NET 애플리케이션을 확장하는 방법을 알아보십시오. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
제 이름은 이크발 칸입니다. 저는 기술 전도사입니다. Alachisoft. 우리는 샌프란시스코 베이 지역에 본사를 둔 소프트웨어 회사입니다. 저는 개인적으로 Tampa에 거주하고 있지만 다음과 같은 제품이 있습니다. NCache. .NET 분산 캐시입니다. 오늘은 분산 캐싱을 사용하여 .NET 애플리케이션을 확장하는 방법에 대해 이야기하겠습니다. 이건 할 얘기가 아니야 NCache, 확장성 문제와 분산 캐싱으로 이를 해결하는 방법에 관한 것입니다. 당신은 무엇을 해야 합니까? 어떻게 사용해야 할까요? 모범 사례에는 어떤 것이 있나요? 궁금한 점이 있으면 언제든지 문의해 주세요. 그래서 우리는 더 상호적인 토론을 할 수 있습니다. 시작하겠습니다.
확장성이란 무엇입니까?
그럼 몇 가지 정의를 알아보겠습니다. 첫 번째는 확장성입니다. 확장성은 성능이 아닙니다. 5,000명의 사용자로 매우 잘 작동하는 응용 프로그램이 있을 수 있지만 50,000명, 500,000명 또는 5명의 사용자로 동일한 방식으로 수행할 경우에만 확장 가능합니다. 따라서 확장성은 최대 부하에서 실제로 높은 성능을 발휘합니다. XNUMX명의 사용자가 있을 때 애플리케이션이 제대로 작동하지 않으면 다른 강연에 참석해야 합니다.
선형 확장성 및 비선형 확장성
선형 확장성은 애플리케이션 배포 개념에 가깝습니다. 애플리케이션을 배포할 때 배포에 더 많은 서버를 추가할 수 있고 선형 방식으로 트랜잭션 용량을 늘릴 수 있으면 더 많은 서버를 추가하면 애플리케이션 아키텍처는 선형적으로 확장 가능하고, 그렇지 않으면 비선형 확장 가능합니다.
이것이 의미하는 바는 특정 수의 서버 이후에 더 많은 서버를 추가하면 실제로 상황이 더 악화된다는 것입니다. 즉, 단지 더 많은 서버를 추가하는 것만으로는 해결되지 않는 애플리케이션 어딘가에 병목 현상이 있음을 의미합니다. 당신은 확실히 비선형 확장성을 원하지 않으며 애플리케이션에서 선형 확장성을 확실히 원합니다.
확장성이 필요한 애플리케이션 유형은 무엇입니까?
확장성이 필요한 애플리케이션 유형은 무엇입니까? 이는 ASP.NET 응용 프로그램입니다. 이들은 웹 서비스입니다. 이는 대부분 웹 서비스인 IOT 백엔드입니다. 이는 .NET에서는 흔하지 않은 빅 데이터 처리 애플리케이션이며 점점 더 많은 작업이 Java로 수행되고 있지만 그럼에도 불구하고 확장성이 필요한 애플리케이션과 기타 서버 애플리케이션입니다. 예를 들어, 수백만 명의 고객을 보유한 대형 은행에서 근무하고 있는데 고객이 주소 변경을 위해 전화를 걸거나 새 카드 발급을 원하거나 은행에서 자금을 이체하려고 할 수 있습니다. 모든 거래는 규정 준수를 위해 미리 정해진 시간 내에 처리되어야 합니다. 따라서 단일 컴퓨터에서는 처리할 수 없는 시간 내에 수백만 개의 요청을 처리해야 합니다. 따라서 그러한 경우에도 확장할 수 있어야 합니다. 따라서 확장성이 필요한 애플리케이션이 있다면 이것이 올바른 이야기입니다.
확장성 문제
따라서 확장성 문제도 정의해 보겠습니다. 확장성 문제는 무엇입니까? 애플리케이션 계층은 선형 방식으로 확장됩니다. 웹 애플리케이션 ASP.NET 또는 웹 서비스가 있을 수 있습니다. 모든 서버에 트래픽을 균등하게 라우팅하는 로드 밸런서가 앞에 있습니다. 문제 없이 서버를 더 추가할 수 있습니다. 모든 것이 완벽하게 작동합니다. 이전에 누군가에게 데이터베이스에 병목 현상이 발생하는 것에 대해 이야기했는데 그들은 내 의견에 동의하지 않았습니다. 그래서 이번이 그런 논의를 할 수 있는 좋은 기회라고 생각합니다.
따라서 데이터베이스 자체가 초고속으로 수행됩니다. 성능에는 문제가 없습니다. 데이터베이스는 매우 똑똑하고 자체 서버에서 메모리 내 캐싱을 많이 수행하지만 확장성은 설계상 달성할 수 없는 것입니다. 예를 들어 여기에 10, 20, 30, 40, 50개의 서버를 추가할 수 있기 때문입니다. 층. 사용자가 너무 많기 때문에 애플리케이션 계층에 50개 이상의 서버를 보유한 고객이 있습니다. 당신이 대형 은행이거나 항공사라고 상상해보십시오. 귀하의 웹 사이트를 방문하는 수백만 명의 사람들이 있습니다. 당신은 하와이행 항공권 같은 대규모 프로모션을 진행했습니다. 모두가 와서 항공편 검색을 하고 표를 사고 싶어 합니다. 여기에는 문제 없이 더 많은 서버를 추가할 수 있습니다. 데이터베이스는 매우 빠른 성능을 발휘했고 소프트웨어도 훌륭했지만 설계상 데이터베이스는 분산 데이터베이스가 아닙니다. 한 곳에 보관되어 있습니다. 아마도 활성-활성, 활성-수동의 두 서버로 구성된 클러스터를 가질 수 있지만 실제로는 확장성보다는 안정성이 더 중요합니다.
따라서 여기에는 실제로 10개의 서버가 있을 수 없습니다. NoSQL database, 그러면 할 수 있습니다. 그러나 관계형 데이터베이스의 경우 SQL Server, Oracle, Db2, MySQL이 될 수 있으며 매우 빠릅니다. 메모리 처리에서 많은 작업을 수행할 수도 있지만 점점 더 확장해야 하므로 병목 현상이 발생합니다. 그리고 기본적으로 천 명 이상의 동시 사용자가 있으면 성능 문제가 나타나기 시작하고 1,000명에서 5,000명, 5,000명에서 10,000명으로 증가할수록 더 많은 문제가 발생하기 시작합니다. 따라서 우리가 본 것은 사용자가 1000명이면 캐싱을 사용할 수도 있고 사용하지 않을 수도 있지만 사용자가 5,000명, 10,000명, 15,000명으로 늘어나면 분명히 고통을 느끼고 이러한 확장성을 갖게 된다는 것입니다. 병목 현상.
이제 관계형 데이터베이스나 메인프레임 레거시 데이터베이스에 이 문제가 발생합니다. 이유 중 하나입니다 NoSQL database그의 움직임이 시작된 것은 그것 때문이었다. 하지만 다른 이점도 있으며 제품이 있습니다. 참고용으로 빨리 오겠습니다. 따라서 캐싱 제품이 있지만 NoSQL 문서 데이터베이스. 문서 DB와 마찬가지로 오픈 소스 데이터베이스입니다.
그래서, NoSQL database 확실히 확장성 문제가 없습니다. 그러나 항상 대답은 아닙니다. 왜 그런 겁니까? 왜냐하면 그것이 대답이 되려면, NoSQL database 모든 데이터를 그 안에 저장하길 원합니다. 따라서 데이터를 다른 곳에 저장하지 않는 한 NoSQL database 이는 적어도 데이터의 해당 부분에 대해 관계형 데이터베이스 사용을 중단한다는 의미이며 문제가 해결되지는 않습니다. 따라서 대부분의 경우 데이터 중 일부, 즉 많은 데이터를 NoSQL database 그리고 그것이 바로 이 일을 이끄는 것입니다 NoSQL 움직임. 그러나 관계형 데이터베이스, 레거시 메인프레임 데이터는 그대로 유지됩니다. 기술적인 이유와 비즈니스적인 이유 때문에 그냥 버리고 싶어할 수 있는 것이 아닙니다. 따라서 해결해야 하는 확장성 문제가 무엇이든 관계형 데이터베이스를 사용하여 해결해야 합니다. 그렇기 때문에 NoSQL database 항상 답은 아닙니다.
솔루션: 인메모리 분산 캐시
그리고 그 문제를 해결하는 방법은 지난 XNUMX~XNUMX년 정도에 걸쳐 등장한 새로운 모범 사례인 인메모리 분산 캐시입니다. 어떤 사람들은 이를 인메모리 데이터 그리드라고도 부릅니다. Microsoft는 데이터 패브릭을 호출하곤 했습니다. 하지만 그들은 계속해서 정의를 바꾸고 있습니다. 그러나 이는 메모리 내 분산 키-값 저장소이며 현재 아키텍처의 필수적인 부분입니다. 확장 가능한 애플리케이션을 원한다면 프로그래밍이 필요하며 분산 캐시를 염두에 두고 애플리케이션을 개발해야 합니다. 따라서 애플리케이션이 병목 현상을 일으키지 않도록 할 수 있습니다.
이제 분산 캐시란 무엇입니까? 본질적으로 두 개 이상의 저비용 서버입니다. 이들은 고급 데이터베이스 서버가 아니며 웹 서버 유형의 상자입니다. 일반적으로 듀얼 CPU, 8코어 구성이 매우 일반적입니다. 램은 16기가가 거의 평균입니다. 우리는 16~32기가가 메모리의 최적 지점과 같다고 봅니다. 64기가 이상의 경우 고객에게 권장하지도 않습니다. 이 상자를 더 강하게 만드는 대신 다른 상자를 추가한다고 합니다. 왜냐하면 64GB 이상을 추가하면 .NET 애플리케이션에는 처리 능력을 많이 소모하는 가비지 수집기라는 기능이 있기 때문입니다. 따라서 메모리가 많을수록 가비지 수집기가 모든 메모리를 수집할 수 있으려면 CPU 속도가 빨라져야 합니다.
따라서 실제로 소수의 고급 서버를 보유하는 것보다 많은 서버를 보유하는 것이 더 좋습니다. 물론 안정성을 원하기 때문에 최소 2개입니다. 서버가 다운된 후 그 비율이 4:1 또는 5:1인 경우 일반적으로 애플리케이션 계층에 2, 3, 4 또는 5개의 서버가 있게 됩니다. 우리가 볼 수 있는 가장 일반적인 것은 4와 10 사이이고 물론 10개 이상을 사용하는 고객도 많지만 4와 10이 우리가 보기에 가장 좋은 지점입니다. 그리고 이를 위해 2개의 서버 클러스터를 사용합니다. 10개 또는 12개 이상 성장하면 세 번째, 네 번째 등이 추가됩니다. 그리고 분산 캐시는 키 값 저장소이므로 분산됩니다. 지능적인 방식으로 여러 서버에 걸쳐 데이터를 복제하므로 안정성을 확보하는 동시에 복제에 많은 시간을 소비하지 않습니다. 예를 들어, 모든 데이터 조각을 모든 서버에 복제해야 한다면 불필요한 추가 처리가 필요합니다. 따라서 수행해야 하는 것은 이러한 유형의 지능적인 복제입니다. 때로는 그런 방식으로 복제가 필요하지만 이는 특수한 경우입니다. 따라서 분산 캐시가 있으면 약 80%의 시간 동안 해당 캐시로 이동하게 됩니다. 모든 읽기는 여기에서 수행되고 모든 업데이트와 일부 읽기는 데이터베이스와 캐시에 대해 수행됩니다. 따라서 데이터베이스 트래픽의 약 80%를 캐시로 트랩할 수 있다면 갑자기 데이터베이스가 매우 가벼워지는 것입니다. 할 일이 많지 않습니다. 따라서 무엇을 하든 훨씬 빠르게 수행됩니다. 따라서 성능은 물론 확장성도 향상됩니다.
이 메모리 내 분산 캐시는 NCache, 그것이든 Redis .NET 측에는 더 많은 플레이어가 있고 Java 측에는 더 많은 플레이어가 있습니다. 분산 캐시를 선택하는 제품은 현재 모범 사례입니다. 이를 아키텍처에 통합해야 합니다.
계속 진행하기 전에 지금까지 궁금한 점이 있으신가요? 그렇습니다. 하나의 논리적 캐시가 여러 서버에 걸쳐 있을 수 있습니다. 다음의 경우 NCache 동일한 서버에 여러 캐시를 가질 수 있습니다. 따라서 각 캐시는 격리 목적으로 자체 컨테이너가 되지만 하나의 캐시는 XNUMX개 서버 모두에 걸쳐 있을 수 있습니다. 제가 범위라고 말하면 일부 데이터는 한 서버에 있고 일부는 다른 서버에 있으며 복제는 귀하의 선호도에 따라 수행될 수도 있고 수행되지 않을 수도 있는 별도의 부분임을 의미합니다. 하지만 그렇습니다. 모든 서버는 해당 캐시를 저장하는 데 사용되며 캐시는 일관성이 있어야 합니다. 항상 정확해야 합니다. 또는 결국에는 정확해야 하지만 거의 항상 정확해야 한다고 말할 수 있습니다. 캐시에 무엇을 저장하든 업데이트하면 데이터가 어디에 있는지 신경쓰지 않으며 아마도 데이터가 어디에 있는지조차 모를 것입니다. 여러분이 아는 것은 이 클러스터에 내 데이터가 있고 가져올 때마다 이 서버에서 데이터를 저장했을 수 있으며 이후 즉시 여기에서 읽으려고 하면 동일한 복사본을 얻을 수 있다는 것입니다. 그렇게 할 수 있다면 이는 일관성이 있는 캐시가 됩니다. 따라서 업데이트에 대한 많은 데이터 무결성이 항상 보장됩니다.
이는 귀하가 선호하는 사항이므로 실제로 캐시를 사용하는 방법에 관해 더 자세히 설명하겠습니다. 따라서 여러분이 해야 할 한 가지는… 지금까지의 주요 목표는 확장성을 원한다면 이를 아키텍처의 일부로 포함해야 한다는 점을 확신시키는 것입니다.
분산 캐시의 일반적인 사용
이제 분산 캐시가 필요하다는 데 동의했다고 가정해 보겠습니다. 가장 먼저 떠오르는 질문은 이를 어떻게 사용하는가입니다. 어디에 사용하나요? 당신은 그것을 무엇을 위해 사용합니까? 여기에 보관되는 데이터와 해당 데이터와 관련된 모든 문제.
애플리케이션 데이터 캐싱
따라서 세 가지 높은 수준의 사용 사례가 있습니다. 첫 번째는 제가 방금 얘기한 애플리케이션 데이터 캐싱입니다. 즉, 데이터베이스에 데이터가 있고 이를 가져와서 캐시하는 것입니다. 따라서 애플리케이션 데이터 캐싱의 목표는… 하지만 방금 언급한 바에 따르면 데이터베이스를 많이 사용하기보다는 애플리케이션 확장을 위해 해당 데이터베이스 트래픽을 줄이는 것이 좋습니다. 그러나 이제 데이터는 두 곳에 존재합니다. 캐시에도 존재하고 데이터베이스에도 존재합니다. 그렇다면 데이터가 두 곳에 존재할 때마다 가장 먼저 떠오르는 우려 사항은 무엇입니까? 둘 사이의 동기화. 그럼 일관성이 있는 걸까요? 왜냐하면 데이터가 일관성이 없으면 읽기 전용 데이터에만 캐시를 사용하도록 제한되기 때문입니다. 실제로 대부분의 사람들은 캐시를 무엇에 사용합니까? 무릎 반사 반응은 읽기 전용 데이터입니다. 아시다시피 저는 실시간으로든 런타임에든 실제로 변경될 데이터에 대해 캐시를 사용하는 것이 불편합니다. 그러나 자주 변경되는 데이터에 대해 제가 사용하는 용어인 트랜잭션 데이터에 캐시를 사용할 수 없다면 해당 데이터는 아마도 데이터의 80%~90%일 것입니다. 즉, 이는 80%에서 90%의 시간 동안 캐시를 사용할 수도 없고 캐시를 사용할 수도 없으면 마치 NoSQL database. 항상 답은 아니죠. 그리고 여러분은 그것이 답이 되기를 원하므로 좋은 분산 캐시는 여러분이 캐시하는 모든 것이 데이터베이스와 일치할 것이라는 확신을 주어야 합니다. 그렇지 않다면 해당 캐시는 귀하에게 적합한 캐시가 아닙니다. 이것이 바로 첫 번째 사용 사례입니다.
ASP.NET 특정 캐싱
두 번째 사용 사례는 ASP.NET 응용 프로그램이 있는 경우입니다.
- ASP.NET 세션 캐싱
세션을 캐시에 저장할 수 있습니다. 세션은 거의 모든 ASP.NET 응용 프로그램에 있는 것입니다. In-Proc 모드 또는 SQL Server 모드로 유지됩니다. SQL Server는 두 가지 이유로 세션을 유지하기에 적합한 장소가 아닙니다. 첫 번째 이유는 데이터베이스에 데이터를 더 많이 보관할수록 확장성 병목 현상이 더 커진다는 것입니다. 두 번째는 세션이 Blob으로 유지되고 관계형 데이터베이스가 실제로 Blob용으로 설계되지 않았다는 것입니다. 이는 색인화하고 검색할 수 있는 보다 구조화된 데이터를 위해 설계되었습니다. 분산 캐시의 키 값은 항상 blob입니다. 따라서 이러한 세션은 분산 캐시와 매우 잘 맞습니다.
- ASP.NET View State 캐싱
ASP.NET 데이터의 두 번째 유형은 기존 ASP.NET 응용 프로그램 중 상당수가 아직 사용하지 않는 MVC 프레임워크를 사용하지 않는 경우 상태 보기 그리고 보기 상태는 보관되어 웹 서버에서 브라우저로 전송되고 웹 서버로 다시 돌아오는 암호화된 문자열일 뿐이며 꽤 커질 수 있습니다. 쉽게 수백 킬로바이트가 될 수 있으므로 추가 대역폭을 많이 소비합니다. 여행하는 데 시간이 더 걸립니다. 여기에 처리 중인 수백만 개의 요청을 곱하면 대역폭 소비 비용도 상당히 늘어납니다. 따라서 서버 측에서 캐싱하고 작은 키만 보내는 이상적인 경우입니다. 따라서 다음에 View State를 사용해야 할 때 키가 다시 전송되고 View State가 캐시에서 가져옵니다.
- ASP.NET 출력 캐싱
ASP.NET 관련 캐싱의 세 번째 예는 페이지 출력입니다. ASP의 일부입니다..NET framework 페이지가 변경되지 않을 경우 페이지의 출력을 캐시할 수 있는 출력 캐시라고 하며, 모든 웹 서버에 별도로 보관하는 대신 분산 캐시를 사용하여 캐시할 수 있으며 동기화해야 하는 여러 복사본이 됩니다. 따라서 이러한 세 가지 사용 사례 또는 세 가지 예는 ASP.NET 관련 캐싱 사용 사례에 대한 것입니다.
이제 여기서는 애플리케이션 데이터 캐싱과 달리 문제의 성격이 매우 다릅니다. 여기서 데이터는 캐시에만 존재합니다. 내 말은 이 모든 데이터가 더 이상 다른 곳에 저장되지 않는다는 뜻입니다. 따라서 데이터베이스에 저장되지 않습니다. 따라서 더 이상 데이터베이스와 캐시 간의 동기화 문제가 발생하지 않습니다. 하지만 이제 또 다른 문제가 생겼습니다. 메모리 내 캐시가 있는 경우 이것이 데이터의 유일한 저장소입니다. 가장 큰 관심사는 무엇입니까? 그게 무슨 문제가 될 수 있나요? 그것은 사라진다. 예, 사라질 수 있습니다. 하나의 서버가 다운되고 서버가 다운되면 Windows도 포함됩니다. 따라서 서버가 다운되면 데이터가 손실되고 특히 일부, 즉 보기 상태 및 세션 상태의 경우 출력 캐시가 손실되더라도 페이지를 다시 실행하면 됩니다. 단, 이 두 가지는 제외됩니다. 예를 들어 세션 상태를 예로 들면 항공사 고객이 온갖 종류의 항공편 검색을 했는데 주문을 하려고 하는데 서버가 충돌하고 세션이 끊어지면 실제 로그인해야 합니다. 그 고객을 잃을 수도 있습니다. 그래서, 당신은 확실히 잃고 싶지 않습니다. 따라서 이 데이터가 사라지는 것을 원하지 않습니다. 따라서 여기서 동기화는 신뢰성이 큰 문제였습니다.
따라서 안정성은 복제를 통해 처리됩니다. 복제를 수행하지 않는 캐시에는 세션을 저장할 수 없습니다. 그런데 ASP.NET 전용 캐싱의 좋은 점은 프로그래밍이 필요하지 않다는 것입니다. ASP 내에 완벽하게 맞습니다..NET framework. 불행하게도 애플리케이션 데이터 캐싱을 위한 프로그래밍을 해야 합니다. Java 측에서는 그럴 필요가 없거나 실제로 더 많은 표준이 등장하고 있습니다. JCache라는 표준이 있는데, 이를 프로그래밍하면 타사 캐시 중 하나를 여기에 연결하기만 하면 어느 하나의 캐시에 집착할 필요가 없습니다. 더욱이, Hibernate와 같은 OR 매핑 엔진을 사용하거나 .NET NHibernate의 경우 캐시를 연결할 수 있습니다. EF 코어까지 또는 EF 코어 이전까지 Entity Framework에서는 타사 캐시가 자동으로 연결되는 것을 허용하지 않았습니다. EF6용 ADO .NET 공급자를 구현했지만. 이는 ADO.NET 수준 캐싱에 가깝기 때문에 캐싱하지 않는 것보다 더 나은 쿼리를 캐싱했지만 업데이트를 추적할 수 있는 엔터티 수준의 캐싱만큼 강력하지는 않습니다.
Entity Framework 또는 EFCore 캐싱
새로운 EF7 또는 EF Core는 훨씬 더 유연한 아키텍처를 갖추고 있습니다. 이를 통해 타사 캐시를 연결할 수 있습니다. 따라서 EF Core로 이동하면 다음과 같은 분산 캐시를 연결할 수 있습니다. NCache 프로그래밍 없이. 따라서 표준 프로그래밍과 캐시 플러그인만 수행하고 있었습니다. 하지만 그 외에는 다른 작업을 수행해야 합니다. 하지만 해당 플러그인에서도 제가 설명할 모든 기능을 사용할 수는 없습니다. ASP.NET에서는 적어도 이것이 가장 쉬운 승리입니다. 캐시를 가져올 때 프로그래밍이 필요하지 않기 때문에 몇 가지 기본적인 온전성 테스트만 수행하면 애플리케이션의 성능과 확장성이 갑자기 크게 향상됩니다.
계속하기 전에 질문이 있으신가요? 애플리케이션 측면에서요, 아니면 캐시 측면에서요? 캐시 측면에서. 캐시는 데이터베이스와 같습니다. 데이터베이스를 호출한 다음 예외를 처리하는 것과 같습니다. 캐시에 문제가 발생하면 캐시에서 예외가 발생하고 이를 포착한 다음 적절한 조치를 취해야 합니다. 그러나 검사 제약 조건이나 기타 참조 무결성 제약 조건이 있을 수 있기 때문에 데이터 무결성에 대한 업데이트가 실패할 수 있는 데이터베이스와 달리 캐시에는 이러한 제약 조건이 없습니다. 캐시는 사용자가 제공하는 모든 데이터를 받아들입니다. 캐시 업데이트 또는 작업이 실패하는 유일한 경우는 시스템에 문제가 있는 경우입니다. 응, 뭔가 치명적인 일이었어. 따라서 캐시가 정상적인 작업에서 항목을 업데이트하지 않는 것에 대해 걱정할 필요가 없습니다.
보안
따라서 이는 사용하는 캐시 제품에 따라 다릅니다. NCache 모든 기능이 내장되어 있습니다. 보안, 따라서 캐시를 사용하는 모든 사용자는 인증/권한 부여를 받아야 합니다. 또한 내장된 암호화와 같은 다른 보안 기능도 많이 있습니다. 따라서 사용 중인 응용 프로그램이 매우 민감한 경우 데이터가 캐시되기 전에 데이터를 암호화할 수 있으며 모든 작업은 추가 노력을 하지 않고도 캐시에 의해 자동으로 수행됩니다. 제가 말했듯이, 가장 큰 사용자 중 하나이기 때문입니다. NCache 금융 서비스 산업입니다. 왜냐하면 그들은 온라인 뱅킹을 많이 가지고 있기 때문입니다. 많은 e-비즈니스가 그곳에서 발생하며 해당 데이터는 매우 민감합니다. 따라서 어떤 제품을 선택하느냐에 따라 달라집니다.
이벤트를 통한 런타임 데이터 공유
세 번째 활용 사례는 이벤트를 통한 런타임 데이터 공유. 메시지 대기열을 사용하는 것과 마찬가지로 MSMQ는 하나이고 RabbitMQ는 또 다른 것입니다. 둘 이상의 위치에 있는 분산 환경에 대한 메시징 측면에서 훨씬 더 많은 기능을 가지고 있습니다. 귀하의 애플리케이션이 모두 하나의 데이터 센터에 있고 다음을 수행해야 하는 경우 Pub / Sub 데이터 공유 유형인 분산 캐시는 다른 메시지 대기열보다 확장성이 훨씬 뛰어납니다. 그만큼 많은 기능이 없을 수도 있지만 모든 기능이 필요하지는 않을 수도 있습니다. 하지만 훨씬 더 빠르고 확장성이 뛰어나며 이는 사실입니다. NCache 이는 이 기능을 제공하는 다른 분산 캐시에도 적용됩니다. 왜냐하면 이 전체 클러스터가 다시 메시지 버스가 되기 때문입니다. 따라서 많은 활동을 수행하는 경우 이벤트는 해당 이벤트를 처리하는 서버가 두 개 이상이므로 매우 빠르게 전파되며 로드가 증가함에 따라 더 많은 서버를 추가할 수 있습니다.
따라서 요즘 이러한 서버 애플리케이션에는 워크플로가 내장되어 있는 경우가 많습니다. 하나의 애플리케이션이 어떤 작업을 수행하고 일단 해당 작업이 완료되면 다른 애플리케이션이 다른 작업을 수행합니다. 이것이 Pub/Sub 또는 생산자/소비자 개념이 나오는 곳입니다. 이벤트 알림 기능이 있습니다. NCache 이 기능이 있습니다 연속 쿼리 이는 매우 강력한 기능으로 Java 측에도 존재하지만 다른 .NET 캐시에는 없습니다.
따라서 런타임 데이터 공유는 분산 캐시를 통해 수행하는 것을 강력히 고려해야 하는 작업이며, 다른 여러 제품을 통합하는 대신 생활을 훨씬 단순하게 만듭니다. 여기서도 문제의 본질은 대개 이와 동일합니다. 즉, 공유하려는 데이터가 캐시에만 존재한다는 것입니다. 그것은 데이터베이스에 존재할 수 있지만 다른 형태로 있을 수 있습니다. 왜냐하면 여러분이 그것을 구성하고 생산했으며 많은 데이터를 함께 가져왔고 이 최종 또는 중간 형태에서 누군가와 공유하고 있기 때문입니다. 또 다른. 따라서 해당 데이터를 잃어버리면 모든 작업을 다시 실행해야 합니다. 따라서 세션만큼 나쁘지는 않지만 여전히 성능에 많은 영향을 미칩니다. 따라서 해당 데이터를 잃고 싶지 않습니다. 따라서 여기서도 관심은 캐시가 신뢰할 수 있는지 확인하는 것입니다.
이것이 바로 분산 캐시가 제공하는 세 가지 고급 사용 사례입니다. 앞서 말했듯이 분산 캐시는 본질적으로 키 값 저장소인 분산 메모리 내 데이터베이스입니다.
실습 데모
이를 수행하는 방법에 대해 더 구체적으로 설명하기 전에 분산 캐시가 어떻게 생겼는지 빠르게 보여 드리겠습니다. 따라서 응용 프로그램에서 이를 사용하면 어떻게 될지 확인할 수 있습니다. 당연히 이용할 예정 NCache 예를 들어. NCache 오픈 소스 캐시입니다. 그래서 돈이 없거나 예산이 없다면 구매하지 않고도 사용이 가능합니다. 귀하의 프로젝트가 비즈니스에 더 민감한 경우에는 물론 Enterprise Edition을 구입하십시오. 그래서 저는 사용할 일부 VM을 Azure에 설정했습니다. 2노드 캐시 클러스터를 사용할 예정이므로 캐시 서버로 'demo1'과 'demo2'가 있고 애플리케이션 서버 상자는 'demo-client'입니다. 이것이 바로 ASP.NET 서버 상자입니다. 그래서, NCache 클라이언트는 실제로 애플리케이션 서버입니다.
예를 들어 데모 클라이언트에 로그인했습니다. 그래서 가장 먼저 할 일은 새 캐시를 만드는 것입니다. 그래서 저는 다음과 같은 도구를 사용하겠습니다. NCache 매니저. 따라서 이는 탐색기 스타일 도구입니다. 새로운 클러스터 캐시를 생성한다고 말씀드리겠습니다. ~ 안에 NCache 모든 캐시에는 이름이 지정됩니다.
스토리지나 복제 전략을 선택하겠습니다.
여기서는 첫 번째 캐시 서버를 지정하겠습니다. 두 번째 것을 지정하십시오.
계속해서 서버가 소비해야 하는 메모리 양이 얼마인지 말씀드리겠습니다. 귀하의 경우에는 훨씬 더 많을 것입니다. 방금 한 공연을 지정했습니다.
따라서 해당 메모리가 소비되면 제거 정책을 지정할 수 있습니다. 따라서 최근에 사용된 정책은 가장 최근에 사용되지 않은 항목 중 일부를 제거하는 것을 의미한다고 가정해 보겠습니다.
그래서 방금 얻었습니다. 계속해서 내 상자인 클라이언트 노드를 추가하고 캐시를 시작하겠습니다.
그렇다면 이것을 어떤 기계에 설정하고 있습니까? 이것은 Azure입니다. 그래서 이 두 개가 제 데모1과 데모2입니다. 그래서 저는 실제로 이 상자에 로그인하여 다음을 사용하고 있습니다. NCache 여기 관리자가 있고 저는 여기에 데모1과 데모2의 클러스터를 만들고 있습니다.
이제 이 작업을 시작했으므로 계속해서 통계를 볼 수 있습니다. 따라서 PerfMon 카운터 활동을 볼 수 있습니다. 이 모니터링 도구를 시작할 수도 있습니다. NCache 이를 통해 상황을 볼 수 있으며 스트레스 테스트 도구라는 이 도구를 빠르게 실행하겠습니다. 이를 통해 사용자 환경에서 캐시를 신속하게 테스트하여 작동 방식을 확인할 수 있습니다.
따라서 해당 도구는 애플리케이션과 같습니다. 이를 사용하여 다양한 유형의 부하, 다양한 유형의 작업을 시뮬레이션할 수 있습니다. 예를 들어, 여기서는 초당 약 600개의 요청을 수행하고 있으며 각각 약 700~800개의 요청을 수행하고 있습니다.
바로 여기에서 Stress Test Tool 인스턴스를 하나 더 실행하겠습니다. 따라서 부하가 두 배로 증가한다는 것을 알 수 있습니다. 따라서 점점 더 많은 애플리케이션 인스턴스를 추가하면 이 두 서버가 최대치에 도달할 때까지 캐시의 로드가 증가하고 세 번째 서버를 추가하기만 하면 됩니다.
그리고 아무것도 중단하지 않고 런타임에 이 모든 작업을 수행할 수 있습니다. 갑자기 인프라가… 생각해 보십시오. 데이터베이스가 막히기 시작하면 실제로 다른 서버를 추가하고 그 문제에서 벗어날 수 있습니까? 당신은 할 수 없습니다. 그 특성상 특정 데이터베이스에 관한 것이 아니라 모두 관계형 데이터베이스이기 때문입니다. 그러나 캐시의 경우 다른 서버를 추가하면 이제 캐시가 작동합니다.
이것이 캐시의 모습입니다. 보시다시피 사용 및 구성이 매우 쉽습니다. 내가하지 않은 유일한 일은 설치라는 것입니다. 그건 단지 Windows 설치 프로그램이었는데, 아시다시피 그렇게 오래 걸리지는 않습니다. 그 외에도 XNUMX노드 클러스터를 파악하는 데 약 XNUMX분이 걸렸습니다.
이제 이 모든 것이 구성되었으므로 실제로 이 상자에서 실행되는 응용 프로그램에 이 캐시 이름을 지정할 수 있습니다. 따라서 더 많은 클라이언트 상자가 있으면 여기에 계속 추가하겠습니다.
귀하의 경우 이 두 가지에 대해 아마도 8~10개가 있을 것입니다. 따라서 모두 추가한 다음 이 캐시를 수행하면 데모 캐시를 거기에서 사용할 수 있고 업데이트할 수 있습니다.
이제 캐시가 어떻게 생겼는지 알았으니 다음 주제로 빠르게 넘어가겠습니다. 그래서 제가 말했듯이 캐시를 사용하는 가장 쉬운 방법은 캐시를 세션에 사용하는 것입니다. 어떻게 해야 하나요? 그래서 ASP.NET 응용 프로그램이 있습니다. 들어가서 web.config를 열고 두 가지 작업을 수행하겠습니다. 먼저 어셈블리를 추가하겠습니다.
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=1448e8d1123e9096" />
</assemblies>
</compilation>
...의 경우 NCache 그것이 구현하는 어셈블리입니다. ASP.NET 세션 상태 공급자. 그래서, 그게 방법이야 NCache ASP에 연결.NET framework. 모든 타사 캐시가 그렇게 해야 합니다. 따라서 어셈블리에 해당 줄을 추가하고 두 번째로 세션 태그로 이동하여 선택한 분산 캐시에 대해 이를 지정합니다.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...의 경우 NCache 이것을 복사하면 확인해야 할 몇 가지 사항이 있습니다. 먼저 모드가 'custom'인지 확인해야 합니다. 따라서 맞춤형은 타사 스토리지를 의미하기 때문입니다. 그런 다음 '타임아웃'을 통해 원하는 상태인지 확인하고 기본값으로 유지할 수 있는 다른 모든 항목을 확인하고 여기에 바로 캐시 이름을 지정하면 됩니다. 따라서 'demoCache'여야 합니다. 이렇게 변경하고 응용 프로그램을 다시 실행하거나 실제로 이를 저장하자마자 ASP.NET 작업자 프로세스가 재활용된다는 것을 알 수 있습니다. 픽업됩니다 NCache 구성을 실행하면 갑자기 모든 세션이 하나의 세션으로 계산되는 것을 볼 수 있습니다. 그래서, 우리가 본 모든 것, 아시다시피, 그 숫자는 NCache 여기 PerfMon에서요.
따라서 저장되는 세션은 540개이며, 세션을 더 추가하면 개수도 늘어납니다.
따라서 이 작은 노력으로 즉시 애플리케이션을 크게 향상시킬 수 있습니다. View State도 마찬가지입니다. 출력 캐시를 사용하면 구성이 조금 더 필요하지만 보기 상태와 세션을 아무런 노력 없이 몇 분 만에 수행할 수 있으며 갑자기 애플리케이션이 엄청난 성능을 발휘합니다.
애플리케이션 데이터 캐싱 개요(API)
이제 이 대화의 대부분을 다루는 애플리케이션 데이터 캐싱으로 넘어가겠습니다. 따라서 애플리케이션 데이터 캐싱을 위해 캐시를 사용해야 하는 경우 해당 API에 프로그래밍해야 합니다. 아직은 표준 API가 없기 때문입니다. 그래서 우리는 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");NCache 2005년쯤부터 있었으니까 이제 거의 11년 반 정도 됐네요. 그러나 이는 ASP.NET 캐시 개체와 매우 유사해 보입니다. 몇 가지 추가 사항이 있으므로 캐시 이름으로 캐시에 연결한다고 가정해 보겠습니다. 캐시 핸들을 얻습니다. 그러면 그 캐시 핸들이 당신이 사용하는 것입니다 캐시.가져오기. Get에는 추가, 삽입, 제거가 포함되어 있으며 비동기 버전이 있습니다. 즉, 캐시가 업데이트될 때까지 기다리지 말고 물론 비동기를 호출할 때 콜백을 지정할 수 있습니다. 따라서 문제가 발생할 경우 콜백이 호출됩니다.
적절한 애플리케이션에서처럼 시각적으로 어떻게 보이는지 보여드리겠습니다. 따라서... 이것은 표준 콘솔 응용 프로그램입니다. 캐시 어셈블리를 참조해야 합니다. 다음의 경우 NCache, 이 두 개의 어셈블리만 있으면 됩니다. Alachisoft.NCache.실행 시간, Alachisoft.NCache.편물. 여기에서 동일한 네임스페이스를 지정한 다음 ASP.NET의 경우 응용 프로그램 시작 부분에 있을 것입니다. 글로벌.asax Init 메소드 또는 애플리케이션 시작 메소드에서. 하지만 여기서는 아시다시피 캐시 이름과 캐시 이름을 기반으로 캐시에 연결한다고 가정해 보겠습니다. NCache 이것이 캐시가 인식되고 캐시 핸들을 얻는 방법입니다. 그런 다음 개체를 만들고 다음을 수행합니다. 캐시.추가. 키를 지정합니다. 이것은 좋은 열쇠가 아닙니다. 그 안에는 좀 더 독창성이 있어야 합니다. 그러나 키를 지정하고 여기에 실제 객체의 값이 있다고 가정해 보겠습니다.
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 이라는 일을 하고 있어요 절대 만료. 그럼 그 얘기를 해보죠. 그래서 우리는 캐시를 최신 상태로 유지하기 위한 애플리케이션 데이터 캐싱에 대해 이야기했습니다. 따라서 캐시를 최신 상태로 유지할 수 없다면 강제로 읽기 전용 데이터에 사용해야 합니다. 그렇다면 캐시를 어떻게 최신 상태로 유지합니까? 여러 가지 방법이 있습니다. 거의 모든 캐시에 있는 첫 번째 방법은 절대 만료라고 합니다. 여기서 캐시에 이를 보관할 기간을 지정합니다. 따라서 당신은 캐시에 이 데이터가 99분 이상 캐시에 유지되어서는 안 된다고 생각하는 90분 동안만 편안함을 느낀다고 말합니다. 왜냐하면 제 생각에는 데이터가 XNUMX분 이상 캐시에 보관되어 있으면 다른 사람이 있을 것이기 때문입니다. 업데이트할 예정이며 캐시가 오래될 것입니다. 따라서 캐시에 데이터가 얼마나 오래 보관되어야 하는지에 대해 정보를 바탕으로 추측하고 있습니다. 물론 캐시하는 모든 데이터에는 일종의 만료 기간이 있어야 합니다. 거의… 제 말은 어떤 데이터는 절대 만료되지 않을 것이라고 가정할 수 있으므로 만료가 없다고 말할 수 있다는 뜻입니다. 그러나 데이터의 XNUMX% 또는 XNUMX% 이상의 데이터에는 만료가 있어야 합니다. 따라서 절대 만료는 학습된 추측을 기반으로 캐시를 최신 상태로 유지하는 것입니다.
라는 또 다른 만료일이 있습니다. 슬라이딩 만료. 그 목적은 전혀 다릅니다. 동일한 이름 호출 만료를 사용하지만. 슬라이딩 만료에는 이렇게 오랫동안(10분 동안, 20분 동안) 아무도 이 개체를 건드리지 않으면 만료된다고 나와 있습니다. 그리고 이는 일시적인 데이터에 더 많이 사용됩니다. 따라서 이는 실제로 정리 작업을 수행하는 ASP.NET 관련 데이터에 더 많이 사용됩니다. 당신은 더 이상 다른 사람이 그것을 필요로 하지 않는다고 말하고 있습니다. 따라서 사용자가 20분 동안 더 이상 세션을 사용하지 않으면 이 사용자가 어쨌든 로그아웃했다는 의미이므로 세션을 제거하십시오. 따라서 이는 정리 만료입니다. 그런 다음 동기화 목적인 절대 만료입니다. 절대 만료의 목적은 동기화입니다. 그리고 다시 할 수 있습니다. 10초, 15초, 1분, 5분, 10분 후에 만료할 수 있습니다. 가장 일반적인 만료는 아마도 XNUMX~XNUMX분일 것입니다.
그런데 유통기한이 문제네요. 추측을 하고 있다는 것입니다. 이렇게 오랫동안 캐시해도 괜찮을 것 같다고 말씀하셨는데요. 그러나 보장은 없습니다. 어떤 경우에는 있을 수 있지만 대부분의 경우에는 보장이 없습니다. 동일한 데이터베이스에 액세스하는 다른 애플리케이션이 있고 해당 애플리케이션이 해당 데이터를 업데이트하면 어떻게 될까요? 일부 스크립트가 실행 중일 수 있습니다. 따라서 그런 일이 발생할 때마다 만료만으로는 충분하지 않습니다. 그리고 데이터베이스의 변경 사항을 모니터링하는 기능을 갖추려면 캐시가 필요한 곳입니다.
캐시에 있는 항목과 데이터베이스에 있는 해당 데이터 간의 연관성을 지정할 수 있고 캐시에 이 데이터 세트를 모니터링하라고 말할 수 있는 경우. 이 데이터 세트가 변경되면 캐시에서 해당 항목을 제거하세요.
데이터베이스 종속성
그것이 어떻게 이루어지는지 보여드리겠습니다. 그래서 이라는 기능이 있습니다. SQL 종속성 ADO.NET에서는 NCache 사용합니다. 어느 것이 허용합니까? NCache 데이터베이스의 클라이언트가 되려면. 그리고 이것은 SQL 데이터베이스일 수도 있고 Oracle일 수도 있습니다. 그런 다음 NCache 해당 데이터 세트가 변경되고 해당 데이터 세트가 사용자가 지정한 SQL 문일 때 이를 알리도록 데이터베이스에 지시합니다. 대부분의 경우 캐시된 개체를 구성하는 데 사용된 테이블의 하나 이상의 행에 해당합니다. 예를 들어 여기에서 SQL 종속성 항목으로 이동해도 마찬가지입니다. 캐시 핸들이 있고 추가할 때 다음이 표시됩니다. 캐시.추가, 이제 다음의 경우를 지정하고 있습니다. NCache 이것은 값과 다른 메타데이터를 포함하는 일종의 구조인 캐시 항목이라고 합니다. 포함된 메타데이터 중 하나를 SQL 캐시 종속성이라고 합니다. NCache 서버 측의 ADO.NET SQL 캐시 종속성에 매핑되는 클래스입니다. 연결 문자열을 전달하고 SQL 문을 전달합니다.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset 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.Id);
// 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);
}따라서 '제품 ID가 값이 무엇이든 제품에서 일부 열을 선택하세요'와 같이 말합니다. 따라서 이것은 이것을 매핑하는 하나의 제품입니다. 그래서 당신이 말하는 것은 NCache 이 SQL 문을 사용하고, 이 연결 문자열을 사용하여 해당 데이터 세트를 모니터링하거나 SQL 서버에 해당 데이터 세트를 모니터링하도록 요청하세요. 사실 이 코드가 여기서 실행되고 있는 거죠. 왜냐하면, 바로 그곳이 NCache 이다.
따라서 이는 캐시 클러스터와 통신하고 캐시 서버는 실제로 ADO.NET 호출을 수행하며 캐시 서버는 이제 데이터베이스와 통신하여 클라이언트가 됩니다. 그리고 캐시 서버는 알림을 받는 서버입니다. 그리고 캐시 서버는 데이터베이스가 이 데이터가 변경되었음을 알릴 경우 캐시에서 해당 항목을 실제로 제거하는 서버입니다. 따라서 해당 기능이 내장되면 데이터가 언제 변경될지 예측할 수 없는 캐시에 데이터를 보관할 수 있는 유연성이 갑자기 확보됩니다. 그러나 예측할 수 없는 방식으로 변경될 수 있다는 점만 알고 있으므로 SQL 종속성을 지정하는 데 사용할 수 있습니다.
이것은 정말 강력한 기능입니다. 이는 캐시를 통해 트랜잭션 데이터를 캐시할 수 있도록 하는 기능입니다. 항상 업데이트를 제어할 수 없는 경우에도 모든 종류의 데이터를 캐시하므로 해당 캐시가 실제로 유용할 것입니다. 그리고 기본 데이터베이스가 SQL Server 및 Oracle의 경우와 같이 데이터베이스 알림을 지원하는 경우 이는 다양한 방법으로 수행될 수 있으며, 그렇지 않은 경우에는 SQL 종속성 또는 Oracle 종속성 기능을 사용합니다. NCache 적어도 사용자가 지정할 수 있는 폴링 메커니즘이 내장되어 있습니다. … 특별한 테이블을 지정하는 메커니즘이 있습니다. NCache 이를 모니터링하고 그 안에 변경된 모든 행에는 해당 캐시 항목이 있으며 제거됩니다.
세 번째 옵션은 CLR 프로시저 내에서 실제로 캐시 호출을 수행하는 것입니다. 따라서 데이터가 변경될 때마다 캐시를 호출하는 프로시저를 호출하는 데이터베이스 트리거가 있습니다. 그리고 데이터를 추가하거나 업데이트하거나 캐시에서 데이터를 제거할 수 있습니다. CLR 프로시저에서 유일한 문제는 비동기 호출을 하고 싶지 않다는 것입니다. 즉, 비동기 호출을 원한다는 것입니다. 왜냐하면 무엇을 부르든 실제로는 데이터베이스가 이전 버전과 마찬가지로 캐시의 클라이언트가 되었기 때문입니다. 그래서 여기에 들어갈 무언가를 업데이트하려고 시도하고 있으며 복제될 수 있습니다. 따라서 이러한 모든 작업은 데이터베이스 트랜잭션 내에서 발생하며 아시다시피 데이터베이스 트랜잭션의 시간 초과는 매우 빠르게 발생합니다. 따라서 비동기 호출을 수행하면 즉시 캐시 호출을 수행한 다음 컨트롤을 반환할 수 있습니다.
따라서 캐시가 관계형 데이터베이스와 동기화된 상태로 유지되도록 할 수 있는 세 가지 방법이 있습니다. 물론 비관계형에도 동일한 논리가 적용됩니다. 데이터가 클라우드 어딘가에 있다면 어떨까요? 아니면 메인프레임에 있습니다. 아시다시피, 항상 가져오기 위한 웹 메소드 호출이 있습니다. 그렇다면 다음의 경우 NCache 최소한 코드가 캐시 클러스터에 등록되는 사용자 정의 종속성 기능을 가질 수 있습니다. NCache 15초마다 호출하고 계속 진행하여 데이터 소스를 확인하고 해당 데이터가 변경되었는지 확인하라고 말합니다. 그렇다면 이벤트를 발생시키고 동일한 논리가 시작됩니다.
그래서 다시 캐시를 최신 상태로 유지 분산 캐시에서 가장 중요한 것입니다. 캐시를 최신 상태로 유지할 수 없으면 사용이 매우 제한됩니다.
연속 읽기 및 연속 쓰기
라는 또 다른 기능이 있습니다. 연속 읽기 및 연속 쓰기. Read-Through는 매우 유용하고 강력한 기능입니다. 본질적으로 캐시 서버에서 실행되는 코드입니다. 어디입니까? 여기. 따라서 다음과 같은 경우에 읽기 인터페이스를 구현한다고 가정해 보겠습니다. NCache. 이제 read-through/write-through는 다음과 같이 구현되는 개념입니다. NCache. 또한 많은 Java 플레이어에 의해 구현되지만 .NET 측에서는 구현됩니다. NCache 그것을 가지고 있는 유일한 사람입니다. 따라서 읽기 인터페이스는 본질적으로 코드입니다. Init 메서드, Dispose 메서드가 있으므로 Connect, Disconnect, Load 메서드가 있습니다.
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...이는 당신에게 키를 제공하고, 키를 기반으로 어디로 가서 데이터를 얻을지 파악해야 합니다. 그리고 데이터를 반환할 뿐만 아니라 만료 및 기타 정보와 같은 일부 메타데이터도 반환합니다. 연속 읽기의 가치는 무엇입니까? 다시 말씀드리지만, 이 코드는 여러분이 구현하고 등록하는 것입니다. 즉, 이 코드는 여기 캐시 서버에서 실행됩니다. 그래서 우리는 사용자 정의 종속성에 대해 이야기했습니다. 따라서 사용자 정의 데이터 소스가 있는 경우 이는 캐시 서버에서 실행되는 코드이고 읽기도 캐시 서버에서 실행되는 코드입니다.
낭독은 어떤 용도로 좋은가요? 왜 Read-through를 사용해야 합니까? 두세 가지 이점이 있습니다. 첫째, 모든 지속성 코드를 한 곳에 통합합니다. 따라서 캐시를 사용하는 여러 애플리케이션이 있는 경우, 예를 들어 여러 애플리케이션이 있다고 가정하면 해당 코드를 모두 반복해서 구현할 필요는 없습니다. 따라서 캐시 서버 자체 내에 보관됩니다. 이것이 첫 번째 이점입니다. 두 번째 이점은 무언가를 만료할 때 만료나 데이터베이스 동기화로 인해 무언가를 만료시키는 경우 캐시에서 해당 항목을 제거하는 대신 그냥 다시 로드하는 것이 좋다는 것입니다. 왜냐하면 제거하면 다음에 애플리케이션이 원할 때 어쨌든 다시 로드되기 때문입니다. 따라서 이것과 함께 읽기를 매핑하고 이 항목이 만료되거나 가져오면 캐시가 괜찮다고 말하는 위치를 말할 수 있습니다. 자동 동기화이고 제거해야 하는 경우 대신 읽기를 호출하겠습니다. 그렇다면 read-through를 호출하는 것이 왜 좋은가요? 내 말은, 뭐가 그렇게 큰 일이야? 그냥 애플리케이션으로 다시 로드하면 안 되나요? 글쎄요, 트래픽이 많은 애플리케이션이 있다면 많은 사용자가 동일한 데이터를 요구할 가능성이 있습니다. 이러한 항목은 수십만 개가 있으며 모두 고유한 시간에 계속 만료됩니다. 따라서 항목이 만료될 때마다 동일한 항목에 대해 데이터베이스에 도달하는 요청이 수천 건은 아니더라도 수백 건에 달하게 됩니다. 그리고 모두 가서 캐시를 다시 업데이트합니다. 따라서 불필요한 트래픽이 많이 데이터베이스로 이동합니다. 읽은 내용이 있으면 캐시를 떠나지 않을 것입니다. 항상 캐시에 남아 있으며 어느 시점에 업데이트됩니다. 따라서 데이터베이스에 대한 트래픽이 발생하지 않습니다.
두 번째 기능은 쓰기용이라는 점을 제외하면 연속 읽기와 정확히 동일하게 작동하는 연속 쓰기입니다. 그럼 그걸 보여드리겠습니다. 예를 들어 여기에도 Init가 있고 Dispose가 있지만 이제 Write가 있고 실제 개체를 제공하면 쓰기가 추가, 업데이트 또는 제거될 수 있습니다. 따라서 세 가지 모두 쓰기라고 합니다. 따라서 해당 작업 유형이 무엇이든 기반으로 데이터베이스나 데이터 소스를 업데이트하세요.
#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
bool result = false;
OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
Customer value = (Customer)operation.ProviderCacheItem.Value;
if (value.GetType().Equals(typeof(Customer)))
{
result = sqlDatasource.SaveCustomer((Customer)value);
}
if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
return operationResult;
}
public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
throw new Exception("The method or operation is not implemented.");
}이제 연속 기입에는 또 다른 이점이 있습니다. 코드의 공통성 측면에서 읽기와 동일한 이점이 있습니다. 연속 기입의 두 번째 이점은 후행 기입이라고 합니다. 즉, 업데이트할 수 있습니다. 따라서 캐시를 동기 방식으로 즉시 업데이트할 수 있지만 데이터베이스 업데이트는 비동기 방식으로 발생하는 write-behind라는 기능이 있습니다. 그게 왜 좋은 거죠? 글쎄요, 그 데이터베이스가 느리거든요. 따라서, 데이터베이스 업데이트가 적시에 완료될 것이라고 확신한다면… 그냥 대기열에 등록하지 않는 것이 왜 좋은지 예측할 수 있습니다. 대기열에 추가되고 캐시는 실제로 백그라운드에서 이 작업을 수행합니다. 해당 대기열은 둘 이상의 서버에도 복제됩니다. 따라서 서버 하나가 다운되더라도 대기열은 손실되지 않습니다.
모든 것은 확장성의 맥락에서 보아야 한다고 생각합니다. 속도가 빠른 것은 무엇이든, 메모리 내 데이터베이스라도 모두 하나의 서버에 있습니다. 따라서 더 많은 업데이트가 전송될수록, 더 많은 읽기가 전송되고, 데이터베이스에 더 많은 로드가 가해질수록 속도가 느려집니다. 단일 실패 지점과 같습니다. 그게 다야. 이것이 바로 이 모든 것이 존재하는 진짜 이유이며, 이 모든 존재의 맥락 내에서 여러분은 모든 추가적인 이점을 얻는 것입니다. write-behind 기능이 있는 경우 갑자기 애플리케이션은 동기 방식으로 캐시를 업데이트하기만 하면 됩니다. 캐시가 업데이트되면 캐시는 비동기 방식으로 데이터베이스 업데이트를 처리하기 때문입니다. 그리고 해당 대기열에는 자체 최적화가 있습니다. 대량 업데이트를 수행할 수 있고 복제할 수 있습니다. 따라서 write-behind에는 성능이 있으며, 말씀하신 속도 부분은 read-through보다 write-through 및 write-behind와 더 관련이 있습니다.
연속 읽기는 응용 프로그램이 액세스하는 것보다 어떤 경우에는 더 빠를 수도 있지만, 뒤에 쓰기에서는 확실히 항상 더 빠릅니다.
질문이 있으신가요? 이제 몇 분밖에 남지 않았어요. 기능 하나 더 이야기한 뒤 마지막으로 가겠습니다. 따라서 ASP.NET 캐시 개체와 같은 독립형 In-Proc 인 메모리 캐싱을 수행하는 데 익숙한 사람들이 분산 캐시로 이동할 때 많은 고객이 우리에게 전화를 걸어 캐시를 약속했다고 말합니다. 실제로 내 성능을 향상시킵니다. 실제로 내 성능이 저하되었습니다. 왜 그런 겁니까? 추측할 수 있는 사람 있나요? In-Proc 캐시가 아닌 분산 캐시로 이동하자마자 실제로 속도가 느려지는 이유는 무엇입니까? 네트워크 대기 시간. 네트워크 대기 시간은 XNUMX입니다. 더 큰 문제는 엄청난 비용이 드는 직렬화 및 역직렬화입니다.
클라이언트 캐시 또는 근거리 캐시
따라서 분산 캐시 중 일부가 수행하는 작업은 다음과 같습니다. NCache, 그들은 클라이언트 캐시, 일부는 캐시 근처라고 부릅니다. 이는 애플리케이션 서버 내에 보관되는 이 캐시의 하위 집합입니다. In-Proc일 수도 있고 OutProc일 수도 있습니다. 그러나 대부분의 경우 In-Proc입니다. 따라서 이와 동기화된다는 점을 제외하면 독립형 In-Proc 캐시와 동일한 이점을 제공합니다.
그리고 이것은 더 작은 하위 집합이므로 각 서버마다 16GB일 수도 있고 단지 XNUMXGB일 수도 있다고 가정해 보겠습니다. 그리고, 움직이는 창문이죠? 따라서 캐싱하는 모든 항목은 그대로 유지되며 계속 진행하면 이전 항목이 만료되거나 제거되고 새 데이터가 캐시됩니다.
따라서 클라이언트 캐시는 실제 성능을 제공합니다. 신청 프로세스 내에서 데이터를 객체 형태로 유지합니다. 따라서 수백 번, 수십 번 가져오는 경우에는 당연히 처음에는 분산 캐시에서 가져와야 합니다. 아마도 처음으로 데이터베이스에서 이를 가져올 것입니다. 분산 캐시로 이동한 다음 클라이언트 캐시로 이동하지만 일단 완료되면 모든 추가 읽기가 자체 힙 내에서 매우 빠르게 수행됩니다. 따라서 이것은 정말 강력한 기능입니다. 당신은 확실히 이것을 활용하고 싶습니다.
따라서 확인해야 할 몇 가지 사항이 있습니다. 데이터베이스와 마찬가지로 분산 캐시는 프로덕션 환경의 데이터 센터에서 실행됩니다. 따라서 일부 아키텍처 요구 사항을 충족해야 합니다. 가용성이 높아야 합니다. 데이터 신뢰성과 확장성을 제공해야 합니다. 따라서 지능적인 복제를 수행해야 합니다.
이에 대해서는 자세히 다루지 않겠습니다. 당신은 그것을 들여다 볼 수 있습니다. 온라인으로 조사를 할 수 있습니다. 예를 들어, 여러 데이터 센터가 있는 경우 데이터베이스가 복제될 것으로 예상하는데 캐시는 왜 안 될까요? 알잖아. 캐시를 여러 환경에서 동기화된 방식으로 사용할 수 있으면 안 되는 이유는 무엇입니까? 그렇습니다. 좋은 캐시는 그래야 합니다.
.NET 분산 캐싱 옵션
.NET 애플리케이션을 수행하는 경우 현재 캐싱에 사용할 수 있는 옵션은 거의 두 가지입니다. 하나는 Redis Microsoft가 Azure에 적용한 것입니다. 다른 하나는 NCache. 자바 쪽에서는 제가 말했듯이 꽤 좋은 선수들이 많아요.
그래서 저는 아주 높은 수준의 비교를 해보고 싶습니다.
NCache 가장 오래된 .NET 캐시입니다. 2005년부터 시장에 출시되었습니다. 기본 .NET입니다. 마찬가지로 오픈소스이기도 합니다. Redis. Azure 또는 Amazon 모두에서도 사용할 수 있습니다. Redis … 그래서 두 가지 버전이 있습니다. Redis, 에 의해 개발된 것 Redis Linux에서만 실행되는 Labs입니다. 실제로 Microsoft는 Azure에서 해당 버전을 사용합니다. 그리고 Microsoft가 Windows로 포팅한 버전은 자체적으로 사용하지도 않습니다. 실제로 우리는 고객으로부터 많은 불만을 들었습니다. 그다지 안정적이지는 않습니다. 그러나 Azure 외부에서 Windows용으로 사용할 수 있는 유일한 버전은 Microsoft가 포팅한 MS Open Tech 버전입니다. 하지만 그 외에 다른 곳으로 가면 Redis 그들은 당신에게 Linux 버전만을 제공할 것입니다. Azure 자체에는 두 가지 차이점이 있습니다. NCache 그리고 Azure는 바로 NCache 실제로 캐시 서버를 VM으로 제공합니다. 따라서 모든 서버측 코드를 직접 실행하고 모니터링할 수 있습니다. Redis 캐시를 서비스로 제공합니다. 그러니까 캐시는 블랙박스인 거죠. 호출하는 매우 간단한 API만 있습니다. 그리고 그 한계는 우리가 방금 이야기한 모든 기능을 얻을 수 없다는 것입니다. 데이터베이스 동기화는 어떻게 합니까? 연속 쓰기. 사실 저는 시간이 없었기 때문에 SQL 검색도 하지 않았습니다. 따라서 이를 수행할 수 있는 두 가지 방법이 있습니다. 이에 대해 더 자세히 알고 싶으시면 저희 웹사이트를 방문해 주세요. 자세한 비교 문서. 그래서 내가 들어가자면 Redis vs NCache 여기에서 본격적인 문서를 볼 수 있습니다. 다운로드할 수도 있습니다. 이는 해당 문서와 우리의 문서를 기반으로 한 기능별 비교이며 어느 것이 귀하의 요구 사항에 맞는지 확인할 수 있습니다. 질문이 있으신가요? 그게 내 얘기의 끝이야. 감사합니다.
의존성이 있습니까? .NET Core Framework 또는 .NET 4.0과 함께 사용할 수 있습니까? 좋은 질문. 그래서, NCache 서버 지원 .NET framework에스. 4.0 이상입니다. 그만큼 NCache 클라이언트는 기본적으로 .NET framework 물론. 우리는 곧 .NET을 출시할 예정입니다… 그래서 우리는 ASP를 지원합니다.NET Core. 그래서 .NET Core Linux에서 실행할 수 있는 기능은 제한이 있기 때문에 아직 지원하지 않습니다. 하지만 .NET Core ASP에서 실행되는.NET framework, Windows, 특히 ASP에서만 아래에 있습니다..NET Core NCache 그것을 지원할 것입니다. 정말 고마워요.