확장 가능한 .NET Pub/Sub 메시징 NCache
녹화된 웨비나
론 후세인과 에드워드 베이터 저
이 웨비나에서는 트래픽이 많은 .NET 애플리케이션에 강력한 Pub/Sub 메시징을 사용하고 성능 병목 현상을 극복하는 방법을 배우게 됩니다. NCache 다양한 Pub/Sub 메시징 기능을 제공하는 확장 가능한 .NET용 분산 캐시입니다.
시니어 솔루션 설계자가 모든 Pub/Sub 기능과 사용 사례를 안내하고 .NET 애플리케이션에 통합하는 방법을 보여줍니다.
이 웨비나는 다음 내용을 다룹니다.
- 일반적인 Pub/Sub 메시징 소개
- 이해 NCache 게시/구독 기능
- Pub/Sub 설정 NCache
- .NET 앱에서 Pub/Sub 사용 실습
- Pub/Sub 메시징 데모 NCache
- NCache Pub/Sub를 위한 고가용성 및 확장성
오늘의 주제는 .NET 애플리케이션 내의 메시징에 관한 것이며 우리는 다음을 사용할 것입니다. NCache 예시 제품으로. 주요 초점이 될 것입니다 게시/구독 메시징. 게시자 구독자 모델. 왜 중요한가? 정확히 어디에, 왜 사용하는지 NCache .NET에 대해 표시되는 다른 옵션과 비교하여 더 적합합니다. .NET core 응용 프로그램? 그래서 우리는 덮을 것이 많습니다. Eddie가 제안한 대로 질문이 있으면 질문 답변 탭을 사용하고 필요한 만큼 많은 질문을 하라고 제안한 경우 이것으로 빠르게 시작하겠습니다. 자, 빨리 시작합시다.
게시/구독이란 무엇입니까?
처음 몇 개의 슬라이드는 소개 부분에 중점을 둡니다. 게시/구독이란 무엇입니까? 모두가 알고 있다고 확신하지만 완전성을 위해 Pub/Sub 메시징 패러다임을 살펴보겠습니다.
따라서 게시자 구독자 모델입니다. 기본적으로 세 가지 구성 요소가 있습니다. 메시지를 보내는 게시자가 있으며 해당 메시지를 통신 채널로 브로드캐스트합니다. 그런 다음 해당 메시지를 수신하는 또 다른 애플리케이션이 될 수 있는 구독자가 있고 통신, 버스 브로커, 서비스, 게시자 내의 프로세스 및 게시자에서 구독자에게 해당 메시지를 전달하는 데 도움이 되는 구독자 중간 구성 요소가 있습니다. 경우에 따라 메시지를 저장하고 메시지를 처리할 수 있습니다. 이것은 시간 기반이 될 수 있으며 수신자를 기반으로 할 수 있습니다.
Pub/Sub 작동 방식
따라서 사용을 계획할 때 조정할 수 있는 다양한 옵션이 있습니다. 그러나 일반적으로 일반적인 Pub/Sub 메시징 플랫폼에 공통적인 몇 가지 지침과 몇 가지 규칙이 있습니다. 느슨하게 결합되어 있습니다. 게시자와 구독자는 서로 의존하지 않고 독립적으로 작업할 수 있습니다. 그들은 서로를 완전히 인식하지 못할 수도 있으며 시스템은 문제 없이 작동해야 합니다. 전체 아이디어는 게시자가 단순히 통신 채널에 메시지를 보낸 다음 통신 채널이 해당 메시지를 릴레이하고 구독자가 해당 메시지를 수신한다는 것입니다. 게시자는 구독자 응용 프로그램에 대한 ID 또는 정보에 대해 알 필요가 없으며 마찬가지로 구독자는 게시자 정보가 무엇인지 알 필요가 없습니다. 그들은 메시지를 처리할 수 있습니다. 이것이 주요 관심 지점이며 전체 아이디어는 각 구성 요소가 독립적으로 작동한다는 것입니다. 게시자는 통신 채널이나 구독자에 대한 종속성이 없으며 그 반대의 경우도 마찬가지입니다.
대부분의 게시자 구독자 모델인 Pub/Sub 모델을 사용하면 주제나 채널 또는 스트림을 가질 수 있는 문제를 분리할 수 있습니다. 메시지를 분리하는 데 사용됩니다. 따라서 단순한 단일 목적을 제공하는 유사한 성격의 메시지는 특정 주제에 포함될 수 있으며 Pub/Sub 메시징 패러다임 내에서 여러 주제, 여러 스트림, 여러 채널을 가질 수 있으며 이러한 메시지를 받을 수 있습니다. 게시자는 주제에 연결한 다음 해당 메시지를 특정 주제로 전송하고 구독자는 커뮤니케이션 채널 내의 주제에 연결한 다음 해당 메시지를 수신할 수 있으며 이 주제 기반 접근 방식을 사용하여 완벽하게 작동합니다.
다음은 아키텍처 세부 사항을 강조하는 다이어그램입니다.
우리는 주제가 있습니다. 이것은 커뮤니케이션 채널입니다. 이것은 구독자 응용 프로그램이 있는 게시자 응용 프로그램입니다. 여러 게시자가 있을 수 있습니다. 마찬가지로 구독자가 여러 명일 수 있으며 커뮤니케이션 채널 내에서도 여러 주제를 가질 수 있습니다. 예를 들어 주문 처리 정보를 다루는 주제가 하나 있을 수 있습니다. 고객 정보 등을 다루는 또 다른 주제가 있을 수 있습니다. 따라서 메시지의 목적에 따라 메시지 유형에 따라 로드 요구 사항입니다. 그러면 메시지를 주제에 배포할 수 있습니다. 그러면 이 구독자는 주제 A에 연결됩니다. 여기서 구독자 2는 다음과 같이 주제 A에 연결됩니다. B뿐만 아니라 구독자 3은 주제 B에만 연결됩니다. 따라서 게시자는 이러한 메시지를 보내고 해당 주제에 연결된 구독자는 문제 없이 해당 메시지를 수신합니다.
Pub/Sub의 일반적인 사용 사례
자, 그럼 다음으로 넘어갑니다. Pub/Sub의 일반적인 사용 사례는 무엇인가요? 이 전체 Pub/Sub 메시징 패러다임은 시장에 출시된 지 꽤 되었으며 트래픽이 많은 애플리케이션에서도 많이 사용되었습니다. 그것은 많은 견인력을 가지고 있습니다.
따라서 주로 비동기 데이터 처리를 처리하는 Pub/Sub 메시징의 이점을 얻을 수 있는 백엔드 시스템이 있습니다. 일부 워크플로, 일부 백그라운드 작업, 필요한 절차, 수행 중인 계산이 될 수 있습니다. 따라서 백엔드 시스템은 주로 이 메시징 플랫폼을 사용합니다.
채팅 애플리케이션은 수백만 명의 사용자와 수백만 개의 메시지를 처리하고 사용자에게 전송되는 게임 산업이 될 수 있습니다. 예를 들어 고객 중 한 명이 게임 사이트에 다양한 토너먼트가 있을 때 정보 공유를 위해 Pub/Sub를 사용하고 있었습니다. 그래서 유저들끼리 토너먼트 관련 정보를 많이 공유하고 있었다.
금융 산업, 전자 상거래, 모든 예약, 공개적으로 접하고 일부 백엔드 주문 처리, 일부 예약 처리 또는 일반적으로 응용 프로그램의 서로 다른 구성 요소 간에 일부 상호 작용을 제공해야 합니다.
자동화 및 제조 공장. 그러나 일반적으로 가장 중요한 사용 사례가 될 수 있고 기술적인 사용 사례가 될 수 있습니다. 마이크로 서비스 사용 사례. 큰 응용 프로그램을 나타내지만 이러한 구성 요소는 단일 독립적인 용도로 사용되는 서로 다른 마이크로서비스가 있는 곳입니다. 이러한 마이크로 서비스에 대한 통신 계층을 구현하는 것은 매우 어렵습니다. 마이크로 서비스로 다시 작동하는 별도의 통신 채널이 있어야 합니다. 이 채널은 다른 마이크로 서비스도 수행할 수 없으며 마이크로 서비스 인스턴스가 서로 독립적인 독립적인 마이크로 서비스 계층을 원하는 전체 아이디어입니다. 한 인스턴스는 단일 목적을 수행하며 다른 인스턴스에 종속되지 않으며 그 반대의 경우도 마찬가지입니다. 따라서 응용 프로그램 내에 마이크로 서비스가 있는 이러한 마이크로 서비스 응용 프로그램의 경우 통신 채널을 구현하는 것은 매우 어렵고 복잡하며 종속성이 많으며 속도도 느려집니다. 따라서 통신 채널이 플랫폼 자체에서 관리되고 마이크로 서비스가 게시자와 구독자 역할을 한 다음 서로 정보를 공유하는 Pub/Sub 메시징 플랫폼을 사용하는 것이 좋습니다. 따라서 자체 통신 채널을 사용하는 마이크로서비스 플랫폼 애플리케이션인 Pub/Sub에서 일반적으로 볼 수 있는 아키텍처 문제와 로드를 줄이는 데 도움이 됩니다. 이를 완화하려면 Pub/Sub를 사용해야 합니다.
문제: Pub/Sub 플랫폼의 확장성 문제
많은 Pub/Sub 플랫폼이 있지만 일반적으로 병목 현상이 있으며 다음에 다룰 내용입니다. 우리는 전형적인 전통적인 메시징 플랫폼을 가지고 있습니다. 그들은 사물의 건축적 측면에서 매우 우수합니다. 메시지를 보내면 그 메시지는 모든 구독자에게 전송될 것이며 모든 것이 잘 작동합니다. 그러나 일반적으로 이것은 낮은 부하에서 매우 잘 작동합니다. 사용자가 적으면 애플리케이션에 더 적은 수의 요청 또는 더 적은 수의 메시지가 전송될 뿐만 아니라 로드합니다. 로드에 관해서는, 예를 들어 애플리케이션 로드가 증가할 때 많은 사용자가 있고 많은 처리가 발생하고 게시자에서 구독자로의 많은 메시징 로드가 있습니다. 일반적으로 우리는 기존의 메시징이 데이터베이스와 같은 플랫폼에서는 병목 현상이 발생합니다. 다음은 이를 설명하는 다이어그램입니다.
게시자 응용 프로그램, 구독자가 있습니다. 이것은 웹 애플리케이션, 일부 .NET 또는 .NET Core 백엔드. 일부 워크플로. 모든 종류의 .NET 또는 .NET Core 데이터베이스 또는 메시징 대기열과 같은 기존 매스 플랫폼에 연결된 애플리케이션 또는 Java 애플리케이션. 우선, 이것들은 인메모리 스토어만큼 빠르지 않습니다. 맞습니다. 그래서, 그것은 당신이 해결해야 할 일입니다. 그러나 주요 문제는 메시징 로드가 증가하면 사용자가 많을 때 단일 소스이기 때문에 메시징 로드가 플랫폼 자체를 질식시킬 수 있기 때문에 속도가 느려지기 시작한다는 것입니다. 애플리케이션이 가하는 증가된 로드를 수용하기 위해 더 많은 서버를 추가할 수 있는 기능이 없습니다.
이것이 주요 문제이며 최종 사용자에게 미치는 영향은 무엇입니까? 예를 들어 메시지가 적시에 중계되지 않고 많은 시간이 소요되어 애플리케이션 측의 대기 시간에 기여했습니다. 예를 들어 최종 사용자는 처리가 완료되기를 기다리고 있었고 해당 처리는 Pub/Sub 모델 플랫폼에 종속되어 있고 플랫폼이 느렸습니다. 따라서 이는 최종 사용자 요청에도 영향을 미치며 밀리초 또는 몇 초 지연이 있는 경우 비즈니스를 잃게 됩니다. 그러면 최종 사용자에게 영향을 미칠 수 있으며 이는 다음과 같이 비즈니스에 영향을 미칠 것입니다. 그리고 그것은 관리하기가 매우 어렵습니다. 방법이 없기 때문에 해당 문제를 해결하는 데 도움이 되도록 애플리케이션 아키텍처 내부에서 무엇이든 변경할 수 있습니다. 데이터베이스 계층이 있는 애플리케이션 아키텍처 외부에 문제가 있습니다. 맞습니다. 그렇다면 그 특정 시나리오를 어떻게 처리해야 할까요?
솔루션: 인메모리 분산 캐시
솔루션은 다음과 같이 자연적으로 분산된 인메모리 Pub/Sub 메시징 플랫폼을 사용하는 매우 간단합니다. NCache. 매우 빠르기 때문에 기존 메시징 플랫폼과 차별화됩니다. 기능이 적을 수도 있지만 인정합니다. 부터, NCache의 주요 초점은 개체 캐싱, 데이터 캐싱, 세션 캐싱을 갖는 것이며, 데이터 처리 및 저장 및 성능 향상을 위한 것입니다. Pub/Sub 기능 중 하나입니다. 메시징 대기열과 같은 제품이 있습니다. 예를 들어 Java 메시징 서비스, MSM 대기열은 더 정교합니다. 그러나 무엇을 만드는가 NCache 이 제품들과 별개로 NCache 는 인메모리입니다. 따라서 시작하는 것이 매우 빠릅니다.
따라서 XNUMX명의 사용자가 있고 메시징 부하가 적은 경우 해당 사용자는 기존 메시징 플랫폼과 비교하여 매우 빠른 경험을 보게 될 것입니다. 따라서 메모리 내입니다. 따라서 이는 큰 장점이며 해당 메시징 플랫폼을 호스팅하는 여러 서버가 있습니다. 메싱 플랫폼을 공식화하는 논리적 용량으로 결합된 팀 서버를 볼 수 있으며 그 위에 Pub/Sub 메커니즘이 구현되어 있습니다. 따라서 게시자 애플리케이션은 이 캐시에 연결할 수 있으며 캐시 내에서 별도의 주제를 가질 수 있습니다. 이것이 어떻게 작동하는지 보여드리겠습니다. 그런 다음 구독자도 게시자일 수 있습니다. 그들은 또한 다음에서 제공하는 동일한 통신 채널에 연결되어 있습니다 NCache 분산 캐시의 형태로 해당 통신 채널은 이러한 게시자 및 구독자에게 모든 통신 관련 정보를 제공합니다. 이것은 메시지를 중계할 수 있고 이 모든 다른 종류의 탐색, 몇 가지 다른 종류의 지속성 및 다른 기능을 가질 수 있습니다.
이 플랫폼의 좋은 점은 필요한 만큼 서버를 추가할 수 있고 여기에서 볼 수 있는 것처럼 플랫폼이 확장성 병목 현상이 되는 것에 대해 걱정할 필요가 없다는 것입니다. 따라서 더 이상 확장성 병목 현상이 아닙니다. 즉석에서 더 많은 서버를 추가할 수 있고 XNUMX~XNUMX개의 서버를 바로 늘릴 수 있으며 XNUMX~XNUMX개의 서버로 처리할 수 있는 요청 수, 초당 처리할 수 있는 메시지 수의 용량을 거의 두 배로 늘릴 수 있습니다. 성능을 저하시키면서 메시지 전달을 위한 선형 확장성을 개선할 수 있으며 이는 애플리케이션 측면에서 많은 도움이 될 것입니다. 최종 사용자는 애플리케이션과 사용자를 위해 더 빠른 응답 시간, 짧은 대기 시간 및 높은 처리량을 볼 수 있는 많은 이점을 얻을 수 있습니다.
지금까지 질문이 있습니까? 사용을 고려해야 하는 이유를 설명합니다. NCache 기존 Pub/Sub 메시징 플랫폼의 문제점은 무엇이며 기존과 비교합니다. 지금까지 질문이 있습니까? 다음 몇 슬라이드는 아키텍처 세부 사항에 중점을 둡니다. NCache Pub/Sub 메시징에 대해 설명한 다음 이의 일부로 제공되는 다양한 기능에 대해 설명하겠습니다. 안녕하세요 Ron, 질문이 있습니다. 사용 가능한 모니터링 옵션은 무엇입니까? 좋아, 내 생각에 NCache, 예, 그것은 내가 이것을 위해 정렬된 끝 부분을 가지고 있는 또 다른 플러스입니다. 그러나 나는 그 부분까지 기다렸다가 제품의 실습 데모를 제공하고 그 일환으로 모니터링 기능도 보여 주면 매우 좋을 것이라고 생각합니다. 따라서 해당 부분에 도달하면 이 질문을 다시 검토하겠습니다. 괜찮길 바랍니다.
NCache 게시/구독 메시징
좋구나, NCache Pub/Sub 메시징. 여기에서 본 것과 매우 유사합니다. 전통적인 Pub/Sub 메시징 플랫폼입니다. 다음은 아키텍처 분석입니다. 에서 제공하는 메시징 채널이 있습니다. NCache 우리는 바로 여기에 서버 팀이 있고 해당 메시징 채널 내에 주제 1, 주제 2가 있으며 모든 .NET이 될 수 있는 게시자가 있습니다. .NET Core 응용 프로그램이 있고 다시 .NET 또는 .NET Core, 심지어 그것에 연결된 Java 응용 프로그램.
이를 위해 전용 캐시를 구성할 수 있으며 메시지는 게시자에서 구독자로 메시지가 전송되는 일반적인 Pub/Sub 메커니즘을 사용하여 통신 채널에서 릴레이되는 것입니다. 다음은 간단한 코드 조각입니다.
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
...
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");
Message orderMessage = new Message(payload);
// Publish message to all registered subscribers
// Register delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);관심 객체인 페이로드를 구성한다는 아이디어를 얻으려면 캐시를 초기화하고 캐시에 연결하고 이름을 지정하면 됩니다. 캐시 클러스터 생성 다른 서버를 사용하여 주제를 생성하거나 기존 주제에 연결합니다. 주제는 유사한 메시지를 위한 별도의 매체인 채널이며 메시지를 구성한 다음 게시하면 됩니다. 기본 사용 사례의 경우 간단합니다.
구독자 측에서는 다시 주제에 연결하거나 새 주제를 생성한 다음 구독 생성 메서드를 사용하여 구독자가 되어야 합니다. 그러면 메시지가 수신될 때마다 호출되는 콜백이 있으며 이는 비동기식 호출입니다. -뒤.
Cache cache = NCache.InitializeCache("PubSubCache");
ITopic productTopic = cache.MessagingService.GetTopic(topicName);
ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);
private void MessageReceived(object sender, MessageEventArgs args)
{
// Perform operations
}실습 데모
빨리 제품 데모를 드려야 하고 데모를 하고 나면 훨씬 이해하기 쉬울 것 같아요. 저는 계속 진행하고 이것의 일부로 모니터링 옵션에도 답변할 것입니다. 알았어, 그럼 빨리 가서 보여줄게 NCache 함께 설치되는 관리자 도구.
캐시 생성
새로운 캐시를 생성하겠습니다.
이름을 PubSubCache로 지정하고 마지막에 Windows Win을 추가하겠습니다. 모든 캐시의 이름을 지정해야 합니다. 애플리케이션에 의미 있는 Pub/Sub 캐시의 이름을 지정할 수 있습니다. 캐시를 생성할 수 있으며, NCache Windows 환경, Windows 서버 및 Linux 서버에서 캐시를 생성할 수 있으며 Windows 모노 릴리스도 제공합니다. 따라서 Linux에서는 다음을 사용해야 합니다. .NET Core Windows에서는 .NET뿐만 아니라 .NET Core 의 릴리스 NCache. 그래서 저는 Windows 서버로 진행할 것입니다. 요청 처리 용량에 기여하는 여러 서버를 갖고 싶기 때문에 파티션 복제본 캐시를 선택하십시오.
따라서 Partitioned 및 Partitioned Replica는 매우 좋은 옵션입니다. Partitioned Cache를 사용하면 여러 서버에서 데이터를 분할할 수 있지만 Partitioned Replica는 Partitioned와 유사하지만 백업도 있습니다. 따라서 전적으로 귀하에게 달려 있습니다. 본질적으로 메시지가 중요하기를 원하면 한 서버에서 다운되면 여전히 통신 채널에 있는 메시지를 잃지 않으려면 분할된 복제본을 사용할 수 있습니다. 그렇지 않으면 분할된 캐시가 더 편심하게 수행됩니다. .
두 가지 다른 토폴로지가 있지만 더 작은 구성을 위한 것입니다. NCache 건축 웨비나 이러한 토폴로지와 관련된 모든 세부 정보를 매우 효과적으로 다룹니다. 따라서 이러한 토폴로지에 대해 자세히 알아야 하는 경우 해당 웹 세미나를 검토하고 해당 웹 세미나를 방문하는 것이 좋습니다. 나는 모든 것을 간단하게 유지합니다. 복제 옵션으로 비동기를 선택합니다.
그것은 활성 파티션과 다른 서버의 백업 사이에 있으며 여기에서 내 캐시 클러스터를 호스트할 서버 팀을 지정합니다. 처음에는 두 대가 있을 수 있으며 앞에서 설명한 것처럼 언제든지 서버를 더 추가할 수 있습니다. 참고로 이것은 TCP 포트입니다. 사이의 모든 통신 NCache TCP/IP를 통해 구동되며 크기는 서버당 크기입니다. 따라서 메시징 로드를 기반으로 데이터 로드를 기반으로 애플리케이션에 적절한 크기를 구성하는 것이 좋습니다. 모든 것을 간단하게 유지하겠습니다. 자동 시작에서 이 캐시를 시작하면 서버가 재부팅될 때마다 캐시가 자동으로 시작됩니다.
이것이 이 캐시를 구성하는 것이 얼마나 간단한지 다음으로 애플리케이션을 실행하는 방법을 보여 드리겠습니다. 하지만 계속 진행하기 전에 한 단계가 더 필요합니다. 시작도 하고 있으니 시간이 좀 걸립니다. 알겠습니다.
통계 모니터링
그래서 모니터링 옵션에 대한 질문이 있었는데 지금 당장 해결해야 한다고 생각합니다. 게시자 및 구독자 응용 프로그램을 실행할 클라이언트로 내 상자를 추가하겠습니다. 이 캐시에 액세스할 수 있는 모든 서버에서도 실행할 수 있습니다. 내 상자를 클라이언트로 추가했으므로 본질적으로 클라이언트 상자입니다. 다른 상자를 추가할 수 있으며 이 상자에서 응용 프로그램을 실행할 수도 있습니다. 관리자 도구에서 사용할 수 있는 몇 가지 통계 창 옵션이 있지만 Pub/Sub의 경우 처음에는 NCache 모니터 도구를 사용한 다음 Pub/Sub에 특별히 사용할 수 있는 몇 가지 카운터도 보여 드리겠습니다.
예를 들어 이것은 내 Pub/Sub 대시입니다. 나는 계속 할 것이고 이것은 NCache 함께 설치되는 모니터 도구 NCache. 필요하다고 생각합니다. 1 x 3이 좋습니다. 좋습니다. 우선, 주제 통계가 있다는 것을 알게 된다면. 그런 다음 초당 몇 개의 메시지가 게시됩니다. 예를 들어 메시지 수와 초당 메시지 만료가 있습니다. 좋은 것 같아요. 그건 그렇고 더 추가할 수도 있습니다. 여기에 여러 가지가 있으며 사용 가능한 PerfMon 카운터도 있습니다. 그것들도 활성화하고 응용 프로그램을 실행하여 이것이 어떻게 작동하는지 보여 드리겠습니다. 카운터를 보여주기만 하면 모니터 도구도 PerfMon 카운터를 사용하고 있습니다. 따라서 여기에서 보고 있는 것은 모니터에서도 볼 수 있으며 그 반대의 경우도 마찬가지입니다. 자, 모두 준비되었습니다. 그래서 여기에도 카운터가 있습니다. 예를 들어 메시지 수, 초당 배달 만료됨. 따라서 숫자 보기, 숫자 보기를 볼 수 있으며 모니터에서도 그래픽 보기를 볼 수 있습니다.
게시자 실행
이제 함께 설치되는 응용 프로그램을 실행하지만 필요한 만큼 많은 메시지를 게시할 수 있도록 약간 조정했습니다. 따라서 이것은 게시자를 위한 앱 구성이고 소비자인 구독을 위한 앱 구성입니다. 알겠습니다. 이 응용 프로그램을 실행하겠습니다. 우선 게시자 응용 프로그램을 시작하고 이것이 어떻게 작동하는지 보여줍니다. 내가 저장하지 않았을 수도 있습니다. 알겠습니다. 루프를 돌릴 필요가 있으니 잠시만 시간을 주세요. 실제로 루프가 있습니다. 알겠습니다. 디버그하겠습니다. 따라서 이 캐시에 연결할 정보가 없습니다. 자, 이것을 알아봅시다. 내 상자를 추가했으니 양해해 주십시오. 이 문제를 빠르게 수정하겠습니다. 몇 분 정도 걸립니다. 추가했지만 오타가 있었을 수 있습니다. 가세요. 잘못된 캐시 이름을 지정했습니다. 바로 여기에서 이름을 검토하겠습니다. 펍서브캐시윈입니다.
데모 캐시였던 어제의 캐시 이름을 사용하고 있었습니다. 그것은 일어난다. 알겠습니다. 빨리 고칠 수 있어서 다행입니다. 그렇지 않으면 총체적 재앙이 되었을 것입니다. 그래서 저는 우리가 좋다고 생각합니다. 따라서 이것은 Publisher.exe가 될 프로그램을 시작하고 XNUMX개의 메시지를 게시합니다. 같은 메시지를 계속해서 게시하고 있습니다. 이 시점에서 게시자가 시작되고 구독자가 아직 시작되지 않았습니다. 그럼 모니터링 정보를 알려드리겠습니다.
물론 이와 관련된 몇 가지 요청이 있습니다. 하지만 눈치채셨겠지만 제 주제는 10번입니다.
항목이 거기에 있고 만료 시간이 경과한 후에 만료된 메시지가 표시되어야 합니다. 제 생각에는 만료 시간을 10분 이상으로 설정하고 있습니다. 이제 몇 가지 더 게시하겠습니다. 여기에 추가로 추가된 항목이 20개 있어야 합니다. 따라서 총 XNUMX개의 항목이 있고 메시지 수가 증가하는 것을 볼 수 있습니다.
이것이 그래프이며 Windows 성능 모니터에서도 동일한 옵션을 볼 수 있습니다. 여기에서 크기와 메시지 수는 이제 20에서 12까지입니다. 주로 일부가 만료되었기 때문입니다. 나는 이미 그 일환으로 더 적은 만료를 사용하고 있다고 생각합니다. 내 생각에는 메시지 수가 올바르게 표시되지 않는 것 같습니다. 내 생각에는 이것이 내 모니터에 따라 20이어야 합니다.
구독자 실행
구독자의 도움으로 이것을 검토해 보겠습니다. 얼마나 많은 메시지를 수신하는지 보겠습니다. 그런데 데모가 끝나면 코드를 보여 드리겠습니다.
따라서 기존 메시지를 가져와야 하고 모든 메시지를 무작위 방식으로 가져왔다고 생각합니다. 이것은 메시지의 비동기식 호출입니다. 메시지가 해당 순서로 배달된다는 보장은 없습니다. 따라서 나중 단계 등에서 첫 번째 메시지를 받을 수 있습니다.
그리고 바로 여기로 돌아오면 메시지 수가 10으로 떨어집니다. 나는 이 카운터를 생각한다, 이것을 한 번 더 검토하자. 이것이 주어진 주제에 대한 메시지를 나타내는지 또는 게시된 전체 메시지를 나타내는지 확실하지 않습니다. 알겠습니다. 올바른 값이 표시되지 않는 반면 이것이 표시되어야 합니다. 그런 메시지를 받은 것 같아요. 따라서 이를 달성하려면 구독자를 닫아야 합니다. 다른 구독자를 실행하겠습니다. 따라서 여러 메시지가 전달되는 것을 볼 수 있습니다. 그런 다음 결론을 내리고 이에 대한 코드 예제를 보여드리겠습니다. 몇 가지 메시지를 더 입력하고 계속 하면 구독자 측에서 이 메시지가 XNUMX개 메시지를 수신한 다음 이 메시지가 몇 개 더 수신되는 것을 볼 수 있습니다. 두 가지 배달 옵션이 있는 경우 이러한 모든 구독자 또는 누구에게나 메시지를 브로드캐스트하도록 선택할 수 있습니다. 맞습니다. 따라서 메시지를 받는 쪽을 기준으로 캐시에서도 메시지가 만료됩니다. 그래서, 그것은 빠른 데모였습니다. 이제 메시지를 게시하기 위해 관련된 세부 사항을 보여 드리겠습니다. 주제 측면의 기능은 무엇입니까? 게시자 측의 기능과 구독자 측의 기능은 무엇입니까? 이 시점에서 질문이 있으면 알려주십시오. 지금 바로 그 질문에 답변해 드리겠습니다. 그렇지 않으면 계속해서 세부적인 아키텍처 측면을 보여드리겠습니다.
의 기본 Pub/Sub 인터페이스 NCache
이것들은 내부의 주요 인터페이스입니다. NCache.
주제
주제가 있습니다. 다시 말하지만, 그것은 소통을 위한 채널입니다. 여기에는 구독자 목록이 포함되어 있으며 게시된 메시지를 연결된 구독자에게 전달합니다.
보내실 내용
그런 다음 주요 페이로드인 메시지가 있습니다. 관심 지점, 구독자의 관심 대상입니다. 직렬화 가능한 페이로드입니다. 어떤 대상이든, 전달하려는 모든 메시지든, 어떤 데이터든 정확할 수 있습니다.
작성자
Publisher는 메시지를 게시하는 응용 프로그램이며 선택적 배달 상태 알림도 받을 수 있습니다. 배달 상태는 켜기로 선택할 수 있는 것이지만 앞서 결정했거나 앞서 논의한 것처럼 게시자는 메시지가 배달될 때까지 기다릴 필요가 없습니다. 계속 진행할 수 있습니다. 따라서 선택적 배송 상태는 필요에 따라 켜거나 끌 수 있는 것입니다.
구독자
구독자는 특정 주제에 대해 스스로 등록하고 모든 메시지를 받습니다.
이제 이것들을 하나씩 검토하고 다이어그램은 우리가 방금 논의한 모든 것을 보여줍니다.
게시자는 메시지를 만들고, 이벤트를 등록하고, 메시지를 보내고, 메시지를 주제로 저장하고, 구독자를 저장하고, 메시지를 보냅니다. 구독자는 구독하고 메시지 알림을 받습니다.
NCache Pub/Sub 주제 인터페이스
이제 주제 인터페이스를 검토해 보겠습니다. 따라서 먼저 다음을 생성할 수 있습니다. NCache Pub/Sub 주제를 선택한 다음 기존 주제에 연결하거나 주제를 삭제할 수도 있습니다. 자, 여기 이 인터페이스에 무엇이 관련되어 있는지 볼까요? 따라서 여기 이 게시자에게 가려면 먼저 프로그램으로 이동해야 하고 이 프로그램에서 알아차리면 캐시 이름이 표시됩니다. 나는 당신이 선택할 수 있는 어떤 주제든 될 수 있는 주제 이름을 얻었고 무작위 메시지인 메시지 카운터를 얻었고 그 다음 나는 구현했고 그 안에 나는 Publisher.start 메소드를 가지고 있습니다. m 캐시가 초기화됩니다. 즉, 캐시에 연결한 다음 주제 생성 인터페이스를 얻게 되며 바로 여기로 돌아오면 IMessagingService가 있습니다. 자, 여기에서 이것을 빨리 보여 드리면.
IMessagingService Interface for managing Topics in NCache
namespace Alachisoft.NCache.Web.Caching
{
public interface IMessagingService
{
ITopic CreateTopic(string topicName);
void DeleteTopic(string topicName);
ITopic GetTopic(string topicName);
}
}CreateTopic 메서드가 있는 IMessagingService 인터페이스, 주제를 삭제하는 DeleteTopic 메서드, 그리고 GetTopic이 있습니다. 이를 하나씩 검토해 보겠습니다. 따라서 메시징 서비스는 주제를 만들거나 기존 주제에 연결할 수 있습니다. 실제로 하고 싶은 일은 메시지 배달, 배달 실패 알림을 활성화할 수 있다는 것입니다. 예를 들어, 바로 여기에서 콜백을 설정할 수 있으며 해당 콜백은 차례로 호출될 수 있지만 이는 선택 사항입니다. 활성화하지 않으려면 반드시 필요하지 않습니다. 따라서 앞서 말했듯이 메시지 전달 알림은 선택 사항이므로 필수로 활성화할 필요가 없습니다. 그것은 전적으로 사용 사례에 달려 있습니다. 활성화하려는 경우 계속 진행할 수 있습니다.
그런 다음 이 응용 프로그램에 대한 사용자 지정 메서드인 게시 메서드, 이에 대한 래퍼가 있고 그 안에서 우리가 실제로 하고 있는 것은 메시지를 구성한 다음 topic.publish 메시지를 사용하는 것입니다. 따라서 이것은 메시지, 주제를 반환합니다. 해당 주제에 대한 일종의 핸들이고 여기서 topic.publish가 실제 방법입니다. 바로 여기에서 빠르게 보여드리겠습니다. 이것은 이름이 있는 ITopic 인터페이스입니다. 메시지 수를 가질 수 있고 만료 시간이 있을 수 있습니다. 잠시 후 이를 보여주고 삭제된 주제에 대한 일부 회신, 메시지 전달 실패 및 그런 다음 주제에 대한 구독을 가질 수 있으며 주제에 대한 메시지도 게시할 수 있습니다. 이것이 제가 보여주고 싶었던 첫 번째 방법입니다. topic.publish를 사용할 수 있다는 것입니다. 잘. 모든 사람에게 필수품으로 또는 누구에게나 배달할 수 있습니다. 이것은 메시지 수준입니다. 그래서 그것은 전달되거나 해당 주제로 보내는 메시지에 대한 전달 옵션입니다. 그리고 여기에 선택적 마지막 부울이 있습니다. 이것을 확인하고 제안하는 내용은 무엇입니까? 이 경우 실패 알림을 받고 싶은지 여부. 따라서 이 경우에는 이것을 true로 설정하지만 끌 수 있으며 그렇게 하면 그에 따라 게시자 측에서 콜백을 호출합니다.
그래서 우리는 여기에서 두 가지 방법을 보았습니다. 주제를 생성할 수 있으며 이와 유사하게 주제를 얻을 수도 있습니다. 대안으로 사용할 수 있는 또 다른 방법입니다. 그러나 이것을 처음 실행하기 때문에 주제 생성을 사용하여 주제에 메시지를 게시하고 필요한 경우 주제를 삭제할 수도 있습니다. 이것은 일부 시나리오이며 이 슬라이드에서 볼 수 있듯이 이와 함께 동일한 예가 표시됩니다.
Create Topic: Code snippet to create a new topic in distributed cache
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.CreateTopic(topicName);따라서 주제를 삭제하면 주제 삭제 콜백이 호출되고 주제 삭제 콜백이 최종 사용자에게 알리거나 게시해야 하는 모든 정보를 알릴 수 있는 곳입니다.
Delete Topic: Deletes an existing Topic distributed
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
cache.MessagingService.DeleteTopic(topicName);
OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.
using (Subscriber subscriber = new Subscriber())
{
// Subscribes on it, using the provided cache-Id and the topic-name.
subscriber.OnTopicDeleted = TopicDeletedCallback;
}
static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
{
Console.WriteLine("Topic '{0}' deleted.", args.TopicName);
}NCache Pub/Sub 메시지 인터페이스
메시징 인터페이스를 살펴보고 여기에서 메시지 무효화 옵션, 메시지 수신 알림, 실패 또는 수신, 실패 알림이 있고 그 일부로 암호화 및 압축이 지원된다는 점에 대해 논의합니다. 따라서 해당 문제에 대한 IMessage 인터페이스를 살펴보겠습니다. 그래서 우리는 바로 여기에 메시지가 있습니다.
namespace Alachisoft.NCache.Runtime.Caching
{
public class Message : IMessage
{
public Message(object payload, TimeSpan? timeSpan = null);
public static TimeSpan NoExpiration { get; }
public string MessageId { get; }
public TimeSpan? ExpirationTime { get; set; }
public object Payload { get; }
public DateTime CreationTime { get; }
}
}그 일부로 사용할 수 있는 것이 무엇인지 봅시다. 따라서 우선 TimeSpan이 있습니다. NoExpiration을 선택하거나 여기에서 TimeSpan ExpirationTime을 메시지 옵션으로 지정하도록 할 수 있습니다. 여기로 돌아와서 시간 기반 만료를 설정하고 있음을 알게 되면 이것에 관해서도, 이것이 바로 여기에서 전달되고 있고 우리에게 시간 범위가 있다는 것을 알게 된다면. 따라서 이것은 프로그램 자체에서 호출됩니다. 그래서, 우리는 "TimeSpan.FromMinutes(5)". 따라서 본질적으로 전달되지 않은 주제는 구독자가 없거나 구독자가 연결이 끊긴 경우 해당 메시지가 지정된 시간 동안 통신 채널에 유지된다는 것을 의미합니다. 일종의 지속성이지만 메시지를 무기한 유지하는 것은 Pub/Sub 플랫폼에 반대하므로 시간 기반이 올바른 옵션입니다. 여기서 특정 시간 동안 메시지를 유지하고 그 후에는 저장소 자체를 제거합니다. 이러한 메시지는 통신 채널에서도 개별적으로 만료되지 않으며 이 만료는 주제 수준 자체에 있을 수 있습니다. 주제 자체에 만료가 있거나 메시지에 개별 만료가 첨부될 수도 있습니다. 따라서 게시자와 구독자가 연결되어 있으면 게시자가 메시지를 게시하고 해당 메시지가 즉시 중계됩니다. 만료될 때까지 기다리지 않습니다. 메시지가 전달된 경우 유지되지 않습니다. 따라서 메시지가 전달되면 즉시 캐시에서 사라집니다. 그래서, 만료를 설정하는 방법입니다.
그런 다음 메시지에 대한 알림을 수신했습니다. 앞서 보여드린 것들입니다. 예를 들어 배달을 볼 수 있습니다. "Publisher.MessageDeliveryFailure" 알림을 받은 다음 메시지, 성공 상태도 메시지에서 생성할 수 있습니다. 따라서 이 옵션의 일부로 켤 수 있는 또 다른 옵션이고 메시지 암호화 및 압축도 수행할 수 있으며 이는 코드 변경 없음 옵션입니다. 당신이해야 할 일은 캐시 자체에 와서 모든 것이 NCache 그 자체. 따라서 압축을 활성화하고 마우스 오른쪽 버튼을 클릭하고 핫 적용 구성을 선택할 수 있습니다.
압축은 크기가 더 큰 개체를 위한 것입니다. 메시지의 페이로드는 크기가 더 크므로 자동으로 압축을 켜야 하며 암호화는 바로 여기에서 또 다른 옵션입니다. 암호화를 활성화해야 하며 이를 위해서는 먼저 통신 채널을 중지하고 캐시를 중지한 다음 암호화를 활성화해야 합니다. 선택할 수 있는 공급자가 많이 있으며 모든 메시지는 암호화된 다음 게시자와 구독자에게 다시 전송됩니다. 나는 그것이 간단하기를 바랍니다. 그래서, 메시지 예제가 바로 여기에 있습니다.
//Payload containing OrderId to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with payload and expiration time set to 150 seconds
Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);주문을 사용하고, 메시지를 구성하고, 만료 시간을 설정한 다음 사용할 수 있습니다. "주제.게시" 그리고 그 메시지를 적절한 주제에 제공하십시오.
메시지 수신 알림
그래서 메시지 수신 알림. 구독자 입장에서도 그런 모습을 보여드리고 싶어요.
Callback invoked when a message is published on the topic
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);
//Register subscribers for Order topic
ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);
private void messageReceivedCallback(object sender, MessageEventArgs args)
{
//perform operations
if (args.Message.Payload is Order ord)
{
//perform operations
}가입자의 입장에서는 캐시에 연결하여 시작하기만 하면 됩니다. 다음을 사용하여 주제에 연결 "_cache.MessagingService.GetTopic". 이것은 내가 이전에 보여 주었던 방법이거나 주제를 생성할 수 있습니다(존재하는 경우). 그런 다음 콜백으로 메시지를 수신할 수 있는 구독을 생성하고 여기에 메시지 수신 콜백이 있습니다. 바로 여기 프로그램에 있어야 한다고 생각합니다. 메시지 수신 콜백. 따라서 이것은 메시지가 수신될 때마다 호출됩니다. 자, 여기까지 예제를 마치겠습니다.
단계별: 주제에 메시지 게시
그래서, 한 번 더 차근차근. Pub/Sub 캐시 클러스터를 초기화하거나 전용 주제를 생성하거나 기존 주제에 연결합니다. 필요한 경우 메시지 배달 이벤트를 등록합니다. 이는 선택 사항입니다. 메시지를 작성하고 별도의 주제에 게시하십시오. 만료를 활성화하고 필요에 따라 배달 옵션을 활성화하면 이를 정당화하는 데 도움이 되는 코드입니다.
public void PublishMessages()
{
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);
//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;
//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;
//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";
//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);
//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);그런 다음 구독자 측에서 캐시에 연결하고 기존 주제를 가져오거나 새 주제를 만듭니다. 메시지 수신을 위한 주제에 대한 구독을 생성합니다. 비동기 이벤트가 될 수신 이벤트를 등록한 다음 주제에서 구독을 취소하고 필요한 경우 삭제하고 이벤트를 삭제할 수 있습니다.
NCache Pub/Sub 모니터링
다음 몇 슬라이드는 모니터링 측면에 초점을 맞출 것입니다. 이것들을 전체적으로 검토해 봅시다. 우리는 이미 PerfMon 카운터 지원 내에서 기본 세부 사항을 다루었습니다. NCache, 대시보드에는 다양한 옵션이 있습니다. 다른 대시보드를 만들어 보겠습니다.
이 모든 것을 추가해 봅시다. 따라서 주제 통계도 있습니다. 예를 들어, 이미 보여드린 주제 통계가 있습니다. 주제 수, 가지고 있는 주제 수. 메시지 수. 주제의 총 크기 및 바이트인 메시지 저장소 크기는 용량 구축에 매우 중요합니다. 얼마나 많은 메시지가 배달되거나 게시되는지 이해하려는 경우 초당 게시된 메시지 및 초당 배달된 메시지를 끌어다 놓으면 일부 메시지 만료 상태와 그 일부가 있을 수 있습니다. 이것이 카운터의 일부입니다. 샘플 애플리케이션을 한 번 더 실행하면 이 모든 작업에 대한 활동이 표시됩니다. 알겠습니다. Enter 키를 여러 번 눌러 계속 부하를 가하고 여기로 돌아오면 모든 활동을 볼 수 있습니다.
220개의 글이 있습니다. 이 시점에서 주제 수는 1입니다. 메시지 개수는 약 220개입니다. 메시지 저장소 크기도 표시됩니다. 메시지가 게시됩니다. 그러나 배달된 메시지도 없고 만료된 메시지도 없으며 구독자를 실행하면 정말 빠를 것입니다. 해당 메시지도 수신된다는 것을 알 수 있습니다. 자, 이제 여기로 돌아오면 여기에서도 활동을 볼 수 있을 것입니다. 메시지도 수신됩니다.
따라서 이렇게 하면 이 카운터를 기록하여 용량을 확인하고, 거기에 있는 전체 주제, 거기에 있는 메시지, 저장소 크기 및 해당 메시지의 만료를 볼 수 있는 프로세스가 완료되며 기반으로 필요한 만큼 많은 주제를 만들 수 있습니다. 내 요구 사항에. Windows PerfMon에서도 동일한 카운터를 사용할 수 있습니다. 따라서 여기에 동일한 세트가 있고 추가로 일부 PowerShell Cmdlet도 있습니다. 예를 들어 바로 여기에서 문서로 이동하면 내가 문서를 빠르게 열 수 있습니다. 따라서 PerfMon Counters라는 세 가지 옵션이 있습니다. NCache 모니터링 및 PowerShell Cmdlet. 어떤 경우에는 도구에만 의존하고 싶을 수도 있습니다. 따라서 해당 목적을 위해 문서를 사용할 수 있으며 PowerShell 가이드 내에서 내가 정말 빨리 검색할 수 있는지 봅시다. 일반적인 링크를 제공했으므로 여기에서 몇 가지 모니터링 옵션을 살펴보겠습니다. 따라서 캐시 이름을 기반으로 주제 이름을 가져올 수 있는 PowerShell Cmdlet인 "Get-Topics"를 볼 수 있습니다. 예를 들어 여기에서 PowerShell을 여는 경우입니다. 이 명령을 사용할 수 있습니다. 이 쪽에서 열도록 하겠습니다. 명확합니다. 좋습니다. 예를 들어 여기 아무 상자에서나 실행할 수 있습니다. 그러면 pubSubCachewin이 캐시 이름입니다. 그것은 나에게 아무 것도주지 않을 것입니다. pubSubCachewin이 아닌 것 같아서 서버 자체에서 실행해야 합니다. 내 주제, 구독자, 게시자 및 메시지 수입니다.
캐시가 어디에 있는지 알기 위해서는 IP 주소가 필요하기 때문에 내 상자에서 작업을 시작하는 이유입니다. 따라서 PowerShell 측에 필요한 몇 가지 통계를 볼 수 있는 몇 가지 도구가 있습니다. 이상으로 데모 부분이 완료되었습니다. 질문이 있으면 알려주세요. 아키텍처에 대한 세부 사항이나 이 커뮤니케이션 채널의 일부로 제공되는 내용에 대해서는 끝까지 시간을 할애할 예정입니다. NCache 메시징 플랫폼과 그 이유 NCache 더 적합합니까?
분산 캐시 아키텍처
우선, NCache 오픈 소스입니다. 따라서 시작할 수 있으며 Pub/Sub는 다음의 오픈 소스 버전에서도 사용할 수 있습니다. NCache. 선형적으로 확장 가능하며 그 이전에는 인메모리입니다. 성능만 추구하고 시작하는 데 높은 로드 요구 사항을 원하지 않는 애플리케이션의 주요 관심 지점입니다. 따라서 성능 문제가 있는 경우 NCache 다시 한 번 기존 Pub/Sub 메시징 플랫폼에 비해 더 적합합니다.
선형적으로 확장 가능하므로 기본적으로 필요한 만큼 서버를 추가할 수 있습니다. 서버 XNUMX개면 충분합니다. 그러나 용량에 영향을 받을 수 있으므로 용량에 도달하면 NCache 서버도. 데이터베이스에서 본 초기 문제입니다. 우리는 그것을 말하는 것이 아닙니다 NCache 이 문제가 표시되지 않습니다. 하나의 서버로 용량에 도달할 수 있고 문제에 대해 더 많은 서버를 가질 수 있지만 더 많은 서버가 용량을 추가할 수도 있습니다. 예를 들어, 이 두 서버는 최대 용량을 사용하고 있으며 애플리케이션의 부하 요구 사항이나 부하가 높다는 것을 미리 알고 있기 때문에 적기입니다. 따라서 더 많은 서버를 추가하고 더 나은 용량 계획을 세워 이를 선점할 수 있습니다. 따라서 더 많은 서버를 즉시 추가할 수 있으며 선형 확장이 가능한 장점이 있습니다.
그런 다음 세 번째 중요한 특징은 필요한 경우 복제 지원도 제공할 수 있으며 이는 안정성을 보장한다는 것입니다. 이미 고가용성이며 서버가 다운되더라도 최종 클라이언트에 영향을 미치지 않거나 게시자 또는 구독자의 플랫폼이 문제 없이 작동합니다. 캐시 클러스터에 하나의 살아남은 노드가 있는 한 Pub/Sub 플랫폼은 계속 작동하고 실행되며 이것이 가능한 이유는 무엇인가요? 본질적으로 동적이기 때문에 가용성이 높습니다.
100% 피어 투 피어 아키텍처 캐시 클러스터입니다. 이를 통해 필요한 만큼 서버를 추가할 수 있으며 이러한 서버는 본질적으로 독립적입니다. 부하를 분산하여 요청 처리 용량에 기여하지만 100% 독립적인 용량으로 작동합니다. 서버가 다운되거나 새 서버가 추가되더라도 캐시에 영향을 미치지 않습니다. 이를 위해 플랫폼을 중지할 필요가 없습니다. 계속 작동할 수 있으므로 클라이언트를 중지하거나 다시 시작할 필요가 없습니다. 서버가 다운되면 남아 있는 노드를 사용하기 시작하기 위해 클라이언트를 다시 시작해야 할 수 있는 기존 소스의 문제입니다. 따라서 클라이언트가 자동으로 조정되고 클러스터 자체가 자가 치유 메커니즘을 통해 100% 가동 시간을 갖는 동적 특성이 있습니다. 서버가 추가되면 클러스터는 새로 추가된 서버에 부하를 분산시키면서 동시에 클라이언트에 이를 알린다.
유사하게, 서버가 다운되거나 실패하는 유지 관리 사례 또는 서버 다운 사례에서 캐시 클러스터는 계속 작동하고 실행됩니다. 이것이 작동하고 클라이언트가 런타임에 알림을 받으려면 하나의 살아남은 노드가 필요합니다. 연결 장애 조치 지원은 클라이언트 측 프로토콜에 내장되어 있습니다. 따라서 클라이언트는 오류를 감지한 다음 자동으로 장애 조치를 취하고 생존 노드를 사용하기 시작하므로 캐시 측과 여기에 연결된 최종 클라이언트에 대해 100% 가동 시간을 보장합니다. 그래서 본질적으로 역동적입니다. 100% P100P 아키텍처입니다. 연결 장애 조치 지원이 내장되어 있으며 클러스터는 자체적으로 자가 치유됩니다. 프로토콜에 내장된 메커니즘입니다. 이는 고가용성 캐시 시나리오인 XNUMX% 가동 시간을 보장합니다.
캐싱 토폴로지: 분할된 캐시
통신 채널의 토폴로지.
Pub/Sub 플랫폼은 데이터를 분할할 수 있습니다. 서버 1과 서버 2에서 데이터를 분할할 수 있습니다. 이는 메시지를 나타내는 데이터 요소입니다. 따라서 일부 메시지는 서버 1에서 전달되고 일부는 서버 2에서 전달됩니다. 배포 알고리즘을 기반으로 하는 완전히 무작위이며 게시자와 구독자가 모든 서버에 연결되어 있습니다. 따라서 일부는 서버 1에 연결되고 일부는 서버 2에 연결되지만 각 서버가 있음을 알면 실제로는 모든 서버에 연결되지만 일부 메시지는 서버 1에서 전달되고 일부는 서버 2에서 전달되는 식입니다. 앞으로. 따라서 메시지 로드는 분산될 것이며 이것은 모든 서버의 메모리 용량을 완전히 활용하고, 메시지를 제공하고, 메시지를 저장하고, 만료 시간에 대해 계산 능력을 논리적 용량에 결합하는 편심 수행입니다. 또한. 따라서 이러한 모든 서비스는 요청 처리 용량에 기여하며 이것이 더 많은 서버를 추가하면 시스템에서 더 많은 용량을 얻을 수 있는 이유입니다. 필요하다.
캐싱 토폴로지: 파티션-복제본 캐시
이것은 백업도 지원하는 파티션 복제 캐시입니다.
서버 1 활성 파티션, (서버) 2에 백업이 있습니다. 따라서 모든 서버는 활성 파티션과 다른 서버의 복제본인 다른 서버의 백업 파티션을 공식화합니다. 서버 1은 서버 2의 활성 백업이고, 서버 2는 3의 활성 백업이며, 서버 3은 1의 활성 백업이며, 서버가 다운되더라도 클러스터는 이를 계속 관리할 수 있습니다. 서버 1이 다운되면 서버 1의 백업이 2에 있으므로 이 백업이 활성화되고 서버 2와 3으로 병합되고 클러스터가 자체적으로 치유되고 서버 2 백업이 켜져 있는 1노드 활성 백업, 활성 수동 메커니즘을 공식화하기 때문입니다. 서버 2 백업은 서버 1에 있습니다. 그리고 최종 사용자에게 완벽하게 원활합니다. 최종 사용자가 이에 영향을 받는 것에 대해 걱정할 필요가 없습니다. 따라서 100% 가동 시간으로 NCache 이 모든 것을 보장합니다.
자, 이것으로 프레젠테이션이 끝나갈 무렵입니다. 알려주세요. 우리는 여러분이 가질 수 있는 몇 가지 질문에 대해 끝까지 집중할 수 있습니다. 그래서 이 시점에서 에디에게 넘길 것입니다. 에디 여기에서 가져올 수 있습니다. 시간 내주셔서 다시 한 번 감사드립니다. 도움이 되었기를 바라며 다음 웨비나에서 다시 뵙기를 기대합니다. 그동안 온라인에서 방금 검토한 기존 웨비나를 검토해야 하는 경우 alachisoft.com/resources 다시한번 상기시켜드리자면, NCache 현재 시장에서 최고의 성능을 제공하는 유일한 기본 응용 프로그램입니다. 곧 다시 뵙기를 기대합니다. 고맙습니다.