분산 캐시를 사용하여 Microsoft Azure에서 .NET 앱 확장
녹화된 웨비나
론 후세인
Microsoft Azure에서 .NET 앱의 확장성 병목 현상이 무엇이며 분산 캐싱으로 확장성을 향상할 수 있는 방법을 알아보세요.
이 웨비나는 다음 내용을 다룹니다.
- .NET 애플리케이션의 성능 병목 현상에 대한 간략한 개요
- 분산 캐싱이란 무엇이며 Azure에서 이것이 답인 이유는 무엇입니까?
- 애플리케이션의 어디에서 분산 캐싱을 사용할 수 있습니까?
- 분산 캐시의 몇 가지 중요한 기능은 무엇입니까?
- Azure에서 분산 캐시를 사용하는 몇 가지 실습 예제
가입해주셔서 대단히 감사합니다. 웨비나에 대해 빠르게 알려드리겠습니다. 우선 제 이름은 Ron Hussain입니다. 나는 기술 전문가 중 한 명입니다. Alachisoft 저는 오늘 웨비나의 발표자가 될 것입니다. 메모리 내 분산 캐싱 시스템을 사용하여 Microsoft Azure에서 .NET 응용 프로그램을 확장하는 데 필요한 모든 기술 세부 정보를 다루겠습니다. NCache 이에 대한 예시 제품으로. 이것이 분산 캐싱을 위한 우리의 주요 제품입니다. 우리는 자랑스러운 메이커입니다 NCache 예시 제품으로 사용하겠습니다. 이 웨비나의 더 많은 부분은 듣기 전용으로 진행됩니다. 즉, 제가 대부분의 이야기를 하게 되지만 언제든지 참여할 수 있습니다. 필요한 만큼 질문할 수 있습니다. 화면 오른쪽에 이 질문과 답변 탭이 있습니다. 질문 탭을 확장하면 필요한 만큼 질문을 게시할 수 있으며 내가 말했듯이 이 창에 게시할 모든 질문에 대한 답변을 드리겠습니다. 그러니 확인을 위해서라도 동일한 질문과 답변 탭을 이용하여 확인이 가능하다면 제 화면이 보이는지, 잘 들리는지 확인 부탁드립니다. 빠르게 시작할 수 있습니다. 괜찮아. 이미 게시 중인 몇 가지 질문을 볼 수 있습니다. 그럼 확인 정말 감사합니다.
시작하겠습니다. 안녕하세요 여러분, 제 이름은 Ron Hussain입니다. 저는 기술 전문가 중 한 명입니다. Alachisoft 저는 오늘 웨비나의 발표자가 될 것입니다. 오늘 선택한 주제는 메모리 내 분산 캐싱 시스템을 사용하여 Microsoft Azure에서 .NET 응용 프로그램을 확장하는 것입니다. ~에 Alachisoft 다양한 제품을 보유하고 있으며 가장 인기 있는 제품은 NCache.NET 및 Java 애플리케이션을 위한 메모리 내 분산 캐싱 시스템입니다. NCache 예제로 사용할 주요 제품이 될 것이지만 Microsoft Azure의 기본 사항에 충실하겠습니다. 사용하는 방법 NCache (A Distributed Caching System)을 Microsoft Azure에 설치하고 아키텍처에 대한 응용 프로그램 성능 및 전반적인 시스템 안정성 측면에서 확장성 측면에서 이를 활용합니다. 내 화면을 볼 수 있음을 확인했으므로 이 작업을 시작하겠습니다.
확장성이란 무엇입니까?
괜찮아! 실제 주제로 넘어가기 전에. 몇 가지 기본 개념에 대해 이야기하고 확장성이란 무엇인가부터 시작하겠습니다. 확장성은 애플리케이션의 트랜잭션 로드를 증가시키는 동시에 애플리케이션의 속도를 늦추지 않는 능력입니다. 예를 들어 이 시점에서 1,000개의 요청을 처리하는 경우 애플리케이션 로드가 더 많은 사용자 로그인을 증가시킨 다음 로드보다 더 많이 애플리케이션을 사용하기 시작하면 예를 들어 초당 1,000개에서 10,000개 요청으로 증가합니다. 이제 증가된 로드를 수용하고 증가된 로드를 처리하는 동시에 개별 요청 성능을 저하시키고 싶지 않습니다. 하나의 요청이 완료되기를 기다리고 있고 하나의 요청이 완료 과정에 있고 다른 요청이 이를 기다리고 있는 방식으로 발생해서는 안 됩니다. 이러한 요청은 이전에 소요되었던 시간과 정확히 동일한 시간에 처리되어야 합니다. 그러나 동시에 더 많은 요청을 처리할 수 있는 기능이 초당 10,000개 또는 초당 20,000개 요청을 로드할 수 있는 확장성을 원합니다. 따라서 성능을 잃지 않고 애플리케이션의 트랜잭션 로드를 늘릴 수 있는 능력이 있다면 이를 확장성이라고 합니다. 그리고 그것이 오늘 우리가 집중할 것입니다.
선형 확장성이란 무엇입니까?
무제한 확장성이라는 관련 용어가 있습니다. 선형 확장성입니다. 선형 확장성은 초당 읽기 및 쓰기 용량이 선형적으로 증가하는 것입니다. 예를 들어 더 많은 서버를 추가하는 경우입니다. 따라서 이제 하나의 서버를 추가했으므로 읽기 및 쓰기 작업에 대한 요청을 처리하는 특정 기능을 갖게 되었습니다. 다른 서버를 추가한 다음 더 많은 서버를 추가하면 어떻게 될까요? 더 많은 서버를 추가할 수 있는 기능과 더 많은 서버를 추가하면 확장성 수치가 증가하고 애플리케이션 아키텍처에 따라 점점 더 많은 용량 핸들을 얻을 수 있습니다. 이를 선형 확장성이라고 합니다.
어떤 애플리케이션에 확장성이 필요합니까?
지금! 다음 질문은 어떤 종류의 애플리케이션에 확장성이 필요한가 하는 것입니다. 대답은 매우 간단합니다. 사용자의 수백만 건의 요청을 처리해야 하는 모든 애플리케이션. 거대한 트랜잭션 부하를 처리하는 경우. 일반적으로 ASP.NET 응용 프로그램이 있습니다. 예를 들어 전자 상거래 응용 프로그램, 항공 예약 응용 프로그램과 같은 프론트 엔드가 있는 경우 공개 대상이지만 트래픽이 많은 모든 것이 해당 응용 프로그램이 확장성의 주요 후보입니다.
그런 다음 .NET 웹 서비스 및 서비스 지향 아키텍처용 WCF를 사용할 수 있습니다. 다시 들어가거나 프론트 엔드 웹 서비스가 될 수 있으며 웹 응용 프로그램이나 보유하고 있는 내부 응용 프로그램에서 소비할 수 있습니다. 이들은 엄청난 양의 요청을 처리해야 할 수 있으며, 엄청난 양의 데이터를 가져와 호출자 프로그램에 전달해야 합니다. 따라서 이러한 종류의 응용 프로그램에도 확장성이 필요합니다. 그런 다음 요청 로드의 양을 처리할 수 있는 일종의 인프라를 배치할 수 있습니다.
그런 다음 빅 데이터 응용 프로그램이 있습니다. 요즘 유행하는 유행어입니다. 많은 애플리케이션, 많은 아키텍처가 이를 향해 이동하고 있습니다. 다른 모듈, 다른 프로세스에 배포하기 위해 엄청난 양의 데이터를 처리해야 할 수 있지만 결국에는 많은 데이터를 처리해야 합니다. 이를 처리하기 위해 요청합니다.
그리고 우리는 여러 대의 저렴한 서버에 배포하여 엄청난 양의 계산을 처리해야 하는 훌륭한 컴퓨팅 응용 프로그램을 가지고 있습니다. 바로 응용 프로그램입니다. 따라서 일반적으로 사용자나 백 엔드 프로그램의 백만 요청을 처리해야 할 수 있는 해당 문제에 대한 모든 .NET 응용 프로그램 또는 Java 응용 프로그램은 아키텍처에서 확장성이 필요한 주요 후보입니다.
그리고 이 중 일부에 한 번 집중하고 사용 사례도 계속 진행합니다. 그리고 여러분, 우리는 이 웨비나의 시작에 불과합니다. 방금 가입한 여러분을 위해 분산 캐싱의 관점에서 몇 가지 기본 개념을 다룰 것입니다. 직면하게 될 다양한 문제와 솔루션에 대해 이야기하고 다음과 같은 분산 캐시 배포에 대해서도 이야기하겠습니다. NCache 마이크로소프트 애저에서. 따라서 질문이 있는 경우 질문 및 답변 탭에 자유롭게 입력하십시오. 그리고 항상 저에게 피드백을 줄 수 있습니다. 참여를 원하시면 같은 질의응답 탭을 다시 이용하시면 됩니다.
확장성 문제란 무엇입니까?
이제 다음으로, 일단 우리가 가지고 있다고 정의하면 확장성이란 무엇입니까? 선형 확장성이란 무엇이며 어떤 종류의 애플리케이션에 확장성이 필요합니까? 이 웨비나의 다음이자 가장 중요한 점은 어떤 종류의 애플리케이션 또는 어떤 종류의 확장성 문제가 귀하의 애플리케이션에 직면하게 될까요? 확장성 문제는 정확히 어디에 있습니까?
이제 응용 프로그램 아키텍처는 ASP.NET 응용 프로그램 또는 WCF 서비스일 수 있습니다. 이러한 확장은 매우 훌륭하고 이미 선형적으로 확장됩니다. 로드 밸런서를 앞에 놓고 앱 서버 또는 웹 서버, 웹 프런트 엔드 서버를 더 많이 추가하기만 하면 이미 아키텍처에서 선형 확장성을 얻을 수 있습니다. 그래서 거기에는 문제가 없습니다. 데이터 스토리지, 이러한 애플리케이션 서버 또는 웹 서버와 관련된 실제 문제는 항상 데이터베이스 상태 서비스와 같은 일부 백엔드 데이터 소스와 통신하거나 해당 문제에 대한 백엔드 파일 시스템 또는 레거시 데이터 소스일 수 있습니다. . 엄청난 트랜잭션 로드를 처리할 수 없으며 여기에 더 많은 서버를 추가할 수 없습니다. 그리고 이 도표는 이것을 잘 설명하고 있습니다.
데이터 스토리지가 있는 곳에 확장성 병목 현상이 있습니다. 여기에 ASP.NET WCF 예제가 있지만 원하는 만큼 서버를 추가할 수 있습니다. 두 대의 서버로 시작하여 로드가 증가하면 다른 서버를 추가하고 로드 밸런서를 앞에 놓고 모든 서버를 고르게 사용할 수 있습니다. 이 레이어의 리소스. 따라서 문제가 없습니다. 그러나 이러한 애플리케이션 상자 또는 웹 프런트 엔드 서버는 항상 일부 백엔드 데이터 소스와 통신합니다. 그리고 이것은 시작하기에 그리 빠르지 않은 데이터베이스 서버가 있고 확장성 문제가 있는 일반적인 배포입니다. 그들은 엄청난 트랜잭션 부하로 질식하고 어떤 경우에는 단일 실패 지점이기도 합니다. 그러나 가장 중요한 것은 모든 애플리케이션 아키텍처에서 이러한 데이터베이스 서버는 매우 심각한 위협을 내포하고 있으며 이것이 바로 확장성 병목 현상입니다. 따라서 모든 요청을 일부 데이터베이스 서버로 다시 대상으로 지정하면 이 계층에서 달성한 모든 확장성을 잃게 됩니다. ASP.NET 세션 상태도 마찬가지입니다. SQL Server 또는 세션 상태 서버를 사용하는 경우 그 이상을 유지하기 때문입니다. 항상 모든 세션 데이터를 호스팅하는 단일 서버가 될 것이며 세션은 매우 트랜잭션적인 종류의 데이터이므로 이러한 요청을 처리하려면 확장 가능한 데이터 소스가 필요합니다. 그래서 이것이 우리가 분산 캐싱 시스템의 도움으로 해결하려고 하는 주요 과제입니다.
솔루션: 인메모리 분산 캐시
솔루션은 제가 말했듯이 매우 간단합니다. 확장 가능한 인메모리 분산 캐싱 시스템을 사용할 수 있습니다. 와 같은 NCache 확장성과 관련하여 데이터 소스와 관련하여 방금 이야기한 모든 문제를 처리합니다.
다음으로, 다음과 같은 메모리 내 분산 캐싱 시스템의 몇 가지 기본 사항에 대해 빠르게 설명하겠습니다. NCache. 다음에서 찾을 수 있는 몇 가지 중요한 특성이 있습니다. NCache 그리고 이것이 사용 가능한 대부분의 인메모리 분산 캐싱 시스템의 일부가 될 것으로 예상합니다. 따라서 이와 관련하여 NCache 정의해야 한다면 메모리 내 캐싱 시스템은 무엇입니까?
동적 클러스터링
여러 대의 저렴한 캐시 서버로 구성된 클러스터로, 함께 결합되어 메모리와 CPU 용량을 끌어올 수 있습니다. 따라서 그들은 하나의 용량으로 함께 결합되고 CPU 리소스뿐만 아니라 메모리도 가져옵니다. 따라서 물리적으로 여러 서버가 될 수 있습니다. 웹, 간단한 웹 서버 구성 상자에서 수행할 수 있는 것처럼 그렇게 비싸지 않습니다. 캐싱에 사용할 수 있는 것입니다. 그런 다음 해당 서버가 함께 결합되고 형식적인 논리적 용량이 됩니다. 따라서 애플리케이션의 관점에서 보면 하나의 분산 캐시를 사용하고 있지만 물리적으로는 여러 서버가 뒤에서 작동하여 이 인메모리 분산 캐시를 만들기 위해 모든 계산 능력과 메모리를 끌어올릴 수 있습니다. 따라서 이것이 이 단일 서버가 아니라는 첫 번째이자 가장 중요한 특성입니다. 여러 서버가 서로 결합하여 작동합니다. 따라서 우리는 이미 모든 데이터를 호스팅하고 모든 요청을 처리하는 하나의 서버만 있으면 되는 데이터베이스보다 앞서 있습니다.
데이터 일관성
다음 특징은 우리가 배후에서 여러 서버를 다루고 있기 때문에 데이터 일관성에 관한 것입니다. 다음 질문은 업데이트를 처리하는 방법입니다. 예를 들어, 동일한 데이터가 하나 또는 두 개의 서버에서 업데이트되거나 복제본이 있거나 다른 서버에 데이터 복사본이 여러 개 있는 경우 업데이트됩니다. 따라서 사용하는 토폴로지에 관계없이 데이터는 일관된 방식으로 업데이트되어야 합니다. 따라서 캐시 서버에서 무엇이든 업데이트하면 분산 캐시의 모든 캐시 서버에서 모든 업데이트를 볼 수 있어야 합니다. 그건 그렇고, 저는 가시적인 것을 사용하고 있습니다. 저는 복제라는 용어를 사용하지 않습니다. 복제는 또 다른 기능입니다. 따라서 가시적이라는 것은 예를 들어 서버 XNUMX에서 요청 핸들을 얻고 해당 데이터가 업데이트됨을 의미합니다. 다음 요청이 XNUMX번 서버로 가는 경우, XNUMX번 서버에도 동일한 데이터가 있었다면 분산 캐시에서 stale 값이 아닌 업데이트된 값을 가져와야 합니다.
따라서 이것은 모든 데이터 업데이트가 모든 캐싱 서버에 일관되게 적용되어야 하는 분산 캐시 측면에서 매우 중요한 특성입니다. 그리고 이것은 애플리케이션이 아니라 분산 캐시의 책임이어야 합니다. 아키텍처는 이 모델을 지원해야 합니다.
선형 확장 성
오늘 우리의 주제와 일치하는 다음 것은 선형적으로 확장하는 방법입니다. 따라서 분산 캐시는 트랜잭션 및 메모리 용량에 대해 선형적으로 확장되어야 합니다. 더 많은 캐싱 서버를 추가할 수 있고 더 많은 캐싱 서버가 있으면 선형 확장성을 얻을 수 있습니다. 앞서 그래프를 보여드린 적이 있습니다. 그래서 제가 여기에서 언급하는 것은 서버를 점점 더 추가하면 처리할 수 있는 요청자 수와 동시에 처리할 수 있는 데이터 수, 데이터 수를 늘려야 합니다. 선형으로 캐시를 분산합니다. 따라서 이는 분산 캐시에서 선형 확장성을 제공하고 전체 애플리케이션 아키텍처를 매우 확장 가능하게 만드는 매우 중요한 특성입니다.
신뢰성을 위한 데이터 복제
네 번째 중요한 특성. 이것은 옵션 XNUMX이며 복제도 지원하는 토폴로지를 선택할 수 있습니다. 안정성을 위해 서버 간에 데이터를 복제하는 분산 캐시가 있습니다. 서버가 다운되거나 유지 관리를 위해 오프라인으로 전환해야 하는 경우 데이터 손실이나 애플리케이션 다운에 대해 걱정할 필요가 없습니다. 따라서 이것이 분산 캐시의 몇 가지 중요한 특성입니다. 다음 슬라이드에서 이에 대해 점점 더 자세히 설명하고 Azure 관련 분산 캐시 배포에 대해서도 설명하겠습니다. Microsoft Azure에서 분산 캐시를 사용하는 방법은 무엇입니까? 지금까지 질문이 있으면 알려주세요. 질의응답 탭을 이용해주세요. 나는 일반적으로 손을 든 사람들을 봅니다. 회의에 참석할 때 이 문제가 있습니다. 여기에서 많은 손을 들지만 실제로 질문이 있는 경우 알려주세요. 질문 및 답변 탭에 입력해 주시면 기꺼이 답변해 드리겠습니다. 계속해야 한다고 생각합니다.
다음은 분산 캐시의 일반적인 배포입니다. 이것은 일반 배포이며 Microsoft Azure에만 국한되지 않습니다.
NCache Microsoft Azure에서 배포
배포로 이동하겠습니다. NCache 이 직후 Microsoft Azure에서. 따라서 일반적으로 온프레미스일 수도 있고 클라우드일 수도 있습니다. NCache 간다. 일반적으로 배포하는 방법입니다. NCache, 캐싱의 전용 레이어가 있는 곳입니다.
이들은 온프레미스의 물리적 상자일 수도 있고 호스팅된 상자 VM일 수도 있고 실제 클라우드 VM일 수도 있습니다. 별도의 전용 캐싱 상자에 캐시를 공식화할 수 있습니다. 권장되는 것입니다. 선호하는 플랫폼은 64비트이며 NCache .NET 4.0입니다. 그런 다음 애플리케이션은 온프레미스이거나 호스팅될 수도 있습니다. IIS의 서버에 직접 배포하거나 Microsoft Azure와 관련하여 웹 또는 작업자 역할이 될 수 있습니다. 그들은 모두 데이터 요구 사항을 위해 이 캐싱 계층에 연결할 수 있습니다. 이들에 대해 별도의 설치를 가지거나 이들에 대해 별도의 레이어를 가질 수 있습니다. 또는 동일한 레이어에 모든 것이 있을 수도 있습니다. 두 모델 모두 지원됩니다. 하지만 일단 소개하면 NCache 개체 캐싱 또는 세션 캐싱을 위해 배포된 후에는 응용 프로그램 아키텍처에 NCache 유스 케이스로 이동하면 유스 케이스.
사용을 시작하면 NCache, 그것은 뒤와 데이터베이스를 통해 비싼 여행을 저장합니다. 그런 다음 원하는 만큼 서버를 추가하고 확장할 수 있는 매우 확장 가능한 플랫폼을 제공합니다. 이제 이것을 앞서 보여드린 도표와 비교해 보십시오.
확장 가능한 플랫폼이 바로 여기에 있었지만 이것이 주요 경합의 원인이었습니다. 확장성 병목 현상의 주요 원인입니다. 이제 이것을 비교하면 애플리케이션 계층과 데이터베이스 사이에 매우 확장 가능한 플랫폼이 있습니다. 이것은 매우 확장 가능한 플랫폼이며 이제 다시 매우 확장 가능한 분산 캐시 측면에서 데이터 소스를 갖게 되었습니다. 원하는 만큼 서버를 추가할 수 있습니다. 부하가 증가하는 경우 백엔드 데이터 소스가 그 때 질식되는 것에 대해 걱정할 필요가 없습니다. 원하는 만큼 서버를 추가할 수 있으며 요청 처리 용량을 선형적으로 확장할 수 있습니다. NCache. 배포 아키텍처에 대한 질문이 있으면 알려주십시오. NCache 그러나 전반적으로 매우 간단합니다.
이제 다음은 배포 방법입니다. NCache 마이크로소프트 애저에서. 그래서 저는 저희 웹사이트를 이용하겠습니다. 나는 거기에서 다이어그램을 사용할 것입니다. 그러니 양해해 주십시오. Microsoft Azure에서의 배포는 온프레미스에서 배포하는 것과 크게 다르지 않습니다.
따라서 우선 동일한 Microsoft Azure 가상 네트워크에 모든 것이 있는 기본 배포인 것이 좋습니다. 예를 들어 가상 네트워크를 만든 다음 Microsoft Azure 가상 머신이 있는 경우 서버 측 배포는 항상 VM에서 이루어집니다. 그래서 우리가 선택한 모델은 NCache 마이크로소프트 애저에서. VM을 만들거나 동일한 가상 네트워크를 선택하여 모든 VM 배포를 만듭니다. 예를 들어 여기에 표시된 대로 XNUMX개의 VMS로 시작한 다음 필요에 따라 이 캐싱 계층에 VM을 추가할 수 있습니다. 또한 애플리케이션이 동일한 Azure 가상 네트워크에 있기를 원합니다. 따라서 대부분의 성능과 안정성 이점을 얻을 수 있는 동일한 가상 네트워크의 일부가 모든 것이 될 수 있습니다. NCache. 이에 대한 엄격한 요구 사항이 없으면 항상 다른 VM에 애플리케이션을 배포할 수 있습니다.
따라서 이 모델을 기반으로 하는 애플리케이션 아키텍처는 VM 자체에 있을 수 있습니다. 즉, 애플리케이션을 직접 관리하는 IIS에 직접 배포할 수 있고, 그런 다음 전체 책임을 맡거나 본인이 Azure 웹 역할 또는 작업자 역할이 될 수 있습니다. 모델은 애플리케이션 측에서 지원되지만 NCache 서버 측 배포는 항상 VM에 있습니다. 그럼 이렇게 신청하시면 됩니다 NCache 실습 부분으로 넘어가면 실제로 보여드리겠습니다.
또 다른 종류의 배포는 사용자에 대해 하나의 특정 Azure 가상 네트워크를 가질 수 있다는 것입니다. NCache 모든 서버가 동일한 가상 네트워크의 일부인 서버 VM. 동일한 서브넷도 가능합니다. 그리고 애플리케이션이 별도의 가상 네트워크에 있을 수도 있습니다. 그런 경우에는 어떤 종류의 포트가 서버에 전달되어야 합니다. NCache 가상 네트워크. 예를 들어 개인 포트는 여기에서 공용 포트에 매핑되고 애플리케이션은 이 공용 포트를 사용하여 실제로 연결됩니다. NCache. 여기에서 추가 구성을 수행해야 할 수도 있지만 이에 대한 자세한 도움말 문서가 있지만 문제 없이 작동합니다. 이 가상 네트워크 서버가 다른 가상 네트워크의 캐싱 서버에 액세스하도록 할 수 있습니다. 또한 동일한 기능을 사용하여 캐시 간 응용 프로그램을 사용할 수도 있습니다.
따라서 이것은 또 다른 종류의 배포이지만 선호되는 접근 방식인 권장 접근 방식은 모든 캐시 서버와 애플리케이션 서버를 동일한 Microsoft Azure 가상 네트워크에 배포하는 것입니다. 가장 많은 혜택을 받을 때입니다. NCache. 질문이 있으면 알려주세요.
지원을 받을 수 있는 경우 웹 사이트에도 Azure 배포 가이드가 있습니다. 사실, 여기 문서로 이동하겠습니다. 설명서에는 이러한 모든 세부 사항을 매우 자세하게 다루는 배포 가이드인 특정 가이드가 있습니다.
괜찮아. 질문이 있습니다. 어때 NCache 다른 Redis? 괜찮아. 오늘의 일정은 NCache 또는 Microsoft Azure에서 분산 캐싱 시스템을 사용합니다. 에 대한 별도의 웹 세미나가 있습니다. Redis 대 NCache. 에서 사용할 수 있는 다양한 기능에 대해 이야기하는 곳 NCache 일부가 아닌 Redis. 이에 대한 빠른 답변을 얻으려면 바로 여기에서 비교 페이지로 이동한 다음 Redis 대 NCache. 빠르게 회원가입을 하시면 모든 기능, 기능별 기능 비교를 보실 수 있습니다. NCache 대 Redis. 그리고 사실, 우리는 이를 위한 웹 세미나도 있습니다. 이것은 우리 YouTube 채널의 웹 세미나입니다. 따라서 YouTube에 로그인하기만 하면 Alachisoft 그리고 나서 Alachisoft 많은 비디오가 있을 것이고 그 중 하나는 Redis 소스 NCache 제목. 이에 대한 별도의 웹 세미나가 있습니다. 이것이 귀하의 질문에 대한 답변이 되기를 바랍니다. 이에 대한 질문이 더 있습니다. 괜찮아. 다시 돌아와서 배포에 대해 다루었으므로 배포 관련 질문이 있는 경우 알려주시면 기꺼이 해당 질문에 답변해 드리겠습니다.
분산 캐시의 일반적인 사용
다음은 분산 캐시를 사용하는 방법입니다. 다음과 같은 분산 캐싱 시스템을 사용하는 공통 영역은 무엇입니까? NCache? 나는 가장 일반적인 것 중 세 가지를 나열했지만 이것은 산업에 따라 다를 수 있으며 요구 사항, 사용 사례에 따라 다를 수 있습니다. NCache. 그러나 주로 이러한 세 가지 범주로 나뉩니다.
애플리케이션 데이터 캐싱
첫 번째 범주는 애플리케이션 데이터 캐싱입니다. 다음과 같은 분산 캐싱 시스템을 사용할 수 있습니다. NCache 응용 프로그램 데이터 캐싱으로. 이전에 데이터베이스에 있었고 애플리케이션이 데이터베이스로 이동했던 모든 항목을 이제 NCache. 그리고 이전에 데이터베이스에 있던 모든 데이터에 액세스하기 위해 데이터베이스에 비해 더 빠른 인메모리 캐시를 얻을 수 있습니다. 따라서 애플리케이션 성능을 개선한 다음 가장 중요한 것은 데이터베이스가 그렇게 하지 못하는 부분을 선형적으로 확장한다는 것입니다. 극적인 수준으로 확장할 수 있습니다. 엄청난 양의 트랜잭션 로드를 처리할 수 있으며 원하는 만큼 서버를 추가할 수 있습니다. 그리고 여기에는 NCache API. 키-값 쌍에 데이터를 추가하기만 하면 됩니다. 키는 문자열이고 값은 .NET 허용 개체입니다. 도메인 개체, 컬렉션, 데이터 세트, 이미지를 캐시할 수 있으며 모든 종류의 응용 프로그램 관련 데이터는 개체 캐싱 모델을 사용하여 캐시할 수 있습니다. 그러면 데이터 캐싱 측면에서 제공하는 기능 측면에서 몇 가지 큰 이점을 얻을 수 있습니다.
ASP.NET 특정 데이터를 위한 안정적이고 확장 가능한 캐시
다음 사용 사례는 ASP.NET 특정 응용 프로그램에 관한 것입니다. 예를 들어 ASP.NET을 시작하는 매우 쉬운 방법이 있습니다. NCache. 여기에 세 가지 옵션이 있습니다.
ASP.NET 세션 저장소
ASP.NET 세션 상태 저장소가 있습니다. MVC 또는 ASP.NET 웹 양식에서 사용할 수 있으며 모든 ASP.NET 웹 응용 프로그램에서 이를 사용할 수 있습니다. 코드를 변경하지 않고도 세션 데이터를 분산 캐시에 저장할 수 있습니다. 그리고 데이터베이스나 상태 서버와 달리 단일 서버가 아닙니다. 여러 서버를 가질 수 있습니다. 따라서 매우 확장 가능하고 서버 간에 복제된 세션 데이터가 있고 메모리에 있기 때문에 매우 우수한 성능을 얻을 수 있기 때문에 매우 안정적입니다. 그리고 코드 변경 없이 모든 것이 변경됩니다. 그리고 NCache, 다중 사이트 세션 배포도 있습니다. 두 개의 데이터 센터를 가질 수 있으며 코드 변경 없이 세션을 동기화할 수 있습니다. 따라서 사용할 수 있는 몇 가지 확장 기능입니다. ASP.NET 응용 프로그램에 대한 세션 상태 지원 외이며 코드 변경이 필요하지 않습니다.
ASP.NET View State 캐싱
이에 대한 다음 기능은 ASP.NET view state, 코드 변경 옵션도 없습니다. 알고 싶은 분들을 위해 뷰 상태는 무엇입니까? 보기 상태는 클라이언트 측 상태 관리입니다. 예를 들어 보기 상태가 웹 양식에만 적용되는 경우 MVC 아키텍처에는 더 이상 상태가 없습니다. ASP.NET 웹 양식의 경우 모든 컨트롤은 페이지에 있는 모든 버튼 또는 모든 위젯, 보기 상태 생성에 기여합니다. 이는 응답과 관련하여 브라우저로 다시 전송되며 보기 상태는 다음과 같이 결합됩니다. 응답 패킷을 보낸 다음 브라우저로 다시 보냅니다. 브라우저 측에서는 실제로 사용되지 않습니다. 그것은 단지 거기에 머물고 뷰 상태를 다시 게시하면 서버의 요청 패킷과 함께 제공되며 실제로 뷰 상태를 사용할 때입니다. 따라서 항상 응답의 일부로 브라우저로 다시 전송되고 요청의 일부로 서버로 다시 보내지기 때문에 요청 및 응답 패킷이 더 무거워집니다. 브라우저 측에서는 실제로 사용되지 않습니다. 항상 서버 측에서 사용됩니다. 특히 트랜잭션 부하가 큰 경우 많은 대역폭을 소모합니다.
따라서 성능 및 대역폭 사용 측면에서 많은 문제가 있습니다. 와 함께 NCache 보기 상태를 서버 측에 저장할 수 있고 서버 측에 유지할 수 있습니다. NCache, 작은 더미 토큰을 브라우저로 다시 보냅니다. 따라서 보기 상태의 크기가 작아지고 대역폭 활용 비용이 향상됩니다. 많은 대역폭을 절약할 수 있습니다. 그리고 동시에 더 작은 패킷은 더 쉽게 처리할 수 있습니다. 요청 및 응답 패키지가 작아지면 애플리케이션 성능 향상에도 기여합니다. 따라서 당사의 사용을 시작하면 성능이 향상되고 대역폭 활용 비용이 절감됩니다. ASP.NET view state 공급자. 그리고 이것은 또한 코드 변경 없음 옵션입니다. NCache. 그리고 Microsoft Azure에서 매우 쉽게 사용할 수 있습니다.
ASP.NET 출력 캐싱
여기서 세 번째 중요한 기능은 ASP.NET MVC 및 웹 팜용 ASP.NET 출력 캐싱 공급자입니다. 서로 다른 요청에 대해 XNUMX개의 서로 다른 페이지에 상당히 정적인 콘텐츠가 있는 경우 해당 요청에 대한 응답으로 동일한 데이터를 얻더라도 해당 요청을 모두 다시 렌더링하고 다시 실행하는 대신 캐시하고 이를 캐시하는 것이 좋습니다. 그런 다음 후속 요청에 대해 캐시된 출력을 사용합니다. 동일한 요청을 다시 받으면 드릴을 거치지 않고 캐시 콘텐츠를 가져오기만 하면 됩니다. NCache 곧장. 따라서 전체 ASP.NET 페이지 출력을 다음 위치에 저장할 수 있습니다. NCache 후속 요청에 사용됩니다. 그리고 이것은 또한 우리의 ASP.NET 출력 캐시 공급자의 도움으로 많은 처리 능력, 많은 실행 시간, 많은 성능 이점을 얻을 수 있기 때문에 코드 변경이 없습니다.
따라서 빠르게 시작할 수 있는 이 세 가지 중요한 측면이 있습니다. 이들은 모두 코드 변경이 없는 옵션입니다. 설정하는 데 10-15분이 소요될 수 있으며, 그러면 방금 논의한 모든 이점을 볼 수 있습니다. 그리고 Microsoft Azure에는 실제로 이를 대체할 수 있는 것이 없습니다. 기본 옵션을 사용하면 결국 이 데이터베이스의 프로세서에 있는 모든 것을 유지하게 됩니다. 그리고 우리는 이미 그것들과 관련된 문제에 대해 이야기했습니다. 따라서 이러한 기능을 먼저 살펴보고 사용 사례가 진행되면 애플리케이션 데이터 캐싱을 함께 사용할 수 있도록 적극 권장합니다. 세 번째 중요한 사용 사례 NCache, 저는 여러분의 애플리케이션 아키텍처에서 분산 캐시를 사용하는 것의 중요성을 전달할 수 있도록 이것에 많은 시간을 할애하고 있습니다. 지금까지 이 시점에서 질문이 있으면 알려주십시오.
메시징을 통한 확장 가능한 런타임 데이터 공유
이제 세 번째 중요한 사용 사례 NCache 메시징 지원을 통해 런타임 데이터 공유 플랫폼을 위해 확장 가능하고 매우 안정적이며 확장 가능한 방식으로 사용할 수 있다는 것입니다. MSN 대기열 및 Java 메시징 서비스와 유사합니다. 메시징 플랫폼도 있습니다. 이미 캐시에 데이터가 있기 때문입니다. 예를 들어, 일부 데이터가 추가되고, 일부 제품 카탈로그가 있고, 제품이 캐시에서 추가, 업데이트 또는 제거되고, 전파한 다음 통지할 수 있는 이벤트 통지 전파 시스템을 가질 수 있다는 것을 기반으로 통지를 받고 싶습니다. 캐시에서 데이터가 변경되는 경우 사용합니다. 따라서 필요에 따라 연결하여 해당 메시지를 사용할 수 있는 데이터 수준 메시지가 있으며, 메시징 플랫폼의 도움으로 한 응용 프로그램이 다른 응용 프로그램과 통신할 수 있는 일부 사용자 지정 응용 프로그램 메시지도 있을 수 있습니다. 따라서 한 응용 프로그램이 다른 응용 프로그램과 데이터를 공유할 수 있고 동일한 분산 캐싱 시스템을 사용하는 다른 응용 프로그램 간에 메시지를 공유할 수 있기 때문에 매우 강력한 데이터 공유입니다. 따라서 이것은 매우 강력한 기능입니다. 많은 사람들이 알지 못하지만 제공하는 기능 면에서는 매우 강력합니다.
질문이 있음을 알려주세요. 다음은 몇 가지 중요한 사용 사례입니다. NCache, 내가 빠르게 다룰 것입니다. Microsoft Azure에서 분산 캐시를 사용할 계획이라면 매우 중요한 개념이 있습니다. 매우 중요한 장면을 만들어야 합니다.
캐시할 데이터는 무엇입니까?
어떤 종류의 데이터를 캐시해야 합니까? 이제 분산 캐시는 일반적으로 가장 쉽게 액세스할 수 있는 데이터를 위한 것입니다. 더 많은 읽기 및 쓰기가 있고 이후 요청을 위해 해당 데이터를 계속해서 읽습니다. 데이터를 두 가지 범주로 분류했습니다. 일반적으로 데이터베이스에 존재하는 영구 데이터를 가질 수 있습니다. 변경될 수 있지만 변경 빈도가 그리 크지 않기 때문에 참조 데이터와 트랜잭션 데이터로 더 나누었습니다. 하지만 영구 데이터가 있고 임시 데이터가 있습니다. 영구 데이터는 데이터베이스에 실제로 존재하며 이를 캐시하는 것이 매우 중요합니다. 따라서 백엔드 데이터베이스에 대한 값비싼 여행을 줄일 수 있습니다.
그리고 우리는 임시 데이터인 임시 데이터를 가지고 있으며, 현재 사용자의 범위에 대해서만 유효하거나 해당 문제에 대한 현재 적용 주기의 범위에 대해서만 유효할 수 있습니다. 사용자 구성, 사용자 설정, 사용자 ASP.NET 세션, 보기 상태 출력 캐싱이 될 수 있습니다. 일반적으로 데이터베이스에 속하지 않지만 얼마나 빨리 필요한지, 캐시한 후 필요한 횟수에 따라 캐시에 보관하는 것이 합리적입니다. 그런 다음 이 데이터를 다른 범주로 더 나눌 수 있습니다. 예를 들어 데이터가 대부분 읽기인 경우 쓰기보다 읽기가 더 많거나 읽기 또는 쓰기 수가 동일합니다. 따라서 참조는 쓰기보다 읽기이며 트랜잭션은 쓰기뿐만 아니라 읽기입니다.
그리고 우리는 임시 데이터인 임시 데이터를 가지고 있으며, 현재 사용자의 범위에 대해서만 유효하거나 해당 문제에 대한 현재 적용 주기의 범위에 대해서만 유효할 수 있습니다. 사용자 구성, 사용자 설정, 사용자 ASP.NET 세션, 보기 상태 출력 캐싱이 될 수 있습니다. 일반적으로 데이터베이스에 속하지 않지만 얼마나 빨리 필요한지, 캐시한 후 필요한 횟수에 따라 캐시에 보관하는 것이 합리적입니다. 그런 다음 이 데이터를 다른 범주로 더 나눌 수 있습니다. 예를 들어 데이터가 대부분 읽기인 경우 쓰기보다 읽기가 더 많거나 읽기 또는 쓰기 수가 동일합니다. 따라서 참조는 쓰기보다 읽기이며 트랜잭션은 쓰기뿐만 아니라 읽기입니다. 따라서 모든 참조 데이터를 캐싱하는 것을 고려할 수 있습니다. 이는 일반적으로 데이터베이스에 속하는 영구 데이터입니다. 분산 캐시로 가져오고 가능한 한 많이 캐시하여 데이터베이스로 돌아가지 않도록 하십시오. 그리고 이를 통해 필요한 대부분의 성능 이점을 얻을 수 있습니다. 그런 다음 ASP.NET 세션 상태, 보기 상태 및 출력 캐싱과 같은 일부 트랜잭션 데이터를 캐싱하는 것을 고려해야 합니다. 백엔드 데이터 원본에서 이 임시 데이터 또는 트랜잭션 데이터를 가져올 때 성능이 저하되지 않기 때문입니다. . 사용자 수에 따라 수백만 명의 사용자가 로그인한 경우 사용자당 두 번 데이터베이스로 이동하는 시나리오를 생각하면 느린 소스에서 해당 데이터를 가져오는 데 얼마나 많은 시간을 소비하는지 알 수 있습니다. , 백엔드 데이터 소스에서. 캐시에서 가져오기를 위해서는 분산 캐시에서 캐시를 고려해야 합니다.
캐싱 API 개요
이것이 캐싱의 모습입니다. Interface와 같은 해시 테이블입니다. 문자열 기반 키가 있고 그 값으로 객체가 있습니다. 개체는 모든 .NET 매개 변수 개체가 될 수 있습니다. .NET에서 허용하는 모든 것을 개체 캐시로 저장할 수 있습니다. 반면에 문자열 키는 의미 있는 키 구성을 생각해낼 수 있습니다. 예를 들어 사원 ID가 1000인 모든 직원, 사원 ID가 1000인 사원을 바로 여기에 이 키로 저장할 수 있습니다. 해당 직원의 모든 주문은 이 키를 가질 수 있습니다. 여기서 직원 주문과 해당 직원의 ID가 있습니다. 런타임 매개변수도 있을 수 있습니다. 그런 다음 직원 쿼리를 가질 수 있습니다. 예를 들어 담당 쿼리를 캐시하고 인수는 관리자와 같은 직함을 기반으로 직원 코드를 찾는 것이었습니다. 따라서 캐시에 단일 개체로 저장된 컬렉션을 얻을 수 있습니다. 따라서 이것은 캐시 키를 공식화할 수 있는 방법의 한 예일 뿐이지만 필요에 따라 모든 키 기반 기술을 생각해낼 수 있습니다. 이것은 단지 예일 뿐이며 귀하의 애플리케이션에 더 적합한 것을 사용하십시오.
여러분, 질문이 있으면 알려주세요. 오늘은 질문이 많이 안 보이네요. 지금까지 질문이 있으면 알려주세요. 또한 특정 부분에서 너무 느리거나 너무 빨리 진행하는 경우 속도를 유지할 수 있도록 알려주세요. 동일한 질문 답변 탭을 사용하여 피드백을 제공할 수도 있습니다. 그러면 특정 기능에 대해서도 더 많은 시간을 할애할 것입니다.
여러분, 질문이 있으면 알려주세요. 오늘은 질문이 많이 안 보이네요. 지금까지 질문이 있으면 알려주세요. 또한 특정 부분에서 너무 느리거나 너무 빨리 진행하는 경우 속도를 유지할 수 있도록 알려주세요. 동일한 질문 답변 탭을 사용하여 피드백을 제공할 수도 있습니다. 그러면 특정 기능에 대해서도 더 많은 시간을 할애할 것입니다. 괜찮아. 질문이 있습니다. 공간 데이터는 어떻습니까? 괜찮아. 그런 종류의 데이터도 쿼리할 수 있습니까? 예. 확실히, 우리는 매우 강력한 쿼리 지원을 가지고 있으며 이 개체는 모든 유형이 될 수 있습니다. 따라서 여기에는 캐싱을 계획할 모든 종류의 데이터가 포함됩니다. 이제 전달하는 다양한 매개변수를 기반으로 다양한 인수를 기반으로 데이터를 쿼리할 수 있습니다. 사실, 우리는 바로 여기에서 계획한 매우 강력한 객체 쿼리 언어를 가지고 있습니다. 따라서 개체 쿼리 언어의 도움으로 병렬 쿼리가 있습니다. 또한 개체 쿼리 언어를 사용하여 매우 유연한 쿼리를 실행할 수 있습니다. 예를 들어, 귀하의 질문이 있습니다. 예를 들어 현재 위치 근처에 있는 모든 장소를 가져오려면 예입니다. 당신은 할 수 있습니다. 예를 들어 캐시에 전파된 모든 데이터가 있습니다. 캐시에 별도의 개체로 별도로 저장된 모든 메뉴가 있습니다. 오른쪽? 그런 다음 위치 정보도 제공할 수 있는 개체 속성을 가질 수 있습니다. 따라서 모든 장소를 선택하라는 쿼리를 실행할 수 있습니다. 여기서 장소는 해당 위치와 동일합니다. 따라서 개체 속성에 이 정보가 있으면 배포 캐시에서 일치하는 모든 레코드를 가져올 수 있습니다. 그렇기 때문에 한 가지 방법입니다.
두 번째 방법은 공간 정보 또는 쿼리해야 하는 모든 정보를 태그 형식으로 해당 개체의 일부로 전달하는 것입니다. 개체를 저장한 다음 태그로 바로 여기에 있는 추가 키워드를 저장합니다. 이들은 캐시에서 논리적 컬렉션을 만드는 식별 식별자입니다. 따라서 태그 기반 API를 사용할 수 있습니다. 여기에서 get by tag라고 말하면 결과와 일치하는 전체 컬렉션을 얻거나 tag가 동일하고 tag가 본질적으로 선택되는 장소를 선택하는 쿼리를 실행할 수도 있습니다. 이미 추가한 위치에서 태그는 XYZ 위치와 같으며 해당 기준에 따라 일치하는 모든 레코드를 얻을 수 있습니다. 따라서 쿼리를 처리할 수 있는 두 가지 방법이 있습니다. 개체 위에 태그를 추가하거나 실제 개체 속성에만 의존할 수 있습니다. 그런 다음 검색 쿼리와 같은 SQL을 수행합니다. 귀하의 질문에 답변이 되었기를 바랍니다. 이에 대해 더 궁금한 사항이 있으면 알려주세요.
또 다른 질문이 있습니다. 이벤트를 기반으로 캐시된 특정 항목의 만료를 설정할 수 있습니까? 예를 들어, 레코드는 캐시이고 데이터베이스에서 업데이트되면 만료됩니다. 전적으로! 우리에게는 두 가지 종류의 만료가 있습니다. 시간은 만료이며 두 가지 유형의 만료가 있으므로 시간이 경과하면 항목을 만료할 수 있으며 이 만료는 데이터베이스 종속성을 기반으로 할 수도 있습니다. 예를 들어, 데이터베이스에서 무언가가 변경되면 귀하의 질문에 답이 될 것입니다. 예를 들어, 데이터베이스의 레코드가 변경되면 캐시에 레코드가 있었고, 이에 의존하고 있었습니다. 해당 데이터베이스 레코드가 변경되는 즉시 데이터베이스는 이벤트 알림을 보낼 수 있고 캐시의 항목은 자동으로 전면에서 제거될 수 있습니다. 캐시. 따라서 데이터베이스에서 만료되는 즉시 만료될 수 있습니다. 따라서 관계형 데이터베이스 종속성 측면에서 우리가 제공하는 것이 바로 이것이고 SQL 종속성이 이를 다룰 것입니다. 다른 슬라이드로 빠르게 이동한 다음 객체 캐싱 부분으로 이동하여 많은 질문에 답할 수 있다면 감사하겠습니다. 다른 질문이 더 있으면 알려주세요. 같은 부분에서 프레젠테이션을 다시 시작하겠습니다.
질문이 있습니다. 샘플 지속성을 보여주고 샘플 캐시에서 데이터를 검색할 수 있습니까? 다음으로 시작하는 샘플을 살펴보는 것이 좋습니다. NCache 그리고 그것들은 우리 웹사이트에서도 볼 수 있습니다. 따라서 샘플로 신속하게 안내해 드리겠습니다. NCache. 나는 이것을 정확하게 처리하는 샘플로 당신을 안내할 수 있습니다. 따라서 데이터베이스 동기화가 있고 종속성이 있습니다. 그래서, 이것들은 해야 합니다. 종속성 핸들, SQL 종속성 및 데이터베이스 동기화는 읽기 및 쓰기 요청의 도움으로 시나리오를 처리하는 데 도움이 되는 또 다른 종류의 샘플입니다. 이것이 귀하의 질문에 답이 되기를 바랍니다. 매우 감사합니다.
질문이 하나 더 있습니다. 이것을 쿼리하여 데이터를 정렬할 수 있습니까? 예. 우리는 지원에 의해 순서로 그룹화했습니다. 따라서 쿼리와 함께 해당 속성을 사용할 수 있습니다. 아주 좋은 녀석들! 이러한 질문을 보내주셔서 대단히 감사합니다. 정말 감사합니다. 계속 오게 해주세요. 이것은 프레젠테이션이 끝날 즈음에 계획되었고 이미 이 내용을 다루려고 했지만 모든 질문이 들어오는 것이 좋으므로 계속해서 질문을 해주시기 바랍니다. 매우 감사합니다.
NCache 아키텍처
이제 다음으로 빠르게 아키텍처로 이동하겠습니다. 분산 캐시는 서버 추가 또는 제거 측면에서 매우 탄력적입니다. 원하는 만큼 서버를 추가할 수 있습니다. 모든 서버를 오프라인으로 전환할 수 있습니다. TCP 기반 캐시 클러스터링을 기반으로 합니다. 우리가 구현한 질문 프로토콜입니다. 우리는 타사 또는 Windows 클러스터링을 사용하지 않습니다. Microsoft Azure에서도 IP 주소와 포트에 의존하고 NCache 나머지는 처리할 것입니다. 100% 피어 투 피어 아키텍처입니다. 단일 실패 지점이 없으며 모든 서버를 오프라인으로 전환하고 새 서버를 추가할 수 있으며 클라이언트는 아무런 영향을 미치지 않습니다. 실행 중인 캐시 클러스터에 변경 사항을 동적으로 적용할 수 있습니다. 그런 다음 이러한 구성은 이러한 서버가 클라이언트와 지속적으로 통신하는 방식으로 동적입니다. 서버가 다운되거나 새로운 서버가 추가되면 즉시 알림을 받습니다. 클라이언트에 전파되고 캐시에 변경 사항이 있을 때마다 업데이트되는 메모리 내 맵이 있습니다. 따라서 이러한 맵은 클러스터 멤버십 정보와 캐시 토폴로지 정보 맵으로, 캐시 클러스터에 변경 사항이 발생하는 즉시 업데이트됩니다. 따라서 연결 장애 조치 지원이 있으며, 서버가 다운되면 클라이언트가 이를 자동으로 수행하고 서버는 해당 서버를 떠나고 살아남은 노드를 자동으로 사용할 수 있게 되며 클라이언트는 자동으로 연결합니다. 따라서 간단히 말해서 클라이언트 응용 프로그램에 관한 한 데이터 손실이나 응용 프로그램 다운타임이 없으며 선택할 수 있는 네 가지 토폴로지가 있습니다.
캐싱 토폴로지
활성 및 수동 모드 또는 마스터 또는 슬레이브 모드는 캐싱 토폴로지를 기반으로 결정됩니다. 내가 말했듯이, 이것은 PXNUMXP 아키텍처입니다. 따라서 각 서버는 캐시 클러스터에 독립적으로 참여합니다. 따라서 종속성이 없거나 리드 호스트에 대한 개념이 없습니다. AppFabric 또는 구성 또는 클러스터 관리 측면에서 능동 또는 수동이 없습니다. 모든 서버는 구성 측면에서, 캐시 클러스터에서의 위치 측면에서 100% 독립적입니다. 그러나 다른 캐싱 토폴로지가 있으며 능동 및 수동이 있지만 캐시의 데이터를 기반으로 합니다. 데이터가 활성 상태이면 활성 데이터라고 하고 데이터가 백업일 뿐이면 클라이언트가 연결되어 있지 않으면 수동 데이터라고 합니다. 그러나 이 수동 서버는 100% PXNUMXP 아키텍처에서 캐시에 다시 추가됩니다.
질문이 있습니다. 모바일 플랫폼, Android 또는 iOS에서 사용할 SDK가 있습니까? NCache 네이티브 모바일 앱에서? 현재 우리는 .NET과 Java API를 보유하고 있으며 안정적인 API를 작업 중이므로 이 API가 출시되면 iOS 앱뿐만 아니라 Android에서도 사용할 수 있을 것이라고 확신합니다. 이에 대한 이메일을 보내주시고 이에 대한 요청을 보내주시면 엔지니어링팀에 전달하여 이에 대한 일정을 알려 드리겠습니다.
이제 네 가지 다른 캐싱 토폴로지가 있습니다.
미러링된 캐시
능동/수동인 미러링을 했습니다. 이것은 오늘 우리의 의제가 아니기 때문에 빠르게 훑어보겠습니다. 나는 우리의 실습 부분에 더 집중하고 싶습니다. 다양한 토폴로지가 무엇인지 살짝 보여 드리겠습니다. NCache 제공합니다. 네 가지 토폴로지가 있습니다. 미러링 캐시는 XNUMX노드 액티브-패시브입니다. 모든 클라이언트가 활성 상태로 연결되어 있고 바로 여기에 백업 서버가 있습니다. 활성이 다운되면 백업이 자동으로 활성이 됩니다. 그리고 이러한 클라이언트는 자동으로 장애 조치됩니다. 이것은 더 작은 구성에 권장되며 읽기에 매우 좋으며 오른쪽에 매우 좋고 또한 매우 안정적입니다.
복제된 캐시
그런 다음 활성-활성 모델인 Replicated가 있습니다. 따라서 두 서버는 모두 활성 상태이지만 클라이언트는 분산되어 있습니다. 따라서 Microsoft Azure에 XNUMX개의 웹 역할 또는 작업자 역할이 있고 부하가 고르게 분산된 경우 일부는 서버 XNUMX에 연결되고 일부는 서버 XNUMX에 연결됩니다. 여기에 동기화 모델이 있습니다.
미러링에서는 비동기식이므로 읽기 성능도 매우 빨랐습니다. 복제에서는 항상 동기화 모델이 있습니다. 따라서 각 서버에 전체 캐시 사본이 있고 이러한 서버는 동일한 데이터를 가지며 동기화된 방식으로 모든 업데이트가 모든 서버에 적용됩니다. 예를 들어 서버 XNUMX에서 서버 항목 번호 XNUMX를 업데이트하면 해당 작업이 완료된 후에만 동기화 방식으로 서버 XNUMX에 적용됩니다. 그러나 읽기는 클라이언트가 연결된 서버에서 로컬로 적용됩니다. 따라서 읽기는 매우 빠르게 확장 가능하고 쓰기는 매우 일관적입니다. 여기서 무언가를 변경하면 항상 해당 작업만 완료될 뿐만 아니라 여기에서도 변경이 가능하기 때문입니다. 따라서 업데이트를 위한 안정적인 데이터 트랜잭션, 초고속 성능을 위해 이것은 매우 좋은 토폴로지입니다. 서버 XNUMX을 잃어버리면 이 클라이언트는 서버 XNUMX로 장애 조치되고 서버 XNUMX를 잃으면 이 클라이언트가 장애 조치됩니다. 따라서 데이터 손실이나 응용 프로그램 수신 거부가 없습니다.
파티션된 캐시
그런 다음 데이터를 분할한 다음 복제로 분할한 캐시를 분할했습니다. 따라서 필요에 따라 두 개 이상의 서버를 가질 수 있고 데이터가 모든 서버에서 자동으로 분할되는 데이터 분할이 있습니다. 일부 데이터는 서버 XNUMX로 이동하고 일부 데이터는 서버 XNUMX로 이동합니다. 코인의 분포 맵은 캐시에 데이터가 있는 위치를 이미 알고 있으며 서버를 정확히 찾아내고 해당 서버를 사용하여 데이터를 읽고 쓸 것입니다. 더 많은 서버는 캐시에서 더 많은 복사본을 읽고, 더 많이 쓰고, 더 많은 서버에서 데이터를 읽고, 더 많은 서버에서 데이터를 쓸 수 있음을 의미합니다. 따라서 이러한 서버는 전반적인 성능, 전반적인 확장성에 기여합니다. 따라서 더 많은 서버는 캐시에서 더 많은 확장성을 의미합니다. Partitioned에는 백업이 없습니다.
파티션 복제본 캐시
수동 복제본 파티션의 다른 서버에 각 파티션을 백업할 수 있는 복제본이 있는 파티션이 있습니다. 예를 들어, 한 사람의 백업은 서버 XNUMX에 있고 서버 XNUMX의 백업은 서버 XNUMX에 있습니다. 따라서 서버 하나가 다운되거나 서버를 오프라인으로 전환해야 하는 경우 데이터 손실이 없습니다. 백업은 한 번에 사용할 수 있습니다. 그리고 이것은 또한 매우 선형적으로 확장 가능합니다. 사실 성능 수치 측면에서 가장 확장 가능한 토폴로지입니다.
이를 뒷받침하는 몇 가지 벤치마크 수치를 빠르게 보여드리겠습니다. 질문이 있으면 알려주세요. 내가 말했듯이 여기서 시간을 절약하기 위해 이러한 토폴로지를 빠르게 훑어볼 것입니다.
다음은 두 개의 노드가 있는 미러링된 캐시입니다. 복제는 읽기에 매우 적합하고 쓰기는 확장 가능하지 않지만 읽기 및 쓰기 확장성과 함께 업데이트 및 파티션의 동기화 특성이 있기 때문에 여기서 요점을 알 수 있습니다. 읽기 및 쓰기가 있는 분할된 복제본에는 백업도 있으므로 성능 및 확장성과 함께 백업을 얻을 수 있습니다. 그런 다음 동기화 복제본으로 파티션을 나눈 복제본도 있습니다.
클라이언트 캐시
몇 가지 기능이 더 있습니다. 예를 들어, 코드 변경 없이 로컬 근처 클라이언트 캐싱도 지원합니다. 애플리케이션 측에서도 캐싱을 켤 수 있습니다. 그리고 이 캐시는 서버 캐시와 동기화되며 주로 참조 유형의 데이터에 권장됩니다. 따라서 쓰기보다 읽기가 더 많은 경우 이 기능을 켜고 싶을 수 있으며 이렇게 하면 기존 애플리케이션에서 초고속 성능 향상을 얻을 수 있습니다. 네트워크를 통한 여행을 분산 캐시에 저장합니다. 이것은 이미 데이터베이스에 뒤로 여행을 저장하고 있지만 클라이언트 캐시를 사용하여 네트워크를 가로질러 이동해야 하는 곳에 이 여행을 저장할 수도 있습니다. 당신은 그것을 끄면됩니다. 또한 직렬화 및 프로세스 간 통신을 추가로 저장하기 위해 응용 프로그램에 대한 프로세스에서 만들 수도 있습니다. 그리고 NCache 모든 동기화를 관리합니다. 여기에서 무언가가 변경되면 다른 클라이언트 캐시뿐만 아니라 여기에서도 전파되며 그 반대의 경우도 마찬가지입니다. 시작하기에 아주 좋은 기능입니다. 이미 성능 벤치마크를 다뤘습니다.
분산 캐시의 WAN 복제
그런 다음 Microsoft Azure에서도 WAN 복제를 지원합니다. 예를 들어 두 개의 데이터 센터가 있는 경우 하나는 뉴욕에 다른 하나는 유럽에 있을 수 있으므로 한 데이터 센터에서 다른 데이터 센터로 데이터를 전송할 수도 있습니다. 여기에서 캐시 클러스터를 가질 수 있고 브리지의 도움으로 활성-수동 노드로 백업될 수 있습니다. 브리지는 데이터를 브리지로 전송할 수 있으며 브리지는 차례로 대상 사이트로 전송할 수 있습니다. 이것은 DR 시나리오에 대해 능동-수동일 수도 있고 능동-능동일 수도 있습니다.
괜찮아. 질문이 있습니다. 일시적으로 네트워크에 연결되지 않은 모바일 앱인 연결이 끊긴 시스템에서 클라이언트 캐시를 사용할 수 있습니까? 아주 좋은 질문입니다. 문제는 연결 해제 모드에서 클라이언트 캐시를 사용할 수 있느냐는 것입니다. 우리는 그것에 대해 이야기했습니다. 이것은 클라이언트 중 하나의 기능 요청이었고 실제로 길게 논의했습니다. 따라서 관심 있는 특정 요구 사항이 있습니다. 우리는 이미 몇 가지 계획을 가지고 있고 이미 이에 대해 논의했으며 그 이후로 이와 유사한 요청을 이미 받았습니다. 이메일을 보내주시면 제 사용 사례에 클라이언트 캐시를 사용하고 연결 해제 모드에서도 사용하기를 원합니다. 그들이 이미 논의 중이고 우연히 이것을 제공하기 때문에 나는 이것을 엔지니어링에 전달하게 되어 매우 기쁠 것입니다. 매우 감사합니다.
괜찮아. 이 경우 이메일을 기다리겠습니다. 이 시점에서 클라이언트 캐시는 서버 캐시와 함께 이동합니다. 이것이 서버 캐시와 동기화되어 클라이언트 캐시가 다운되면 모든 데이터가 손실됩니다. 그러나 우리는 연결이 끊긴 모드를 사용할 계획입니다. 이 모드에서는 서버 연결이 끊어지더라도 클라이언트 캐시가 계속 실행되고 나중에 수행할 일부 작업을 대기열에 추가합니다.
실습 데모
다음으로 실습 데모를 빠르게 보여 드리겠습니다. 실제 제품은 어떻게 작동합니까? 시간이 얼마 남지 않았습니다. XNUMX분 남았습니다. 따라서 Azure 개요를 빠르게 알려 드리겠습니다. 시작하기 위해 기본적으로 필요한 것 NCache 에 대한 배포를 계획한다는 것입니다. NCache.
가장 먼저 필요한 것은 Azure 가상 네트워크를 만드는 것입니다. Microsoft Azure에 와서 가상 네트워크를 만듭니다. 빠른 만들기 또는 사용자 지정 만들기를 사용할 수 있습니다. 그런 다음 예를 들어 빠른 만들기를 선택하면 다음과 같이 말할 수 있습니다. NCache VM. 이것은 내가 사용할 가상 네트워크입니다. NCache 그런 다음 이 가상 네트워크를 만들 수 있습니다. 필요에 따라 가상 네트워크에 대한 특정 세부 정보를 제공할 수 있습니다. 또는 사용하려는 환경에 이미 가상 네트워크가 있을 수 있습니다. NCache 배포. 이것이 우리의 첫 번째 단계입니다. 이미 생성된 가상 네트워크가 몇 개 있습니다. 그래서 저는 그냥 다음 단계로 넘어갈 수 있습니다.
다음 단계는 NCache 가상 머신. 다음을 수행할 수 있는 가상 머신을 생성하기만 하면 됩니다. NCache 사전 설치된, 당신은 그냥 설치할 수 있습니다 NCache Microsoft Azure VM 이미지를 가져옵니다. Azure marketplace 그것은 NCache professional 하지만 관심이 있다면 NCache enterprise, 단순히 일반 이미지 2012 서버를 사용할 수 있습니다. 설치 NCache 그 위에 새 VM을 생성해야 할 때마다 나중 단계를 위해 해당 이미지를 저장한 다음 로드합니다. NCache 서버 배포. 따라서 갤러리에서 이미지(예: 2012 서버)를 선택할 수 있습니다. 이름을 지정하기만 하면 다음으로 선택할 수 있습니다. 예를 들어 데모 3입니다. 일부 서버 계층을 선택한 다음 필요에 따라 일부 정보를 입력할 수 있습니다.
Azure 관련 단계입니다. 그래서, 나는 당신이 이것에 익숙할 것이라고 확신합니다. 다음으로 가장 중요한 것은 새로 만들 것인지 여부입니다. cloud service 또는 이미 있는 것을 사용하십시오. 예를 들어 벤치마크를 사용하면 가상 네트워크도 자동으로 선택됩니다. 그러나 VM을 자체적으로 생성할 수 있습니다. cloud services 뿐만 아니라 새로운 cloud service. 그러나 여전히 모든 서버 VM에 대해 가상 네트워크를 선택한 다음 모든 서버 VM에 대해 동일해야 합니다. NCache. 따라서 서버 간 통신이 진행되는 한 시스템에서 더 많은 성능을 얻을 수 있습니다. 따라서 저는 이 벤치마크를 선택하고 이를 기반으로 다음을 선택할 수 있습니다.
필요한 경우 네트워크에 대한 몇 가지 특정 세부 정보를 채울 수 있습니다. 그러나 전반적으로 이것이 내가 필요한 전부입니다. 그래서, 난 그냥... 알았어. 내가 선택한 클라우드 서버는 이러한 종류의 가상 머신을 지원하지 않습니다. 따라서 새로 만들기를 선택하기만 하면 됩니다. cloud service 그것으로. 괜찮아. 그래서, 나는 그것이 승인되고 거기에 간다고 말할 것입니다. 그래서, 이렇게 될 것입니다. 이만 취소하겠습니다. 여기에 이미 이러한 서버가 있으며 사실 이미 구성한 몇 대의 서버에 빠르게 로그온할 수 있습니다. 그러니 조금만 참아주세요. 캐시 생성 및 구성을 시작하고 사용자 환경에서 빠르게 테스트하는 방법을 보여드리겠습니다. XNUMX분 정도 있습니다. 그래서 최대한 활용하고 싶어요. 그리고 여러분이 필요로 하는 만큼 질문을 자유롭게 게시해 주십시오. 저는 환경을 준비하는 동안 항상 질문에 답합니다.
괜찮아. 이미 이러한 서버가 있습니다. 빠르게 로그인할 수 있습니다. 우리는 이미 몇 가지 테스트를 위해 이것을 사용하고 있습니다. 여기에서 비밀번호를 엉망으로 만든 것 같습니다. 양해해 주십시오. 저기요! 좋아요! 저기요! 그러면 바로 여기에 데모 2가 있습니다. 자, 여기 두 상자가 있습니다. 좋아요! 따라서 Microsoft Azure에서 동일한 가상 네트워크의 일부인 이 두 상자가 이미 구성되어 있습니다.
질문이 있습니다. VM이 반드시 필요한가요? 아니면 Azure 앱 서버를 사용할 수 있나요? 도커는 어떻습니까? 아직 도커 지원이 없습니다. 엔지니어링 부서에서 작업 중인지 확인할 수 있습니다. 서버 모델에 관한 한, NCache Microsoft Azure에 VM이 있어야 합니다. 가상 애플리케이션은 서비스 모델일 수 있습니다. cloud service, 웹 역할일 수도 있고 작업자 역할일 수도 있고 애플리케이션이 배포되는 실제 VM일 수도 있습니다. 하지만 NCache 서버 부분은 VM이어야 하며 내가 말했듯이 가장 쉬운 방법은 미리 구성된 VM 이미지를 만드는 것입니다. NCache. 갤러리에 보관하고 새 인스턴스를 생성해야 할 때 로드합니다. VM 템플릿을 사용할 수 있는 자동 크기 조정에 대해 동일한 것을 선택할 수도 있습니다. NCache 활성화 및 구성을 설치한 경우 노드가 특정 제한까지 커지면 새 VM을 생성하기만 하면 됩니다.
또 다른 질문이 있습니다. 이미 언급했을 수 있으며 대역폭 사용 측면에서 데이터 감소를 위한 암호화 및 압축이 있으며 암호화 및 압축에 대해 질문하고 있다고 생각합니다. 예! 이 두 기능은 코드 변경 없이 사용할 수 있습니다. 민감한 데이터 전송을 위해 데이터를 암호화할 수 있으며 데이터를 암호화한 다음 데이터도 압축할 수 있습니다. 따라서 이들은 일부 NCache 지원하다. 이러한 질문을 해주셔서 대단히 감사합니다. 질문이 더 있으면 알려주세요.
환경 설정
실제 제품을 빨리 보여드리고 싶습니다. 따라서 다음으로 해야 할 일은 당사 웹사이트로 이동하여 설치하는 것입니다. NCache 전문가용 클라우드인 클라우드 버전은 Microsoft에서 사용할 수 있습니다. Azure marketplace 뿐만 아니라 일반 Enterprise Edition을 다운로드하여 Microsoft Azure VM에 설치합니다. 이미 엔터프라이즈 설치를 완료했습니다. 이렇게 XNUMX단계가 완료되었습니다. 이제 XNUMX단계는 이름 없는 캐시를 만드는 것입니다. 이를 위해 NCache 함께 설치되는 관리자 도구 NCache. 따라서 필요에 따라 VMS 중 하나에서 모든 것을 관리하거나 네트워크에서 이러한 서버에 액세스할 수 있는 별도의 서버에서 모두 관리할 수 있습니다.
클러스터형 캐시 생성
다음 단계는 명명된 캐시를 만드는 것입니다. 빨리 할게요. 데모 캐시라고 합니다.
이것은 이 캐시를 사용하기 위해 모든 클라이언트 응용 프로그램에 사용할 이름입니다. 캐시에서 데이터를 가져오기 위해 이 이름을 참조할 수 있습니다. 파티션된 복제본 캐시 토폴로지가 가장 권장되는 토폴로지이므로 선택하겠습니다.
나는 이것이 더 빠르기 때문에 복제 옵션으로 비동기를 선택합니다. 서버 1은 서버의 사설 IP를 사용하고 있으므로 서버 간 배포 측면에서 가상 네트워크를 측정하는 것이 좋습니다. 따라서 내부 IP에서 액세스할 수 있고 서버 간에 매우 빠른 통신이 이루어집니다.
기본적으로 통신을 위한 TCP 포트는 Azure VMS에 방화벽이 열려 있습니다. 그래서, 나는 당신이 그것을 끄거나 최소한 펀치하는 것이 좋습니다 NCache 방화벽에서 통신을 위한 포트. 그런 다음 서버당 캐시 크기는 데이터를 기반으로 하는 메모리를 기반으로 하며 캐시에 포함할 계획입니다. 따라서 XNUMX기가의 캐시 크기가 필요한 경우 여기에 지정된 적절한 양의 메모리를 사용하면 됩니다. 이것은 상한선일 뿐입니다. 캐시가 가득 차면 두 가지 옵션이 있습니다. 새 업데이트를 거부하여 데이터를 추가할 수 없음을 의미하거나 예외가 발생하거나 제거 비율만 지정할 수 있는 제거를 켤 수 있습니다. 이러한 알고리즘은 새 항목을 위한 공간을 만들기 위해 이러한 알고리즘을 사용하여 제거할 수 있는 항목의 양을 제어할 수 있습니다. 따라서 캐시가 가득 차면 축출이 켜지고 일부 항목이 자동으로 제거되고 항목을 더 추가할 수 있습니다. 저는 그냥 기본 설정으로 끝내기로 했습니다.
그런 다음 오른쪽 창에 캐시가 구성되어 있고 이 캐시와 관련된 모든 설정이 있는 2단계가 완료됩니다. 3단계는 클라이언트 노드를 추가하는 것입니다. 데모 3을 추가할 수 있지만 서버가 두 개뿐이므로 이 두 상자도 클라이언트로 추가하겠습니다. 4단계는 이 캐시 클러스터를 시작하고 테스트하는 것입니다. 이를 위해 마우스 오른쪽 버튼을 클릭하고 선택하면 모든 캐싱 서버에서 이 캐시가 시작되고 이러한 클라이언트 노드는 실제로 내 웹 역할 또는 VM입니다. 여기서 내 응용 프로그램이 배포됩니다.
따라서 동일한 네트워크에 모든 것을 유지하는 것이 좋습니다. 따라서 NCache 관리자. 통계를 마우스 오른쪽 버튼으로 클릭하면 성능 카운터가 열립니다. 캐시가 시작되었습니다. 일부 설정은 회색으로 표시되어 캐시가 실행되는 동안 변경할 수 없지만 압축을 켜고 마우스 오른쪽 버튼을 클릭하고 하드 적용 구성을 선택할 수 있는 것과 같은 일부 설정은 계속 변경할 수 있습니다. 먼저 프로젝트를 저장하라는 메시지가 표시됩니다. 그래서 저는 그렇게 한 다음 구성을 하드 적용할 것입니다. 가세요.
이제 캐시가 구성되고 클라이언트가 구성되었습니다. XNUMX단계를 완료하고 설치했습니다. NCache.
스트레스 시뮬레이션 및 캐시 통계 모니터링
우리는 캐시를 생성하고 클라이언트를 구성했으며 구성 관점에서 작업을 완료했지만 이 캐시 클러스터를 시작하고 실행하기만 하면 됩니다. 이를 위해서는 함께 설치되어 제공되는 스트레스 테스트 도구만 사용하겠습니다. NCache. 내 캐시에 대해 실행합니다. 그래서 약간의 활동도 볼 수 있었습니다. 또한 두 번째 상자에 로그온하여 이 콘솔 기반 응용 프로그램도 실행할 것입니다. 그래서, 그 이전에 두 번째 인스턴스를 실행하여 초당 요청 카운터를 살펴봅니다. 스트레스 테스트 도구의 한 인스턴스에서 생성된 초당 약 천 개의 요청이 있습니다.
두 번째 서버에서는 이것을 실행하겠습니다. 따라서 로드가 더 많고 초당 요청 카운터가 거의 두 배로 증가한 것을 알 수 있습니다. 초당 XNUMX개의 요청.
이 상자에서 하나의 인스턴스를 실행했지만 여전히 두 서버를 모두 사용하고 있었습니다. 응용 프로그램이 두 서버를 서로 조합하여 사용하는 또 다른 인스턴스를 실행한 다음 상태, CPU, 요청, 크기, 네트워크 및 서버 측의 다양한 매트릭스를 제공하는 이 모니터링 도구가 있습니다. 고객 입장에서.
그리고 여기에서 제가 한 것처럼 자신만의 대시보드를 만들 수도 있습니다. 시간 제약으로 인해 죄송합니다. 이 작업에 조금 더 빨리 다가가야 했지만 이것은 시작하기 위한 간단한 XNUMX단계였습니다. NCache. 캐시가 실행 중입니다.
NCache 견본
다음은 실제 애플리케이션에서 캐시를 사용하는 것입니다. NCache 샘플. 예를 들어 기본 연산을 사용하고 싶다면 이것이 샘플입니다. 세션 상태를 사용하려면 이 ASP.NET 세션 상태 응용 프로그램을 사용할 수 있습니다. 이 목록에는 보기 상태 및 출력 캐싱 샘플도 있습니다. 따라서 이것을 활용하고 사용에 참고하십시오. NCache 실제 응용 프로그램에서.
질문이 있습니다. 두 가지 수준의 캐시를 구성할 수 있습니까? 하나는 영구 상태에서 200GB와 같고 다른 하나는 메모리에서 휘발성이 1GB 더 크며, 수준 1 메모리를 수준 2 캐시에서 일반적으로 참조되는 메모리의 하위 집합과 동기화할 수 있습니까? 이것은 가능하다. 두 가지 질문이 있습니다. 첫 번째 질문은 두 개의 다른 메모리로 두 개의 다른 캐시를 만들 수 있는지 여부입니다. 예. 대부분의 클라이언트는 정적 데이터용 캐시 하나와 동적 데이터용 캐시 하나를 만들 수 있습니다. 그래서 이것이 여러분이 할 수 있는 일이며 이 두 캐시에 대해 완전히 다른 구성을 만들 수 있습니다.
다음 질문은 이 두 캐시 간에 데이터를 동기화할 수 있습니까? 예. 당신은 할 수 있습니다. 이 캐시 동기화 종속성이 있습니다. 이 기능은 개인적으로 사용할 수 있지만 구현 방법에 대한 몇 가지 세부 정보를 공유할 수 있으며 두 개의 서로 다른 캐시 간에 동기화 종속성을 가질 수도 있습니다. 이 동일한 기능은 클라이언트 캐시가 있는 모든 곳에서 현물 캐시를 사용하는 것입니다. 캐시는 다른 서버에 구성된 클러스터된 캐시와 동기화됩니다. 그래서 예. 귀하의 질문에 대답하기 위해 두 개의 다른 캐시를 가질 수 있으며 해당 두 캐시의 데이터 간에 동기화를 가질 수도 있습니다.
신속하게 요약해 드리겠습니다. 활용할 수 있는 개체 캐시 증가가 많이 있습니다. NCache 개체 캐싱 지원에 대해 설명하고 이미 ASP.NET 세션의 보기 상태를 다루었습니다. 일부 타사 통합도 있습니다. 이것이 본질적으로 웨비나의 끝입니다. 시간 제약으로 인해 몇 가지 문제를 실행한 것에 대해 사과드립니다. 그러나 반복해서 말씀드리자면, 우리는 불능 문제에 대한 몇 가지 기본적인 세부 사항을 다루었고, 솔루션의 메모리 내 분산 캐싱에 대해 이야기하고, Microsoft Azure에서의 배포, 다양한 사용 사례에 대해 이야기했습니다. , 클러스터링 지원, 토폴로지 지원 NCache. 지금까지 Microsoft Azure를 시작하는 방법에 대한 구체적인 실습 데모가 있었습니다. NCache 간다.
프레젠테이션이 어땠는지 알려주세요. 제품은 전반적으로 어떠셨나요? 이에 대한 피드백을 주세요. 마지막까지 할 수 있는 일이 있습니다. 웹사이트로 이동하여 30일 평가판을 다운로드할 수 있습니다. NCache. 클라우드 에디션을 선택할 수도 있습니다. NCache professional cloud, Microsoft Azure에서 사용할 수 있습니다. 우리에게도 클라이언트가 있습니다. 그런 다음 필요한 경우 Azure VM을 사용하여 Enterprise Edition 제품과 함께 사용할 수도 있습니다. 지원 페이지로 이동하여 지원 팀에 연락할 수 있습니다. 지원팀에 연락할 수 있는 연락처가 몇 가지 있습니다. support@alachisoft.com.필요에 따라 제품 데모를 요청할 수 있으며 가격 정보는 영업 팀에 문의할 수도 있습니다. 그래서, 우리는 이미 XNUMX시간 마커에 이르렀으니 작별인사를 해야 할 때라고 생각합니다. 이 데모 후에도 질문이 있으면 알려주십시오. 이메일이나 전화를 통해 연락할 수 있으며 여러분의 질문에 대해 매우 기쁘게 생각합니다. 정말 감사합니다. 즐거운 발표였습니다 NCache 오늘 웨비나. 제품이 마음에 드셨는지, 프레젠테이션이 마음에 드셨는지 알려주세요. 그러면 언제든지 가져갈 수 있습니다. 시간 내주셔서 대단히 감사합니다.