분산 캐싱은 고성능 .NET 웹 응용 프로그램의 중요하고 필수적인 부분으로 인식되었습니다. 이는 배포된 중간 계층 서비스 또는 웹 구성 요소에서 빠른 응답 시간을 요구하는 최종 사용자 응용 프로그램에 해당됩니다. 이러한 이유로 Microsoft는 AppFabric, 메모리 분산 캐시를 사용하여 응용 프로그램에 성능 및 확장성을 제공합니다. .NET Framework.
AppFabric 캐싱은 주로 ASP.NET 세션 상태 데이터를 저장하고 기본 개체 캐싱 기능을 제공하는 데 사용되었습니다. 그러나 캐싱이 모든 N-Tier 시스템의 필수적인 부분임에도 불구하고 Microsoft는 다음과 같이 블로그에 게시했습니다. AppFabric 지원 종료 11 년 20 월 XNUMX 일 기준17 모든 버전에 대해. 이것은 다음을 사용하는 .NET 스택에 좋은 인센티브입니다. AppFabric 지원되는 더 나은 분산 캐시로 이동합니다.
그래서, 엔딩 지원은 무엇입니까 실제로 의미? 그 뜻은:
따라서 AppFabric 자신의 위험에. Microsoft는 사고나 버그에 대해 책임을 지지 않습니다. 이 때문에 우리는 신속한 해결이 없는 버그로 인해 비즈니스 운영이 다운타임을 지속할 수 있는지 여부를 평가해야 합니다.
그러한 질문은 당신을 대안으로 이끌 수 있습니다. 대안이 준비되어 있다면 최소한의 코드 변경으로 현재 설정에서 .NET 분산 캐시로 원활하게 마이그레이션할 수 있으므로 버그가 전혀 발생하지 않습니다. 이 대체 분산 캐시는 원활한 마이그레이션을 지원할 뿐만 아니라 더 빠르고 더 많은 기능을 제공합니다. AppFabric.
NCache 대안으로 강력한 선택입니다. Microsoft는 실제로 권장 NCache 자신의 발표 종결 AppFabric 지원합니다. NCache .NET 커뮤니티 내에서 광범위하게 사용되고 있으며 10년 실행. NCache 다음과 같은 다양한 기능과 함께 탁월한 성능을 제공합니다.
다른 이점 NCache 사용 용이성 포함(최고의 분석 회사에서 사용하기 가장 쉬운 분산 캐시로 평가) 특별히 제작된 GUI 도구를 통한 강력한 관리 및 모니터링 기능을 포함하며 거의 비용 없이 오픈 소스(GitHub에서) 사용 가능 마이그레이션 전후. 공식 지원이 포함된 오픈 소스 및 엔터프라이즈 버전은 온프레미스 및 클라우드(Amazon Web Services 및 Azure)에서 사용할 수 있습니다.
DaVinci에는 Redis 좋은 인메모리 캐시이며, Redis 커뮤니티는 Redis 의 가용성에도 불구하고 Windows가 준비되지 않았습니다. Redis 윈도우 포트. Redis 완전히 확장할 수 없거나 고가용성 기능을 제공하지 않습니다. Redis' 모니터링 및 관리 도구 세트는 CLI 전용입니다. NCache 에 비해 많은 이점을 제공합니다. Redis 이처럼 비디오 링크 (그리고 이 슬라이드 공유 스마트 가이드) 포함.
모든 운영 환경의 요구 사항을 충족하기 위해 NCache 에서 .NET 애플리케이션을 마이그레이션하는 세 가지 방법을 제공합니다. AppFabric 에 NCache; 각 방법에는 고유한 장점이 있습니다.
세 가지 마이그레이션 방법은 다음과 같습니다.
NCache AppFabric 래퍼는 더 부드럽고 매끄러운 마이그레이션을 제공하지만 직접 API 호출을 통한 마이그레이션은 더 많은 제어를 제공하고 모든 기능을 활용할 수 있습니다. NCache.
가장 쉽고 빠른 전환을 원하는 조직을 위해 AppFabric, 이 래퍼는 가장 쉬운 마이그레이션을 제공합니다. .NET 응용 프로그램을 만들기 위해 세 가지 사소한 변경만 필요합니다. NCache 가능한 버그를 전혀 도입하지 않고 준수합니다. 이러한 변경 사항은 다음과 같습니다.
<appSettings>
<add key="region1" value="myPartitionedCache"/>
<add key="Expirable" value="True"/>
<add key="TTL" value="5"/>
</appSettings>using Microsoft.ApplicationServer.Caching.Client;
using Microsoft.ApplicationServer.Caching.core;
와:
using Alachisoft.NCache.Data.Caching;그리고 그게 다야! .NET 애플리케이션 내에서 다른 코드를 변경할 필요가 없습니다.
사용 NCache Open Source 다음에서 마이그레이션할 수 있습니다. AppFabric 두 제품 모두 무료이기 때문에 비용이 들지 않습니다. NCache Open Source Enterprise 에디션에 비해 기능이 더 제한적이지만 코어 캐시 성능은 저하되지 않습니다.
마이그레이션을 쉽게 하기 위해 별도의 버전 AppFabric 래퍼가 제공됩니다 NCache 오픈 소스 API와 호환되는 OSS. 더 적은 기능을 감안할 때 NCache Open SourceWalk Through California 프로그램, NCache Open Source 래퍼는 다음과 같은 누락된 기능을 해결합니다.
XNUMXD덴탈의 NCache Open Source 래퍼 AppFabric 다른 클래스 내의 모든 개체를 캡슐화하여 항목 버전 관리의 문제를 극복합니다. 이것은 수정된 래퍼에 MetaDataCapsule이라는 새 클래스를 도입하여 수행됩니다.
namespace Alachisoft.NCache.Data.Caching.Util
{
[Serializable]
class MetaDataCapsule
{
private object value;
public ItemVersion CacheItemVersion { get; set; }
public string Group { get; set; }
public object Value { get { return this.value; } }
private MetaDataCapsule(object value, ItemVersion version, string group)
{
this.CacheItemVersion = version;
this.Group = group;
this.value = value;
}
public static MetaDataCapsule Encapsulate(object value, string region)
{
return new MetaDataCapsule(value, 1, region);
}
}
}이것은 객체의 항목 버전을 유지하고 필요한 경우 다른 유용한 정보를 전달하는 데 도움이 됩니다. 클래스는 네트워크를 통해 이동해야 하므로 직렬화 가능으로 표시됩니다.
서로 다르거나 유사한 응용 프로그램의 모든 여러 인스턴스에서 항목 버전 및 개체 일관성을 보장하기 위해 분산 잠금이 사용됩니다. 분산 잠금은 다음의 기능입니다. NCache 이를 통해 여러 애플리케이션이 데이터 일관성을 손상시키고 가능한 경쟁 조건을 피하지 않고 동일한 리소스에 액세스하고 수정할 수 있습니다.
LockHandle lockhandle = null;
MetaDataCapsule oldMetadata;
bool lockAcquired = GetLock(_key, ref lockhandle, out oldMetadata);
if(!lockAcquired)
{
_NCache.Unlock(key);
throw new DataCacheException("Unable to acqurie lock to update Item Version");
}
//Return in case of version provided
if (oldVersion != null && oldMetadata.CacheItemVersion == oldVersion._itemVersion)
{
_NCache.Unlock(key);
return null;
}
if (lockAcquired)
(_item.Value as MetaDataCapsule).CacheItemVersion = ++metadata.CacheItemVersion;
_NCache.Insert(_key, _item, lockhandle, true);요약하면 모든 Put 작업에서:
위의 시나리오에서 잠그면 다른 응용 프로그램이 동일한 키를 수정하려고 할 때 다른 응용 프로그램이 항목을 업데이트하거나 제거할 수 없습니다.
위의 코드에는 GetLock이라는 메서드가 있으며 구현은 다음과 같습니다.
// <summary>
// Tries to acqurie lock and return LockHandle and MetaDataCapsule object.
// If LockHandle is provided uses that instead.
// <para>Default Lock Timeout (default 5 seconds), Retry Count (default 3)
// and retry interval (default 100 ms) is set when Cache Handler is instantiated.
// </para>
// </summary>
// <param name="key">Formatted Key i.e compile from formatter</param>
// <param name="lockHandle">Either provide a lock or keep it null to acquire a new lock
// </param>
// <param name="metadata">The returned object for internal use</param>
// <returns>true if lock was acquired</returns>
internal bool GetLock(string key, ref LockHandle lockHandle,
out MetaDataCapsule metadata)
{
//Item is locked
int count = _retries;
while (count != 0)
{
//If lock was provided attempt to acquire the lock from the given handle
if (lockHandle == null)
{
lockHandle = new LockHandle();
}
object obj = _NCache.Get(key, _defaultLockTime, ref lockHandle, true);
//obj is null of the lock was not acquired
if (obj == null)
{
count--;
Thread.Sleep(_retryTimeOut);
}
else
{
metadata = obj as MetaDataCapsule;
return true;
}
}
lockHandle = null;
metadata = null;
return false;
}GetLock 메서드는 잠금 획득을 세 번 시도합니다. 실패하면 호출 메서드가 이 예외를 처리할 수 있도록 "null"을 반환합니다. 따라서 분산 잠금의 도움으로 AppFabric 래퍼 NCache Open Source 예외 경우를 포함하여 클라이언트 응용 프로그램에서 삽입한 캐시 항목 버전을 유지 관리합니다.
오픈 소스 에디션에는 일부 엔터프라이즈 기능이 없기 때문에 다음 기능은 "구식"으로 표시되고 "컴파일 오류 발생"으로 표시되어 코드 변경을 보장하고 예상치 못한 상황을 방지합니다.
따라서 애플리케이션이 이러한 기능에 크게 의존하는 경우 NCache Enterprise 버전은 더 부드럽고 매끄럽고 버그 없는 마이그레이션을 허용하는 최상의 옵션일 수 있습니다.
많은 기능을 최대한 활용하려는 개발자를 위해 NCache Enterprise 기능을 직접 호출하는 것을 선호할 수 있습니다. NCache 래퍼를 사용하는 대신 API. 당신은 또한 'unwrap 방법'을 사용할 수 있습니다 AppFabric 직접 작업할 래퍼 NCache 뿐만 아니라.
어느 쪽이든 두 단계로 마이그레이션을 수행하는 것이 좋습니다. 1단계에서 계속 사용 AppFabric 기능을 제공하지만 캐시를 다음으로 교체하십시오. NCache. 2단계에서는 추가, 새로운 NCache 에서 사용할 수 없었던 기능 AppFabric.
이 단계에서 초점은 다음을 대체하는 것입니다. AppFabric. 따라서 이러한 두 개의 분산 캐시가 어떻게 작동하는지 이해하는 것이 중요합니다(자세한 내용은 아래 및 참조 섹션 끝에). 말한 바와 같이, AppFabric 특정 시스템의 영역에 데이터를 저장합니다. 반면에 지역 데이터를 복제하려면 NCache 모든 항목에 대해 캐시를 생성할 수 있습니다. AppFabric 지역을 만들거나 NCache 보유할 그룹 AppFabric 지역 데이터.
NCache 그룹/하위 그룹은 캐시된 항목을 그룹화하는 다양한 방법을 제공합니다. 지역이 명명된 캐시 내부에 있기 때문에 NCache 그룹을 사용하여 이 동작을 재현합니다. 유일한 차이점은 AppFabric 키는 전체 명명된 캐시가 아니라 지역 내에서만 고유해야 합니다. 반면에 NCache, 키는 전체 캐시에서 고유해야 하며 어느 그룹에 속하는지는 중요하지 않습니다. 모든 키 앞에 지역 이름이 추가되면 이러한 장애를 빠르게 극복할 수 있습니다.
예 :
In AppFabric, 기본 추가 작업은 다음과 같습니다.
// AppFabric API
regionCache.Add(stringKey, stringValue);그리고에 NCache 기본 명령은 지역 이름이 명령에서 그룹으로 지정될 수 있다는 점을 제외하고 다르지 않습니다.
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
여기서 모든 키에는 캐시 키 간의 고유성을 확보하기 위해 지역 이름이 미리 추가됩니다. 더 빠른 검색을 위해 또는 검색 작업을 수행할 때 SQL 쿼리를 사용하여 데이터 검색을 용이하게 하기 위해 키에 그룹이 할당됩니다.
캐시된 항목을 그룹화하는 다른 방법은 지역 간 상관 관계를 완전히 삭제하고 모든 지역에 대해 별도의 캐시를 사용하는 것입니다. 모든 지역에 별도의 캐시가 할당되는 동일한 결과를 얻기 위해 캐시에 해당하는 지역 이름 맵을 저장할 수 있습니다.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);이 예에서는 지역 키를 캐시 키에 추가할 필요가 없습니다. NCache 같은 클러스터에 있더라도 상호 배타적입니다.
응용 프로그램이 많은 지역(예: 15개 이상)을 처리해야 하는 경우 클러스터당 15개의 캐시가 권장되는 최대 캐시 수이므로 지역을 그룹으로 사용하는 것이 좋습니다(클러스터가 논리적으로 무한한 수의 캐시를 호스팅할 수 있음에도 불구하고) .
다음 단계에서는 다음과 같은 기능을 활용할 수 있습니다. NCache 제공하는 AppFabric 과 Redis 부족. 다음과 같은 기능:
데이터베이스 동기화는 우수한 분산 캐시에 있어 매우 중요한 기능입니다. 캐시되는 대부분의 데이터는 관계형 데이터베이스에서 가져오기 때문에 다른 응용 프로그램이나 사용자가 데이터를 변경하여 캐시된 데이터가 부실해질 수 있는 상황이 항상 있습니다.
응용 프로그램은 종종 이 데이터의 하위 집합을 가져오려고 하며 SQL과 유사한 쿼리 언어로 분산 캐시를 검색하고 기준의 일부로 개체 속성을 지정할 수 있다면 분산 캐시를 훨씬 더 유용하게 만듭니다.
많은 사람들이 분산 캐시를 데이터베이스에서 직접 데이터를 가져와 캐시에 넣는 "측면 캐시"로 사용합니다. 또 다른 접근 방식은 애플리케이션이 캐시에 데이터를 요청하는 "캐시 스루"입니다. 데이터가 없으면 분산 캐시가 데이터 원본에서 데이터를 가져옵니다. writethrough도 마찬가지입니다.
이와 함께, NCache 또한 In-Memory 데이터에서 Big Data Analytics를 활성화하여 거의 실시간으로 결과를 생성하는 MapReduce를 지원합니다.
클라이언트 캐시는 단순히 클라이언트 시스템의 로컬 InProc/OutProc 캐시이지만 분산 캐시 클러스터와 연결 및 동기화된 상태를 유지하는 캐시입니다. 이러한 방식으로 애플리케이션 성능은 데이터 무결성을 손상시키지 않으면서 이러한 "밀접함"의 이점을 실제로 누릴 수 있습니다.
WAN 복제는 재해 복구 목적이나 지역 트래픽의 로드 밸런싱을 위해 여러 데이터 센터에 배포되는 많은 애플리케이션에서 중요한 기능입니다.
WAN 복제의 기본 개념은 WAN의 높은 대기 시간으로 인해 각 지리적 위치의 캐시 속도를 늦추지 않아야 한다는 것입니다. NCache 이 모든 것을 처리하기 위해 Bridge Topology를 제공합니다.
Microsoft 지원 AppFabric 2017년 XNUMX월에 종료됩니다. 이 백서는 AppFabric 에 NCache, 그리고 이러한 변경의 장점. NCache Azure 및 Amazon Web Services에서 오픈 소스로 사용할 수 있는 안정적인 완전한 기능의 분산 .NET 캐시입니다. NCache 웹사이트. 전폭적인 지원도 가능합니다.
무료 사용 NCache AppFabric 둘 중 하나에 대한 래퍼 NCache Open Source or NCache Enterprise, 코딩이 필요 없는 가장 쉬운 버그 없는 마이그레이션 방법을 제공합니다. 직접 호출하여 마이그레이션 NCache API는 더 많은 데이터 제어를 제공하고 모든 NCache 특징. 모든 마이그레이션 방법은 이 백서에 설명되어 있습니다.
평가 및 제품 요구 사항을 충족하려면 이 추가 리소스를 확인하십시오.
지역 in AppFabric 하나의 서버 시스템에 바인딩된 캐시 인스턴스에 저장된 키-값 쌍의 논리적 컨테이너입니다. 이 때문에 지역 내부의 데이터를 배포할 수 없습니다. 이 아키텍처 구조는 더 빠른 가져오기를 가능하게 한다고 주장합니다. 그러나 분산 캐시에 비해 전반적인 성능이 크게 저하됩니다.
NCache 핵심은 분산 캐시입니다. 내부의 모든 데이터 NCache 배포되고 백업 복사본은 다음과 같은 경우 다른 물리적 시스템에 유지됩니다. 파티션 복제본 (PR) 토폴로지가 사용됩니다. PR은 데이터 손실이 없는 세계 최고 수준의 초고속 성능 및 장애 조치 복제본을 제공합니다.
따라서 지역 AppFabric 에서 별도의 캐시로 구성됩니다. NCache 데이터 가져오기 기능을 손상시키지 않으면서 그만큼 AppFabric 래퍼는 이러한 복잡성을 인수하고 모든 지역 데이터를 제공된 캐시 이름에 자동으로 저장합니다. 유일한 요구 사항은 NCache 기존에 존재해야 합니다. 다음을 통해 캐시를 생성합니다. NCache 매니저, GUI 기반 클러스터 관리 도구. 캐시가 생성되면 다음 위치에 있는 데이터 AppFabric 지역은 지정된 NCache 클러스터. 데이터가 실제로 배포되고 있음에도 불구하고 SQL 쿼리(SQL 쿼리는 AppFabric 조금도).
다른 눈에 띄는 차이점은 NCache 과 AppFabric 두 제품이 구성된 방식입니다. AppFabric 런타임(캐시 생성 포함) 시 애플리케이션에 의해 구성되며 대조적으로 NCache 캐시가 시작되기 전에 구성됩니다. 예를 들어 캐시 토폴로지는 런타임에 변경할 수 없는 반면 캐시 기본 만료 등과 같은 다른 구성은 나중에 변경할 수 있으며 이를 핫 적용 가능이라고 합니다. 일지라도 NCache .NET 애플리케이션을 사용하여 관리할 수 있지만(캐시 생성 포함) NCache 관리자 - 캐시 클러스터를 관리하기 위한 전용 단일 도구입니다. CLI에서도 캐시를 생성, 구성 및 유지 관리할 수 있습니다.
DaVinci에는 NCache AppFabric-wrapper는 .NET 애플리케이션을 다음으로 마이그레이션하는 가장 쉬운 방법을 제공합니다. NCache, 또한 가능한 한 최소한의 코드 변경으로 가능하지만 일부 개발자는 여전히 모든 기능을 활용하는 것을 선호합니다. NCache 제공해야 합니다. 바로 전화를 거는 곳입니다. NCache API가 도움이 됩니다. Unwrap 메소드를 호출하여 두 메소드를 모두 사용하는 옵션도 있습니다. AppFabric 싸개.
XNUMXD덴탈의 AppFabric 클러스터는 완전히 동적이지 않습니다. 의존성 "리드 호스트 다수결 원칙" 하나의 리드 호스트가 다운되더라도 클러스터가 매우 쉽게 다운될 수 있음을 의미합니다. 이러한 리드 호스트 노드는 또한 "마스터" 및 "슬레이브" 아키텍처와 유사하므로 완전히 피어 투 피어도 아닙니다.
NCache 반면 매우 역동적인 캐시나 애플리케이션을 중단하지 않고 런타임에 캐시 서버를 추가하거나 제거할 수 있습니다. 데이터는 중단이나 성능 저하 없이 런타임에 자동으로 재조정됩니다(상태 전송이라고 함). NCache 클라이언트는 서버 상태에 관계없이 캐시 서버와 계속 통신합니다. 클러스터는 데이터 밸런싱이 진행 중인 경우에도 클라이언트 작업의 실행을 보장합니다.
이것은 심지어 NCache, 클러스터에 "마스터" 또는 "슬레이브" 노드가 없습니다. 최상위 노드인 "기본 조정자" 노드가 있습니다. 그리고 다운되면 다음으로 가장 높은 노드가 자동으로 기본 조정자가 됩니다. 이 모든 작업은 클라이언트 작업을 중단하지 않고 발생합니다.