AppFabric 캐싱 - Read-Through/Write-Behind 전략

Question

새 프로젝트에서는 AppFabric 캐싱을 핵심 구성 요소로 삼기를 원합니다. 일반적인 지침으로 쓰기 모델/도메인과 읽기 모델/도메인을 갖습니다. 백엔드 서비스는 공급자/기타 서비스에 의해 통보되고 비즈니스 규칙에 따라 일부 데이터를 캐시에 저장합니다. 프론트 엔드 서비스/웹 사이트는 필요에 따라 데이터를 소비합니다.

읽기/쓰기 - 쓰기가 좋은 접근 방법 인 것 같습니다. 그러나 실제 비즈니스 솔루션을 구현하는 방법은 무엇입니까? 각 예제에서는 ADO.NET에서 데이터를로드하는 간단한 쿼리를 사용합니다. 우리의 경우 데이터로드는 비즈니스에 따라 다르며 많은 어셈블리와 상호 작용이 필요합니다. 우리의 모든 비즈니스를 각 캐시 호스트에 배치하는 것은 좋은 해결책이 아닌 것 같습니다.

또 다른 접근법은 도메인 당 고유 서비스를 가지며 캐시에서 가져 오기/읽기 및 캐시에 쓰기/쓰기를 담당하는 것입니다. AppFabric 캐싱에 대한 래퍼가 될 것이므로 이상적인 것은 아니며 성능이 저하됩니다.

추가 질문 사항이 있으시면 언제든지 알려주세요.

도움 주셔서 감사합니다.

Answer 1

이러한 경우에 대한 가능한 해결책 중 하나는 데이터에 액세스하기위한 모든 비즈니스 로직과 규칙을 포함하는 서비스 (데이터베이스 서버와 함께있을 수도 있음)를 만들 수 있다는 것입니다. 반면에 각 리드 - 쓰레드/라이트 - 비 쓰이 제공자는 데이터를로드하기 위해 그 서비스에 접속할 것이다. 이렇게하면 각 캐시 서버 시스템에 비즈니스 로직 및 관련 어셈블리를 배포 할 필요가 없으며 동시에 동시 읽기/쓰기 숨김 기능을 사용할 수 있습니다.

캐싱 솔루션의 경우 NCache을 조사하면 일괄 쓰기 작업과 같은 쓰기 작업이 실패 할 경우 다시 시도하는 등 더 많은 구성 가능한 옵션이있는 read-through, write-behind(async) and write-through(sync) 기능을 제공합니다.