이용 방법 NCache as AppFabric 대안투자

녹화된 웨비나
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)

AppFabric 수명이 다했으며 여기에서 어디로 가야할지 생각하고 있다면 이 웨비나를 시청해야 합니다. 이 웨비나는 .NET 애플리케이션을 마이그레이션하는 다양한 방법을 보여줍니다. AppFabric 에 NCache.

NCache 매우 빠르고 확장 가능한 .NET/.NET Core 분산 캐싱 시스템에 대한 래퍼를 제공합니다. AppFabric 로 마이그레이션할 수 있는 NCache 애플리케이션에서 코드 변경이 거의 없거나 전혀 없습니다. 당신의 Appfabric 애플리케이션에서 사용되는 API는 NCache 원활하게. 에서 제공하는 다른 많은 API 및 기능을 추가로 사용할 수 있습니다. NCache 누락된 고급 캐싱 기능을 위해 AppFabric.

이 웨비나에서 다루는 내용은 다음과 같습니다.

• 개요 AppFabric 수명 종료 문제
• NCache 에 대한 최선의 선택이자 대안입니다. AppFabric
• 마이그레이션을 위한 다양한 방법 NCache
  • 코드 변경 없는 래퍼를 통해
  • 직접 통해 NCache API 호출
  만 제공하는 고급 분산 캐싱 기능 NCache 이벤트
• 실습 예제 및 마이그레이션 시연

오늘의 주제는 "사용 방법"입니다. NCache 로 AppFabric 대안?" 오늘 웨비나는 무수히 많은 주제를 다룰 것입니다. 특히 개요 AppFabric 수명 종료 문제. 뿐만 아니라, 왜 NCache 에 대한 최선의 대안입니다 AppFabric 그리고 우리가 제공하는 모든 고급 분산 캐싱 기능을 대신하여 사용할 수 있습니다. AppFabric 어떻게 할 수 있는지에 대한 실습 예제와 시연을 제공하는 데 사용됩니다. 이주하다 AppFabric 에 NCache?

이제 이것은 라이브 웨비나이므로 언제든지 질문 탭을 사용하여 질문이나 질문 또는 우려 사항을 입력할 수 있으며 귀하에게 답변을 드릴 수 있습니다. 그리고 마지막으로 웨비나 마지막에는 별도의 Q&A 세션도 있을 예정이므로 끝까지 저장하고 싶은 질문이 있는 사람이 있으면 그 질문에 대해서도 알려드릴 수 있습니다. 좋아, 더 이상 고민하지 않고 Ron, 당신은 바닥을 가지고 있습니다.

그래서 오늘의 주제는 매우 구체적인 것입니다. 알다시피, 그것은 덮을거야 AppFabric 수명 종료 문제와 Microsoft 자체에서 이 기술에서 마이그레이션해야 한다고 권장했기 때문입니다. 따라서 다음을 사용하는 경우 AppFabric 여전히 애플리케이션 아키텍처의 일부인 경우 다음과 같은 몇 가지 옵션을 제공합니다. NCache 그 전환이 얼마나 순조로울 수 있는지 보여드리겠습니다. 마이그레이션이 얼마나 쉬운지 AppFabric 사용할 수 있고 NCache 의 일부 확장 기능을 사용할 수 있습니다. NCache 어느 AppFabric 완전히 부족합니다. 그래서, AppFabric 매우 한정된 제품입니다. 예전에는 잘 작동했지만 수명이 다했으므로 백업되지 않습니다. 더 이상 업데이트가 되지 않습니다. 따라서 마이그레이션해야 할 때입니다.

그래서 오늘 우리는 모든 세부 사항을 다룰 것입니다. 사용과 관련하여 다른 옵션은 무엇입니까 NCache, App Fabric의 대체 제품으로 마이그레이션이 얼마나 쉬운지, 사용을 시작할 경우 얻을 수 있는 이점은 무엇입니까? NCache. 따라서 다루어야 할 몇 가지 기술 세부 정보가 있습니다.

개요 AppFabric

그래서, 이야기하자 AppFabric 일반적으로. 나는 당신이 이미 대부분 알고 있다고 확신합니다 AppFabric 그리고 그 아키텍처. 귀하의 환경에서 사용되는 경우 다음을 직접 경험해야 합니다. AppFabric. 메모리 내 .NET 분산 캐싱 시스템입니다. 주로 Windows Server의 일부로 제공되는 무료 분산 캐시로 사용됩니다. 데이터베이스에 여행을 저장하기 위해 캐싱이 필요한 웹 응용 프로그램, 중간 계층 서비스 및 기타 .NET 응용 프로그램에 주로 사용됩니다. Microsoft에서 출시하고 지원했습니다. 2010년에 1.0이 나왔고 1.1년에 2015이 나왔고 그게 마지막 버전이었습니다. AppFabric. 캐싱 API, 사용 방법 AppFabric? 주로 .NET 애플리케이션이 될 것입니다. AppFabric 데이터 클래스를 표시한 다음 Wrapper를 노출하면 다음의 API가 노출됩니다. AppFabric 해당 라이브러리를 통해 일부 공급자를 사용할 수도 있습니다. AppFabric 가지고 있었다. ASP.NET 세션 상태 공급자 및 ASP.NET 출력 캐싱 공급자. 따라서 이것은 코드 변경 옵션이 아니므로 데이터 캐싱을 사용하지 않으려는 경우, 웹 특정 캐싱에 더 중점을 두는 경우 코드 변경 없이 사용할 수 있는 두 가지 기능이었습니다.

AppFabric 아키텍처 다이어그램

다음은 아키텍처 분석입니다. 다음과 관련하여 캐시 호스트라고 하는 캐시 서버가 있다는 것은 매우 간단합니다. AppFabric. 캐시 클러스터를 공식화할 수 있습니다. 몇 가지 제한 사항이 있지만 다수결 원칙이라는 개념이 있었습니다. 최소한 3개의 서버가 있어야 하며 하나의 서버가 다운되면 다수결 규칙을 위반하게 됩니다. 따라서 고가용성과 데이터 안정성이 손상될 수 있으며 Lead Host라는 개념도 있었습니다.

그러나 여기서 아이디어는 캐시를 호스팅하는 캐시 서버가 있다는 것입니다. 그들은 캐싱을 위한 리포지토리를 공식화한 다음 애플리케이션이 여러 서버에서 백업되는 이 캐시 리포지토리에 연결할 수 있으며 캐싱 작업을 수행할 수 있습니다.

PowerShell 기반 캐시 관리 도구가 있었습니다. 캐시 구성 및 클러스터 구성은 일반적으로 스토리지 위치, 파일 시스템 또는 데이터베이스에 있었습니다. 그래서 그것은 또 다른 종속성이었습니다. AppFabric. 따라서 캐시 활성화 애플리케이션 서버 또는 캐시 클라이언트가 이 캐시 서버에 연결하는 방법에 대한 개요가 있습니다. 실제로 환경에서 누가 캐시를 호스팅할 것인지 알 수 있습니다.

AppFabric 이미 인생의 끝입니다. 첫 번째 발표는 2016년 2016월에 나왔습니다. Microsoft는 더 이상 지원되지 않을 것이기 때문에 이 기술에서 마이그레이션해야 한다고 권장하기 시작했습니다. 그들은 20년 XNUMX월에 해당 제품, 이 제품에 대한 지원 수명 주기 종료를 발표한 후 XNUMX년 이내에 주요 스트림 지원을 종료했습니다. 그래서 XNUMX17 그들의 주류 지원이 끝났습니다. AppFabricMicrosoft의 공식 지원과 확장된 지원이 관련됩니다. 현재 몇 년 동안 지원을 연장해 왔지만 현재 마지막 날짜는 2022년이 될 것입니다.

따라서 기본적으로 이것이 Microsoft가 제공한 마지막 확장이 될 것으로 기대합니다. 따라서 그들은 이 기술에서 마이그레이션할 것을 적극 권장합니다. 오픈 소스가 아닙니다. 따라서 백업할 커뮤니티도 없습니다. 제가 이 웨비나를 준비할 때 당신도 아시다시피 온라인 리소스는 AppFabric Microsoft 포털의 도움말 설명서는 사용을 시작할 때 매우 어렵습니다.

따라서 도움 자원을 얻는 것은 매우 어렵습니다. 공식 지원은 더 이상 없습니다. 제한된 확장 지원이 제공됩니다. 더 이상 버그 수정이 제공되지 않습니다. 기능 세트에 더 이상 향상된 기능이 추가되지 않습니다. 다음과 같은 최신 플랫폼을 사용하는 경우 .NET Core, 플랫폼 호환성, 보안 업데이트는 여기에 포함되지 않습니다. 따라서 본질적으로 수명이 다한 것입니다. 이것은 더 이상 사용되지 않는 셸프 제품이며 이것이 Microsoft가 이 제품에서 마이그레이션하고 대안을 사용하도록 권장하는 이유입니다. 그래서 우리는 이 웨비나도 수행하여 사용자가 다음의 일부로 쉬운 마이그레이션 옵션을 갖도록 합니다. NCache, 교체 옵션으로.

App Fabric을 주로 사용하는 것은 매우 위험합니다. 주요 공급업체인 Microsoft가 권장 사항을 제공했기 때문입니다. 프로덕션 배포는 지원, 버그 수정, 개선, 호환성 또는 보안 업데이트가 없기 때문에 위험에 처해 있습니다. 당신은 떠난다. 미션 크리티컬 애플리케이션에서 사용 중일 수 있고 해당 애플리케이션이 AppFabric 문제가 발생하거나 다운되면 어디로 가야할지 모릅니다. 따라서 비즈니스에 영향을 미칠 수 있으며 전반적인 사용자 경험에도 영향을 미칠 수 있습니다.

따라서 마이그레이션을 수행하는 것이 좋습니다. 특히, 쉽게 사용할 수 있는 마이그레이션 옵션이 있는 경우 NCache 제공합니다. 따라서 이 프로젝트를 우선순위에 따라 완료하는 것이 좋습니다. 사실 이 웨비나에서는 이 웨비나가 끝날 무렵 기존 프로젝트를 완벽하게 사용할 수 있습니다. AppFabric 애플리케이션에서 마이그레이션하는 단계별 가이드를 보여드리겠습니다. 이전 AppFabric 에 NCache. 그 응용 프로그램은 사용을 완전히 중단할 수 있습니다. AppFabric 그리고 사용 시작 NCache 그리고 얼마나 간단한지 보여드리겠습니다. 이 웨비나에서 다루게 될 XNUMX단계 프로세스는 사용을 시작하는 방법에 대한 매우 좋은 아이디어를 제공할 것입니다. NCache 대안으로. 지금까지 질문이 있으십니까?

그래서 이것은 단지 몇 가지 소개 세부 사항이었습니다. 방법에 대한 몇 가지 세부 정보 AppFabric 생겨난? 문제는 무엇이며 실제로 마이그레이션하는 방법은 무엇입니까?

NCache 마이그레이션 옵션으로

그래서, NCache 마이그레이션 옵션입니다. 지극히 자연스러운 선택입니다. NCache 100% 네이티브 .NET 제품으로 현재 15년 이상 시장에 나와 있으며 완전한 시장 실적을 보유하고 있으며 많은 견인력과 실제 맞춤형 배포를 많이 사용하고 있습니다. NCache 그들의 응용 프로그램에서 그리고 우리는 다른 산업 분야의 모든 고객을 보유하고 있습니다.

• 따라서 마이그레이션과 관련하여 얻을 수 있는 첫 번째 이점은 AppFabric 에 NCache 즉, Windows 플랫폼을 얻는다는 것입니다. 그래서, AppFabric Windows 기반 제품이며, NCache 또한 기본 Windows 기반 제품입니다. 따라서 우리는 .NET 기반 Caching Server를 보유하고 있으므로 이를 Windows에 기본적으로 배포할 수 있습니다. 당신이 사용하는 경우 AppFabric, 2012 또는 2016 상자를 사용 중일 수 있습니다. 따라서 동일한 운영 체제 세트를 사용하고 계속 설치할 수 있습니다. NCache 같은 상자에. 따라서 다른 기술에서 마이그레이션하기 위해 일치시켜야 하는 특정 하드웨어 요구 사항이나 운영 체제 요구 사항이 없습니다. 따라서 이는 이미 환경에 있는 것과 매우 호환됩니다.
• 가장 오래된 가장 안정적인 .NET 분산 캐시입니다. 우리는 이 분야의 시장 리더입니다. 우리는 사용하고 있는 거대한 고객 기반을 가지고 있습니다. NCache .NET 애플리케이션에서. 부터, AppFabric 또한 .NET API를 기반으로 합니다. 따라서 사용을 시작하는 매우 자연스러운 선택입니다. NCache API를 사용하거나 코드 변경 옵션이 없는 당사의 래퍼 접근 방식을 사용하고 AppFabric 그리고 사용 시작 NCache. 완벽하게 지원됩니다. 오른쪽. 이것이 바로 이전 슬라이드에서 제기한 요점입니다. AppFabric 삶의 끝이다. 어떤 커뮤니티에서도 백업되지 않습니다. 오픈 소스가 아닙니다. 공식적인 지원은 없습니다. 확장 지원을 사용할 수 있지만 결국 중단됩니다. 그래서, 당신은 위험에 처해 있습니다.
• 와 NCache, 클라이언트 관점에서 뿐만 아니라 서버에서 완벽하게 지원되는 소프트웨어를 얻습니다. 성능 문제, 보안 문제, 버그 등 새로운 기능이 필요한 경우 당사에 연락하면 함께 작업할 수 있습니다.
• 훨씬 더 강력하고 기능도 풍부합니다.

그래서 여기에서 고려해야 할 가장 일반적인 몇 가지 요소를 나열했습니다. NCache 대안으로. 주로 .NET 및 Windows 지원 때문입니다. 둘째, 업계 또는 .NET 응용 프로그램 내에서 실적이 있으며 완벽하게 지원됩니다. 공식 정규 및 24x7 지원 옵션은 당사 팀에서 사용할 수 있습니다. 그리고 확장할 수 있는 다양한 기능에 대해 이야기하겠습니다. 따라서 기존 캐싱 사용 사례를 확장할 수 있습니다. 고객이 우리에게 오는 것을 보고 그들은 다음에 대한 사용 사례를 가지고 있습니다. AppFabric 하지만 그들이 입양할 때 NCache 사용 사례를 확장하고 고급 기능을 사용하기 시작합니다. NCache 과 AppFabric 이러한 기능이 완전히 부족합니다. 따라서 고려해야 할 또 다른 요소입니다. NCache 마이그레이션 옵션입니다.

NCache 기업에 배포

NCache 일반적으로 대기업에서 배포하는 방법은 다음과 같습니다. NCache 처럼 보인다. 다시 캐시 클러스터를 호스팅하는 서버 세트가 있습니다. AppFabric, 다수결 규칙이나 리드 호스트 개념이 필요하지 않습니다. 100% PXNUMXP 아키텍처 캐시 클러스터입니다. TCP/IP 기반 클러스터링 프로토콜을 사용합니다. 서버 팀에 캐시 클러스터를 만들고 여기에 연결된 클라이언트 애플리케이션의 요청 처리 용량에 기여합니다. 따라서 이들은 ASP.NET 또는 ASP일 수 있습니다..NET Core 웹 앱. 최신 스택에도 있습니다. .NET 또는 .NET Core 웹 서비스 또는 .NET Core 서버 애플리케이션.

따라서 일반적으로 모든 .NET, .NET Core 또는 Java 응용 프로그램도 연결할 수 있습니다. NCache 그리고 활용 NCache 캐싱. 매우 간단합니다.

2부터 시작할 수 있습니다. NCache 캐시 클러스터를 구성하는 서버는 최소 2개로 고가용성 및 데이터 안정성 기능을 얻을 수 있습니다. 단일 서버도 작동할 수 있지만 최소 2개를 사용하는 것이 좋습니다. NCache 고가용성 및 데이터 안정성을 활용하는 서버. 그리고, 매우 유연합니다. 필요한 만큼 캐시를 생성할 수 있습니다. 크기가 커질 수 있고 메모리가 증가할 수 있으며 채택의 일부로 얻을 수 있는 많은 기능이 있습니다. NCache.

우리는 정기적으로 이 섹션을 매우 자세하게 다룹니다. NCache 건축 웨비나 그러나 이것은 소개 슬라이드에 가깝습니다. 따라서 특정 질문이 있는 경우 알려주세요. NCache 전개.

NCache 애플리케이션이 별도의 상자에 있는 별도의 전용 서버에 배포할 수 있습니다. NCache 별도의 상자에 있거나 NCache 동일한 상자에 있는 응용 프로그램도 마찬가지입니다. 따라서 Windows Server 박스 호스팅 NCache 클라이언트 상자, 웹 서버 상자 역할을 할 수도 있습니다. 애플리케이션이 동일한 시스템에 배포되는 것입니다. NCache 또한 실행 중입니다. 따라서 이는 또한 가능성이 있거나 별도의 캐싱 서버 계층을 가질 수 있고 응용 프로그램이 별도의 상자에 있을 수 있습니다. 그래서 우리는 매우 유연합니다.

그것은에서 사용할 수 있습니다 Microsoft Azure, 뿐만 아니라 AWS 및 모든 퍼블릭 또는 프라이빗 클라우드에서. 당신은 단지 그것을 필요로 .NET Framework 에 대한 전제 조건으로 NCache 그것이 필요한 전부입니다. 내가 말했듯이 매우 유연하고 사용하기 쉬운 제품입니다. App Fabric과 비교하여 AppFabric 에 NCache 채택할 계획이라면.

마이그레이션 옵션

그래서 다음에는 마이그레이션 옵션에 대해 이야기하고 이를 달성하기 위한 실습 예제를 보여드리겠습니다.

앱 데이터 캐싱

따라서 데이터 캐싱의 경우 .NET API가 있다고 논의했지만 다음과 같은 세션 및 출력 캐싱 기능이 있습니다. AppFabric, 따라서 이것은 다음과 같은 전반적인 사용 사례여야 합니다. AppFabric. 현재 실행 중인 라이브 애플리케이션이 있는 경우 데이터 캐싱이 App Fabric을 사용하는 동안 애플리케이션에서 사용해야 하는 가장 일반적인 사용 사례일 가능성이 있습니다.

• 사용 AppFabric 싸개

  따라서 다음을 사용하여 애플리케이션을 마이그레이션하는 방법에 대해 이야기해 보겠습니다. AppFabric 그리고 당신은 사용하기 시작합니다 NCache 대체품으로. 따라서 두 가지 옵션이 있습니다. 우리는 래퍼를 설계했고 애플리케이션 코드를 변경하지 않고 구현했습니다. 코드를 변경할 필요가 없습니다. 당신은 사용을 시작할 수 있습니다 NCache 대체품으로 AppFabric. 당신은 단지 우리를 사용할 필요가 NuGet 네임스페이스를 업데이트합니다. 따라서 우리가 수행한 작업은 래퍼를 구현한 것입니다. AppFabric API를 만들 때마다 응용 프로그램에서 AppFabric 래퍼 구현이 해당 호출을 받고 호출을 시작하는 배후의 API 호출 NCache 매우 간단하고 이동하기 쉬운 옵션입니다. 내가 보여드릴 기존 애플리케이션을 실제로 관리하는 방법입니다. 나는 이것을 나란히 달릴 것이고 당신의 모든 AppFabric API는 NCache 원활하게. 코드 변경이 필요하지 않습니다. 라이브러리, 이름 공간 변경만으로 작업을 완료할 수 있습니다.

• 직접 만들기 NCache API 호출

  두 번째 옵션은 직접 NCache API 부르다. 여기에서 코드를 변경하고 NCache API는 자신을 호출합니다. 교체를 시작할 수 있습니다 AppFabric API 또는 기존 확장을 시작할 수 있습니다. AppFabric 확장된 기능도 사용할 수 있습니다.

이 두 가지 접근 방식을 나란히 사용할 수도 있습니다. 예를 들어, 이미 가지고 있는 것 AppFabric, 래퍼를 사용하여 해당 베이스를 덮은 다음 확장된 풍모. 에서 누락된 기능 AppFabric, 네이티브 API를 통해 사용을 시작할 수 있습니다.

NCache 래퍼 접근 방식

그래서 저는 이 두 가지 측면을 보여드리겠습니다. NCache 샘플 응용 프로그램의 도움으로. 이것이 우리의 래퍼 접근 방식입니다.

실제로 시작하기 전에 환경을 설정하고 방법을 보여 드리겠습니다. NCache 구성 및 설정이 얼마나 쉬운지 NCache 클러스터 환경. 이를 위해 데모 환경에 로그온하겠습니다.

환경 설정 및 캐시 클러스터 생성

이것은 우리입니다 웹 관리 도구. 이는 사용자 환경의 어디에서나 액세스할 수 있습니다. 클라이언트 상자, 응용 프로그램 상자가 될 수 있습니다. 당신의 현재가 될 수 있습니다 AppFabric 서버 상자. 당신은 단지 설치해야합니다 NCache 하나 또는 두 개의 상자에 그리고 한 번 NCache 설치가 완료되면 웹 관리 프로세스를 시작하고 캐시 클러스터를 구성할 수 있습니다.

그래서 나는 가지고있다 NCache 캐시 클러스터 서버로 사용할 두 개의 상자에 설치했습니다. 따라서 여기 클러스터된 캐시로 오기만 하면 됩니다. 그런데 클러스터 캐시, 로컬 캐시, 클러스터 캐시를 만들 수 있습니다. IP 주소 자체에서 액세스할 수 있습니다.

따라서 새로 만들기를 클릭한 다음 이름을 지정할 수 있습니다. 예를 들어 democache입니다. 무엇이든 이름을 지정할 수 있습니다. NCache Binary 및 JSON 직렬화를 기반으로 하므로 이러한 형식 중 하나를 선택할 수 있습니다. Binary를 선택하고 Next를 선택하겠습니다.

알다시피, 함께 NCache 우리는 많은 것을 가지고있다. 캐싱 토폴로지 그리고 나는 당신이 우리의 NCache 이러한 모든 토폴로지를 자세히 다루는 아키텍처 웨비나.

그래서, 분할된 복제 토폴로지, 이것에 대한 간략한 개요를 제공해야 하는 경우 백업된 파티션을 기반으로 합니다. 이것이 우리의 Partition of Replica 토폴로지입니다. 각 서버에는 클라이언트가 연결된 데이터 파티션이 있습니다. 따라서 서버 1과 2는 활성 파티션을 호스팅합니다. 항목 번호 1, 2는 서버 1에 있고 항목 번호 3과 4는 서버 2에 있으며 서버 1은 2에 백업이 있고 서버 2는 서버 1에 백업이 있는 백업 파티션도 있습니다.

따라서 서버가 다운되는 경우 백업이 활성화되고 데이터가 손실되지 않습니다. 따라서 각 서버는 캐시 클러스터의 다른 서버에 백업되며 필요한 만큼의 서버를 가질 수 있습니다. 이 설정과 유사하게 다른 토폴로지가 있습니다. 건축 웨비나. 따라서 Partitioned of Replica를 선택하겠습니다. 모든 것을 단순하게 유지하십시오.

활성 파티션과 다른 서버의 백업 간의 복제 모드는 동기화 또는 비동기일 수 있습니다. Async가 더 빠르기 때문에 Async를 사용하겠습니다. 동기화가 더 안정적이지만 비동기도 꽤 빠릅니다.

그리고 여기에서 내 캐시 클러스터를 호스트할 서버를 지정하겠습니다. 그래서 107과 108 두 개의 상자가 있습니다.

서버 노드와 제거 간의 통신을 위한 해당 캐시, TCP/IP 기반 매개 변수를 켤 수 있는지 살펴보겠습니다. 이후 여기에서 캐시 크기를 지정했습니다. 이 화면에서 캐시 크기도 지정합니다. 따라서 캐시가 가득 차면 수행할 퇴거를 선택할 수도 있습니다. 따라서 이 경우 캐시는 일부 오래된 항목을 제거하고 새 항목을 위한 공간을 만들 수 있습니다.

사용중인 경우 NCache 세션 캐싱을 위해 AppFabric 에 NCache, AppFabric 세션 저장 모듈 NCache 세션 저장소 모듈의 경우 제거를 해제하는 것이 좋습니다. 이는 사용자 데이터이자 민감한 데이터이기 때문입니다. 객체 캐싱 API를 사용하는 경우에도 캐시가 가득 차면 데이터 손실을 감당할 수 있는 경우에만 제거를 켤 수 있습니다. 따라서 이 문제를 완화하기 위해 항상 더 큰 캐시 크기를 제공할 수 있습니다. 완료 시 이 캐시를 시작합니다. 서비스 시작 시 이 캐시를 자동으로 시작합니다. 따라서 서버가 재부팅될 때마다 자동으로 캐시 클러스터에 다시 가입해야 하므로 다운타임이나 데이터 손실이 없습니다. 클러스터는 모든 구성원이 실행 중인 경우 완전히 작동하므로 재시작 시 자동으로 다시 조인해야 합니다. 수동으로 수행해서는 안되며 그게 다입니다.

캐시 클러스터를 구성하는 것이 이렇게 쉽습니다. 보시다시피 107과 108이 있고, democache가 완전히 가동되어 실행 중입니다.

캐시 통계 모니터링

이제 몇 가지 통계를 보여드릴 수 있습니다. 이들은 Windows 성능 카운터입니다. 따라서 Windows 성능 모니터를 통해 Windows 통합 모니터링 시스템을 사용하는 것은 매우 자연스러운 선택입니다.

또한 Windows 성능 카운터와 일부 모니터링 매개 변수를 사용하는 자체 모니터링 도구도 사용할 수 있습니다. NCache 애플리케이션. 예를 들어 클라이언트 연결 수, 일부 사용률, 캐시 호스트 내의 일부 통계 등이 있습니다. 따라서 대기 시간, 추가, 가져오기, 업데이트, 삭제/초 캐시 크기, CPU 그래프, 메모리 그래프, 캐시 수의 총 데이터, CPU 시간을 표시하기 위해 클러스터, 초당 요청, 평균 마이크로초/캐시를 완전히 연결했습니다. 에 의해 지출 NCache, 바로 여기에 시스템 메모리가 있고 연결된 클라이언트 프로세스도 있습니다.

따라서 매우 정교하고 그 위에 클라이언트 대시보드, 서버 및 클라이언트의 보고서 보기가 있으며 자체 대시보드도 추가할 수 있습니다. 예를 들어 새 대시보드를 만드는 경우 이름을 Api Logs로 지정해야 합니다. Create로 이동한 다음 여기에서 카운터를 끌어다 놓을 수 있습니다.

예를 들어 클러스터 작업을 볼 수 있고 초당 추가를 볼 수 있습니다. 따라서 특히 모니터링에 필요한 카운터를 추가할 수 있습니다. NCache 무리. 따라서 현재 실행 중인 클라이언트 애플리케이션이 없으므로 신속하게 하나를 실행하고 이를 위해 test-stress democache라고 말할 것입니다. 따라서 이 응용 프로그램을 실행하자마자 처음에는 약간의 시간이 걸립니다. 이 상자의 PowerShell 창은 약간 지연되지만 이것이 실행되자마자 내 캐시에서 일부 더미 활동을 시뮬레이트하고 초당 요청이 들어오는 것을 볼 수 있습니다.

여기로 가져오면 캐시 작업당 평균 마이크로초가 작업당 100마이크로초보다 조금 적고 초당 추가, 가져오기, 업데이트가 꽤 혼합되어 있습니다. 캐시 크기가 몇 메가바이트씩 증가하고 있습니다. 평균적으로 5킬로바이트 개체 크기에 불과합니다. CPU는 4% 미만, 현재 XNUMX%입니다. 메모리는 추가하는 것이며 모든 카운터 세트가 여기에서 활동을 표시하는 것을 볼 수 있습니다.

여기에도 표시되는 클라이언트 프로세스가 있습니다. 클라이언트 대시보드를 표시하면 이 모든 보고서도 볼 수 있습니다.

따라서 설정하는 것이 얼마나 쉬운지 알려드리기 위한 것입니다. 따라서 이것은 테스트 중 하나이므로 이미 가지고 있다면 AppFabric 서버, 당신이 해야 할 일은 다운로드 NCache 당사 웹 사이트의 소프트웨어를 동일한 서버에 설치하십시오. 고가용성 및 데이터 안정성을 위해 권장하는 최소 요구 사항은 두 대의 서버입니다. 테스트용으로 한 개로 시작할 수도 있지만 프로덕션 환경에서 최소 두 대의 서버를 사용하는 것이 좋습니다. 그런 다음에는 애플리케이션으로 이동하여 동일한 캐시 클러스터를 사용할 수 있습니다.

그런 다음 설치 후에 분명히 방금 수행한 캐시 클러스터 생성을 생성해야 합니다. 그런 다음 응용 프로그램 사용을 시작한 다음 응용 프로그램으로 와서 사용을 시작할 수 있습니다. NCache 마이그레이션 옵션으로 사용할 수 있으며 샘플 애플리케이션의 도움을 받아 보여드리겠습니다.

샘플 실행 AppFabric 어플리케이션

그래서 저는 이 샘플 애플리케이션을 가지고 있습니다. 사실상 동일한 샘플 애플리케이션 XNUMX이며 기본 AppFabric 콘솔 UI와 여기에서 변환한 두 번째 NCache AppFabric 콘솔 UI. 따라서 이 두 개를 열면 완전히 동일한 응용 프로그램이지만 다음과 호환되도록 약간 변경되었습니다. NCache. 이러한 변경 사항에 대해 안내해 드리겠습니다. 이에 대한 별도의 사본이 있어 시연하겠습니다. 그래서 저는 이것을 Startup Project로 설정했습니다. 맞습니다. 그리고 이것을 실행할 계획이며 이것을 실행하기 전에 저는 AppFabric 여기서도 서버가 가동됩니다. 그래서 우리는 AppFabric 섬기는 사람. 현재 통계를 보여드리면 몇 가지가 있습니다. 아시다시피 이것을 다시 시작하고 이것이 다시 시작되는 동안 여기로 돌아와 보겠습니다. 이것은 일반적인 AppFabric, 데이터 캐싱 호출. 여기에서 Program.cs를 보여드리면 보겠습니다.

질문이 있습니까? 나는 당신의 방식으로 하나를 던지고 싶었습니다. 예. 참석자 중 한 명은 다시 슬라이드 XNUMX에서 캐시 클러스터가 Windows 및 Linux에서 실행되고 있으므로 서버를 Linux에서 호스팅할 수 있으며 그렇다면 대시보드 기능은 어떻게 작동하는지 언급했습니다.

아주 좋은 질문입니다. 이것은 웹 기반 관리 도구, ASP에서 구현.NET Core, 맞습니다. Linux 환경에서도 사용할 수 있는 모든 도구가 있습니다. 그래서, 당신의 NCache 서버는 Linux에서 호스팅됩니다. 우선, Linux의 일부인 웹 관리에 계속 액세스할 수 있습니다. 모든 Windows 상자 또는 환경 내의 모든 브라우저에서 액세스할 수 있으며 Linux 모니터링을 위해 아직 Linux에는 PerfMon 카운터가 없습니다.

XNUMXD덴탈의 .NET Core 아직 진화 중이므로 PerfMon 카운터는 아직 없습니다. 그래서 우리는 Linux 환경에 대한 맞춤형 카운터를 제공했습니다. Linux 서버 모니터링에 대해 거의 비슷한 관점을 얻을 수 있습니다. NCache. 따라서 유일한 차이점은 Windows 대신 Linux 상자가 될 것이고 .NET Core 해당 Linux 상자에 설치합니다.

따라서 보기는 동일할 것입니다. 우리가 다른 길을 선택한 것 뿐이야, 한계를 극복하기 위해 .NET Core. PerfMon 카운터가 없으므로 특정 사용 사례에 대한 사용자 지정 모니터링을 구현했습니다. 귀하의 질문에 대한 답변이 되었기를 바랍니다.

그래서 이것을 지우고 현재 통계를 보여 드리겠습니다. 따라서 이것은 같은 이름의 'democache'이며 같은 이름의 캐시를 다음과 함께 사용할 수도 있습니다. NCache 또한. 캐시 이름을 변경할 필요조차 없습니다. 그것이 우리가 이것을 설계한 방법입니다. 자, 이 캐시의 통계를 보여드리겠습니다. 그래서 지금은 아무것도 없습니다 AppFabric 캐시 클러스터. 그래서 이 응용 프로그램을 시작하겠습니다.

그래서 여기서 제 목표는 다음을 사용하여 애플리케이션을 실행하는 것입니다. AppFabric, 작동하는 것을 보여준 다음 이것에서 마이그레이션하고 이것을 다음으로 마이그레이션합니다. NCache 사용 중지 AppFabric 그리고 사용 시작 NCache. 그래서 저는 이것을 실행할 것입니다.

괜찮은. 이것이 제가 디자인한 개인 테스트 케이스이자 샘플 애플리케이션입니다. 모든 API, 아마도 다음의 모든 API를 거치게 됩니다. AppFabric. 그렇기 때문에 이 시점에서 많은 API가 실행되는 것을 볼 수 있습니다. 그래서 저는 이것을 AppFabric 그런 다음 동일한 샘플을 실행하면 알림 테스트도 있을 것입니다. 이 작업이 완료되는 동안 여기에 도킹한 다음 바로 여기로 가져오겠습니다. 실제로 여기에서 이 샘플을 열어 보겠습니다. 좋습니다. 기본적으로 동일한 샘플 응용 프로그램입니다. 괜찮은. 그래서 이것은, 아시다시피, AppFabric 그리고 이 샘플이 몇 가지 추가 작업을 수행했음을 보여드리겠습니다. 그래서 통계를 보여드리겠습니다. 항목 수는 48개, 지역 수는 60개, 요청 수는 154개입니다.

따라서 많은 매개변수가 있으며 캐시의 키를 보여 주면 캐시 내의 일부 통계를 볼 수 있습니다. 그래서 몇 가지 항목이 있습니다. 하나의 주 서버는 현재 하나의 서버만 있지만 캐시에 추가된 지역도 있습니다.

완전히 작동하는 샘플 응용 프로그램입니다. 이제 동일한 샘플을 실행한 다음 만드는 방법과 변경 사항을 수행한 방법도 보여 드리겠습니다. 그래서 저는 우리가 실행한 첫 번째 샘플의 복사본인 이 샘플을 살펴보겠습니다. AppFabric 장비하도록 변경했습니다. NCache. 새 인스턴스를 시작하면 여기에서 실행됩니다. 따라서 동일한 샘플이 다음과 같이 실행되는 것을 볼 수 있습니다. NCache 잠시 후에 모든 변경 사항을 보여 드리겠습니다.

따라서 나란히 비교하면 실제로 도움이 될 것입니다. 샘플 XNUMX에서 기대하는 바는 AppFabric 그리고 우리가 얻는 것 NCache 정확히 동일할 것이며 이를 달성하기 위해 코드를 변경하지 않을 것입니다. 우리가 수행한 모든 단계를 안내해 드리겠습니다. 자, 거의 완성되었습니다. 그래서 맨 위로 가도록하겠습니다. 그건 그렇고 여전히 실행 중입니다. 따라서 노란색 마커는 기본적으로 우리가 수행하고 있는 작업이며 완료되면 녹색으로 표시되고 서버 측에서 오류가 표시되면 진한 빨간색, 더 밝은 오른쪽, 더 진한 빨간색(파싱 측인 경우 클라이언트 측)을 볼 수 있습니다. 그래서 저는 그들에게 색상으로 구분된 보기를 제공했습니다. 따라서 발생했을 수 있는 오류 코드 및 예외를 포함하여 모든 출력이 정확히 동일한 것을 볼 수 있습니다. 따라서 여기에서 시작하여 키 값을 추가하고 존재하지 않는 키를 추가하면 여기에 동일한 결과가 표시됩니다. 따라서 테스트에 항목을 추가하면 동일한 출력이 됩니다. 항목, 항목 XNUMX, 아시다시피 이것도 성공, 오류입니다. 따라서 나란히 있는 모습을 볼 수 있으며 이것은 정확히 일치합니다. NCache, 오른쪽.

그래서 마지막으로 몇 가지 이벤트만 보여드리겠습니다. 따라서 영역도 사용하고 있습니다. 따라서 여기에서 지역 사용 사례를 사용하면 다음에서 동일한 출력을 볼 수 있습니다. NCache 또한. 따라서 영역 지우기, 영역 추가, 영역 테스트 제거는 실제로 예상대로 정확히 수행되고 있습니다. 이것이 우리가 이것을 달성할 수 있었다는 빠른 시연입니다.

관련된 단계가 무엇인지 보여 드리겠습니다. 이제 이것을 닫고 모든 모니터링을 할 수 있도록 할 것입니다. 제가 보여주어야 했지만 우리가 수행한 단계를 보여드리겠습니다. 우리가 한 것은 NuGet 패키지를 추가한 것뿐이며 이를 위해 실제로 이 단계를 단계별로 살펴보겠습니다. 따라서 실제로 해야 할 일은 App Fabric 콘솔 UI입니다. 그래서 사용중입니다 AppFabric 순간.

따라서 가장 먼저 해야 할 일은 NuGet 패키지를 추가하는 것입니다. 따라서 NuGet 패키지 관리로 이동하면 설치된 일부 NuGet 패키지를 볼 수 있거나 일부를 찾아보고 볼 수 있습니다. AppFabric NCache. 이것을 클릭하면 이것을 설치합니다. 이것이 우리의 첫 번째 단계입니다.

따라서 마이그레이션 옵션 내에서 코드 변경 옵션 없이 바로 여기로 돌아와서 가장 먼저 해야 할 일은 다음과 같은 NuGet 패키지를 도입하는 것입니다. AppFabric.싸개.NCache 그런 다음 이 다음 단계는 Microsoft.ApplicationServer.Caching; 네임스페이스 Alachisoft.NCache.데이터.캐싱; 이것은 래퍼 어셈블리와 NCache 그 시점부터 모든 통화를 담당합니다.

당신 앞에서 이것을 하게 해주세요. 그래서 이것은 네이티브 샘플입니다. AppFabric 견본. NuGet이 설치되어 있습니다. 아직 진행 중입니다.

빠른 질문 나는 이것으로 당신의 길을 던집니다. 질문은 태그로 항목을 가져오는 것이 래퍼에서 지원됩니까?

예. 점점, 알다시피, AppFabric 지역이 있습니다. 따라서 내에서 지역을 사용하는 경우 AppFabric, 따라서 태그를 사용한 다음 그룹을 사용하여 이를 지원하지만 사용하려는 경우 NCache 태그, 맞아. 따라서 캐싱 사용을 확장하고 싶고 웨비나 내의 주제이기도 합니다. 이 경우 API를 직접 사용할 수 있습니다. 따라서 지역을 통해 이미 가지고 있는 것을 지원하기 위해 래퍼를 사용하세요. 태그는 뒤에서 사용되고 있으며 특별히 제공되는 태그를 사용하려는 경우 NCache, NCache API. 따라서 직접 사용할 수 있습니다. NCache API도 마찬가지입니다. 그래서, 나는 당신의 질문에 대답하기를 바랍니다.

그래서 저는 이것을 하나씩 살펴볼 것입니다, 맞습니다. 여기 이 슬라이드를 사용하기만 하면 됩니다. Alachisoft.NCache.Data.Caching; 맞아, 그게 여기 아이디어야. 그래서 저는 이것을 통해 캐시에 추가할 것입니다. 에 대한 참조가 없습니다. AppFabric 그러나 이것은 가지고 있습니다. 따라서 이 이름 공간을 포함하기만 하면 됩니다. Alachisoft.NCache.Data.Caching; 그리고 그게 다야.

따라서 NuGet 패키지는 여기에 많은 리소스를 추가했습니다. NCache, 래퍼인 Data.Caching 그리고 NCache 정기 집회와 이 모든 것이 필요한 것입니다. NuGet이 추가 중입니다. NCache 클라이언트 리소스를 애플리케이션에 넣은 다음 하나씩 이동한 다음 이를 교체하기 시작합니다.

여기로 돌아와서 이것을 복사하겠습니다. AppFabric 예를 들어 여기에서 참조를 다음으로 바꿉니다. NCache 얼마나 쉬운지 볼 수 있도록 여러분 앞에서 이 일을 하고 있습니다. 그래서 우리는 계속 진행합니다. 죄송합니다. Alachisoft.NCache.Data.Caching; 이것을 반복합시다. 오타가 있어서 저도 지운 것 같아요. 괜찮은. 그래서 저는 다른 테스트로 넘어갈 것입니다. 이건 괜찮아. 영역 지우기는 괜찮고 영역 만들기는 괜찮습니다. 따라서 모든 지역 테스트는 직접 참조를 사용하지 않지만 태그 테스트가 있습니다. 따라서 이 샘플을 GitHub에도 게시하겠습니다. 그건 그렇고, NuGet은 최신 서비스 팩 정보와 함께 이미 활성화되어 있지만 이 정보는 에 게시하겠습니다. 그래서, 나는 내가 모든 것을 완료했으면 좋겠다. 이것을 다시 빌드하겠습니다. 오류가 있으면 바로 가서 구체적으로 해결하겠습니다. 그래서 저는 이렇게 생각합니다. 괜찮은. 따라서 올바른 래퍼를 사용하고 있는지 확인하겠습니다.

괜찮은. 따라서 이 작업을 완료한 후 몇 가지를 놓친 것 같지만 여기로 돌아와서 클라이언트 측 연결 설정을 추가해야 합니다. 예를 들어 제 경우에는 바로 여기 이 상자인 101입니다. 이 상자는 제 상자이고 구성에는 캐시의 이름이 있어야 합니다.

예를 들어, 우리는 'democache'를 가지고 있었습니다. 그래서 제 로컬 캐시를 사용한 로컬 테스트를 보여드리지만 원격 캐시도 항상 사용할 수 있습니다. 예를 들어, 바로 여기에서 이 캐시를 사용할 수 있습니다. 내 상자를 클라이언트로 추가하겠습니다. 오른쪽에 다음을 추가합니다. 내 상자에는 클라이언트 노드가 있습니다. 예를 들어 101은 클라이언트 시스템입니다.

괜찮은. 자, 이제 모든 설정을 마쳤습니다. 따라서 client.nc conf를 사용하거나 여기에서 클라이언트 상자로 107을 가리킬 수 있습니다.

오른쪽. 따라서 이것은 한 가지이며 앱 구성은 캐시 이름을 가리켜야 합니다. 그래서 저는 여기서 아무것도 바꿀 생각이 없습니다. 이제 실제 캐시로 이 샘플을 실행하겠습니다. 잘 지어졌습니다. 그 후에 나는 그것을 실행할 것입니다. 완료되는 대로 시작 프로젝트로 만들겠습니다. 프로젝트를 시작한 다음 실행해 보겠습니다.

따라서 기본적으로 XNUMX단계 프로세스입니다. NuGet을 포함하고 교체할 수 있습니다. AppFabric 라이브러리, ApplicationServer.Caching Alachisoft. NCache.데이터.캐싱. 응용 프로그램을 다시 빌드하십시오. 오류가 없는지 확인하십시오. 최신 NuGet 패키지를 사용하고 client.nc conf를 업데이트하여 방금 선택한 서버를 가리키도록 합니다. 이 경우에는 서버에서 추가되는 client.nc conf 파일이 있습니다. 이제 클러스터가 구성되었습니다. 해당 서버를 가리키고 바로 여기로 돌아오면 이제 이 서버를 모니터링하고 스트레스 테스트 도구를 종료하겠습니다. 오른쪽. 따라서 응용 프로그램 자체에서 통계를 표시해야 합니다.

따라서 일반적으로 이것이 래퍼 접근 방식을 마이그레이션하고 사용하는 방법의 수명 주기입니다.

직접 NCache API 호출

직접 API 호출 사용법도 보여드리겠습니다. 이제 질문이 있었던 두 번째 접근 방식과 다음을 사용하면 어떻게 됩니까? NCache 태그 또는 NCache 특징? 따라서 많은 고급 기능을 사용할 수 있습니다. 따라서 직접 만들 수 있습니다. NCache 위에서 API 호출 AppFabric 애플리케이션. 따라서 이를 위해 도움말 문서를 가이드로 사용하는 것이 좋습니다. 이것이 바로 다이렉트 API입니다. 그래서, 당신이 해야 할 일은 ICache 캐시 = CacheManager.GetCache 캐시 핸들을 얻은 다음 사용을 시작하십시오. NCache API 및 이를 위해 필요한 모든 것은 SDK를 사용하는 것입니다. 우리는 이 모든 것을 보유하고 있는 범용 애플리케이션에 추가할 수 있는 기능을 제공하는 샘플 애플리케이션을 보유하고 있습니다.

따라서 래퍼 접근 방식을 사용하는 응용 프로그램도 해당 사용을 확장할 수 있으며 사용을 시작합니다. NCache 나중 단계의 API도 마찬가지입니다.

그래서 샘플을 열어서 보여드리면 NCache 견본. 기본 작업은 작업을 완료하는 매우 간단한 샘플 응용 프로그램입니다. 이렇게 기본 동작 샘플이 준비되었습니다. 그것은 매우 간단한 접근 방식, 기본 작업을 가지고 있으므로 추가하기만 하면 됩니다. Alachisoft.NCache.고객 도서관.

그래서 내가 말했듯이 이것을 참조로 사용할 수 있습니다. AppFabric, 예를 들어 Bulk Get Tests를 열면 여기에 이름 공간을 포함할 수 있습니다. 바로 그 안에 이 이름 공간을 실제로 필요한 형식으로 가져올 수 있습니다. 그러니 제발 참아주세요. 샘플에서 아무 것도 변경하고 싶지 않기 때문에 어디에 추가해야 하는지 찾아보겠습니다. 맞아요 그냥 사용하는거 같아요 AppFabric 그 위에 래퍼 테스트. 그래서 저는 이 기본 동작 샘플에 충실해야 한다고 생각합니다. 오른쪽. 따라서 이것은 우리의 ICache 클래스 캐시이고 개체인 새 고객 만들기를 사용할 수 있습니다. 그런 다음 구현인 캐시에 개체 추가라고 말할 수 있습니다. 사용자 지정 구현이지만 이것이 사용 방법입니다. NCache 아피스.

캐시 항목을 구성한 다음 호출할 수 있습니다. 캐시.추가 그리고 이것은 나타냅니다 NCache, 알다시피, API Alachisoft 캐시 객체. 그래서, 그것은 Alachisoft.NCache.클라이언트.ICache.

따라서 캐시 핸들을 반환하고 다음을 사용할 수 있습니다. NCache 그 위에 API. 따라서 내가 언급한 것처럼 래퍼를 통해 마이그레이션을 시작한 다음 그 위에 확장된 API를 사용할 수 있으며 사용할 수 있는 많은 문서 리소스가 있습니다. AppFabric API의 모양과 방법 NCache 아피스. 따라서 사용을 중단하고 싶다면 AppFabric 그리고 사용 시작 NCache API의 경우 처음부터 시작한 다음 이 접근 방식을 사용하거나 간편한 마이그레이션을 위해 래퍼를 사용한 다음 다음을 사용하여 확장하는 병렬 접근 방식을 사용할 수 있습니다. NCache 아피스.

ASP.NET 캐싱 NCache

우리는 이미 이것을 했습니다. 그래서 ASP.NET 세션 캐싱, 다음을 가리키도록 웹 구성 변경을 제공할 수 있는 방식으로 공급자를 변경하기만 하면 됩니다. NCache 세션 저장소 및 출력으로 다음을 가리킬 수 있습니다. NCache 출력 캐싱 공급자로. 이 프런트에서도 자세한 도움말 문서를 사용할 수 있습니다. 예를 들어, 당신이 말한다면 NCache 세션 캐싱은 세션 상태 공급자를 가리키며 마찬가지로 출력 캐싱도 찾을 수 있습니다. 맞습니다. 이것은 웹 구성 내에서 수정해야 하는 것입니다.

<configuration>
  ...
  <sessionState cookieless="false"
                regenerateExpiredSessionId="true"
                mode="Custom"
                customProvider="NCacheSessionProvider"
                timeout="20">
    <providers>
      <add name="NCacheSessionProvider"
          type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"
           cacheName="demoClusteredCache"
           sessionAppId="demoApp"
           exceptionsEnabled="true"
           writeExceptionsToEventLog="false"
           enableLogs="false"
           enableSessionLocking="true"
           sessionLockingRetry="-1"
           emptySessionWhenLocked="false" />       
    </providers>

  </sessionState>
...
</configuration>

바로 여기에 있는 출력 캐싱도 마찬가지입니다. 따라서 제공자 개요를 제공하는 경우 다음을 사용하여 App Fabric 출력 캐싱을 높이기 위해 애플리케이션 내부에 추가해야 하는 항목입니다. NCache 출력 캐싱.

<!-- caching section group -->
<caching>
  <outputCache defaultProvider ="NOutputCacheProvider">
    <providers>
    <add name="NOutputCacheProvider" 
         type= "Alachisoft.NCache.OutputCacheProvider.NOutputCacheProvider, Alachisoft.NCache.OutputCacheProvider, 
         Version=x.x.x.x, Culture=neutral, PublicKeyToken=cff5926ed6a53769" 
         cacheName="demoClusteredCache" 
         exceptionsEnabled="false"enableDetailLogs="false" 
         enableLogs="true" 
         writeExceptionsToEventLog="false"/>"
    </providers>
  </outputCache>
</caching>

그리고 왼쪽에서 다음과 같은 목록을 볼 수 있습니다. NCache 거대하다. 다중 사이트 세션 지원되며, 보기 상태 공급자가 지원되지만 누락되었습니다. AppFabric. 출력 캐싱 사용자 지정 후크를 사용하는 것은 NCache. 마찬가지로, 우리는 SignalR Backplane, ASP.NET Core 응답 캐싱, ASP.NET Core SignalR Backplane. 따라서 이 목록은 매우 광범위한 것입니다. AppFabric.

WAN 복제

그리고 일반적으로 NCache 에 비해 100% PXNUMXP 아키텍처입니다. AppFabric. 비교할 수 있는 많은 캐싱 토폴로지를 검토할 수 있습니다. WAN 복제를 사용할 수 있습니다. 다중 데이터 센터 지원이 가능합니다. NCache활성-수동, 활성-활성 또는 3개 이상의 활성-활성 데이터 센터를 사용할 수 있습니다.

우리는 이미 백업에 대해 논의한 수많은 고객을 보유하고 있습니다. NCache 는 Windows 및 .NET 환경에 활발히 배포되고 있습니다. 이것으로 오늘 세션을 거의 마치겠습니다. 질문이 있으면 알려주세요.

론에게 질문이 하나 있습니다. 질문은 우리의 AppFabric 우리가 가지고 있는 캐시 클라이언트 래퍼. API와 app.config를 통해 모든 클러스터 노드, 포트, 시간 초과 설정 등을 제공합니다. 이제 래퍼를 사용하여 API와 구성을 통해 동일한 것을 제공할 수 있습니까?

예, 일반적으로 인라인 매개변수도 있기 때문에 가능합니다. 따라서 래퍼는 최소한의 코드 변경 및 구성 변경으로 캐시에 연결할 수 있도록 설계되었습니다. 그래서 그것은 그런 식으로 설계되었습니다. 그래서 마이그레이션이 매우 쉬운 옵션인 것처럼 보이게 만들고 싶었습니다. 따라서 구성 수준 변경 사항만 표시했지만 인라인으로 무엇이든 제공하는 데 관심이 있는 경우 초기화 매개변수가 있습니다. 따라서 서버, 서버 1, 서버 2, 서버 3 포트 목록을 제공할 수 있는 초기화 매개변수가 있습니다. 지금까지 client.ncconf의 일부로 본 모든 클라이언트 측 설정을 여기에서 열어 보겠습니다. 따라서 이들은 응용 프로그램 코드 내에서도 지정할 수 있는 구성 설정입니다. 그래서 그것은 가능성입니다.

그래서 참석자 중 한 명이 공연 정보에 대해 묻고 있습니다. 예를 들어, 대역폭.

NCache 100% 선형 확장성을 달성하기 위해 응용 프로그램을 갖추는 능력이 있습니다. 따라서 점점 더 많은 서버를 추가할 수 있으며 요청 처리 용량이 증가할 뿐입니다. 따라서 일반적인 용도의 아이디어를 원한다면 벤치마크를 검토하는 것이 좋습니다. 이것을 보여드리겠습니다. 우리는 벤치마크를 게시했습니다. 아시다시피 초당 처리량 작업은 단 5개입니다. NCache 서버, 우리는 초당 2백만 요청을 달성할 수 있었습니다. 네, 그건 여러분이 검토할 수 있고 여기에서도 볼 수 있는 것입니다. 우리는 방금 5개를 사용했습니다. NCache 서버. 거기에 비디오 데모 이것에 대해서도. 따라서 이것을 검토하고 싶다면 백서 그런 다음 이 테스트의 비디오 라이브 데모가 있습니다. 여기서 우리는 2대의 서버로 시작하여 약간의 처리량과 요청 처리 용량을 달성할 수 있었고 점점 더 많은 부하를 가하여 서버 수를 늘릴 수 있었습니다. 단 5개의 노드 클러스터로 초당 2백만 작업을 달성할 수 있었습니다.

따라서 서버 리소스에 관한 한, 귀하의 질문이 필요한 대역폭이나 서버 리소스에 더 초점이 맞춰져 있다면 이들은 꽤 고급형인 AWS 서버였습니다. 로 달성할 수 있습니다 NCache. 그래서 우리는 서버를 한계까지 확장할 수 있었고 초당 2백만 요청을 얻을 수 있었습니다. 그러나 8Gig 이상의 메모리 요구 사항을 가진 1기가비트 네트워크 인터페이스 카드와 함께 최대 16개의 코어와 함께 웹 서버 종류의 구성을 사용할 수 있습니다. 따라서 8Gig도 좋지만 16Gig를 권장합니다. 따라서 데이터를 호스팅하기에 충분한 메모리가 있습니다.

왜? NCache 보다 나은 솔루션 Redis?

따라서 기본적으로 상위 XNUMX가지 이유를 제시해야 한다면 우선 .NET과 네이티브가 아닌 .NET의 차이입니다. Redis Windows와 잘 호환되지 않습니다. 타사인 Microsoft Open Tech에서 지원하는 포팅된 버전이 있습니다. Redis 실험실 또는 Redis 오픈 소스 자체는 사용하지 말 것을 권장합니다. Redis Windows 플랫폼에서. 그래서 비교해보면 AppFabric NCache 더 적합합니다. 주로 같은 스택에 있기 때문에 AppFabric & Redis 아니다. Redis 일반적으로 Linux 기반 제품에 가깝습니다. 반면 NCache Windows 및 Linux 기반 제품입니다.

많은 고가용성 문제가 있습니다. Redis. Redis 클러스터는 100% PXNUMXP 아키텍처가 아닙니다. NCache. NCache 모든 서버를 오프라인으로 전환할 수 있는 완전한 PXNUMXP 아키텍처 캐시 클러스터입니다. 연결된 캐시 클라이언트에 영향을 미치지 않으며 데이터 손실도 발생하지 않습니다. 그런 다음 많은 기능이 누락되었습니다. Redis. 클라이언트 캐시와 같은 것은 없습니다. 최근에 도입했지만 매우 기본적입니다. 우리는 2008년부터 클라이언트 캐시를 가지고 있습니다. 따라서 매우 오래된 기능이며 다음의 일부로 매우 향상되었습니다. NCache. 브리지, 서버 측 코드 SQL 유사 검색, Read-Through, Write-Through 핸들러, 캐시 로더, 이러한 모든 기능이 누락되었습니다. Redis 우리 웹사이트에 게시된 비교 문서를 빠르게 살펴보시기 바랍니다. 비교 페이지. 그래서, 당신은 볼 수 있습니다 하늘빛 Redis vs NCache, Redis vs NCache 요약 차이, Redis vs NCache (슬라이드 데크) 그리고 다음에 대한 일반적인 목적의 정보가 있습니다. NCache.

그래서 제가 이것을 아주 빠르게 보여드리고 질문이 있으면 알려드리겠습니다. 저는 여기에 등록되어 있으므로 로그인하겠습니다. 물론입니다. 이에 대한 후속 질문은 Async Replication에 대한 질문이었습니다.

비동기 복제 동작이 안전하다고 가정할 수 있습니까? 보장됩니까?

그것은, 그것은…. 그래서, 당신은 알고 있습니다. 매우 드문 시나리오인 중간에 실패하면 해당 업데이트를 잃을 수 있지만 매우 빠릅니다. 전용 스레드가 있습니다. 도표를 보여드리고 다시 첫 번째 질문으로 돌아가겠습니다. 자, 먼저 이 질문을 해결해 봅시다. 따라서 서버 1 활성 파티션은 응용 프로그램이 여기에 무언가를 추가하자마자 반환합니다. NCache 백업에서 업데이트를 담당하며 비동기 및 동기화 옵션이 있습니다.

따라서 비동기식은 꽤 빠릅니다. 1밀리초 미만이며 서버 XNUMX에서 호출이 트리거되고 복제하는 동안 이 서버가 다운되어 업데이트를 받을 수 없는 시나리오를 재현할 수 있다면 매우 기쁠 것입니다. 내에서 매우 드문 시나리오입니다. NCache. QA 팀에서도 이를 재현하기 위해 정말 열심히 노력하지만 그렇게 할 수 없습니다. 따라서 약간의 밀리초 미만의 지연으로 전용 스레드가 백업을 업데이트하고 해당 서버가 다운되는 동안 업데이트를 잃을 가능성이 약간 있지만 제가 말했듯이 재현하는 것은 매우 드문 시나리오이며 동기화 옵션이 있습니다. 이 상황을 수용하기 위해 사용할 수도 있습니다. 항상 백업을 업데이트해야 하는 것이 걱정된다면 클라이언트가 활성 및 백업을 한 번에 업데이트하는 동기화 업데이트를 사용할 수 있습니다. 트랜잭션 작업입니다. 중간에 실패하면 전체 작업을 롤백합니다. 따라서 귀하의 질문이 그것에 초점을 맞추면 매우 안전합니다.

그래서 다시 돌아와서 Redis이있다 하늘빛 Redis vs NCache. 따라서 기능 수준 비교를 볼 수 있으며 Azure가 있는 목록을 볼 수 있습니다. Redis 이 모든 측면에서 부분적인 역할과 제한적인 지원을 받습니다. 따라서 고가용성은 부분적으로 지원되고 캐시 토폴로지는 제한적이며, WAN 복제 매우 제한적이며, ASP.NET 캐싱 풍모, 개체 캐싱 풍모, 동기화 기능이 완전히 누락되었습니다. Redis 그리고 당신이 사용하는 경우 NCache 개체 캐싱의 경우 이러한 동기화 기능을 사용할 수 있도록 하는 것이 좋습니다.

SQL 유사 검색 누락, 데이터 그룹화 누락되고 서버 측 코드가 완전히 누락되었으며 이는 .NET도 아닙니다. Redis .NET으로 작성되지 않았습니다. 그래서 목록이 계속됩니다.

질문: 그래서, 나는 압니다 NCache Windows에 기본 제공되며 Linux에 비해 Redis 더 좋지만 어떻게 NCache Linux에서 비교 Redis 리눅스에서?

다음을 통해 지원되는 동일한 기능 세트, 동일한 지원 .NET Core 리눅스에서 사용할 수 있습니다. 그래서, NCache Windows 제품만 있는 것이 아닙니다. Redis. 어디에 Redis 대부분 Linux 지향 제품입니다. NCache 윈도우와 리눅스다. 따라서 여기에 표시되는 모든 기능 세트는 Linux 환경에서 완전히 지원됩니다. 모든 .NET Core Windows의 릴리스에서 모든 Linux는 서로 동등합니다. 우리는 Linux에 있는 PerfMon 카운터 문제를 수용하기 위해 맞춤형 모니터링을 가지고 있지만 그 외에 여러분이 보고 있는 모든 기능 세트, 이 비교는 거의 유효하며 모든 것이 Linux 환경에도 유효합니다. 저는 Windows에 더 집중하고 있습니다. Redis 일반적으로 Windows 지원이 완전히 부족합니다. 하지만, 어디까지나, NCache 우리의 Windows 제품과 Linux 제품은 정확히 동일합니다. 따라서 우리가 논의한 모든 기능은 NCache Linux 환경에서도 확실한 승자이며 실제로 더 많은 고객이 채택하고 있는 새로운 배포에서도 마찬가지입니다. .NET Core 애플리케이션 내에서 사용하는 것을 선호합니다. NCache Linux 환경에서. 라이센싱 관점에서 오픈 소스 관점에서 볼 때 호환 가능하고 사용하기 더 쉽기 때문에 Linux는 상대적으로 더 쉽습니다. 그래서 우리의 NCache Linux 서버에 있는 서버를 통해 .NET Core 요즘 매우 일반적인 관행입니다.

Docker 지원이 있습니까?

네, 물론이죠. 우리는 어떻게 가질 수 없습니까? 도커 지원 NCache. 다운로드 페이지로 이동하면 Docker에 대한 섹션을 찾을 수 있습니다. 우리는 .NET Core Docker 이미지는 Linux에서 사용할 수 있으며 .NET Framework Windows와 두 가지 모두에 사용할 수 있는 Docker 파일이 있습니다. 따라서 Enterprise, Professional, Open Source의 경우 우리가 의도적으로 .NET Core Linux 전용 이미지는 Linux가 더 일반적이기 때문에 실제로 사용할 수 있습니다. 도커 이미지 모든 Kubernetes 플랫폼에서도 마찬가지입니다. 와 같은 오픈시프트같은 Azure Kubernetes 서비스, Elastic Kubernetes 서비스 AWS 및 Google Kubernetes Service에서도 제공합니다. 그래서 매우 일반적입니다. 응용 프로그램 배포에서 매우 인기가 있습니다. 따라서 저희 웹사이트에서 직접 다운로드하거나 도커 허브 그 문제에 대한.

귀하의 질문에 대한 답변인지 확인하십시오. 질문이 더 있으면 알려주세요. 다른 사람? 지금 질문을 모두 받을 수 없더라도 이미 충분히 받고 있지만 언제든지 이메일을 보낼 수 있습니다. support@alachisoft.com. 기술적인 질문이나 기능 이메일에 대한 질문이 있는 경우 support@alachisoft.com. 우리의 지원팀은 귀하의 모든 질문, 귀하의 생각, 사용 사례 질문 등에 답변할 것입니다.

그리고 관심 있으신 분들은 NCache 시작했습니다. 두 달 동안 무료로 사용할 수 있습니다. NCache Enterprise 무료 평가판을 다운로드하여 환경에서 사용할 수 있으며 원하는 경우 다음 주소로 문의할 수 있습니다. support@alachisoft.com or sales@alachisoft.com. 설정하는 데 도움을 드리고 작업 중인 사용 사례도 알려드리겠습니다. 관심 있는 기능은 무엇입니까? 우리는 당신이 기술적 측면에서 절대적으로 만족할 수 있도록 할 것입니다.

또한 질문이 있었습니다. 프레젠테이션 슬라이드를 받을 수 있습니까?

물론, 이 웨비나 녹화본이 공개될 뿐만 아니라 귀하의 이메일을 통해 분명히 예상할 수 있지만 특별히 귀하에게 슬라이드를 보낼 수도 있습니다. 귀하가 원하거나 다른 사람이 슬라이드를 원하면 지금 바로 요청하십시오. 모든 사람이 슬라이드를 받을 수 있도록 하겠습니다.

더 이상 질문이 없으면 언제든지 저희에게 연락하실 수 있습니다. 다운로드 NCache Enterprise, 아직 확실히 플레이하지 않은 경우. 귀하의 환경에 설치하는 데 도움이 필요하면 반드시 저희에게 연락하십시오.

다음에 무엇을할지?

• NCache 세부 정보
• 다운로드 NCache
• 맞춤형 라이브 데모 요청