WCF 서비스의 요청 수준에서 캐싱을 구현하려고합니다. 이 서비스에 대한 각 요청은 많은 수의 데이터베이스 호출을 수행합니다. 여러 데이터 수집기를 생각해보십시오. 한 데이터 수집기가 이전 데이터 수집기에서 이미 검색 한 정보에 액세스 할 수있게해야합니다.메모리 캐시 또는 동시 사전?
요청 당 특정 인스턴스를 생성하여 새로운 .Net 4.0 메모리 캐시를 사용하려고했습니다.
이것은 좋은 아이디어입니까? 아니면 Dictionary 객체 만 사용해야합니까?
BTW : 데이터 수집이 병렬로 진행될 예정이므로 잠금과 관련하여 좀 더 복잡해 지겠지만 동시 수집을 사용할 수도 있습니다.
만료 논리가 필요없는 경우 동시 수집을 사용하는 것이 좋습니다. ConcurrentDictionary 및 Lazy 클래스를 결합하여 single entry caching mechanism을 쉽게 구현할 수 있습니다. Lazy와 ConcurrentDictionary 조합에 대한 링크는 another입니다.
항목이 만료되어야하는 경우 내장형 MemoryCache를 사용하고 double-checked locking pattern을 구현하여 캐시 항목을 한 번만 검색하도록하십시오. 2 중 검사 잠금 구현에 대한 준비는 Locking pattern for proper use of .NET MemoryCache
Ok - 나는 같은 줄로 생각하고 있었지만 아직도 "왜?"라고 이해하지 못합니다. 그것의. MemoryCache는 AddOrGet과 같은 캐시 관련 함수를 제공합니다. 나는 동시 수집으로 이동할 때 그것을 잃을 것이다. 만료 기능이 동시 컬렉션 대 메모리 캐시 중에서 선택할 이유가 있습니까? –
@zync ConcurrentDictionary를 Lazy와 함께 사용하는 아이디어는 응용 프로그램 도메인 당 한 번 캐시 항목을 검색하고 절대 변경하지 않도록하는 것입니다. 그렇지 않은 경우 MemoryCache가 더 좋습니다. 그러나 단일 항목 검색 논리가 필요한 경우 MemoryCache.AddOrGetExisting 메서드에 값이 필요하며이 값을 검색하는 동안 잠금을 구현해야하므로 ConcurrentDictionary를 사용하는 것이 더 적절합니다. 그러나 ConcurrentDictionary.GetOrAdd (TKey 키, Func
그런데 서비스가 시작되기 전에 캐시 항목이 잘 정의되어 있고 (즉, 동적으로 캐시하지 않은 경우) 캐시에있는 모든 데이터로드를 단 한 번에 할 수있는 경우 서비스 클래스의 정적 생성자를 사용하여 해당 캐시 항목을로드 할 수 있습니다 . 이것은 정적 생성자가 응용 프로그램 도메인 당 한 번 실행되고 해당 유형의 모든 인스턴스 생성자가 실행되기 전에 보장되므로 더 좋습니다. 간단하다. –
에서 확인할 수 있습니다. 업데이트 - 시스템 수준 메모리 캐시보다 나은 모델을 만들기 때문에 동시 컬렉션을 사용하기로 결정했습니다. –
MemoryCache 클래스를 이해하기 때문에 프로세스 레벨 캐시 인 – Legends
또는 심지어 AppDomain 수준에서도 테스트하지 않았습니다. – Legends