스케일링 .NET Core 최고의 성능을 위한 앱
개요
.NET Core 그리고 ASP.NET Core 디자인의 단순성, 가볍고 오픈 소스이며 Windows와 Linux 모두에서 실행할 수 있기 때문에 인기를 얻고 있습니다. 결과적으로 많은 기존 애플리케이션도 다음으로 이동하고 있습니다. .NET Core 인사말 .NET Framework. 거의 모든 새로운 응용 프로그램이 다음에서 개발되고 있습니다. .NET Core.
이들 중 다수 .NET Core 애플리케이션은 본질적으로 트래픽이 많으며 수백만 명의 사용자와 트랜잭션에 서비스를 제공합니다. 결과적으로 이러한 애플리케이션은 비즈니스에 막대한 영향을 미치므로 매우 중요합니다.
누가 확장성을 필요로 합니까?
XNUMXD덴탈의 .NET Core 일반적으로 확장성이 필요한 응용 프로그램은 매우 빠른 응답 시간으로 많은 트랜잭션을 매우 빠르게 처리해야 하는 서버 응용 프로그램입니다. 이러한 애플리케이션 중 다수는 고객을 대면하며 고객 요청을 처리하고 있음을 의미합니다. 고객 요청을 신속하게 수행하지 않으면 수익 손실과 만족스러운 고객 손실 측면에서 비즈니스 비용이 높아집니다.
수행원 .NET Core 애플리케이션에는 확장성이 필요합니다.
- 웹앱(ASP.NET Core): 이들은 일반적으로 고객 대면 애플리케이션이지만 대기업을 위한 내부 대면 애플리케이션일 수도 있습니다.
- 웹 서비스(ASP.NET Core): 이들은 웹 API를 고객에게 직접 제공하거나 이러한 웹 서비스의 애플리케이션 계층 논리를 포함하는 다른 높은 트랜잭션 애플리케이션의 일부일 수 있습니다.
- 실시간 웹 앱(ASP.NET Core 신호R): 이들은 ASP를 사용하여 사용자에게 자주 새로 고침을 제공해야 하는 실시간 응용 프로그램입니다..NET Core의 SignalR 프레임워크. 또한 일반적으로 고객을 대면하므로 빠르게 수행해야 합니다.
- 마이크로서비스(.NET Core): 이것은 서버측 애플리케이션을 위한 새로운 애플리케이션 아키텍처입니다. 그리고 웹 서비스와 마찬가지로 이러한 마이크로 서비스는 일반적으로 고객 대면 웹 애플리케이션 또는 고객 대면 웹 서비스 애플리케이션의 일부입니다. 결과적으로 트랜잭션 로드가 많은 경우에도 고성능 요구 사항이 있습니다.
- 기타 서버 앱(.NET Core): 많은 양의 트랜잭션을 매우 빠르게 처리해야 하는 다양한 기타 서버 응용 프로그램이 있습니다. 다양한 유형의 백엔드 워크플로를 처리하는 일괄 처리 애플리케이션이거나 거의 실시간 처리를 위해 대량의 데이터를 수집하는 스트림 처리 애플리케이션일 수 있습니다. 목록은 계속됩니다.
문제: 확장성 병목 현상
흥미롭게도 위에서 언급한 모든 애플리케이션에는 확장성이 뛰어난 애플리케이션 수준 아키텍처가 있습니다. 각각은 로드 밸런서와 함께 더 많은 서버, VM 또는 컨테이너 인스턴스를 추가하여 트랜잭션 로드가 증가함에 따라 선형적으로 확장할 수 있습니다.
그러나 애플리케이션 계층에서 매우 확장 가능한 아키텍처에도 불구하고 .NET Core 오늘날 서버 애플리케이션은 주요 확장성 병목 현상에 직면해 있습니다. 이러한 병목 현상은 다음과 같은 다양한 영역에서 발생합니다.
- 애플리케이션 데이터베이스(관계형 데이터베이스): 이것이 가장 큰 병목 현상입니다. 아래에서 자세히 설명하겠습니다.
- ASP.NET Core 세션 스토리지: 세션이 SQL Server에 저장되어 있으면 ASP.NET Core 응용 프로그램은 엄청난 병목 현상에 직면하게 됩니다.
- ASP.NET Core 반복 페이지 처리: 동일한 페이지가 반복적으로 실행되고 출력 또는 응답이 동일하게 유지되면 리소스 낭비 및 성능 병목 현상이 발생합니다.
- ASP.NET Core SignalR Backplane 제공자 : SignalR을 사용하는 라이브 웹 앱이 확장되어야 하는 경우 백플레인 제공자가 쉽게 병목 현상이 될 수 있습니다.
- Pub/Sub 메시징(메모리 내 아님): 귀하의 경우 .NET Core 애플리케이션이 Pub/Sub 메시징을 사용하고 있다면 인메모리가 아니므로 병목 현상이 발생할 가능성이 있습니다.
관계형 데이터베이스 병목 현상
모든 높은 트래픽에 대한 가장 큰 병목 현상 .NET Core 응용 프로그램은 응용 프로그램 데이터베이스입니다. 오늘날 대부분의 애플리케이션은 여전히 SQL Server 또는 Oracle과 같은 관계형 데이터베이스를 사용하고 있습니다. 이러한 데이터베이스는 이러한 응용 프로그램에서 트랜잭션 부하를 증가시키면 빠르게 확장성 병목 현상이 됩니다. 이는 VM에서 SQL Server를 사용하든 Azure SQL Database에서 사용하든 마찬가지입니다.
이는 관계형 데이터베이스가 데이터베이스처럼 논리적으로 분할될 수 없기 때문에 발생합니다. NoSQL database 대신 하나의 물리적 위치에 유지됩니다. 일부 열 수준 파티셔닝도 사실과 다릅니다. NoSQL 스타일 파티션. 따라서 데이터베이스 서버를 추가하는 방식으로 데이터베이스 계층 트랜잭션 용량을 늘릴 수는 없습니다. NoSQL database.
예를 들어 애플리케이션 계층은 트랜잭션 부하가 증가함에 따라 10, 20, 30개 이상의 애플리케이션 서버를 쉽게 가질 수 있지만 데이터베이스 계층은 같은 방식으로 전혀 성장할 수 없습니다.
이 모든 것 때문에 관계형 데이터베이스에 저장하는 모든 데이터(응용 프로그램 데이터 또는 기타 데이터)에 대한 성능 병목 현상이 발생합니다.
데이터베이스 서버 메모리 내 최적화가 충분하지 않음
SQL Server는 초당 트랜잭션 수를 늘리기 위해 메모리 내 최적화를 도입했습니다. Oracle은 자체 버전의 In-Memory 테이블도 제공했습니다.
In-Memory 최적화는 성능 향상을 가져오지만 선형 확장성의 핵심 문제는 해결하지 못합니다. In-Memory 테이블은 일반적으로 읽기 전용 데이터에 사용되며 읽기 전용 트랜잭션 용량을 확장하려면 고급 머신에 SQL Server 인스턴스를 더 추가해야 합니다.
In-Memory 테이블에는 데이터 크기에도 제한이 있습니다. 전체 테이블을 메모리에 넣어야 하므로 큰 테이블을 메모리에 넣을 수 없습니다. 그리고 다른 SQL Server 인스턴스에 대한 복제는 적절한 데이터베이스가 아닌 다른 In-Memory 테이블에 대해서만 수행할 수 있습니다.
요약하면 SQL Server 및 Oracle 데이터베이스의 이러한 인메모리 최적화는 .NET Core 응용 프로그램의 확장성 요구 사항.
NoSQL Database 답이 아니다
이유 중 하나 NoSQL databases가 인기를 얻은 것은 해시 기반 및 기타 알고리즘을 기반으로 데이터를 적절하게 분할하기 때문입니다. 이것은 SQL Server 및 Oracle과 같은 관계형 데이터베이스가 직면하는 트랜잭션 용량의 확장성 문제를 대부분 해결합니다.
하지만 이유가 있습니다 NoSQL databases는 이러한 데이터베이스 병목 현상에 대한 이상적인 솔루션이 아닙니다.
- 메모리 내 저장소가 아님: NoSQL databases는 관계형 데이터베이스처럼 디스크에 데이터를 저장합니다. 즉, 무엇을 하든 디스크의 느린 성능이 궁극적으로 성능 병목 현상이 됩니다.
- 대부분의 시간에 사용할 수 없음: NoSQL databases는 SQL Server 및 Oracle과 같은 관계형 데이터베이스 사용을 포기하고 이를 NoSQL database. 대부분의 경우 기술 및 비기술적 이유로 불가능합니다. 기본적으로 비즈니스는 관계형 데이터베이스에 의존하며 쉽게 포기할 수 없습니다. 결과적으로, 귀하는 NoSQL database.
솔루션: 메모리 내 분산 캐시(NCache)
위에서 언급한 모든 문제에 대한 해결책은 다음과 같은 In-Memory Distributed Cache를 사용하는 것입니다. NCache 귀하의 .NET Core 애플리케이션 배포. NCache .NET용 오픈 소스 분산 캐시이며 .NET Core 매우 빠르고 선형적으로 확장 가능합니다. 또한 분산되는 메모리 내 데이터 저장소로 생각하십시오. 인메모리이기 때문에 속도가 매우 빠르고 분산되어 있기 때문에 선형 확장이 가능합니다.
NCache 저비용 캐시 서버의 TCP 클러스터(웹 앱 서버와 동일한 구성이지만 메모리가 더 많음)를 구축하고 이러한 모든 서버의 메모리 및 CPU 리소스를 하나의 논리적 용량으로 풀링하기 때문에 선형적으로 확장 가능합니다. NCache 그런 다음 트랜잭션 로드가 증가함에 따라 런타임 시 이 클러스터에 캐시 서버를 추가할 수 있습니다. 이후 NCache 모두 인메모리이며 초고속이며 관계형 데이터베이스에서 기대할 수 없는 XNUMX밀리초 미만의 응답 시간을 제공합니다. NoSQL databases.
선형 확장성을 제공하는 것 외에도 다음과 같은 분산 캐시가 있습니다. NCache 데이터를 지능적으로 복제하므로 캐시 서버가 다운되는 경우에도 데이터 안정성을 유지하면서 성능이 저하되지 않습니다.
NCache 규모를 조정할 수 있습니다. .NET Core 다음을 통해 신청:
- 애플리케이션 데이터 캐싱
- ASP.NET Core 세션 저장
- ASP.NET Core 응답 캐시 미들웨어
- ASP.NET Core SignalR Backplane
- Pub/Sub 메시징 및 CQ 이벤트(메모리 내)
- 연속 쿼리 이벤트(메모리 내)
애플리케이션 데이터 캐싱
직면한 가장 중요한 병목 현상 .NET Core 애플리케이션은 "애플리케이션 데이터베이스"입니다. 좋은 점은 NCache 그거랑 다른거야? NoSQL databases, NCache 기존 관계형 데이터베이스 사용을 중지하도록 요청하지 않습니다. SQL Server, Azure SQL Database, Oracle 등을 데이터베이스로 계속 사용하면서 다음을 사용하여 선형 확장성을 달성할 수 있습니다. NCache 관계형 데이터베이스 위에. 이 때문입니다 NCache 데이터베이스와 달리 모든 관계형 데이터베이스 확장성 병목 현상을 제거합니다. NCache 실제로 선형 확장 가능합니다.
애플리케이션 데이터 캐싱을 사용하면 데이터베이스 병목 현상을 제거할 수 있습니다. NCache 애플리케이션 데이터를 캐시하고 비용이 많이 드는 데이터베이스 이동을 줄일 수 있습니다. 데이터베이스 트래픽의 80-90%를 NCache. 이렇게 하면 데이터베이스에 대한 부담이 줄어들고 속도 저하 없이 더 빠르게 수행하고 더 큰 트랜잭션 로드를 처리할 수 있습니다.
애플리케이션 데이터 캐싱은 관계형 데이터베이스에서 가져온 모든 애플리케이션 데이터를 캐시한다는 의미입니다. 이것은 일반적으로 도메인 객체(엔터티라고도 함)의 형태입니다. 다음은 다음과 같은 분산 캐시를 사용하는 방법의 예입니다. NCache 애플리케이션 데이터 캐싱용.
Customer Load(string custId)
{
ICache cache = CacheManager.GetCache("myCache");
string key = "Customer:CustomerID:" + custId;
Customer cust = cache.Get<Customer>(key);
if (cust == null) {
// Item not in cache so load from db
LoadCustomerFromDb(cust);
// Add item to cache for future reference
cache.Add(key, cust);
}
return cust;
}그림 3: 앱 데이터 캐싱에 메모리 내 분산 캐시 사용
ASP.NET Core 세션 저장
가능한 또 다른 병목 현상은 ASP를 저장하는 경우입니다..NET Core SQL Server 또는 독립 실행형 MemoryCache의 세션. 두 옵션 모두 성능과 확장성에 큰 제한이 있습니다. SQL Server 저장소는 ASP에 적합하지 않습니다..NET Core 애플리케이션 데이터와 마찬가지로 신속하게 병목 현상이 발생합니다.
NCache ASP를 저장하기에 좋은 장소입니다..NET Core 다른 스토리지 옵션보다 훨씬 빠르고 확장 가능하기 때문입니다. NCache 메모리에 있고 값이 ASP가 "개체"인 키값 인터페이스를 제공하기 때문에 더 빠릅니다..NET Core 세션은. 그리고 분산 캐시이기 때문에 확장 가능합니다.
그리고 NCache 또한 지능적으로 ASP를 복제합니다..NET Core 풍부한 캐싱 토폴로지를 통해 세션을 보호하므로 캐시 서버가 다운되더라도 세션 데이터 손실이 없습니다. 이 복제가 필요한 이유는 NCache 메모리 내 저장소를 제공하고 메모리가 저장소를 위반합니다.
NCache 또한 ASP의 직렬화 속도를 높입니다..NET Core out-of-process로 저장되기 전에 필요한 세션입니다. NCache 일반 .NET보다 10배 빠른 Dynamic Compact 직렬화 기능을 사용하여 이를 수행하고 .NET Core 직렬화. 코드를 변경하지 않고 이 기능을 사용할 수 있습니다.
당신이 사용할 수 NCache 당신의 ASP로.NET Core 두 가지 방법으로 세션 저장소.
- ASP용 IDistributedCache.NET Core 세션: NCache 자동으로 플러그인할 수 있는 IDistributedCache 인터페이스를 구현했습니다. NCache 당신의 ASP로.NET Core 세션 저장소 제공자. 그러나 이것은 다른 옵션보다 기능이 적습니다.
- NCache ASP용 공급자.NET Core 세션: NCache 기능이 풍부한 자체 ASP도 구현했습니다..NET Core 사용할 수 있는 세션 저장소 공급자입니다. 추가 잠금, 시간 초과 등의 측면에서 더 많은 기능이 있습니다.
다음은 ASP를 구성하는 방법의 예입니다..NET Core 사용할 응용 프로그램 NCache 세션 제공자:
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Specify NCache as the session provider
services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
...
}
public void Configure(IApplicationBuilder app, ...)
{
// select NCache session provider for ASP.NET Core
app.UseNCacheSession();
...
}
}그림 4: 플러그인 NCache ASP로.NET Core 세션
ASP.NET Core 응답 캐시 미들웨어
ASP.NET Core 상당히 동적인 콘텐츠가 있는 애플리케이션은 일부 페이지의 콘텐츠나 응답이 여러 요청에서 변경되지 않는 상황에 직면합니다. 그러나 이러한 페이지는 여전히 요청이 올 때마다 실행되어야 합니다. 그리고 이는 웹 서버 리소스와 이 애플리케이션의 모든 계층에 불필요한 부담을 줍니다. 그 결과 성능 병목 현상이 추가되고 애플리케이션의 확장성이 제한됩니다.
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Turn on ASP.NET Core Response Cache with IDistributedCache
services.AddResponseCaching();
// Select NCache as IDistributedCache provider
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
...
}
}그림 5: 플러그인 NCache ASP로.NET Core 응답 캐시 미들웨어
페이지 응답이 변경되지 않는 반복적인 페이지 실행의 오버헤드를 해결하기 위해 ASP는.NET Core ASP.NET 응답 캐시 미들웨어라는 페이지 응답 캐싱 메커니즘을 제공했습니다. 그리고, NCache ASP에서 IDistributedCache 인터페이스를 구현했습니다..NET Core 덕분에 원활하게 플러그인할 수 있습니다. NCache 당신의 ASP로.NET Core 응답 캐시 미들웨어.
그래서 당신은 사용할 수 있습니다 NCache 캐시 ASP.NET Core 다음 번에 동일한 매개변수로 동일한 페이지가 호출될 때 전체 페이지를 다시 실행하는 대신 이 캐시된 응답을 반환할 수 있습니다. 다음은 구성 방법에 대한 코드 예제입니다. NCache 당신의 ASP로.NET Core 응답 캐시 미들웨어.
ASP.NET Core SignalR Backplane
ASP가.NET Core 응용 프로그램은 실시간 웹 응용 프로그램이므로 ASP를 사용할 가능성이 높습니다..NET Core 이 실시간 동작을 제공하는 SignalR입니다. 실시간 웹 애플리케이션은 서버에서 클라이언트로 고주파 업데이트를 제공합니다. 이러한 애플리케이션의 예로는 게임, 경매, 투표, 소셜 네트워크 등이 있습니다.
ASP가.NET Core 애플리케이션이 부하 분산된 다중 서버 환경에서 실행 중이면 ASP를 사용해야 합니다..NET Core SignalR Backplane 여러 웹 서버에서 이벤트를 공유하기 위해 공급자. 그리고 이 백플레인은 확장 가능해야 합니다. 그렇지 않으면 ASP.NET Core SignalR 애플리케이션이 성능 병목 현상에 직면하기 시작합니다.
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Specify NCache as the ASP.NET Core SignalR Backplane
services.AddSignalR().AddNCache(ncacheOptions =>
{ ncacheOptions.CacheName = "myPartitionedCache"; });
...
}
public void Configure(IApplicationBuilder app, ...)
{
// Use SignalR in ASP.NET Core
app.UseSignalR(config => { config.MapHub<MessageHub>("/messages"); });
...
}
}그림 6: 플러그인 NCache ASP로.NET Core SignalR Backplane Provider
NCache ASP를 구현했습니다..NET Core SignalR Backplane 공급자. NCache의 ASP.NET Core SignalR Backplane 공급자는 다음의 Pub/Sub 메시징 기능을 사용합니다. NCache 완전히 메모리에 있기 때문에 초고속입니다. 이렇게 하면 ASP가.NET Core SignalR 응용 프로그램은 모든 웹 서버 간에 그리고 결과적으로 클라이언트에 대한 SignalR 이벤트 전파 속도를 높입니다.
또한 이렇게 하면 클라이언트에 대한 빈번한 업데이트를 제공할 때 실시간 웹 애플리케이션의 응답성이 향상됩니다. 또한 성능 병목 현상에 대한 두려움 없이 클라이언트 수를 계속 늘리고 더 많은 웹 서버를 추가할 수도 있습니다.
Pub/Sub 메시징(메모리 내)
귀하의 경우 .NET Core 애플리케이션이 Pub/Sub 메시징 또는 이벤트를 사용해야 하는 경우 완전히 인메모리가 아닌 대신 모든 메시지를 디스크에 저장하는 Pub/Sub 메시징 플랫폼을 사용하고 있을 가능성이 큽니다. 결과적으로 애플리케이션이 트랜잭션이 많은 경우 쉽게 성능 병목 현상이 발생할 수 있습니다.
NCache 또한 완전히 In-Memory이기 때문에 매우 빠른 Pub/Sub Messaging을 제공합니다. 그리고 모든 메시지를 다른 NCache 하나의 서버가 다운되는 경우 데이터 손실이 없는지 확인하는 서버입니다.
따라서 귀하의 경우 .NET Core 응용 프로그램 사용 NCache Pub/Sub Messaging 플랫폼으로서 초고속 성능과 선형 확장성을 경험할 것입니다. NCache 자체적으로 선형 확장 가능합니다.
다음은 에서 제공하는 Pub/Sub Messaging을 사용하는 방법의 예입니다. NCache 귀하의 .NET Core 응용 프로그램.
private void PublishMessage (string topicName)
{
ITopic topic = _cache.MessagingService.GetTopic(topicName);
Order order = Order.GenerateOrder<Order>();
// Publish message containing "order" with expiry
Message message = new Message(order, new TimeSpan(0, 0, 15));
topic.Publish(message, DeliveryOption.All, true);
}
private ITopicSubscription SubscribeMessage (string topicName)
{
ITopic topic = _cache.MessagingService.GetTopic(topicName);
// Subscribes to the topic. Message delivered to MessageReceivedCallback
return topic.CreateSubscription(MessageReceivedCallback);
}
static void MessageReceivedCallback(object sender, MessageEventArgs args) { ... }그림 7: Pub/Sub 메시징 사용 .NET Core 앱
애플리케이션 데이터 캐싱
가장 큰 확장성 병목 현상 .NET Core 응용 프로그램은 응용 프로그램 데이터베이스에서 제거해야 합니다. 이 영역에서 애플리케이션은 애플리케이션 데이터 캐싱을 통해 고성능 및 선형 확장성을 달성할 수 있습니다. 그 이유는 간단합니다. 최대 .NET Core 응용 프로그램은 데이터베이스에서 앞뒤로 많은 데이터를 처리합니다.
캐시를 최신 상태로 유지
애플리케이션 데이터 캐싱과 관련하여 사람들이 갖는 가장 큰 두려움은 캐시가 오래되어 다른 사용자 또는 다른 애플리케이션에 의해 데이터베이스에서 이미 변경된 이전 버전의 데이터가 캐시에 포함된다는 것입니다.
- 참조 대 트랜잭션 데이터
캐시가 오래될 것이라는 두려움이 너무 커서 대부분의 사람들은 읽기 전용 또는 정적 데이터(참조 데이터)만 캐시합니다. 그러나 이 읽기 전용 데이터는 조회 테이블 및 기타 참조 데이터의 형태로 전체 데이터의 20%에 불과합니다. 데이터베이스에 있는 대량의 데이터는 고객, 계정, 활동 등을 포함하는 트랜잭션 데이터입니다. 그리고 이 트랜잭션 데이터를 캐시하지 않으면 캐싱의 이점을 충분히 누릴 수 없습니다.
따라서 캐싱이 오래될 염려 없이 모든 유형의 데이터를 캐싱할 수 있는 경우 캐싱의 진정한 이점이 있습니다. NCache 는 이러한 문제를 해결하기 위해 다양한 기능을 제공합니다.
- 데이터베이스와 캐시 동기화
캐시를 최신 상태로 유지하는 가장 효과적인 방법은 항상 데이터베이스와 동기화된 상태를 유지하는 것입니다. NCache 다음과 같이 다양한 데이터베이스에 대해 이 작업을 수행할 수 있습니다.
- SQL Server와 캐시 동기화: SqlDependency 및 DB 이벤트 알림 사용
- Oracle과 캐시 동기화: OracleDependency 및 DB 이벤트 알림 사용
- Cosmos DB와 캐시 동기화: Cosmos DB 변경 피드 처리 사용
- 모든 데이터베이스와 동기화 캐시(폴링 기반): 사용 NCache 폴링 기반 데이터베이스 동기화를 제공했습니다.
캐시를 SQL Server와 동기화할 때 묻습니다. NCache 자신을 SQL Server의 클라이언트로 등록한 다음 SQL 쿼리 기반 데이터 세트와 함께 SqlDependency 호출을 실행합니다. 그런 다음 SQL Server가 이 데이터 세트의 변경 사항을 확인하면 이를 알립니다. NCache 그것에 대해
private static void CreateSqlDependency (Product product)
{
string connectionString = "Data Source=localhost;Database=northwind;...";
// SQL stmt on which the SQL Dependency is created in SQL Server
string sqlStmt = "SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice " +
"FROM dbo.PRODUCTS WHERE ProductID = " + product.Id;
CacheDependency sqlDependency = new SqlCacheDependency(connectionString, sqlStmt);
CacheItem cacheItem = new CacheItem(product) { Dependency = sqlDependency };
string key = "Product:ProductId:" + product.Id; ;
cache.Add(key, cacheItem);
}그림 8: SqlDependency를 사용하여 SQL Server와 캐시 동기화
그런 다음, NCache 캐시에서 이 항목을 제거하므로 다음에 응용 프로그램에서 필요할 때 데이터베이스에서 최신 복사본을 가져와야 합니다. Read-through 처리기를 사용하는 경우(아래 참조) NCache 데이터베이스에서 최신 복사본을 자동으로 다시 로드할 수도 있습니다. 다음은 SqlDependency를 사용하여 캐시를 SQL Server와 동기화하는 방법의 예입니다.
Read-through 및 Write-through 캐시
Read-through Cache는 개발자가 개발하여 캐시에 제공한 Readthrough Handler를 호출하여 데이터베이스에서 데이터를 읽을 수 있는 캐시입니다. 마찬가지로 Write-through 캐시는 개발자가 개발하여 캐시에 제공한 Write-through 핸들러를 호출하여 데이터 변경 사항을 데이터베이스에 기록할 수 있습니다. Write-behind 캐시는 데이터베이스 업데이트가 비동기식으로 수행된다는 점을 제외하면 Write-through와 동일합니다.
Read-through, Write-through 및 Write-behind는 많은 이점을 제공합니다. .NET Core 다음을 포함한 애플리케이션:
- 앱 코드 단순화: 지속성 코드를 애플리케이션에서 캐싱 계층으로 이동합니다.
- DB에서 항목 자동 다시 로드: 만료 또는 DB 동기화 시간에 Read-through를 사용합니다.
- 더 빠른 쓰기: write-behind와 함께 비동기 데이터베이스 쓰기를 사용합니다.
다음은 Read-through를 사용하는 방법의 예입니다. NCache.
// Read through handler for SQL Server
public class SqlReadThruProvider : Runtime.DatasourceProviders.IReadThruProvider
{
public void Init(IDictionary parameters, string cacheId) {}
public void Dispose() {}
// Get object from the database/data-source based on the key
public ProviderCacheItem LoadFromSource(string key) {}
// Bulk-Get objects from the database/data-source based on the keys
public IDictionary<string, ProviderCacheItem> LoadFromSource(ICollection<string> keys)
{}
}그림 9: Read-through 핸들러 사용 NCache
캐시 검색
모든 데이터를 캐싱하는 데 익숙해지면 분산 캐시에 많은 데이터를 넣을 수 있습니다. 여기에서 데이터를 빠르고 쉽게 찾는 방법에 대한 또 다른 독특한 문제에 직면할 수 있습니다. 대부분의 분산 캐시는 키-값 저장소이므로 키를 통해서만 모든 데이터를 추적하기가 매우 어렵습니다.
여기는 NCache 캐시에서 데이터를 빠르게 찾을 수 있는 다양한 방법을 제공합니다. 예를 들면 다음과 같습니다.
- 캐시의 그룹 데이터(그룹/하위 그룹, 태그, 명명된 태그): NCache 데이터를 논리적으로 그룹화하고 나중에 한 번의 호출로 전체 그룹을 가져올 수 있는 여러 가지 방법을 제공합니다. 이렇게 하면 데이터 관리가 정말 간단해집니다.
- 쿼리로 데이터 검색(SQL / LINQ): 그룹 API 호출을 기반으로 데이터를 찾는 것 외에도, NCache 또한 개체 특성, 그룹, 태그 및 명명된 태그를 기반으로 캐시에서 데이터를 검색하는 기능을 제공합니다.
- 병렬 검색: 이후 NCache 애플리케이션이 검색 쿼리 또는 검색 API 호출을 발행하면 해당 쿼리가 모든 캐시 서버에서 병렬로 실행됩니다. 그런 다음 모든 서버의 결과는 최종 결과를 애플리케이션에 반환하기 전에 병합되는 클라이언트 시스템(즉, 애플리케이션 서버)으로 반환됩니다. 이렇게 하면 캐시 검색 속도가 정말 빨라집니다.
다음은 LINQ 기반 쿼리를 사용하는 방법의 예입니다. NCache.
// Search the cache based on object attributes by using LINQ
IQueryable>Product< products = new NCacheQuery<Product>(_cache);
var result = from product in products
where product.Id > 10
select product;
if (result != null)
{
foreach (Product p in result1)
{
// Process each “product” fetched from the database
Console.WriteLine("ProductID : " + p.Id);
}
}그림 10: LINQ 쿼리 사용 NCache
NCache 최고의 확장성을 위한 아키텍처
높은 교통량 .NET Core 애플리케이션은 특히 사용량이 많은 시간에 다운되어서는 안 됩니다. 이러한 유형의 애플리케이션에는 우수한 InMemory 분산 캐시와 같은 세 가지 중요한 아키텍처 목표가 있습니다. NCache 이행합니다.
- 클라이언트 캐시(InProc 속도)
- 빠른 복제를 통한 선형 확장성
- 동적 클러스터링을 통한 고가용성
아래에서 각각 설명하겠습니다.
클라이언트 캐시(InProc 속도)
NCache 애플리케이션에 매우 가까운 로컬 캐시인 클라이언트 캐시를 제공합니다. InProc(응용 프로그램 프로세스 내부에 있음을 의미) 또는 로컬 OutProc일 수 있습니다. 어느 쪽이든 현재 이 앱 서버의 애플리케이션에 필요한 캐시된 데이터의 하위 집합에 매우 빠르게 액세스할 수 있습니다. 클라이언트 캐시는 동시에 캐싱 계층과 동기화 상태를 유지하므로 캐싱 계층의 다른 사용자나 애플리케이션에 의해 변경된 모든 데이터가 즉시 클라이언트 캐시로 전파됩니다. 클라이언트를 사용하면 매우 확장 가능한 캐싱 계층의 일부이면서 InProc 속도를 유지할 수 있습니다.
빠른 복제를 통한 선형 확장성
가장 중요한 건축 목표 중 하나는 NCache 캐싱 토폴로지를 통해 데이터 안정성과 함께 선형 확장성을 달성하는 것입니다. 여기 몇 가지가 있습니다 NCache 캐싱 토폴로지 이 두 가지 목표를 모두 달성하는 데 도움이 됩니다.
- 파티션된 캐시: NCache 캐시 서버의 수에 따라 캐시를 분할하고 각 캐시 서버에 하나의 파티션을 할당합니다. 또한 런타임에 캐시 서버를 추가하거나 제거할 때 파티션 수를 조정합니다. 더 많은 서버를 추가할 때 이 캐싱 토폴로지가 전체 저장소 크기와 CPU 처리 능력을 증가시키기 때문에 분할은 선형 확장성을 보장하는 주요 방법입니다.
- 분할된 복제본 캐시: 파티션을 나누는 것 외에도 NCache 또한 각 파티션에 대한 복제본을 제공합니다. 이러한 복제본은 파티션 자체와 다른 캐시 서버에 상주하여 캐시 서버가 파티션과 함께 다운되는 경우 복제본을 즉시 사용할 수 있도록 합니다. 이러한 방식으로 데이터 신뢰성이 제공됩니다. 각 파티션을 다른 캐시 서버에 한 번만 복제함으로써, NCache 선형 확장성을 손상시키지 않으면서 데이터 신뢰성을 달성합니다.
100% 가동 시간을 위한 고가용성
가장 중요한 건축 목표 중 하나는 NCache 고가용성과 캐시 탄력성을 달성하는 것입니다. 다음과 같은 아키텍처 기능을 통해 이를 수행합니다.
- 자가 치유 PXNUMXP 캐시 클러스터: NCache TCP/IP를 통해 캐시 서버 클러스터를 구축합니다. 이 클러스터에는 피어 투 피어 아키텍처 즉, 마스터/슬레이브 노드가 없고 다수결 클러스터링이 없습니다. 대신 각 노드는 동일한 피어입니다. 이를 통해 NCache 노드가 다운될 수 있고 클러스터가 자동으로 조정되고 계속 실행되고 애플리케이션에 중단이 없는 상황을 처리하기 위해.
- 동적 구성: 즉, 구성 파일에 무언가를 하드 코딩할 필요가 없습니다. NCache 런타임 시 구성 정보를 모든 캐시 클라이언트(애플리케이션을 의미)에 전파합니다.
- 연결 장애 조치 지원: 캐시 서버가 다운되면 전체 캐시 클러스터와 모든 캐시 클라이언트가 중단 없이 계속 작동할 수 있습니다. 캐시 클라이언트는 클러스터의 다른 캐시 서버와 상호 작용하여 계속 작동합니다.