스케일링 ASP.NET SignalR 분산 캐시가 있는 앱
녹화된 웨비나
칼 알리와 닉 줄피카르
ASP.NET SignalR 실시간 웹 기능을 응용 프로그램에 추가하기 위해 요즘 매우 일반적으로 사용되는 웹 개발자를 위한 오픈 소스 라이브러리입니다. 당신이 사용할 수있는 ASP.NET SignalR 정보가 제공되는 즉시 서버 측에서 연결된 모든 클라이언트로 콘텐츠를 푸시합니다.
SignalR은 애플리케이션에 실시간 웹 기능을 추가하는 데 필요한 개발 노력을 단순화하는 데 도움이 됩니다. SignalR을 사용할 수 있는 몇 가지 일반적인 응용 프로그램은 채팅 시스템입니다. 사물의 인터넷 IOT (), 게임 애플리케이션, 항공사 예약 시스템, 증권 거래소 애플리케이션 등.
SignalR의 문제는 기본적으로 확장할 수 없다는 것입니다. 그리고 웹 팜을 만들기 위해 Microsoft는 다음을 사용하는 옵션을 제공합니다. SignalR backplane 일반적으로 중앙 메시지 저장소로 정의할 수 있으며 모든 웹 서버가 동시에 연결됩니다. SignalR 메시지는 백플레인을 통해 연결된 모든 최종 클라이언트에 브로드캐스트됩니다.
일반적으로, SignalR backplane 트래픽이 많은 실시간 웹 응용 프로그램의 핵심 요구 사항인 극단적인 메시징 부하를 처리하기 위해 느리고 확장성이 없는 관계형 데이터베이스입니다. SignalR backplane 또한 애플리케이션 측에서 XNUMX% 가동 시간을 가지려면 매우 안정적이고 가용성이 높아야 합니다.
이 웨비나에서는 어떻게 NCache SignalR backplane 실시간 배포 및 확장을 위한 기존 옵션에 비해 더 나은 옵션입니다. ASP.NET SignalR 백플레인이 있는 웹 애플리케이션. 우리는 방법을 보여줍니다 NCache 당신으로 사용할 수 있습니다 SignalR backplane 주요 코딩이 필요하지 않습니다.
시니어 솔루션 아키텍트가 다루는 내용은 다음과 같습니다.
- 장점 소개 ASP.NET SignalR 일반적인 사용 사례
- SignalR 앱 확장 및 기존 백플레인 옵션 관련 문제
- NCache 백플레인은 비교하여 더 나은 옵션입니다.
- 사용 NCache ASP.NET 애플리케이션을 위한 백플레인으로
- NCache Nuget 패키지 SignalR backplane
- 다음을 사용하여 SignalR 앱 생성, 배포 및 실행 NCache 백플레인
그래서, 오늘 우리는 기술로서의 SignalR에 대해 이야기할 것입니다. 어떻게 그리고 어디에서 당신의 애플리케이션 내에서 사용될 수 있는 후보가 무엇이며, 특히 이 시나리오에서 백플레인을 도입할 때 어떻게 그리고 어떻게 가능한 옵션은 무엇이며 기본적으로 어떻게 해결할 수 있습니까? 그래서 나는 그 모든 다른 것들을 다룰 것이고 샘플 제품으로 사용할 것입니다. NCache. 그래서, 우리는 나중에 처음에 그 부분에 대해 다룰 것입니다. 우리는 거기에서 몇 가지 기본 이론을 다룰 것입니다.
SignalR 소개
이제 SignalR에 대한 실제 소개를 살펴보겠습니다. 따라서 다음은 Microsoft 설명서에서 복사한 몇 가지 정의입니다. 그래서, SignalR은 무엇입니까? SignalR은 기본적으로 개발자가 ASP.NET 응용 프로그램 내에서 실시간 웹 기능을 도입하는 데 사용할 수 있는 오픈 소스 라이브러리입니다. 그래서, 제가 여기서 정확히 어떻게 그리고 무엇을 의미하는지 설명하기 위해 예를 드리겠습니다. 예를 들어, 웹 페이지에 액세스하는 사용자가 있고 페이지에 있는 특정 비트의 데이터가 있지만 해당 데이터를 최신 상태로 유지해야 하거나 사용자가 일반적인 시나리오에서 업데이트된 데이터를 얻으려는 경우 , 사용자는 페이지를 새로 고쳐야 합니다. 기본적으로 사용자는 요청을 보내야 하고 업데이트된 데이터가 수신된 것에 대한 응답으로 이것 또는 뒤쪽에서 구현해야 하는 긴 보류가 있어야 합니다. 그러나 SignalR이 있는 경우 이것은 필요하지 않으며 나중에 해당 세부 정보를 얻을 것이며 이것은 SignalR이 매우 좋은 후보인 아주 좋은 사용 사례 중 하나입니다.
따라서 두 번째로 SignalR은 클라이언트 측으로 바로 여러 코드 푸시 콘텐츠를 가질 수 있는 기능을 제공합니다. 따라서 기본적으로 클라이언트가 업데이트된 데이터를 얻기 위해 요청을 보내야 하는 부분은 더 이상 존재할 필요가 없습니다. 따라서 기본적으로 귀하는 클라이언트입니다. 실제로 웹 서버에 연결된 모든 클라이언트는 서버 내에 새로운 데이터가 있는 즉시 업데이트됩니다. 따라서 서버는 클라이언트가 실제로 새 데이터를 요청할 때까지 기다릴 필요가 없습니다. 데이터는 클라이언트에서 자동으로 업데이트됩니다. 따라서 SignalR의 가장 좋은 점은 기능을 사용자에게 노출한다는 것입니다. 따라서 애플리케이션 내에서 SignalR 리소스를 도입하기만 하면 되고 일부 특정 기능을 호출해야 하며 나머지는 모두 SignalR에서 처리됩니다. 따라서 응용 프로그램은 SignalR을 사용하여 예를 들어 클라이언트에서 서비스로, 서버에서 클라이언트로 메시지를 보내게 됩니다. 메시지가 전송되는 방식과 알림을 받는 방식은 SignalR 로직에서 처리합니다. 따라서 애플리케이션 내에서 이를 수행할 필요가 없습니다. 애플리케이션 내에서 이러한 API를 도입하기만 하면 나머지는 모두 SignalR에서 자동으로 처리됩니다. 따라서 이 다이어그램에서 바로 여기를 볼 수 있습니다.
예를 들어 드리겠습니다. 따라서 SignalR에는 Hub라는 개념이 있습니다. 여기 이 다이어그램에서 우리는 서버, 이것은 웹 서버이고 이것은 연결된 클라이언트임을 알 수 있습니다. HTML 또는 JavaScript 클라이언트일 수 있습니다. 따라서 이 서버는 바로 여기에서 클라이언트 측에서 myClientFunc() 함수를 호출할 수 있으며 그 반대의 경우도 마찬가지입니다. 이 도표를 보면.
클라이언트는 이 특정 기능을 호출할 수 있습니다. myServerFunc() 서버 측에서. 따라서 기본적으로 HTTP를 사용하면 상태 비저장 프로토콜이라는 것을 모두 알고 있습니다. 요청이 있고 응답이 있고 다른 것은 없습니다. 나머지는 모두 제거되지만 SignalR을 사용하면 SignalR 아래에서 WebSocket을 사용하여 연결을 유지 관리합니다. 따라서 이것들은 최신 기술을 위한 것이지만 거기에 있는 오래된 기술에서는 기본 기술에서 일반을 사용하지만 서버에서 클라이언트 측으로, 그리고 나서 서버 측에서 기능을 호출할 수 있는 WebSocket 개념을 사용합니다. 클라이언트에서 서버 측으로의 작업은 수행 방법에 따라 다릅니다.
SignalR의 일반적인 사용 사례를 설명하겠습니다. 첫 번째는 채팅 시스템입니다. 이것은 또한 Microsoft 자체에서 공유하는 샘플 프로젝트이며 내 데모에서도 Microsoft에서 제공하는 채팅 시스템을 사용하고 있습니다. NCache 통합되었지만 바로 여기에서 예제로 돌아가 보겠습니다. 따라서 여기에서 전송해야 하는 실시간 메시지가 필요합니다. 예를 들어 그룹 내에 여러 구성원이 있는 그룹이 있고 구성원 중 누군가가 메시지를 보내는 경우 해당 메시지 알림은 다음에서 수신해야 합니다. 그룹의 모든 구성원이 즉시 수행되어야 합니다. 어떤 종류의 지연도 감당할 수 없으며 게임 산업도 마찬가지입니다. 예를 들어 온라인 멀티플레이어 게임이 있고 동일한 세션이 끝날 때 많은 플레이어가 함께 플레이하고 게임의 세부 정보를 모든 플레이어와 동기화해야 하기 때문에 많은 생각을 해야 합니다. .
세 번째 사용 사례는 예를 들어 항공사 예약 시스템입니다. 따라서 티켓 또는 특정 좌석이 예약된 경우 현재 특정 데이터를 보고 있는 다른 모든 사용자 또는 다른 모든 사용자에게 이 특정 티켓 또는 이 특정 좌석이 이미 예약되어 예약할 수 없음을 알려야 합니다. 더 이상.
주식의 비슷한 예는 계속해서 가치가 오르고 내리기 때문입니다. 따라서 클라이언트 측에서 매우 빠르게 업데이트해야 하며 이는 정말 좋은 요구 사항입니다.
다른 하나는 두 번째 화면 콘텐츠로, 광고 또는 표시되어야 하는 기타 알림이 될 수 있으며 마지막으로 장치 인터넷, 사물 인터넷이 있습니다. 기본적으로 이러한 장치는 지속적으로 약간의 데이터를 수집하고 분석하고 알림을 보냅니다. 따라서 이러한 모든 것은 특정 종류의 신뢰성이 필요하며 이러한 것이 수신기에 수신되어야 하는 시급함도 있습니다. 따라서 이러한 모든 사용 사례는 SignalR을 사용할 수 있는 꽤 좋은 시나리오이며 일반적으로 오늘날에 대해 이야기하면 실제로 바로 지금 사용되고 있습니다.
그래서 다음 슬라이드로 넘어갈 수만 있다면. 여러분, 질문이 있는 경우 언제든지 문의할 수 있습니다. 질문이 있으면 Nick이 알려 드리겠습니다. 기꺼이 답변해 드리겠습니다.
SignalR 애플리케이션 확장
이제 SignalR 앱을 확장하는 방법에 대해 이야기해 보겠습니다. 여기 이 예를 보면.
이 예제는 기본적으로 웹 팜이 있고 웹 가든이 될 수도 있음을 보여주지만 웹 팜의 예제를 제공합니다. 따라서 여기에 웹 팜이 있고 여기에 여러 웹 서버가 있고 웹 팜 내에 있는 모든 웹 서버로 들어오는 모든 요청과 관련된 로드 밸런싱이 있습니다. 당신은 이 모든 다른 클라이언트를 가지고 있습니다. 이러한 클라이언트는 웹 팜 내의 모든 웹 서버에 연결됩니다.
따라서 여기에서 이 예를 들면 클라이언트 A는 이 웹 서버에 연결되고 클라이언트 B는 이 웹 서버에 연결되고 클라이언트 C는 이 웹 서버에 연결됩니다. 따라서 여기서 문제는 예를 들어 이 웹 서버가 메시지를 보내야 하는 경우 모든 종류의 메시지 또는 알림을 보내야 한다는 것입니다. 특정 연결된 클라이언트에만 해당 알림을 보낼 수 있으며 이 경우 이 클라이언트 A가 메시지를 보내는 경우 연결된 클라이언트가 이 웹 서버에 대해서만 수신하며 이 경우에는 하나뿐입니다.
따라서 그룹 채팅이 있고 최소한 XNUMX명의 클라이언트 간에 진행되고 있고 XNUMX개의 서로 다른 웹 서버에 연결되어 있다면 어떨까요? 따라서 클라이언트 중 하나가 메시지를 보내면 특정 웹 서버에 연결된 클라이언트만 해당 알림을 받을 수 있기 때문에 이 특정 시나리오에서 다른 클라이언트도 이 메시지를 받을 수 있습니다. 따라서 이 경우 웹 서버에 연결된 클라이언트만 이 알림을 받을 수 있는 것으로 제한되며 이를 제거하기 위해 SignalR은 다음과 같은 용어를 도입했습니다. SignalR Backplane.
SignalR Backplane
이것이 정확히 무엇인지 설명하겠습니다. 따라서 동일한 예를 가지고 있지만 다른 시나리오를 조금 다르게 사용하면 바로 여기에 웹 팜이 있고 그 사이에 로드 밸런서가 있고 모든 클라이언트의 요청이 해당 로드 밸런서를 통해 들어오고 있다고 가정해 보겠습니다. 해당 웹 서비스로 이동합니다.
따라서 이 경우 바로 여기에 공유 버스가 있고 바로 여기 양식 내에 있는 모든 웹 서버에 연결된 공유 저장소가 있습니다. 따라서 XNUMX개의 웹 서버가 있고 이들 모두가 실제로 바로 여기 이 백플레인에 연결되어 있고 이것이 기본적으로 메시지 또는 알림을 전송하거나 브로드캐스트하는 데 사용되는 일반적인 장소라고 가정해 보겠습니다. 연결된 모든 웹 서버에
따라서 이 경우 이 웹 서버가 알림이나 메시지를 생성하는 경우 연결된 클라이언트에 직접 보내지 않습니다. 실제로 먼저 백플레인으로 보내고 백플레인이 이 알림이나 메시지를 수신하면 연결된 모든 웹 서버로 보낸 다음 웹 서버에서 연결된 클라이언트로 보냅니다. 메시지 또는 알림이 해당 특정 웹 서버의 연결된 클라이언트에만 국한되지 않도록 합니다. 예를 들어 특정 웹 팜에 연결된 모든 클라이언트가 수신합니다. 자, 이 단계를 단계별로 진행해 보겠습니다.
예를 들어 이 웹 서버가 보내야 한다는 알림이 있었습니다. 그래서, 가장 먼저 할 일은 바로 여기에서 백플레인에 알리고 백플레인이 바로 여기에서 무엇을 할 것인지, 바로 여기에 연결된 모든 웹 서버에 이를 브로드캐스트하는 것입니다. 따라서 첫 번째 메시지는 백플레인에서 수신한 다음 백플레인은 이를 서버 XNUMX로 보낸 다음 바로 여기에서 서버 XNUMX로 보낸 다음 이 특정 웹 서버의 이 두 개가 시나리오에 연결된 모든 클라이언트에 해당 메시지를 보냈습니다.
따라서 이 경우 여기에 있는 시나리오와 달리 예를 들어 앞에서 언급한 그룹 채팅이 진행 중인 경우 이러한 모든 클라이언트는 일관된 경험이나 보기를 얻지 못하지만 이 경우 바로 여기에 그룹이 있는 경우 채팅이 진행 중이면 모든 클라이언트가 일관된 보기를 갖게 되며 업데이트나 새로운 메시지가 수신되면 즉시 알림을 받게 됩니다. 따라서 이것이 백플레인을 시나리오에 도입하는 주요 이점이지만 지금은 백플레인 시나리오에서 볼 수 있는 제한 사항은 무엇이며 가능한 옵션은 무엇입니까?
병목 현상 SignalR Backplane
괜찮아. 그래서 저는 병목 현상에 대해 언급했습니다. SignalR Backplane. 따라서 다음은 SignalR Backplane 그리고 이것들은 또한 모든 가능한 후보자가 다음으로 사용되도록 표시될 수 있는 기회입니다. SignalR Backplane SignalR 시나리오에서.
대기 시간 및 처리량
따라서 첫 번째는 대기 시간과 처리량입니다. SignalR Backplane 대기 시간이 매우 짧고 처리량이 높아야 합니다. 짧은 대기 시간이 무엇을 의미합니까? 대기 시간은 기본적으로 다음과 같은 시간을 의미합니다. SignalR Backplane 또는 Backplane이 메시지를 수신한 후 처리하는 데 걸리는 시간, 해당 메시지를 처리한 다음 이 시나리오에서 연결된 모든 웹 서비스에 브로드캐스트하거나 보내는 데 걸리는 시간, 즉 대기 시간입니다.
따라서 기본적으로 매우 최소한이어야 합니다. 이것이 의미하는 바는 메시지를 받는 즉시 웹 팜에 연결된 모든 웹 서버에 신속하게 보내야 한다는 것입니다. 예를 들어 처리량은 특정 시간 프레임에 수행할 수 있는 총 메시지 수이며 여기에 있는 측정 척도에 따라 XNUMX초, XNUMX초 또는 XNUMX초가 될 수도 있습니다.
일반적으로 온프레미스 배포 환경 애플리케이션에서는 이러한 데이터베이스가 백플레인과 동일하지만 데이터베이스에는 몇 가지 제한 사항이 있습니다. 데이터베이스는 일반적으로 느리고 확장할 수 없으며 일반적으로 높은 트랜잭션 부하에서 질식됩니다. 따라서 속도가 느리고 단일 서버이고 백업이 있기 때문에 확장할 수 없습니다. 예를 들어 시나리오이지만 단일 서버이고 숫자를 처리할 수 있는 특정 제한이 있는 경우 이후에 들어오는 요청의 수가 트랜잭션에 의한 이러한 알림에 압도되기 시작하고 실제로 애플리케이션에 영향을 미치기 시작할 것입니다. 따라서 기본적으로 환경 내의 웹 서버 수를 확장하여 웹 양식에 증가하는 로드를 처리할 수 있지만 이러한 애플리케이션이 데이터베이스와 연결되어야 할 때 처리할 수 있습니다. 예를 들어, 은행에서 병목 현상이 발생하고 모든 애플리케이션이 성능 부분에서 타격을 받는 곳입니다.
메시지 전달 보장
다음은 메시지 전달을 보장하는 것입니다. SignalR Backplane 신뢰할 수 있어야 하며 보장된 메시지 전달을 보장해야 합니다. 메시지가 모두 누락되었거나 제대로 수신되지 않은 시나리오로 인해 메시지가 배달되지 않은 시나리오가 있어서는 안 됩니다. 따라서 메시지 전달을 보장해야 합니다.
또 다른 하나는 앞서 언급한 것처럼 데이터베이스입니다. 데이터베이스는 극도의 부하에서 질식할 수 있으며 단일 실패 지점에도 있습니다. 따라서 해당 특정 서버가 기본적으로 전체 환경에 다운되고 다운되는 경우 시나리오가 되어서는 안 됩니다. 어떤 시나리오든 비상 시나리오에서 해당 특정 시나리오에서 매우 빠르게 복구할 수 있는 일종의 효율적인 백업이 있어야 합니다.
백플레인의 고가용성
세 번째는 가용성이 높아야 한다는 것입니다. 따라서 SignalR은 어떤 시나리오에서든 고가용성이어야 합니다. 어떤 종류의 문제가 있는 경우 전체 시스템이 이제 다운되어야 합니다. 작업을 계속하는 데 도움이 될 수 있는 일종의 백업이 있어야 하며 상황이 발생하더라도 매우 빠르게 영향을 받지 않아야 합니다. 일종의 백업이 있어야 하며 모든 것이 정상으로 복원될 때까지 모든 것을 유지 관리하거나 환경을 계속 유지할 수 있어야 합니다. 이는 계획된 시나리오에 있을 수 있습니다. 잘못.
여기 이 도표를 보면.
우리는 데이터베이스로 확장성 병목 현상을 볼 수 있습니다. 바로 지금 바로 여기에서 제가 여러분에게 설명하고 있던 것입니다. 모든 클라이언트가 연결되어 있고 요청이 로드 밸런서를 통해 다시 라우팅됩니다. 이것이 바로 웹 팜입니다. . 앞서 언급했듯이 이 웹 팜을 확장할 수 있습니다. 웹 서버의 수를 늘릴 수 있습니다. 그러면 실제로 총 요청 수가 증가합니다. 이 경우 환경은 기본적으로 단일 시점에서 처리할 수 있지만 실제 문제는 다음과 같습니다. 이러한 웹 서버가 뒤쪽에 있는 데이터베이스가 있는 백엔드와 연결해야 하는 경우 모든 시나리오가 될 수 있지만 SignalR뿐만 아니라 다른 시나리오도 될 수 있습니다.
메모리 내 분산 캐시 SignalR Backplane
그래서 해결책을 제시하겠습니다. 이에 대한 솔루션은 인메모리 분산 캐시입니다. SignalR Backplane 그리고 저는 앞서 언급한 것처럼 NCache 이를 위한 샘플 제품으로 NCache 오픈 소스 제품입니다. 다른 버전이 있으며 필요한 경우 해당 버전을 평가할 수 있습니다.
캐시 서버 클러스터
그렇다면 메모리 내 분산 캐시가 무엇인지 설명하겠습니다. 따라서 기본적으로 메모리 내 분산 캐시는 캐시 저렴한 캐시 서버의 클러스터입니다. 따라서 매우 동일한 캐시를 호스팅하는 서로 다른 캐시 서버가 있습니다. 논리적으로는 단일 장치이지만 그 아래에는 이 캐시를 호스팅하는 여러 서버가 있고 일단 함께 있으면 여러 서버가 필요합니다. 그들은 총 계산 능력 자원을 끌어들이고 있을 뿐만 아니라 메모리 자원도 끌어들입니다. 따라서 서버 수가 많기 때문에 기본적으로 특정 설정 시간에 수행할 수 있는 트랜잭션 수와 저장할 수 있는 총 데이터 수를 확장합니다.
지금은 일반적으로 다음과 같이 설명하고 있습니다. 메모리 내 분산 캐시란 무엇입니까? SignalR과 관련하여 말하는 것이 아니라 이러한 모든 기능을 처음에 논의된 병목 현상과 매핑할 것입니다. 따라서 처음에는 설명하기만 하고 이것은 개체 캐싱 시나리오나 세션 캐싱 시나리오에 사용할 수 있는 분산 캐시일 수 있습니다. 지금은 이러한 모든 기능을 위한 것이지만 여기에서도 이러한 기능을 매핑할 것입니다.
서버 간에 동기화된 캐시
따라서 여기에서 여러 대의 여러 서버가 메모리 리소스와 컴퓨팅 파워 리소스의 풀링을 풀링하고 다음은 서비스 전체에서 캐시 동기화입니다. 따라서 다음을 참조하여 NCache 예를 들어 동일한 캐시를 호스팅하는 XNUMX개의 캐시 서버가 있고 캐시에 추가되는 새 데이터가 있는 경우에도 수행합니다. 데이터가 추가되거나 업데이트되거나 제거되는 즉시 업데이트되는 배포 맵이 있습니다.
따라서 서버 중 하나, 캐시 서버 중 하나가 새 항목을 추가하더라도 언제든지 클러스터 내의 다른 모든 서버는 자동으로 즉시 캐시에 새 항목이 추가되었다는 알림을 받습니다. . 따라서 전체 환경이 서로 동기화 상태를 유지하고 데이터가 캐시 내에 보관되는 다양한 토폴로지가 있는지 확인합니다. 이는 별도의 논의이지만 일반적으로 항목이 추가되자마자 클러스터의 모든 서버가 추가되는 새 항목에 대해 알림을 받습니다. 따라서 동일한 의상 내에 있는 모든 서버에서 즉시 볼 수 있도록 합니다.
선형 확장 성
세 번째 서버는 앞서 언급한 것처럼 선형으로 확장할 수 있습니다. 이러한 서버는 여러 대의 서버를 함께 끌어올릴 수 있으며 제한이 없습니다. 여기에 필요한 만큼 서버를 추가할 수 있으며 캐시는 자동으로 조정됩니다. 기본적으로 처리할 수 있는 총 요청 수를 늘리고 동일한 캐시에 추가할 수 있는 전체 구성원 데이터 수도 늘립니다. 따라서 모두 선형적으로 확장 가능합니다. 따라서 애플리케이션 계층을 확장할 때 캐싱 계층도 확장할 수 있으며 이는 데이터베이스의 병목 현상 중 하나였습니다. 데이터베이스 환경을 확장할 수는 없지만 이를 통해 캐시 서버, 전체 캐시를 확실히 확장할 수 있으므로 실제로 애플리케이션 성능도 높일 수 있습니다.
신뢰성을 위한 데이터 복제
네 번째는 신뢰성을 위한 데이터 복제입니다. 따라서 앞서 말씀드린 것처럼 이들은 여러 대의 서버를 하나로 묶은 것입니다. 따라서 토폴로지에 따라 다른 서버에서 유지 관리되는 복제가 있습니다. 따라서 서버 중 하나가 다운되더라도 손실된 서버의 데이터가 다른 서버 중 하나에 복제되어 자동으로 복구 프로세스를 시작한 다음 해당 데이터를 가져와 다시 저장합니다. 캐시의 활성 파티션. 예를 들어 토폴로지로 복제본 파티션에 대해 이야기하는 경우 NCache. 따라서 자동으로 해당 데이터를 가져와 동일한 캐시에 추가합니다. 따라서 서버 중 하나가 없어져도 데이터는 손실되지 않으며 해당 서버에 연결된 클라이언트가 손실된 경우 자동으로 이를 감지하고 클러스터 내에 존재하는 나머지 서비스로 연결을 장애 조치합니다. 또 다른 핵심 사항 중 하나는 단일 실패 지점이 아니라는 것입니다. 따라서 클러스터에 하나의 캐시 서버가 남아 있는 한 여러 개의 서버가 있는 경우 캐시가 작동하고 들어오는 요청에 응답하므로 서버 중 하나가 다운되더라도 전체 캐시가 다운되지 않습니다. 귀하의 환경은 다운되지 않으며 귀하의 애플리케이션은 계속해서 정상적으로 작동합니다. 이제 방금 논의한 이러한 모든 항목이나 이전에 논의한 병목 현상을 매핑할 것입니다. SignalR Backplane.
따라서 여기로 이동하면 첫 번째는 대기 시간과 처리량입니다. 따라서 앞서 언급한 대기 시간은 처리 시간의 양입니다. 따라서 많은 메시지를 생성하는 서버가 많은 경우 해당 요청이 백플레인으로 바로 들어오고 이 경우 백플레인은 다음과 같습니다. Ncache. 따라서 환경이 질식되고 있다고 생각되면 서버 수를 추가할 수 있으며 이는 실제로 해당 수의 요청을 처리하는 총 용량을 증가시킬 것입니다.
여기서 질문해도 될까요? 설정이 얼마나 복잡한지 NCache as SignalR Backplane? 그것은 매우 쉽고 문서에 대한 매우 상세하고 설명된 설명이 있어 작업하는 데 도움이 됩니다. 저는 바로 그 부분과 실습 데모 부분을 살펴보고 이 질문에 대해 언급할 것입니다.
따라서 일반적으로 관찰되는 병목 현상으로 돌아가서 SignalR Backplane 및 매핑 NCache 그것에 대한 일반 장애 캐시 기능. 따라서 앞에서 언급한 것처럼 대기 시간은 실제로 들어오는 요청을 처리할 수 있는 여러 개의 서버가 있기 때문에 매우 낮아집니다. 따라서 자동으로 대기 시간이 줄어들고 당연히 처리량도 증가할 것입니다. 대기 시간이 짧으면 처리량이 자동으로 줄어들고 일반적으로 전반적인 성능이 저하됩니다.
두 번째는 메시지 전달을 보장합니다. 따라서 내에서 NCache 알고리즘 및 논리 클라이언트에서 서버로, 유지 관리되는 많은 검사가 있습니다. 따라서 예를 들어 클라이언트가 클러스터된 캐시에 연결을 시도하고 어떤 이유로든 해당 메시지를 전달할 수 없는 경우 구현되는 내부 재시도가 있습니다. 그래서 클라이언트는 NCache 클라이언트는 자동으로 캐시 서버에 다시 연결을 시도하며 재시도 횟수를 구성할 수 있으므로 모두 구성할 수 있습니다. 따라서 기본적으로 이 경우 클라이언트가 특정 캐시 클러스터에 연결할 수 있고 연결이 이미 유지되고 있는 동안에도 연결이 끊어진 것으로 확인되었는지 확인할 수 있습니다. 다시 말하지만, 해당 특정 시나리오에서는 메시지가 실제로 배달되도록 합니다.
세 번째는 백플레인의 고가용성이며 이것은 캐시를 호스팅하는 서버가 여러 개 있다는 초기에 언급한 핵심 사항 중 하나입니다. 따라서 서버 중 하나가 다운된다고 해서 전체 캐시가 다운되는 것은 아닙니다. 다른 서버는 들어오는 로드를 처리할 수 있습니다. 클라이언트의 연결은 클러스터 내에 있는 나머지 서버로 장애 조치됩니다. 따라서 이러한 방식으로 고가용성을 보장하고 메시지가 실제로 전달되도록 한 다음 마지막으로 애플리케이션 계층에서 확장함에 따라 숫자를 추가할 때 성능이 크게 향상되도록 합니다. 캐싱 계층에서 확장할 수도 있습니다.
Kal 또 다른 질문입니다. 사용할 때마다 성능이 얼마나 향상될 수 있습니까? NCache as SignalR Backplane, 데이터베이스와 비교하거나 벤치마크가 있습니까? SignalR의 경우에는 이러한 벤치마크를 조회해야 할 수도 있지만 일반적으로 벤치마크 측면에서 수행되는 트랜잭션 수 측면에서 나중에 확실히 보여줄 수 있으며 스크린샷이 있었습니다. 그래서, 나는 그것을 보여줄 수 있습니다.
바로 거기. 따라서 이것은 확장성 수치이며 토폴로지에 따라 다르지만 일반적으로 한 번입니다. 따라서 서버 수가 많을수록 실제로 수행할 수 있는 총 트랜잭션 수와 트랜잭션 수를 늘리고 초당 읽기 및 쓰기로 세분화합니다. 따라서 확장할 수 없기 때문에 데이터베이스와 확실히 비교할 수 있습니다. 따라서 데이터베이스와 비교하여 실제로 캐시가 올라오는 시간이 될 것입니다.
괜찮아. 자, 여기로 오세요. 이것은 일반적인 배포입니다. Ncache.
따라서 여기에서 볼 수 있듯이 별도의 캐싱 계층을 갖는 것이 좋지만 애플리케이션과 동일한 서버에 캐시를 가질 수도 있습니다. 따라서 이것도 지원되지만 별도의 캐싱 계층을 갖는 것이 좋습니다. 이를 참조하여 참조 대화를 제공할 것입니다. 따라서 이것은 모든 애플리케이션 서버가 있고 이것이 캐싱 계층인 애플리케이션 계층입니다. . 다시 말하지만, 선형 확장이 가능합니다. 여기에 필요한 만큼 서버를 추가할 수 있습니다. 그런 다음 앞에서 언급한 모든 서버에 특정 하드웨어가 필요하지 않습니다. 그들은 첨단 기술이 필요하지 않거나 저렴한 서버와 NCache 유일한 사전 녹화 NCache .NET 4.0, 그렇지 않으면 NCache 모든 Windows 환경에서 지원됩니다. 권장되는 운영 체제는 Windows Server 2008, 12 및 16이며 .NET 4.0이 포함되어 있으므로 확실히 사용할 수 있습니다. NCache.
설치 유형에는 두 가지 종류가 있습니다. 있다 NCache 실제로 캐시를 호스팅할 수 있는 캐시 서버 설치 remote client 설치. Remote client 로컬 또는 기본적으로 독립 실행형 캐시를 가질 수 있으며 클라이언트가 원격 클러스터 캐시에 연결할 수 있는 라이브러리와 리소스가 있으며 앞에서 언급했듯이 클러스터형 캐시는 캐시 서버 설치에서 호스팅되는 캐시입니다. . 따라서 이것은 일반적인 배포이며 모든 응용 프로그램은 캐싱 계층의 데이터베이스에 연결되고 캐시 계층도 뒤쪽의 데이터베이스와 연결됩니다. 우리는 또한 지원되고 사용할 수 있는 기능이 있습니다. 그래서, NCache 예를 들어 SignalR용 백플레인으로 사용할 수 있을 뿐만 아니라 데이터 캐싱, 세션 캐싱에 사용할 수 있으며 관심이 있는 경우 구성하는 데 도움이 되는 다른 웨비나 및 문서가 있습니다.
괜찮아. 이제 이 다이어그램은 기본적으로 NCache, 그것은 SignalR Backplane.
그래서, 그것은 우리가 처음에 보았던 것과 매우 유사합니다. 여기가 바로 여기 웹 팜이고 여기에서 로드 밸런서를 가정해 보겠습니다. 따라서 모든 클라이언트 요청이 다시 라우팅되고 있으므로 여기에서 평면 백플레인 대신 NCache 여기에서 백플레인으로 사용되며 여기에 여러 서버가 있습니다. 이 경우 앞에서 언급한 것처럼 선형으로 확장할 수 있습니다. 여기에 XNUMX개의 웹 서버와 XNUMX개의 캐시 서버가 있습니다. 따라서 이 경우 이 웹 서버는 알림 또는 메시지를 생성했으며 이 알림을 백플레인으로 보냈습니다. 이 경우 백플레인은 NCache. 무엇 NCache 할것이다? 기본적으로 이 알림을 게시하고 바로 여기 이 메시지의 모든 구독자에게 이 알림을 브로드캐스트합니다. 따라서 이 메시지를 받은 후 NCache, 연결된 모든 웹 서버에 브로드캐스트됩니다. 이 경우와 그 이후에는 연결된 모든 클라이언트로 전송됩니다. 따라서 이러한 방식으로 연결된 모든 클라이언트가 일관된 뷰어를 갖고 애플리케이션에서 작업하는 동안 경험하고 NCache 이 경우 백플레인으로 연결되었습니다. 그리고 이것들은 제가 이미 이야기한 숫자입니다. 따라서 기본적으로 여러 서버를 보유하고 있으므로 현재 수행 중인 읽기 수와 쓰기 수에서 선형 개선이 있음을 알 수 있습니다. 따라서 선형적으로 확장 가능하고 중단이 없으므로 환경 내에서 필요한 만큼 서버를 여기에 추가할 수 있습니다.
데모에 손
따라서 실제 실습 데모 파트로 이동합니다. 여기에서 캐시를 생성하는 방법을 시연할 것입니다. 의제의 일부가 아니지만 다른 웨비나가 있기 때문에 빠르게 훑어보겠습니다. 여기에서 우리는 각각의 모든 세부 사항을 다루고 모범 사례 및 기타 일반적인 권장 사항에 대해 이야기하고 있습니다. 캐시 생성 또는 캐시 생성 프로세스와 관련된 다양한 설정 구성 및 설정.
설치 NCache 및 클러스터형 캐시 생성
따라서 가장 먼저해야 할 일은 설치하고 완료하고 사본을 다운로드하는 것입니다. NCache 웹 사이트에서 다운로드한 다음 사용자 환경에 설치해야 합니다. 나는 두 대의 기계를 가지고 있는데, NCache 이미 설치되어 있고 그것을 사용할 것입니다. 그래서, 나는 그것들에 로그인 할 것입니다. 여기에서 demo1 및 demo2에 로그인했습니다. 그래서, NCache 도구가 온다 NCache 기본적으로 캐시를 만들고 구성하고 작업하고 관리할 수 있는 관리자이므로 기본적으로 캐시를 열 때입니다. NCache 관리자. 이것은 클러스터된 캐시를 마우스 오른쪽 버튼으로 클릭하고 새 클러스터된 캐시 생성을 클릭하면 표시되는 보기입니다.
따라서 모든 캐시의 이름을 지정해야 합니다. 계속해서 이름을 SignalRCache로 지정하겠습니다. 모든 캐시는 앞에서 언급한 대로 이름을 지정해야 하지만 대소문자를 구분하지 않으므로 어떤 방식으로든 사용할 수 있습니다. 다음을 클릭합니다. 이 네가지 토폴로지 이 내용은 다른 웨비나에서 다룹니다.
이것은 응용 프로그램 전략입니다. 모든 것을 기본값으로 유지하고 방금 보여드린 두 개의 캐시 서버인 demo1과 demo2를 구성하겠습니다. 다음을 클릭하면 됩니다. 클러스터가 통신하는 포트입니다. 그래서, NCache TCP/IP 포트를 사용하여 연결을 유지합니다. 그래서 저는 Nestor를 찾고 있습니다. 이것이 캐시 크기입니다. 사용하는 경우 NCache SignalR의 경우 및 SignalR의 BackPlane으로서 크기는 실제로 중요하지 않습니다. 이는 캐시 내에서 유지 관리되고 해당 메시지가 연결된 클라이언트로 전송되자마자 제거될 큐일 뿐이기 때문입니다. 따라서 단일 항목 외에 캐시 및 단일 항목에 더 이상 저장될 것이 없습니다. 나중에 함께 제공되는 실제 샘플을 볼 때 이에 대해 이야기하겠습니다.
따라서 여기에서는 모든 것을 기본값으로 유지하고 캐시가 가득 찬 경우에도 제거되는 것을 원하지 않으므로 Evictions를 끌 것입니다. 마침을 클릭할 때 캐시를 시작하는 이 상자를 선택하고 마침을 클릭하겠습니다. 따라서 다음을 사용하여 환경 내에서 캐시를 만드는 것이 얼마나 쉬운지 알 수 있습니다. NCache. 따라서 캐시가 시작될 때까지 기다린 다음 remote client 그것은 바로 여기 내 개인 컴퓨터가 될 것입니다. 자, 캐시가 시작되고 바로 여기에서 볼 수 있습니다. 이 시점에서 이 제로 활동이 진행되고 있지만 그것은 다른 애플리케이션이 없기 때문입니다. 현재 이 캐시에 기본적으로 연결된 애플리케이션이 없기 때문입니다.
그래서 저는 계속해서 제 머신을 클라이언트 노드로 추가하여 클라이언트를 추가하거나 여기를 마우스 오른쪽 버튼으로 클릭하고 노드 추가를 클릭합니다. 나는 그것에 내 개인 컴퓨터 IP를 줄 것입니다. 그것은 컴퓨터 이름이나 IP가 될 수 있습니다. 둘 다 지원됩니다. 여기에서 마침을 클릭하면 됩니다.
내 머신이 다음으로 추가된 것을 볼 수 있습니다. remote client 바로 여기에. 모든 것이 제대로 작동하는지 확인하기 위해 이 캐시를 빠르게 테스트하겠습니다. 모니터링 도구 NCache. 따라서 사용 중인 경우 NCache 백플레인으로, 당신은 캐시에서 무슨 일이 일어나고 있는지에 대한 아주 자세한 정보를 제공하는 훌륭한 도구인 모니터링 도구를 사용할 수 있습니다. 진행 중이며 실제 조회가 어디서 어떻게 발생하며 전반적으로 개선할 수 있는 사항은 무엇입니까? 따라서 여기에서 캐시 이름을 마우스 오른쪽 버튼으로 클릭하면 모니터 클러스터를 클릭할 수 있습니다. 이 열립니다 NCache 모니터, 캐시를 모니터링하는 데 사용할 수 있습니다. 여기에서 다양한 것들을 보여줍니다. 바로 여기에서 서버 대시보드를 열면 캐시에서 무슨 일이 일어나고 있는지 아주 잘 알 수 있습니다. 다른 그래프, 이것은 CPU 그래프입니다. 사용 중인 총 네트워크, 캐시 크기, 들어오는 총 요청 수 여기에서 내가 하려는 것은 바로 여기 내 개인 상자에서 하는 것입니다. 캐시에 대한 더미 로드를 시뮬레이션하기 위해 StressTest 도구 응용 프로그램을 실행하려고 합니다. 이 도구는 다음과 함께 설치됩니다. NCache. 그래서, 나는 그것을 찾을 것입니다. STR을 입력하면 StressTest 도구가 나타납니다.
그래서 Kal은 데이터를 가져오는 동안 어떤 종류의 메인프레임인지 대답할 수 있습니다. NCache SignalR에 사용? 괜찮아. 그래서 기본적으로 NCache 사용하고 있습니다 게시/구독 모델. 따라서 기본적으로 웹 서버인 이 모든 클라이언트는 게시자이자 구독자로 연결됩니다. 따라서 모든 클라이언트가 실제로 메시지를 게시할 수 있으며 연결된 모든 클라이언트도 구독자입니다. 따라서 그들도 이에 대한 알림을 받게 됩니다. 따라서 기본적으로 Pub/Sub 모델은 완전히 분리된 API와 Pub/Sub의 전체 프레임워크를 가지고 있지만 SignalR Pub/Sub 아래에서 별도로 사용할 수도 있습니다.
샘플 데이터 추가 및 캐시 모니터링
괜찮아. 그래서 StressTest 도구를 열겠습니다. 그래서 이것은 위치입니다. 실제로 있는 곳입니다. C:\프로그램 파일\NCache\bin\도구 그래서 여기에서 StressTest 도구를 찾고 명령 프롬프트에서 인스턴스를 열면 여기로 끌어다 놓을 것입니다. 좋아, 사실, 나는 단지 화면을 지우기 위해 너무 빨리 엔터를 쳤다. 좋아, 내가 하려는 것은 StressTest 도구입니다. 캐시 이름을 지정하고 캐시 이름은 signalrcache입니다. 지금은 그냥 엔터를 치겠습니다. 따라서 바로 여기 이 보기로 돌아가서 통계를 열면 요청이 들어오는 것을 보고 바로 지금 수행해야 합니다. 좋아, 지금 들어오는 요청을 확인하고 바로 여기에서 연결된 두 캐시 서버에 서로 다른 요청이 많이 들어오는 것을 볼 수 있습니다. 따라서 이것은 모든 것이 실제로 잘 작동하고 하나의 요청도 받는 것처럼 보입니다. 바로 여기에서 모니터링 도구를 열면 이 하나의 클라이언트가 여기에 연결되어 있고 하나의 클라이언트가 여기에 연결된 것을 볼 수 있습니다. 여기를 보면 들어오는 총 요청 수가 크게 증가한 것을 알 수 있습니다. 또한 메모리 그래프도 약간의 타격을 받고 있음을 알 수 있습니다.
따라서 실제로 작동하는지 확인하면. 이제 이 도구를 중지하겠습니다. NCache 관리자. 여기를 마우스 오른쪽 버튼으로 클릭하겠습니다. 이 내용을 정리하겠습니다.
SignalR 채팅 샘플 실행
이제 캐시가 설정되고 제대로 작동하므로 테스트를 해보니 제대로 작동하는 것 같습니다. 그래서 제가 할 일은 NCache 기본적으로 구성하는 방법에 대해 단계별로 웹 사이트에 게시된 설명서를 따르겠습니다. 사용할 ASP.NET 응용 프로그램을 구성할 수 있습니다. NCache 백플레인으로. 따라서 설치 디렉토리로 바로 돌아가면 NCache 그것은 c:\program files\에 있습니다.ncache 바로 여기에서 샘플 폴더로 이동한 다음 dotnet으로 이동하고 바로 여기에서 바로 여기를 검색하면 여기에 제공된 SignalRChat 샘플이 있음을 알 수 있습니다. 따라서 이것은 다음과 함께 설치됩니다. NCache 그리고 이것은 바로 제가 데모에서 사용할 바로 그 동일한 것입니다. 이미 여기에서 열렸습니다. 따라서 설명서를 열겠습니다. 이 설명서는 고유한 특정 환경 내에서 구성하는 방법에 대한 단계별 보기를 제공하는 설명서입니다.
자, 여기까지만 가자면. 따라서 가장 먼저해야 할 일은 다음을 설치해야한다는 것입니다. NuGet 패키지 그리고 정확히 어떤 NuGet 패키지에 대해 이야기하고 있는지 보여드리겠습니다. 따라서 여기를 마우스 오른쪽 버튼으로 클릭하고 솔루션용 NuGet 패키지 관리를 클릭하면 됩니다. 자, 여기에서 브라우저로 이동하여 nuget.org를 탐색하고 있는 경우입니다. 난 그냥 검색 할거야 NCache, 알겠습니다. 바로 여기입니다. 조금만 내려가면 놓쳤을 수도 있지만 SignalR 커뮤니티입니다. 시간이 없습니다. 찾을 수 있도록 NuGet 패키지 이름은 다음과 같습니다. Alachisoft.NCache.시그널R. 그래서 여기에 올라와야 합니다. Alachisoft.NCache.시그널R. 따라서 애플리케이션 내에 설치해야 합니다. 가 설치되어 있기 때문에 이 시점에서 설치할 필요가 없습니다. NCache 라이브러리가 필요한 참조가 이미 있지만 사용하지 않는 경우 NCache 설치, 당신은 확실히 이것을 NuGet 패키지로 추가할 수 있습니다. 애플리케이션 제품 프로젝트 내에 설치하기만 하면 됩니다.
다음 단계는 이 두 네임스페이스를 포함하는 것입니다. Alachisoft.NCache.시그널R 그리고 마이크로소프트 마이크로소프트.AspNet.SignalR. 따라서 이것들은 Startup.cs에 도입되어야 합니다. 저는 샘플 프로젝트를 따라갈 것이지만 사용자 고유의 특정 설정을 참조하여 수행해야 합니다. 따라서 바로 여기 Startup.cs로 이동하면 맨 위로 이동합니다. 이 두 가지가 이미 여기에서 참조되고 있음을 알 수 있습니다. Alachisoft.NCache.시그널R 과 마이크로소프트.AspNet.시그널R. 그래서 여기에 이미 추가되었습니다.
다음 단계를 살펴보겠습니다. 이제 web.config를 수정해야 합니다. 그래서 우리는 바로 여기에 이 두 개의 특정 키를 추가해야 하고 이것이 무엇인지 설명하겠습니다. 첫 번째 이름은 캐시라는 이름으로 실제 캐시 이름입니다. 따라서 사용할 캐시를 제공해야 합니다. 캐시는 켜져 있고 실행 중이며 이것을 사용해야 합니다.
두 번째는 짝수 키이며 이것이 다중을 구별하는 것입니다. 따라서 동일한 캐시가 여러 다른 응용 프로그램의 백플레인과 같은 매체로 사용되는 경우입니다. 그렇군요, 이것이 차별화되는 것입니다. 따라서 기본적으로 동일한 값을 가진 모든 응용 프로그램이 알림을 받을 수 있는 캐시 내의 채널이 열립니다. 따라서 서로 통신해야 하는 두 개의 응용 프로그램이 있는 경우 이 값이 같아야 하지만 다른 응용 프로그램이 있는 경우 특정 환경에 따라 변경할 수 있습니다. 그래서 지금 바로 여기에서 Chat이라고 하고 여기 샘플 프로젝트로 돌아가서 web.config로 이동하면 바로 여기에 설정되어 있음을 알 수 있습니다.
캐시 이름이 다르고 내가 하려는 것은 우리가 만든 캐시로 변경할 것입니다. 바로 signalrcache입니다. 앞서 언급했듯이 이것은 캐시 이름이 대소문자를 구분하지 않으므로 이것만 사용하면 됩니다. 그래서 이만 저장하고 넘어가겠습니다. 바로 여기로 돌아가서 이것들은 기본적으로 사용할 수 있는 과부하입니다. 저는 제 환경에서 무엇을 사용하고 있는지 보여줄 것입니다. 처음에는 web.config 내에 처음에 저장한 값을 사용하는 문자열 변수에 등록하기만 하면 됩니다. 이것은 캐시 이름과 채널(예: name)이며 다음을 지정합니다. NCache 사용할 수 있어야 합니다. 기본적으로 애플리케이션에 도입해야 하는 코드는 XNUMX-XNUMX줄에 불과합니다. 잘 이용하셔야 합니다 NCache 애플리케이션 내에서 백플레인으로.
처음에는 그것이 얼마나 어려운지에 대해 언급하는 질문이있었습니다. 구성 NCache 백플레인으로 특정 응용 프로그램에 적합하며 매우 쉽습니다. 따라서 도입해야 하는 코드는 세 줄뿐입니다. NCache 특정 환경의 백플레인 역할을 하고 바로 여기 내 프로젝트로 돌아가면 startup.cs로 이동합니다. 우리는 특정한 동일한 코드를 가지고 있습니다. 값이 실제로 제자리에 있고 바로 여기에 있는지 확인하기 위한 몇 가지 검사가 있습니다. 우리는 바로 여기에 이 전화를 걸었습니다. NCache 이를 위한 백플레인으로 사용됩니다. 이제 제가 할 일은 실제로 이 응용 프로그램을 실행하고 몇 가지 인스턴스를 여는 것입니다. 그래서 지금 이 대화방이 어떻게 작동하는지 보여드릴 수 있습니다. 여기에서 실행을 클릭하면 열릴 것입니다. 괜찮아. 이제 빌드가 완료되었으므로 이제 열어야 합니다. 좋아요, 로드를 기다리기만 하면 됩니다. 그리 오래 걸리지는 않지만 바로 지금입니다.
좋아, 그동안 우리가 사용하고 있는 슬라이드를 빠르게 살펴보겠습니다. 따라서 바로 여기에서 Default.html을 클릭하면 여기에 사용할 이름을 묻는 팝업이 나타나야 합니다. 따라서 이곳은 채팅방이기 때문에 이름으로 으로 자신을 등록해야 합니다. 따라서 메시지를 보낼 때 다른 수신자는 이 메시지가 누구에게서 온 것인지 정확히 알아야 합니다. 그래서 바로 여기에서 제 이름을 묻습니다. 저는 그냥 가서 이름을 Kal로 지정하겠습니다. 나는 hello를 쓰고 그것을 보내려고 할 것이고, 그 동안 바로 여기에서 그것의 다른 인스턴스를 열려고 하고, 그것은 열릴 것입니다. 아직 보내지 않았지만 캐시 이름이 올바른지 확인하고 web.config로 돌아갑니다. 이름을 잘못 지은 것 같아요. 그래서, 그것은 signalrcache입니다. 다시 실행해야 할 수도 있습니다. 캐시 이름이 올바르지 않았기 때문에 이 인스턴스를 닫을 것입니다. 작동하지 않으므로 다시 실행해야 합니다. 괜찮아. 이제 time signalrcache를 한 번 더 확인하겠습니다. 이제 정확합니다. 이 시점에서 인스턴스를 중지하고 있습니다. 좋습니다. 한 번만 더 실행하면 이미 완료되었으므로 더 빨라야 합니다.
그동안 궁금한 점이 있다면? 부담없이 문의해 주십시오. 괜찮아. 자, 빌드가 끝났고 이제 제대로 열어보겠습니다. 칼 여기 질문이 있습니다. SignalR 코어에서도 작동합니까? 예, 작동하기 때문에 NCache 를 지원합니다 .NET Core 또한. 그래서, 그것은 예와 함께 작동합니다. 좋아요 또 다른 질문은 메시징 기능이 무엇입니까 NCache SignalR 이외의 제안? 처음에 SignalR 아래에서 백플레인으로 전체 구현을 언급했듯이, NCache Pub/Sub 모델을 사용하고 있지만 Pub/Sub를 별도로 사용할 수도 있습니다. 항상 SignalR의 백플레인으로 사용해야 하지만 그렇지 않은 경우 이벤트 및 이벤트가 데이터 기반 이벤트가 될 수 있거나 특정 이벤트에 대해 기본적으로 다른 응용 프로그램에 알릴 수 있는 특정 사용자 정의 이벤트가 될 수 있습니다. 최신 항목이 추가, 업데이트 또는 삭제되고 이러한 기능이 있으며 연속 쿼리 기능도 있습니다.
따라서 캐시 내에서 특정 결과 세트를 지정하고 업데이트가 구체적으로 수행되면 결과 세트가 매우 동일한 캐시 내의 여러 항목이 될 수 있고 그 중 하나가 업데이트되면 요청한 클라이언트가 될 것입니다. 그것은 그것에 대해 통보받을 것이기 때문에 이것들도 존재하는 다른 것들입니다. 그래서 저는 그냥 기본을 클릭했습니다. 내 이름을 묻는 메시지가 표시되어야 합니다. 이제 나는 그 이름을 기다리기만 하면 됩니다. 괜찮아. 그래서 이름을 Kal로 지정하고 작동하기를 바랍니다. 그래서 그냥 hello라고 입력하고 보내겠습니다. 지금은 이 링크를 복사하여 여기에 붙여넣겠습니다. 알겠습니다. 이름을 지정하면 Nick이라는 이름을 지정하겠습니다. 자, 여기에서 여기에서 인사와 함께 메시지를 보냈고 여기에서도 수신되었습니다. 그래서, 이것은 Nick의 인사입니다. 그래서 Nick의 인사를 입력하고 보내겠습니다. 그래서 바로 여기에서 Nick이 Nick에게서 이 메시지를 보냈습니다. Kal의 관점을 되돌아보면 여기에서도 마찬가지로 생각해 볼 수 있습니다.
따라서 여기에서 원하는 만큼 여러 메시지를 보낼 수 있으며 이 특정 시나리오에 연결된 모든 클라이언트에 수신됩니다. 그래서 우리는 Kal이 많은 메시지를 보내고 Nick의 관점에서도 수신되었음을 알 수 있습니다. 그래서 그들은 자동으로 업데이트됩니다. Nick에서 마지막 하나를 Nick에서 보내고 그냥 보내면 Nick에서 나온 것을 볼 수 있으며이보기에서도 올바르게 볼 수 있습니다. 여기. 따라서 우리가 생성하고 그가 사용하고 있는 캐시를 빠르게 살펴보면. 여기에 하나의 항목이 추가되었음을 알 수 있습니다. 앞서 언급했듯이 하나의 개체만 추가되고 나머지는 전송되는 동안 일시적으로 유지 관리되는 대기열입니다.
따라서 내부에서 도구를 사용하면 NCache 이름은 덤프 캐시 키이며 캐시 내에 있는 키를 덤프합니다. 그래서 저는 여러분에게 빨리 보여주고 싶습니다. 그리고 우리는 그 이름을 signalrcache로 지정하고 Enter 키를 누릅니다.
캐시에 있는 모든 항목을 가져올 것입니다. 따라서 이 시점에서 그것들은 하나일 뿐이며 여기에 이름이 chat이고 이 문자열 값이 이벤트 키 값에 대해 애플리케이션 내에서 구성한 것과 정확히 동일한 항목이 여기에 배치된 것을 볼 수 있습니다. 따라서 이것은 메시지를 보내고 받기 위해 이 특정 채널을 사용해야 하는 모든 애플리케이션 내에서 사용해야 하는 공통 키입니다. 따라서 이것은 모든 곳에서 동일해야 하며 이 특정 캐시에 연결된 모든 클라이언트 또는 연결된 웹 서버가 알림을 받고 발생하는 그러한 일에 대해 정확히 알 수 있도록 하는 것입니다. 그래서, 그것이 얼마나 쉬운 지 NCache 애플리케이션 내에서 백플레인으로.
여기에서 이미 논의한 내용을 빠르게 훑어보면서 마지막 화면과 마지막 프레젠테이션 슬라이드를 빠르게 마치겠습니다. NCache 그 밑에. Pub/Sub 모델을 사용합니다.
따라서 .NET 응용 프로그램 또는 Java 응용 프로그램이 될 수 있는 클라이언트 응용 프로그램이 연결되어 있고 게시자와 구독자 모두 양방향으로 연결되어 있습니다. 따라서 메시지 추측을 보내는 연결된 클라이언트를 보내는 모든 응용 프로그램은 연결된 모든 클라이언트에 수신하고 이러한 방식으로 모든 메시지가 연결된 모든 클라이언트에서 실제로 수신되도록 합니다.
따라서 오늘의 웨비나에서 논의한 내용을 빠르게 훑어보면 우리가 기술로서의 SignalR에 대해 논의한 것입니다. 그것은 무엇이며 다양한 시나리오에 어떻게 도움이 될 수 있습니까? 응용 프로그램이 클라이언트가 실제로 알림을 보낼 때까지 기다릴 수 없거나 해당 데이터로 응답할 수 있기 때문에 매우 필요한 경우입니다. 그들은 클라이언트가 업데이트된 데이터로 업데이트된 내용을 매우 빠르게 자동으로 알림 받기를 원합니다. 그래서 SignalR이 무엇인지 논의했습니다. 기본적으로 어떻게 작동합니까? 가능한 가능성과 실제로 SignalR이 현재 사용되고 있는 다른 사용 사례는 무엇입니까?
따라서 미래의 사용 사례가 아닙니다. 그것들은 현재 사용 사례이기도 하며 SignalR 앱을 확장하면 일관성에 일종의 문제가 발생할 수 있으며 SignalR 자체에서 백플레인 개념을 도입하여 연결된 모든 클라이언트가 일관된 보기를 얻고 캐시 내에서 진행되는 모든 것을 즉시 알립니다. 질문이 있는 것 같아요.
괜찮아. 따라서 SignalR Backplane. 우리는 이 세 가지 주요 사항에 대해 논의했으며 앞서 언급한 바와 같이 이는 모든 솔루션이 취할 수 있는 기회이기도 하며 우리가 논의한 솔루션은 메모리 내 분산 캐시였습니다. 이 경우였다 NCache 우리는 서로 다른 기능을 매핑했습니다. NCache 이상을 소유하고 있습니다. SignalR Backplane 정말 필요합니까? NCache 그것들에 완벽하게 매핑되었고, 기본적으로는 SignalR 애플리케이션을 위한 백플레인이 되는 것이야말로 훌륭한 유스케이스, 훌륭한 후보였습니다. 그리고 우리는 이에 대해 논의했습니다 NCache. 어떻게 NCache 사용할 수 있습니까? 확장성 수치에 대해 논의하고 함께 설치되는 샘플 프로젝트의 실습 데모도 진행했습니다. NCache 사용 방법과 이 구성의 모든 프로세스를 통해 도움이 되는 이 문서가 바로 여기에 있습니다.
그래서, 제 생각에는 닉이 당신에게로 넘어갑니다. Kal, 감사합니다. 매우 유익한 정보였습니다. 질문이 있는 사람이 있으면 알려주세요. 아니면 질문 상자에 질문을 입력할 수 있습니다. 요약하자면 NCache 솔루션을 사용할 수 있습니다 다운로드 우리 웹사이트 www.alachisoft.com. 커뮤니티 에디션, 오픈 소스 버전 및 Enterprise Edition 다운로드할 수 있는 Enterprise에는 30일 평가판 기간이 제공되며 진행하기 전에 테스트하는 데 사용할 수 있으며 오픈 소스는 물론 무료로 사용할 수 있습니다. 따라서 질문은 없습니다. 참석해 주신 모든 분들께 감사드리며 시간을 내주신 Kal에게 감사의 말씀을 전하고 다음 웨비나에서 뵙기를 기대합니다.