당일날 2017 런던
분산 캐싱으로 .NET 애플리케이션 확장
이크발 칸
사장 및 기술 전도사
데이터 트랜잭션 볼륨, 세션 볼륨 또는 객체 크기가 증가하고 있다면 이 강연이 적합합니다. 앱과 데이터베이스 간의 분산 캐시를 사용하여 앱 성능을 향상하는 방법을 알아보세요. 이 강연에서는 다음을 다룹니다.
- .NET 애플리케이션의 확장성 병목 현상에 대한 간략한 개요
- 분산 캐싱에 대한 설명과 성능 문제를 해결하는 방법
- 애플리케이션에서 분산 캐싱을 사용할 수 있는 위치
- 분산 캐시의 몇 가지 중요한 기능
- 분산 캐시를 사용한 실습 예제
살펴보기
안녕하세요 여러분, 제 이름은 이크발 칸입니다. 저는 기술 전도사입니다. Alachisoft. 우리는 NCache. 얼마나 많은 사람들이 들었습니까? NCache 전에? 좋아, 좋아. 오늘의 주제는 분산 캐싱으로 .NET 애플리케이션을 확장하는 것입니다. 에 관한 것이 아닙니다. NCache, .NET 응용 프로그램이 직면한 전반적인 확장성 문제와 이 문제를 해결하는 방법에 관한 것입니다.
나는 더 대화식 토론을 선호합니다. 그러니 질문을 하기 위해 끝까지 기다리지 말고 제가 말하는 동안 질문이 있으면 손을 들어주세요. 아키텍처와 실제 코드의 조합을 살펴보고 보여드리겠습니다. NCache 캐시가 어떻게 생겼는지에 대한 예입니다.
확장성이란 무엇입니까?
따라서 몇 가지 정의를 살펴보겠습니다. 대부분 알고 계시겠지만 확장성이란 무엇입니까? 확장성은 애플리케이션 성능이 아닙니다. 최고 부하 하에서의 애플리케이션 성능입니다. 따라서 사용자가 5명일 때 초고속으로 수행되는 애플리케이션이 있는 경우 사용자가 5,000명, 50,000명 또는 500,000명일 때 초고속으로 수행되지 않는 한 확장성이 반드시 필요한 것은 아닙니다. 물론 애플리케이션이 5명의 사용자로 빠르게 수행되지 않으면 확장성 이외의 다른 문제가 있는 것입니다.
선형 확장성 대 비선형 확장성
선형 확장성은 배포 아키텍처에 가깝습니다. 부하가 분산된 환경에서 더 많은 서버를 계속 추가하고 더 많은 서버를 추가하면 트랜잭션 용량이 증가하는 방식으로 응용 프로그램이 설계되었습니까? 그런데 내가 확장성이라는 단어를 사용할 때 확장성의 데이터가 아니라 트랜잭션 확장성을 의미합니다. 우리는 엄청난 양의 데이터에 대해 말하는 것이 아닙니다. 우리는 테라바이트 또는 페타바이트의 데이터에 대해 말하는 것이 아닙니다. 우리는 많은 활동에 대해 이야기하고 있습니다. 따라서 애플리케이션이 더 많은 서버를 추가할 수 있는 방식으로 설계되고 더 많은 서버를 추가함에 따라 용량이 선형 방식으로 증가하면 선형 확장이 가능합니다.
그렇지 않은 경우 대수 곡선에 가깝습니다. 대학에서 배운 미적분학을 여전히 기억하고 이 곡선의 문제는 증가를 볼 수 있지만 특정 지점 이후에 더 많은 서버를 추가하는 것은 실제로 이점이 없다는 것입니다. 응용 프로그램에 사라지지 않는 일부 병목 현상이 있기 때문에 실제로 성능이 떨어집니다. 따라서 확실히 비선형적이기를 원하지는 않습니다.
어떤 애플리케이션에 확장성이 필요합니까?
그렇다면 어떤 애플리케이션에 확장성이 필요할까요? 물론 이들은 일반적으로 서버 응용 프로그램입니다. 웹 애플리케이션, ASP.NET, 이제 ASP.NET Core 또한. 웹 서비스. 다시 WCF를 통해 수행할 수 있습니다. ASP.NET 웹 API 또는 ASP를 할 수 있습니다..NET Core 웹 API. 즉, 웹 서비스는 일반적으로 요즘 매우 빠르게 부상하는 공간인 사물 인터넷의 백엔드입니다.
이들은 또한 빅 데이터 처리 응용 프로그램입니다. 따라서 데이터가 많은 경우 확장성의 데이터 부분이 제공되지만 데이터에 관한 것이 아니라 데이터를 얼마나 빨리 처리할 수 있는지에 관한 것입니다. 따라서 빅 데이터 처리 애플리케이션이 있는 경우 확장이 필요합니다. 대부분의 빅 데이터 처리 애플리케이션은 일반적으로 .NET이 아닙니다. 그들은 Java 측면에 더 가깝고 저는 .NET 애플리케이션에 더 중점을 둡니다. 그러나 개념적으로 빅데이터 처리 애플리케이션도 확장성이 필요한 것입니다.
그리고 마지막으로 다른 모든 서버 응용 프로그램입니다. 당신은 금융 기관일 수도 있고, 큰 은행일 수도 있고, 수백만 명의 고객이 있고, 고객이 전화를 걸고, 주소를 변경하고, 새 카드를 발급하는 등 처리해야 할 모든 것, 자금 이체를 원할 수 있습니다. 규정 준수를 위해 특정 기간 내에 모든 요청을 처리합니다. 따라서 이러한 백엔드 배치 프로세스가 많이 진행되고 있으며 매일 밤 받는 단 몇 시간이라는 아주 짧은 시간 내에 점점 더 많은 트랜잭션을 처리해야 합니다. 따라서 모든 서버 응용 프로그램. 따라서 이러한 응용 프로그램이 있고 확장성이 필요한 경우 지금 바로 찾아오셨습니다.
확장성 문제
그렇다면 확장성 문제는 무엇입니까? 음, 응용 프로그램 계층은 문제가 아닙니다. 내가 언급한 대부분의 애플리케이션에서 애플리케이션 계층은 완벽하게 잘 작동하는 것 같습니다. 더 많은 서버를 추가할 수 있습니다. 일반적으로 부하 분산 환경이 있습니다. ASP.NET 응용 프로그램이 있는 경우 상단에 로드 밸런서가 있고 로드 밸런서가 트래픽을 보내는 서버 그룹이 있고 더 많은 트래픽이 필요할 때 더 많은 사용자를 처리해야 하므로 서버를 더 추가하기만 하면 됩니다. 아주 간단합니다.
그러나 문제는 데이터베이스가 관계형이든 메인프레임 데이터이든 병목 현상이 발생한다는 것입니다. 그리고 관계형은 특정 데이터베이스를 의미하지 않습니다. SQL 서버일 수도 있고 Oracle, MySQL, Db2 등이 될 수도 있습니다. 모든 관계형 데이터베이스에는 확장할 수 없다는 고유한 약점이 있습니다. 그렇기 때문에 바로 NoSQL 움직임이 시작되었고 실제로 우리는 .NET 공간에 다음과 같은 제품도 있습니다. NosDB 오픈 소스입니다 NoSQL database 하지만 NoSQL databases가 항상 정답은 아닙니다. 확장 성 문제를 확실히 해결한다는 의미입니다. 기술적으로 말하면 NoSQL database 확장성 병목 현상이 발생하지 않습니다. 그러나 문제는 기술 및 비즈니스 이유가 결합되어 관계형 또는 레거시 메인프레임 외부의 모든 데이터를 NoSQL.
그래서, NoSQL 우리가 새로운 데이터라고 부르는 것 중 일부에 더 가깝습니다. 전통적인 비즈니스 데이터는 여러 가지 이유로 여전히 관계형 데이터베이스에 상주합니다. 즉, 관계형 데이터베이스를 사용하면서 이 문제를 해결해야 합니다. 내 사진에서 관계형 데이터베이스를 제거하겠다고 말할 수는 없습니다. 사실 우리 고객 중 어느 누구도 NoSQL. 일부 데이터를 NoSQL. MongoDB와 같은 더 큰 플레이어도 NoSQL database 일부 데이터를 다음 위치로 이동 NoSQL 그들은 여전히 관계형 데이터베이스에 전통적인 데이터를 유지합니다.
분산 캐시 배포(NCache)
따라서 그림에서 관계형 데이터베이스의 문제를 해결해야 합니다. 분산 캐시 들어옵니다. 실제로 동일한 이점을 자주 제공합니다. NoSQL database. 사실 생각해보면 이건 NoSQL 메모리 내 키 값 저장소. 그래서 알아봤다면 NoSQL databases에는 JSON 문서 데이터베이스가 있고 키 값 저장소가 있고 그래프 데이터베이스가 있고 다른 유형이 있습니다. 따라서 키 값 저장소는 ... 분산 캐시의 유일한 점은 지속성을 수행하지 않고 모두 메모리에 있다는 것입니다. 키 값 저장소입니다. 또한 여러 서버에 분산되어 있기 때문에 서버를 더 추가할 수 있으므로 동일한 이점을 얻을 수 있습니다. 따라서 이것을 여기 위의 애플리케이션 계층으로 생각하십시오. 바로 여기에 애플리케이션 계층이 있고 일반적으로 여기 어딘가에 로드 밸런서가 있습니다. 그리고 이 계층에 더 많은 서버를 추가하면 중간에 캐싱 계층을 배치하지 않는 한 데이터베이스에 점점 더 많은 부하가 가해집니다.
캐싱 계층은 애플리케이션 계층과 마찬가지로 확장됩니다. 계속해서 더 많은 상자를 추가하기 때문에 병목 현상이 없습니다. 데이터는 여러 서버에 분산됩니다. 그건 그렇고 저비용 서버입니다. 이들은 고급 데이터베이스 유형의 서버가 아닙니다. 사실 우리 고객은… 일반적인 구성은 일반적인 웹 서버 상자와 같지만 메모리가 더 많은 약 16기가의 RAM, 약 8개의 코어 상자입니다. 16기가, 16~32기가, 32기가 이상은 권장하지 않습니다. 사실 64기가는 우리가 고객에게 권장할 수 있는 최대치입니다. 우리는 더 많은 서버를 추가한다고 말할 것입니다. 왜 그런 겁니까? 메모리를 너무 많이 늘리면 .NET에 가비지 수집이라는 기능이 있기 때문입니다. 그리고 가비지 수집에는 많은 처리 능력이 필요합니다. 따라서 메모리가 많을수록 더 많은 가비지 수집이 필요하고 CPU가 더 빨라져야 합니다. 캐시는 점점 더 데이터베이스처럼 되지 않고 더 비싸지고 있습니다. 따라서 몇 대의 고급 서버를 보유하는 것보다 더 많은 서버를 보유하는 것이 좋습니다.
따라서 분산 캐시는 기본적으로 서버 클러스터를 형성합니다. 이것은 일반적으로 TCP 기반 클러스터이며 해당 클러스터는 클러스터의 모든 서버가 서로에 대해 알고 리소스를 하나의 논리적 용량으로 풀링한다는 것을 의미합니다. 클러스터가 있다는 것은 용량을 늘려야 할 때 클러스터에 다른 서버를 추가하기만 하면 된다는 의미입니다. 또는 용량을 줄여야 할 때 서버를 삭제합니다. 그리고 이 캐싱 계층이 있으면 데이터를 유지할 필요가 없기 때문에 메모리 내 저장소입니다. 상설매장이 아닙니다. 영구 저장소는 여전히 데이터베이스이며 메모리 내 저장소이기 때문에 데이터 복제도 제공해야 합니다.
이 전체 그림의 목표는 본질적으로 시간의 약 80%를 캐시로 이동하는 것입니다. 따라서 상상할 수 있다면 80%의 시간 동안 캐시로 이동하면 데이터베이스에 스트레스가 전혀 없을 것입니다. 확장성을 상당히 높일 수 있습니다.
질문: 애플리케이션이 여전히 데이터베이스와 너무 많이 통신할 필요가 없습니까?
실제로는 그렇지 않습니다. 따라서 데이터에 따라 다릅니다. 그러나 대부분의 애플리케이션 데이터는 몇 초마다 변경되지 않는 참조 데이터 또는 트랜잭션 데이터 범주 사이에 속합니다. 몇 분마다 변경됩니다. 따라서 모든 데이터에 대해 쓰기보다 훨씬 더 많은 읽기를 수행합니다. 따라서 첫 번째 읽기는 데이터베이스로 이동하고 심지어 다음과 같은 기능이 있습니다. NCache 캐시에 데이터를 미리 로드할 수 있는 기능이 있습니다. 따라서 보유할 것이라고 생각하는 모든 데이터로 캐시를 워밍업할 수 있으며 트래픽이 적중하지 않아도 데이터베이스에 적중하지 않습니다. 그러나 데이터에 따라 다릅니다. 예를 들어 다른 유형의 데이터가 있는 경우 세션을 저장하는 경우 한 번 읽을 때마다 한 번 쓸 수 있습니다. 따라서 상황에 따라 다르며 세부 사항을 살펴보겠지만 좋은 질문입니다.
그렇지 않은 이유는 캐시가 데이터를 로드하고 캐시에 보관하기 때문입니다. 따라서 캐시와 데이터베이스 간의 트래픽은 매우 드뭅니다. 다시 말했듯이 읽기가 완료되고 캐시에 데이터가 있는 시간의 80%입니다. 따라서 캐시할 때 특정 시간 동안 캐시하고 해당 기간 동안 캐시는 매번 데이터베이스로 이동하지 않습니다. 그러나 응용 프로그램은 매번 캐시로 옵니다. 따라서 트래픽이 많은 경우에도 모두 캐시로 들어오고 갑자기 데이터베이스가 매우 가벼워집니다.
실제로 각 상자에 대한 분할이 있어 서로 다른 데이터를 저장하고 있으며 안정성을 위해 일부 중복성이 내장되어 있지만 이에 대해 자세히 설명하겠습니다.
따라서 이 그림(그림 1)은 오늘날의 확장성이 높은 환경에서 분산 캐시가 일종의 사실상의 모범 사례라는 것을 확신시키기 위한 것입니다. 따라서 애플리케이션을 설계하는 경우 캐시를 염두에 두십시오. 어떤 캐시인지는 중요하지 않습니다. 그것은 별도의 논의입니다. 첫 번째 논의는 분산 캐시로 이동하는 방식으로 애플리케이션을 설계해야 한다는 것입니다. 그렇게 하면 비즈니스에서 애플리케이션을 수행해야 할 때 애플리케이션이 질식하지 않을 것이라고 확신할 수 있습니다.
그리고 미리 계획하지 않으면 확장할 수 없다는 단점이 있습니다. 이 문제는 비즈니스가 실제로 잘 진행되고 있을 때 발생한다는 것입니다. 당신이 항공사이고 휴가지에서 이번 주말 프로모션을 실행했는데 수백만 명의 신규 사용자가 항공편 검색을 하고 티켓을 구매하기 위해 웹사이트를 방문한다고 상상해 보세요. 클릭이 XNUMX분이면 웹 사이트 성능이 느려지기 시작하면 고객을 잃게 됩니다. 그리고 상황이 더 악화되고 데이터베이스가 막혀서 응용 프로그램이 충돌하기 시작하면 많은 비즈니스를 잃게 됩니다. 따라서 미리 계획을 세워야 합니다. 비록 당신이 오늘 그 문제에 직면하고 있지는 않지만, 이것은 성능에 관한 것이 아닙니다.
많은 사람들이 캐시를 사용하면 성능이 향상된다고 생각합니다. 성능은 향상되지만 요즘 데이터베이스는 매우 빠릅니다. 이 다섯 명의 사용자만 있는 경우. 데이터베이스가 느리다고 불평하는 사람을 본 적이 없습니다. 따라서 문제는 성능이 아닙니다. 문제는 확장성입니다. 데이터베이스 서버가 하나만 있고 응용 프로그램 계층에 더 많은 서버를 추가하면 갑자기 데이터베이스가 병목 상태가 되기 때문입니다.
질문: 캐시 클러스터에 VM을 사용해야 합니까 아니면 물리적 상자를 사용해야 합니까?
아주 좋은 질문입니다. 그것에 대해 이야기하려고 했는데 잊어버렸습니다. 물어봐 주셔서 감사합니다. 따라서 이들은 물리적인 상자일 수 있습니다. 우리는 여전히 물리적 상자를 가지고 있는 고객이 있지만 점점 더 많은 고객이 VM으로 이동하고 있으며 이제 새로운 추세는 컨테이너입니다. 따라서 최소한 VM이 있어야 합니다. 따라서 모든 캐시 서버는 VM입니다. 따라서 최소 16개의 캐시 서버 VM이 있습니다. 내가 말했듯이 각각 32 ~ XNUMX 기가. 물론 동일한 물리적 상자에 두 VMS가 있는 것을 원하지는 않습니다. 그러면 고가용성 이점을 잃게 되기 때문입니다. 그 상자가 충돌하면 두 VMS가 모두 사라지기 때문입니다.
질문이 하나 더 있습니다. 그렇다면 물리적 데이터는 메모리에 저장됩니까?
메모리에. 정확히, 정확히. 모두 메모리 내 저장소입니다. 그리고 임시 저장소이기 때문에 몇 분, 몇 시간, 며칠, 몇 주 동안 저장합니다. 영구적으로 저장하지 않습니다. 영구 저장소는 여전히 데이터베이스입니다. 그것이 무엇이든. 내가 말했듯이 레거시 메인프레임일 수도 있고 관계형일 수도 있고 NoSQL.
심지어 NoSQL database, 분산 캐시를 사용해야 합니다. 왜냐하면 NoSQL 분산 캐시만큼 빠르지 않고 우리가 알고 있는 두 제품을 모두 가지고 있기 때문입니다. 우리는 벤치마크를 수행합니다. 여전히 10배 더 빠릅니다.
나는 익숙하지 않다. NoSQL database, 관계형 데이터베이스보다 성능이 더 좋은 이유가 궁금했습니다.
또한 여러 서버에 분산되기 때문에 더 확장됩니다. 따라서 분산 캐시가 5, 10, 15, 20개의 서버를 가질 수 있는 것처럼 NoSQL database. SQL용 서버는 20개일 수 없습니다. 액티브-패시브 또는 액티브-액티브에 대해 2개를 가질 수 있지만 그게 전부입니다. 알다시피, 당신은 실제로 확장할 수 없습니다. 따라서 확장성 때문입니다.
따라서 VM이거나 이제 컨테이너가 관리를 위해 점점 더 대중화되고 있으며 이는 온프레미스일 수도 있고 클라우드, 모든 환경일 수도 있습니다.
분산 캐시의 일반적인 사용
그래서 저는 이 그림(그림-1)이 여러분이 캐싱을 사용해야 한다는 것을 확신시키기를 바랍니다. 이제 당신은 확신합니다. 오는 다음 질문은 어떻게 사용합니까? 어디에서 사용합니까? 따라서 캐싱을 사용하는 세 가지 일반적인 위치가 있습니다.
앱 데이터 캐싱
첫 번째는 제가 지금까지 이야기한 바로 이 정확한 그림인 애플리케이션 데이터입니다. 여기에 데이터를 캐시하므로 데이터베이스로 이동할 필요가 없습니다. 에서 명심해야 할 유일한 것 애플리케이션 데이터 캐싱 이제 데이터가 두 곳에 존재한다는 것입니다. 하나는 캐시이고 다른 하나는 데이터베이스입니다. 데이터가 두 곳에 존재할 때 무엇이 잘못될 수 있습니까? 동기화. 따라서 대부분의 사람들이 읽기 전용 데이터 이외의 용도로 캐시를 사용하는 것을 두려워하는 큰 문제입니다. 평범한 사람에게 묻는다면 캐시를 사용하는 것에 대해 생각해 본 적이 있습니까, 아니면 캐싱을 하고 있습니까? 사람들은 때때로 이러한 해시 테이블을 만들거나 메모리 저장소에 일부를 만들고 읽기 전용 데이터만 넣습니다. 애플리케이션 전체 또는 매우 편안한 시간 프레임에서 절대 변경되지 않는 데이터. 글쎄, 읽기 전용 데이터 또는 참조 데이터는 전체 데이터의 10-15%에 불과합니다. 따라서 확실히 많은 이점을 제공하지만 실제 이점은 모든 데이터를 캐시할 수 있다는 것입니다. 즉, 실제로 처리 할 수 있어야합니다 ...
좋은 분산 캐시는 동기화를 처리해야 합니다. 따라서 캐시가 항상 최신 상태인지 확인해야 합니다. 따라서 캐시에서 읽고 있는 것이 무엇이든 해당 데이터의 최신 복사본이라는 캐시에 대한 확신을 가질 수 있습니다.
그리고 캐시의 가치를 거의 최소화하거나 줄이는 읽기 전용 데이터로 제한될 것이라는 확신이 없다면.
ASP.NET 특정 캐싱
그래서 두번째 혜택은 ASP.NET 특정 캐싱. 나는 ASP에 가지 않을거야.NET Core 지금은 그것에 대해 간략히 다루겠습니다. 그러나 ASP.NET 캐싱에는 이 작업을 수행할 수 있는 위치가 세 군데 있으며 적어도 지금은 두 군데가 있습니다. MVC 프레임워크가 있는 경우 뷰 상태가 없지만 모든 ASP.NET 응용 프로그램의 세션에는 세션이 있으며 세션은 어딘가에 저장되어야 합니다. 기본적으로 ASP.NET 응용 프로그램 또는 SQL 서버의 작업자 프로세스 내에 있는 In-Proc인 메모리 내 저장됩니다. 상태 서버는 클라우드에서 사용할 수 없으며 온프레미스에만 있으며 모두 문제가 있습니다. 일부는 확장성 문제가 있습니다. 사실 모두 확장성 문제가 있습니다. 일부는 성능 문제도 있습니다. SQL 데이터베이스와 마찬가지로 성능 문제도 있습니다.
따라서 분산 캐시의 매우 훌륭한 사용 사례는 해당 세션을 캐시에 넣는 것입니다. 알다시피, 해당 세션은 저장됩니다. SQL에 저장하면 Blob으로 저장됩니다. 그리고 관계형 데이터베이스는 Blob 저장소용으로 설계되지 않았습니다. 하지만, NoSQL 또는 키 값이 저장되면 값은 blob입니다. 따라서 분산 캐시에 정말 잘 맞습니다. 물론 문제도 해결해야 합니다. 점점 더 많은 사람들이 재해 복구 또는 로드 밸런싱, 지리적 로드 밸런싱을 위해 다중 데이터베이스 또는 다중 데이터 센터로 이동하고 있습니다. 따라서 해당 문제도 해결해야 합니다.
뷰 상태는 더 이상 ASP.NET에 없지만 이전 버전인 경우 ASP.NET 5라고 생각합니다. ASP.NET 4를 사용하는 경우 뷰 상태 또는 이전 MVC에서는 뷰 상태가 존재합니다. 그 동안 개발된 대부분의 ASP.NET 응용 프로그램에는 여전히 존재합니다.
보기 상태가 무엇인지 모르는 분들을 위해 설명드리자면, 보기 상태는 웹 서버에서 브라우저로 보내는 암호화된 문자열로, 포스트백이 발생할 때만 돌아옵니다. 따라서 이 문자열은 수백 킬로바이트가 될 수 있으며 브라우저로 이동하여 브라우저에 저장되었다가 다시 돌아옵니다. 애플리케이션이 처리해야 하는 수백만 건의 트랜잭션을 곱하면 두 가지 문제가 있습니다. 하나는 저렴한 대역폭이 아닌 많은 대역폭을 소비한다는 것입니다. 대역폭 비용을 지불해야 합니다. 둘째, 무거운 페이로드가 이동하기 때문에 응답 시간이 느려집니다. 따라서 서버에 캐싱하고 작은 키를 보내고 다음에 다시 돌아올 때 보기 상태를 캐시에서 가져와서 페이지에 제공하는 것이 이상적인 경우입니다. 다시 말하지만 뷰 상태는 MVC 프레임워크를 사용하지 않는 경우에만 문제가 되며 ASP에도 없습니다..NET Core 때문에 ASP.NET Core MVC입니다.
ASP.NET 출력 캐시는 ASP의 일부이기도 합니다..NET framework, ASP에 없음.NET Core 페이지 출력을 거의 캐시합니다. 따라서 다음 요청에서 페이지가 변경되지 않는다면 왜 다시 실행해야 할까요? 따라서 ASP.NET은 페이지를 캐시하므로 다음에 요청이 동일한 매개 변수와 함께 제공되면 마지막 실행의 출력이 페이지에 제공됩니다.
따라서 해당 프레임워크는 이미 존재하며 이를 위해 분산 캐시를 사용하는 것이 좋습니다. 따라서 다중 서버 환경에서 일단 캐시되면 모든 서버에서 즉시 사용할 수 있습니다. ASP.NET Core 캐싱을 위한 세션만 있고 보기 상태가 없으며 출력 캐시가 없습니다. 그러나 응답 캐싱이라는 또 다른 기능이 있습니다. 그래서 ASP.NET Core 콘텐츠 캐싱이 서버 외부에서 발생하는 전체 웹 응용 프로그램으로 이제 표준화되었습니다. 따라서 캐싱을 위한 좋은 후보이기도 합니다. 그래서 ASP.NET Core 응답 캐싱 미들웨어 개념이 있습니다. 따라서 사용할 수 있는 기본 제공 미들웨어가 있으며 타사 미들웨어를 사용할 수 있습니다. 좋다 NCache 곧 하나를 제공할 것입니다.
어쨌든 ASP.NET 캐싱의 경우 지금 명심해야 할 중요한 점은 이 데이터를 더 이상 캐시에 저장하지 않는다는 것입니다. 따라서 데이터가 두 곳에 존재하는 애플리케이션 데이터와 달리 이제 데이터는 한 곳에만 존재하며 그것이 캐시이고 메모리 내 캐시입니다. 그렇다면 메모리 내 저장소가 유일한 저장소일 때 무엇이 잘못될 수 있습니까? 예. 내 말은 그 상자가 무너지면 당신은 물에 빠진다는 뜻입니다. 메모리는 휘발성이기 때문입니다. 지속되지 않습니다. 따라서 이를 처리하는 방법은 물론 복제를 수행하는 것입니다. 둘 이상의 서버에 해당 데이터를 보유합니다. 그러나 다시 해결해야 할 두 가지 매우 다른 문제입니다. 좋은 분산 캐시는 지능형 복제를 수행해야 합니다. 예를 들어 ASP.NET 세션을 안전하게 저장하려는 경우. 그렇지 않으면 어떻게 될까요? 항공사로 돌아가 봅시다. 나는 방금 그 웹 사이트에 갔다. 5,000원 상당의 표를 사겠습니다. 나는 모든 항공편 검색, 모든 종류의 조합을 수행했고 곧… 지불 정보를 입력하고 제출하려고 하는데 갑자기 시작 페이지로 다시 보냈습니다. 내 세션이 손실되었기 때문입니다. 내가 제출을 눌렀을 때 웹 서버로 이동했는데 해당 웹 서버가 거기에 없었기 때문에 충돌이 발생하고 세션이 사라졌습니다. 그래서 확실히 좋은 사진은 아닙니다.
이벤트를 통한 런타임 데이터 공유
세 번째 사용 사례는 런타임 데이터 공유 이벤트를 통해. 이것은 많은 사람들이 모르는 것입니다. 이제 분산 캐시가 점점 더 대중화되고 있다는 사실을 알고 있습니다. 분산 캐시를 환경에 배치하면 다음과 같이 여러 애플리케이션 간에 데이터를 공유할 수 있는 정말 강력한 플랫폼입니다. Pub / Sub 모델 또는 기타 이벤트 기반 데이터 공유.
예를 들어 데이터를 공유해야 하는 여러 애플리케이션이 있을 수 있습니다. 하나의 애플리케이션이 무언가를 생성하고, 캐시에 저장하고, 일부 이벤트를 발생시키고, 해당 이벤트에 대한 구독자가 있습니다. 따라서 다른 애플리케이션 인스턴스 또는 다른 애플리케이션이 있으며 애플리케이션에서 발생하는 일종의 워크플로우가 있는 경우가 많습니다. 어떤 것이 먼저 수행되고 그 다음에 다른 것이 수행되는 것을 기반으로 합니다. 그리고 이 경우 해당 이벤트에 대한 이러한 구독자가 있습니다. 해당 애플리케이션에 알림이 전송됩니다.
지금 이 사진을 생각해 보십시오(그림 1) 여기. 이것을 애플리케이션과 데이터베이스 사이의 캐시로 보지 마십시오. 이를 메시지 버스로 생각하면 이러한 애플리케이션은 모두 메시지 버스에 연결됩니다. 이 서버의 한 응용 프로그램은 데이터를 캐시에 넣고 이벤트를 발생시킵니다. 이러한 서버 중 일부에 있는 다른 응용 프로그램은 알림을 받고 즉시 이동하여 데이터를 소비합니다. 매우 강력한 방법입니다.
어떤 사람들은 메시지 대기열을 사용합니다. 대부분의 경우 메시지 대기열에는 명확한 목적이 있습니다. 분산 캐시는 이를 완전히 대체하기 위한 것이 아니라 사례의 하위 집합입니다. 모든 데이터 공유가 동일한 데이터 센터 내에 있을 때 매우 분산된 환경이 아니라 트래픽이 많은 환경입니다. 메시지 대기열은 분산 캐시와 달리 확장할 수 없습니다. 메시지 큐에는 이와 같은 클러스터가 없기 때문입니다. 더 이상 추가할 수 없습니다. 따라서 수백만 건의 트랜잭션이 발생하고 그 일부가 메시지 정보이기도 한 경우 메시지 대기열은 해당 로드를 처리할 수 없지만 캐시는 처리할 수 있습니다.
따라서 런타임 데이터 공유는 정말 강력한 방법이며 이에 대해 다루겠습니다. 다시 말하지만, 런타임 데이터 공유에서 데이터는 일반적으로 캐시에만 존재합니다. 그러나 다른 형태가 데이터베이스에 존재할 수 있습니다. 데이터베이스에서 읽어서 다른 형식으로 변환한 다음 공유를 위해 캐시에 넣었기 때문입니다.
따라서 일부 기능은 모든 캐시에서 공통적입니다. 일부는 단지 NCache .NET 측에 있지만 모든 것이 NCache .NET 측에서 .NET 독점 기능이 아닙니다. Java 측과 모든 Java 캐시에서 동일한 기능을 볼 수 있기 때문입니다. 따라서 Java는 .NET보다 오랫동안 서버 측 기술이었기 때문에 훨씬 더 발전했거나 시장에서 훨씬 더 성숙했습니다. 자, 보시다시피... Java 쪽에서요. .NET 측에서는 전부가 아닌 일부 캐시에서 볼 수 있습니다. 예를 들어, AppFabric, 나는 그것을 가지고 있지 않은 것 같아요. Redis 전부가 아니라 일부가 있습니다. NCache Java 캐시와 같은 완전한 기능을 갖추고 있습니다.
이렇게 세 가지 사용 사례가 있습니다. 각각에 대해 더 자세히 알아보기 전에 이것에 대한 질문이 있습니까?
실습 데모
그 전에 먼저 캐시가 어떻게 생겼는지 보여드리겠습니다. 당연히 사용하겠습니다 NCache 예를 들지만 목적은 캐시가 실제로 어떻게 생겼는지에 대한 느낌을 주는 것입니다. 예를 들어 Azure에 1개의 VM이 있습니다. 그들은 달리고 있습니다. Demo2과 demo2는 내 캐시 서버 VM입니다. 그래서 저는 XNUMX노드 캐시 클러스터를 가질 것입니다.
데모 클라이언트는 내 애플리케이션 서버입니다. 따라서 캐시 클라이언트 VM입니다.
클러스터형 캐시 생성
여기서 데모 클라이언트 VM에 로그인했습니다. 계속해서 클러스터된 캐시를 생성하겠습니다. 의 경우 NCache, 나는이 도구를 사용할 것입니다 NCache 매니저, 그래픽 도구입니다. 나는 여기에 와서 캐시가 이미 존재하지 않는지 먼저 확인하겠습니다. 좋아요, 그렇지 않습니다. 좋아요, 여기 와서 새 클러스터 캐시를 생성한다고 말할 것입니다.
의 경우 NCache 모든 캐시에는 이름이 지정됩니다. 그래서 내 캐시는 데모캐시. 모든 기본값을 그대로 두겠습니다. 나는 이것에 대해 자세히 다루지 않을 것입니다. 계속해서... 중요한 부분만 이야기하겠습니다.
가장 먼저 선택할 항목은 캐싱 토폴로지 NCache 여기에서 여러분 중 한 분이 파티셔닝에 대한 질문을 하셨습니다. 데이터가 실제로 분산되어 있는지 아니면 모든 서버에 동일한 데이터가 존재하는지. 따라서 파티션 복제본은 토폴로지입니다. NCache 당신에게 준다.
예를 들어, 저는 이것을 빠르게 건너뛰고 그 토폴로지가 무엇인지에 대해 빠르게 이야기할 것입니다. 따라서 파티션 복제 토폴로지… 이것은 파티션된 토폴로지입니다. 이것은 파티션 복제본입니다.
파티셔닝에서 모든 서버는 데이터의 1n분의 XNUMX을 가집니다. 그렇다면 만약에 NCache, 클러스터된 캐시를 구축하면 500개의 버킷이 생성됩니다. 따라서 두 개의 서버 클러스터가 있는 경우 모든 서버는 XNUMX입니다. 세 개가 있는 경우 모든 서버는 천분의 일입니다.
따라서 이러한 버킷은 본질적으로 해시 테이블 버킷과 같습니다. 모든 버킷에는 할당된 키 값 범위가 있습니다. 따라서 키를 해시 값으로 변환하는 해시 맵 기능이 있으며 키를 기반으로 해야 하는 모든 버킷에 해당됩니다. 따라서 분할된 복제본에는 모든 서버에 하나의 파티션이 있습니다. 예를 들어, 당신이 여기에 온다면. 여기에 XNUMX개의 서버 클러스터가 있고 XNUMX개의 파티션과 모든 파티션이 다른 서버에 백업 또는 복제본을 가지고 있다고 가정해 보겠습니다.
의 경우 NCache 복제본이 활성 상태가 아닙니다. 수동적입니다. 따라서 파티션만 복제본과 통신합니다. 응용 프로그램은 파티션과 통신합니다. 따라서 모든 캐시 클라이언트, 모든 애플리케이션 서버가 모든 캐시 서버에 연결되어 있다고 가정해 보겠습니다. 연결하고 모든 클러스터 구성원 정보를 가져옵니다. 분산 맵이 버킷 맵입니다. 그래서 각 버킷이 어디에 있는지 알려주는 버킷 맵을 얻습니까? 2번 항목을 추가해야 하는 경우 서버 2로 이동해야 합니다. 파티션 3가 있기 때문에 XNUMX번 항목에 대한 키가 있어야 합니다. 그 서버는 그렇게 할 수 있습니다.
그런 다음 서버가 다운되면 파티션 3이 다운되므로 복제본 3이 즉시 활성화됩니다. 이제 파티션이 됩니다. 복제본에서 파티션으로 변환됩니다. 당신은 모르기 때문에 계속하고 싶기 때문입니다. 캐시가 실행되어야 하고 애플리케이션이 계속되어야 합니다. 바로 고가용성입니다. 그런 다음 이 파티션 XNUMX은 서버가 두 개뿐이라는 것을 깨닫고 이 두 파티션으로 병합하고 일종의 사라져야 합니다. 따라서 다른 두 파티션에 자체 병합한 다음 병합이 완료되면 여기에 파티션 XNUMX의 복제본이 생성됩니다.
다시 한 번 그 토폴로지가 의미하는 바에 대한 개요를 제공하고 서버를 더 추가함에 따라 점점 더 많은 스토리지를 확보하기 위해 배포가 발생하는 방식이며 모든 데이터가 두 서버에 존재하도록 복제가 발생하는 방식이기도 합니다. 따라서 서버가 다운되더라도 데이터 손실이 없습니다.
다시 말하지만, 고가용성 이론에 따르면 두 서버가 동시에 다운되지는 않습니다. 두 서버가 동시에 다운될 가능성은 한 서버가 다운될 확률에 비해 천문학적으로 낮습니다. 물론 내가 말했듯이 두 서버가 동일한 전원 공급 장치에 있으면 해당 전원 공급 장치가 다운되면 모든 것이 중복된다고 가정합니다. 그러면 두 가지가 동시에 실패하지 않을 것입니다. 그렇기 때문에 XNUMX개만 있으면 충분합니다.
돌아가자. 그래서 그것은 파티션 복제본이었습니다. 그런 다음 비동기 복제를 선택합니다.
따라서 두 가지 모드가 있습니다. 대부분의 분산 캐시는 최종 일관성이라는 작업을 수행합니다. 즉, 배포 때문에 즉시 동기화해야 한다면 모든 것이 느려질 것입니다. 그러나 감당할 수 있는 대부분의 데이터는 일종의 대기열에 저장되고 비동기 업데이트가 있습니다. 따라서 비동기는 여기에서 기본값으로 사용됩니다.
데모 클라이언트를 선택하거나 데모 1이 첫 번째 서버입니다. 데모 2를 두 번째 서버로 선택하겠습니다.
여기로 올게요. 그냥 기본값을 사용하겠습니다.
각 서버가 사용해야 하는 메모리 양을 지정하겠습니다.
물론 귀하의 경우에는 훨씬 더 많을 것입니다. 예를 들어 각 상자에 16기가 메모리가 있는 경우 일부는 파티션용으로, 일부는 복제용으로 할당해야 합니다. 그러니까 2~3기가는 운영체제와 다른 프로세스에 남겨야 하고 13기가 정도가 남는다고 합시다. 따라서 7.5 또는 6.5기가, 복제본용 파티션 XNUMX용입니다. 그리고 캐시가 이보다 더 많이 소비하지 않도록 해당 크기를 지정하기 때문입니다. 메모리 내 저장소이기 때문에 메모리는 항상 제한되어 있고 해당 상자에서 다른 응용 프로그램이 실행될 수 있습니다. 따라서 캐시가 사용해야 하는 메모리 양과 캐시가 해당 메모리를 사용한 후에는 일종의 제한을 원합니다.
그러면 다음 페이지가 됩니다. 그 메모리를 모두 사용했다고 가정해 보겠습니다. 이제 캐시가 가득 찼습니다. 따라서 두 가지 일만 발생할 수 있습니다. 하나는 이전 데이터 또는 다른 데이터 중 일부를 제거하거나 두 번째로 새 삽입을 거부합니다. 따라서 이 두 가지를 선택해야 합니다. 물론 용량 계획을 세우고 싶을 것입니다. 여기서 데이터는 애플리케이션 데이터인 경우 데이터베이스에서 항상 다시 로드할 수 있으므로 제거해도 됩니다. 세션을 퇴거시키는 것은 옳지 않습니다. 따라서 이러한 세션이 제거되지 않는 방식으로 용량 계획을 수행하려고 합니다. 이제 메모리, RAM, 서버가 충분하여 항상 세션을 위한 메모리를 확보할 수 있습니다. 그리고 테마를 제거하지 않고 세션을 만료하려고 합니다. 퇴거는 세션이 아직 만료되지 않았지만 남은 메모리가 없으므로 일종의 강제 퇴거를 의미합니다. 다음의 경우 만료 NCache 비활성 시간이 20분인 경우에만 세션이 유효하다고 지정했음을 의미합니다. 그 후 세션을 정리해야 합니다. 그래서 만료입니다. 따라서 만료는 괜찮습니다. 문제는 없지만 퇴거는 세션에 수행해서는 안 되는 작업입니다. 응용 프로그램 데이터에 수행하는 것은 괜찮습니다.
그래서, 당신이 할 경우 NCache, 세션에 대한 캐시를 만들고 애플리케이션 데이터에 대한 캐시를 만듭니다. 그래서 둘을 구분하는 방법입니다. 이제 방금 이 캐시를 만들었다고 가정해 보겠습니다. 따라서 XNUMX노드 캐시입니다. 계속해서 데모 클라이언트인 내 상자인 클라이언트 노드를 추가하고 이제 캐시를 시작하겠습니다.
스트레스 시뮬레이션 및 캐시 통계 모니터링
보시다시피 매우 간단합니다. 일종의 Explorer 스타일 인터페이스입니다. 한 곳에서 계속해서 다중 서버 캐시를 만들고 관리하고 모니터링할 수 있습니다. 그런 다음 작업을 완료하면 PerfMon 카운터가 몇 개 표시되고 스트레스 테스트 도구라는 이 도구를 실행할 것입니다. NCache, 애플리케이션 사용을 매우 빠르게 시뮬레이션할 수 있습니다.
그래서 제가 방금 그렇게 했고 이제 시작했다고 가정해 보겠습니다. 서버당 약 500~800개의 트랜잭션을 수행하고 있습니다. 그래서, 그것은 약 2배입니다. 그것이 부하입니다. 부하를 높이고 싶습니다. 그래서 스트레스 테스트 도구를 하나 더 추가하고 싶습니다. 거의 모든 사람들이 자신의 환경에서 캐시가 어떻게 작동하는지 확인하기를 원하기 때문에 우리 고객은 이것을 꽤 많이 사용합니다. 알다시피, 우리는 모든 벤치마크와 모든 것을 게시했지만 그들은 그들의 환경에서 그것을 보고 싶어합니다. 따라서 프로그래밍 및 응용 프로그램 대신 매우 빠르게 시뮬레이션할 수 있습니다. 그래서 두 개를 실행했는데 이제 부하가 증가했습니다. 따라서 이 두 서버를 최대로 사용할 때까지 이러한 서버를 점점 더 추가할 수 있습니다. 따라서 확장성이 제공됩니다.
이 두 서버는 현재 초고속 성능을 발휘하고 있습니다. 그러나 부하를 증가시키면 특정 지점 이후에 최대치에 도달하게 됩니다. 이는 데이터베이스에 발생하는 현상입니다. 유일한 차이점은 여기에 와서 다른 노드를 추가할 수 있다는 것입니다. 따라서 세 번째 VM이 있는 경우 여기로 와서 여기에 추가하면 갑자기 부하가 분산되고 시작 위치를 보여 드린 그림이 있습니다. XNUMX개의 서버와 이제 이 XNUMX개가 최대가 되었습니다. 세 번째 서버를 추가하려고 합니다. 따라서 다른 VM을 가져와서 추가하면 이제 XNUMX개의 서버가 되고 NCache 모든 것을 자동으로 재조정하고 파티션을 다시 나누거나 redis버킷 맵에 경의를 표합니다. 따라서 런타임에 세 번째 서버가 추가됩니다. 따라서 갑자기 용량 문제가 없습니다.
예, 그래서 당신이 할 일은 NCache 서버 소프트웨어, 이러한 모든 VM에서. 클라우드의 경우 일반적으로 인스턴스를 생성하는 미리 구성된 VM 이미지가 있으므로 새 VM을 시작하면 됩니다. NCache 실행 중인 소프트웨어를 이 클러스터에 추가하기만 하면 됩니다.
그러나 다시 한 번 요점은 데이터베이스와 달리 최대 상태에 도달하면 푹 빠져 있다는 것입니다. 너 뭐하니? 알았어, 더 비싼 것을 사고 싶어. 그럼 당신은 가서 다른 상자를 사서 이 상자를 가져와야 하고 그것은 악몽입니다. 여기에 다른 상자를 추가하기만 하면 됩니다.
사용 NCache ASP.NET 세션 사용
그래서, 나는 지금 그 다음으로 갈 것입니다. 이제 캐시가 어떻게 생겼는지 알았습니다. 이제 우리는 ...의 경우 NCache, 모든 캐시의 이름이 지정됩니다. 따라서 캐시의 이름을 알고 있는 한 캐시에 연결하기만 하면 됩니다. 그렇다면 세션 캐시에 어떻게 연결합니까? 그게 가장 쉽습니다. 다시 말하지만 대부분의 고객은 가장 먼저 NCache 그들은 그것을 세션에 사용합니다. 왜? 프로그래밍이 필요하지 않기 때문입니다. 세션의 경우에 확인해야 할 유일한 것은 세션에 넣는 모든 개체가 모두 직렬화 가능하다는 것입니다. 이미 SQL에 세션을 저장하고 있다면 이미 이를 확인한 것입니다. In-Proc 모드에서 세션을 저장하는 경우 이를 보장하지 않았을 수 있습니다. 그래서, 그것이 당신이 해야 할 유일한 시험입니다. 그러나 그 이후는 매우 간단합니다.
여기서 작은 샘플을 보여드리겠습니다. 예를 들어 여기에는 세션 저장소 공급자 샘플이라는 샘플이 있습니다. 그래서 ASP.NET 응용 프로그램이 있습니다. web.config로 이동하겠습니다. 내가 이 응용 프로그램 서버 상자에 있다고 가정합니다. 저 그림을 여기에서 본다면. 사실 여기로 돌아가겠습니다. 여기 캐시 서버가 있지만 내 응용 프로그램은 이 상자에서 실행 중입니다. 그래서 이 상자에 두 개의 서버 클러스터를 만들고 여기에 클라이언트를 추가했습니다. 이제 해당 클라이언트에서 일어난 일은 다음과 같은 경우입니다. NCache, 죄송합니다. 여기가 아닙니다. 좋아, 경우에 NCache 그것은 실제로 client.ncconf가 있는 config 폴더에 생성하므로 항목을 생성합니다. 따라서 이것이 응용 프로그램이 연결할 서버를 아는 방법입니다.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
<cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
<server name="10.2.0.5"/>
<server name="10.2.0.6"/>
</cache>
</configuration>다시 말하지만 이들은 초기 서버 목록일 뿐입니다. 최종 목록이 아닙니다. 왜? 고가용성 환경의 경우 런타임에 세 번째 서버를 추가하면 어떻게 될까요? 그것은 이 목록에 없습니다, 그렇죠? 그래서, 그것이 점 0.8(.XNUMX)이라고 합시다. 따라서 이것은 초기 목록일 뿐입니다. 응용 프로그램이 그 중 하나를 알게 되면 그것에 연결됩니다. 응용 프로그램에 발생하는 첫 번째 일은 일단 연결되면 클러스터 구성원 정보를 수신하고 클러스터 구성원이 변경될 때마다 다른 서버를 추가하고 업데이트된 클러스터 구성원이 클라이언트로 전송되고 모두 메모리에 보관됩니다. 응용 프로그램에서 모두 숨겨집니다. 모두 에서 관리합니다. NCache 클라이언트 부분이지만 그것이 애플리케이션이 캐시에 연결하는 방법을 아는 방법입니다.
따라서 세션의 경우 여기로 오십시오. 따라서 세션에서 수행할 작업은 먼저 어셈블리를 추가하는 것입니다.
...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /></assemblies>
</compilation>
...의 경우 NCache 당신은 단지 ... 이 어셈블리는 세션 상태 공급자 인터페이스 그것은 ASP의 일부입니다.NET framework 그리고 그렇게함으로써 NCache 타사인 맞춤형 스토리지가 됩니다. 따라서 이것은 단지 복사-붙여넣기일 뿐이며 세션 상태 태그의 실제 변경 사항입니다. 따라서 여기서 수행하는 작업은 모드가 사용자 지정인지 확인하는 것입니다.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...따라서 모드는 In-Proc, 상태 서버, SQL 및 사용자 지정이 있습니다. 네 가지 모드가 있습니다. 따라서 모드가 사용자 지정인 경우 시간 제한이 원하는 세션 시간 제한인지 확인한 다음 공급자 세부 정보를 복사해야 합니다. 즉, NCache 그것은 이 줄이며 그들이 가서 변경해야 하는 유일한 것은 캐시 이름입니다. 예를 들어 여기에서는 캐시 이름이 이미 변경되었습니다. 당신이 그 변화를 만드는 것, 그게 전부입니다. 그리고 변경을 하자마자 ASP.NET은 작업자 프로세스를 다시 시작하고 모든 세션이 캐시에 하나의 개체로 저장되는 것을 볼 수 있으며 엄청난 성능 향상을 즉시 확인할 수 있습니다. 이제 SQL에 저장하지 않기 때문입니다.
따라서 다음과 같은 분산 캐시를 활용하는 가장 빠른 방법은 NCache 그냥 세션에 두는 것입니다. 애플리케이션 데이터 캐싱을 위한 개체의 경우 더 많은 작업이 있기 때문입니다. 물론 당신은 그것을 하고 싶고 그것이 내가 들어갈 것이지만 첫 번째 사용 사례는 ASP.NET 사양입니다.
이것에 대해 질문이 있으십니까? 예를 들어 일부 고급 고객은 애플리케이션 계층에 약 50~100개의 서버를 보유하고 있습니다. 이를 위해 1:5 비율을 유지하는 것이 일반적으로 일어나는 일이라고 가정해 봅시다. 따라서 100개의 서버 구성에 대해 20개의 캐시 서버가 있습니다. 50개 이상, 매우 적습니다. 부하 분산 환경에서 50개 이상의 서버를 보유하려면 정말 많은 트래픽이 있어야 합니다. 대부분의 고객은 4~12대의 서버를 보유하고 있습니다. 그리고 제가 말했듯이 애플리케이션의 특성에 따라 4:1 또는 5:1 비율을 갖는 것이 좋습니다. 경우에 따라 5대 1 이상이 될 수도 있지만 이는 일반적인 사용 사례와 같습니다. 따라서 5대 1이고 애플리케이션 계층에 12개의 서버가 있는 경우 XNUMX개의 서버 캐싱 계층이 있습니다. 그래서, 그다지 많은 연결이 아닙니다.
이론적으로는 그렇습니다. 계속해서 더 많은 서버를 추가하면 많은 중복이 발생하게 됩니다. 그러나 우리가 말하는 사용 사례는 떨어지지 않습니다. 빅데이터 처리는 50~100개의 서버가 있을 수 있지만 이 경우 클라이언트가 없고 빅데이터 처리는 서버만 됩니다. 모든 것이 서버 자체에서 실행되기 때문입니다. 그러나 웹 애플리케이션 또는 웹 서비스 애플리케이션의 경우 우리가 전자 상거래라고 부르는 온라인 비즈니스 모델입니다. 내 말은 그게 꽤 많다는 뜻이야. 대부분의 경우 서버가 20개 미만이고 극소수의 고객이 20개 이상, 50개 이상은 매우 적다고 가정할 수 있습니다.
그래, 확실히. 그래서, 예를 들어, 만약 내가 여기 온다면 나는 그냥... 내가 여기 온다면. 나는 사용하지 않습니다 NuGet 패키지 여기에 있지만 여기에 와서 NuGet에 갈 수 있고 여기에서 말할 수 있습니다. NCache, 예를 들어, 당신은 얻을 것이다 NCache SDK, NCache Enterprise 및 Professional을 위한 세션 서비스와 오픈 소스도 있고 NHibernate도 있습니다. 따라서 많은 NuGet이 있습니다. 따라서 일반적인… 세션의 경우 이 세션 NuGet 패키지를 포함합니다. 애플리케이션 데이터 캐싱의 경우 SDK만 포함하면 여기에 필요한 모든 것이 포함됩니다.
앱 데이터 캐싱 개요(API)
그래서, 애플리케이션 데이터 캐싱 프로그래밍을 해야 하는 곳입니다. 따라서 캐시를 데이터베이스로 볼 수 있습니다. 캐시에 연결합니다. 의 경우 NCache 우리는이 방법을 호출 캐시 초기화.
캐시 연결Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");다른 캐시에 대한 다른 방법이 있을 수 있으며 다음과 같은 경우 캐시 이름이 있습니다. NCache 우리가 이야기한 대로 캐시 핸들을 제공합니다.
그럼 신청 들어가겠습니다. 다시 한 번 살펴보겠습니다. 이것은 간단한 콘솔 응용 프로그램입니다. NuGet 패키지를 포함했다면 이 모든 작업이 자동으로 수행됩니다. 당신은 일부를 참조 할 것입니다 NCache 어셈블리. 따라서 참조해야 하는 어셈블리는 두 개뿐입니다. NCache.실행 시간 과 NCache.편물. NCache.편물 다음과 같은 경우 실제 공개 API입니다. NCache. 그런 다음 애플리케이션에 네임스페이스를 포함합니다. 그래서, 당신은 NCache.실행 시간 과 NCache.웹.캐싱 네임스페이스로.
그런 다음 응용 프로그램 시작 시 App.config에서 캐시 이름을 가져온 다음 캐시를 초기화하고 캐시 핸들을 얻습니다. 따라서 애플리케이션의 모든 위치에서 사용해야 하는 캐시 핸들이 있습니다.
이제 해당 캐시 핸들로 이동하겠습니다. 그래서, 당신은 할 수 있습니다 캐시.추가, 키를 지정합니다. 키는 내가 말했듯이 일반적으로 문자열입니다. 객체는 실제 객체입니다. 모든 .NET 개체입니다. NCache 실제로 직렬화하여 클러스터로 보냅니다. 따라서 이 모든 것은 애플리케이션 서버의 클라이언트 측에서 발생합니다.
// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;
namespace Alachisoft.NCache.Samples
{
/// <summary>
/// Class that provides the functionality of the sample
/// </summary>
public class BasicOperations
{
private static ICache _cache;
/// <summary>
/// Executing this method will perform all the operations of the sample
/// </summary>
public static void Run()
{
// Initialize cache
InitializeCache();
// Create a simple customer object
Customer customer = CreateNewCustomer();
string key = GetKey(customer);
// Adding item synchronously
AddObjectToCache(key, customer);
// Get the object from cache
customer = GetObjectFromCache(key);
// Modify the object and update in cache
UpdateObjectInCache(key, customer);
// Remove the existing object from cache
RemoveObjectFromCache(key);
// Dispose the cache once done
_cache.Dispose();
}
/// <summary>
/// This method initializes the cache
/// </summary>
private static void InitializeCache()
{
string cache = ConfigurationManager.AppSettings["CacheID"];
if (String.IsNullOrEmpty(cache))
{
Console.WriteLine("The CacheID cannot be null or empty.");
return;
}
// Initialize an instance of the cache to begin performing operations:
_cache = NCache.Web.Caching.NCache.InitializeCache(cache);
// Print output on console
Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
}
/// <summary>
/// This method adds object in the cache using synchronous api
/// </summary>
/// <param name="key"> String key to be added in cache </param>
/// <param name="customer"> Instance of Customer that will be added to cache </param>
private static void AddObjectToCache(string key, Customer customer)
{
TimeSpan expirationInterval = new TimeSpan(0, 1, 0);
Expiration expiration = new Expiration(ExpirationType.Absolute);
expiration.ExpireAfter = expirationInterval;
//Populating cache item
CacheItem item = new CacheItem(customer);
item.Expiration = expiration;
// Adding cacheitem to cache with an absolute expiration of 1 minute
_cache.Add(key, item);
// Print output on console
Console.WriteLine("\nObject is added to cache.");
}그리고 일단 당신이 그것을 했다면 당신은 또한 할 수 있습니다 _캐시.가져오기 동일한 개체를 다시 가져옵니다. 따라서 API 측면에서 본다면 다음과 같습니다. 캐시. 가져오기, 가져오기, 포함, 추가, 삽입, 제거 세 가지 모두 비동기 버전을 가지고 있습니다. 즉, 기본적으로 응용 프로그램이 캐시가 업데이트될 때까지 기다리지 않고 컨트롤이 즉시 돌아옵니다. 그러나 키는 일반적으로 문자열입니다. 보통 이런 식입니다. 유형 이름이 있습니다. 의 경우 NCache 조건에 따라서. 이 기능을 사용한 경우 클라이언트 캐시. 그래서 저는 그것에 뛰어들 것입니다.
클라이언트 캐시(캐시 근처)
따라서 기본적으로 다음을 수행할 때마다 캐시.가져오기, 실제로 캐싱 계층으로 이동합니다. 그러나 대부분의 사람들이 깨닫지 못하는 흥미로운 점이 있습니다. ASP.NET 캐시 개체와 같은 In-Proc 캐시를 사용하고 있고 다음과 같은 것으로 이동하기로 결정한 경우입니다. NCache 성능과 확장성이 향상될 것이라고 밝혔기 때문입니다. 일종의 확장성 향상이지만 갑자기 성능이 실제로 떨어질 것입니다. 전화를 걸어 연결한 이후로 애플리케이션이 실제로 느려졌다고 말하는 고객이 많습니다. NCache. 그래서, 왜 내가 정말 필요합니까, 당신은 알고 있습니다. 정말 좋지 않습니다. 알다시피. 따라서 우리는 그들에게 In-Proc 캐시를 수행할 때 직렬화가 없으며 동일한 상자에 있든 별도의 상자에 있든 애플리케이션과 캐시 사이에 프로세스 간 통신이 없다는 것을 설명해야 합니다. 별도의 상자, 오른쪽. 따라서 개체가 개체 형태로 힙에 유지되는 경우 매우 빠릅니다. 그냥 가서 참조를 얻으십시오. 어떤 것도 그 성능에 필적할 수 없습니다. 하지만 분산 캐시로 이동하는 이유는 In-Proc 모델이 많은 한계를 가지고 있기 때문입니다. 확장할 수 없습니다. 점점 더 많은 데이터를 추가할 수 없으며 하나의 프로세스일 뿐이며 둘 이상의 프로세스가 있는 경우 복제가 동기화되지 않습니다. 따라서 분산 캐시로 이동하는 이유가 다른 많은 문제가 있지만 그 이점을 잃게 됩니다. 그래서 우리가 한 것은 클라이언트 캐시라고 하는 것을 생각해낸 것입니다. Java 쪽에서는 Near Cache라고 하고 .NET 쪽에서는 캐시가 있는 유일한 것입니다.
이것이 실제로 하는 일은 실제로 애플리케이션 내에서 In-Proc 로컬 캐시를 생성합니다. 따라서 해당 객체를 힙의 객체 형태로 유지합니다. 따라서 독립 실행형 In-Proc 캐시 내에서 사용하던 것과 동일한 성능을 얻을 수 있습니다. 유일한 차이점은 이 캐시는 자신이 클러스터된 캐시의 일부임을 알고 있다는 것입니다. 따라서 로컬 복사본에 보관하는 것이 무엇이든 캐싱 계층에 대한 링크가 있습니다. 캐싱 계층에 내가 이 개체를 가지고 있음을 알립니다. 누군가 해당 개체를 변경하면 알려주세요. 따라서 만약 있다면, 이 클라이언트가 다른 클라이언트의 항목 번호를 가지고 있고 물론 그 항목 번호 XNUMX도 이 캐싱 계층에 있다고 가정해 봅시다. 다른 클라이언트가 들어와 해당 항목 번호 XNUMX을 업데이트합니다. 캐싱 계층은 이러한 클라이언트 캐시에 항목 번호 XNUMX이 있다는 것을 알고 있으므로 이벤트를 통해 알립니다. 의 경우 NCache 꽤 빠른 이벤트입니다. 이들은 .NET 이벤트가 아니며 소켓 수준 통신입니다. 따라서 클라이언트 캐시는 즉시 업데이트됩니다. 그래서 우리는 아마도 밀리초 지연에 대해 이야기하고 있습니다.
그래서, 그렇게 하면 당신이 얻는 것이 무엇이든 그것이 전부 또는 대부분 정확하다는 것을 확신할 수 있습니다. 기술적으로 오래된 사본일 수 있는 작은 가능성이 있습니다. 의 경우 NCache, 그것에 대해 너무 염려한다면 비관적 동기화 모드라고 하는 것을 사용할 수 있습니다. 여기서 무엇이든 가져올 때마다 NCache 캐싱 계층에 최신 복사본이 있는지 내부적으로 확인합니다. 그렇지 않은 경우 클라이언트 캐시의 데이터에서 제공하고 그렇지 않으면 캐시 계층에서 가져옵니다. 그러나 대부분의 경우에는 필요하지 않습니다. 대부분의 경우 그렇게 많은 기회를 가져도 괜찮습니다. 따라서 In-Proc 캐시의 성능이 향상됩니다. 그러나 다시 애플리케이션은 이러한 모든 일이 발생한다는 사실을 알지 못합니다.
의 경우 NCache 귀하의 응용 프로그램은 알고 있습니다. 응용 프로그램은 캐싱 계층과만 통신한다고 생각합니다. 대화하는 캐시는 하나뿐입니다. 그것은 내 캐시 또는 무엇이든이라고합니다. 데모 캐시이며 데모 캐시는 다음과 같은 경우 구성을 통해 클라이언트 캐시를 연결할 수 있습니다. NCache. 이것에 대해 질문이 있으십니까?
J캐시(JSR 107) API
이것이 일반적인 캐시의 모습입니다. 이 프로그래밍을 수행하는 것은 매우 쉽습니다. 지금 Java 쪽에서 일어나고 있는 일입니다. 다시 한 번 말하지만 Java가 이 분야에서 훨씬 더 발전했기 때문에 저는 계속해서 칭찬합니다. 그들은 JCache라는 전체 표준 API를 가지고 있습니다. 따라서 JCache API는 매우 뛰어난 기능입니다. 방금 언급했거나 지금 이야기하고 있는 모든 기능이 포함되어 있습니다. 따라서 JCache는 업계와 호환되려면 모든 Java 캐시가 구현해야 하는 표준입니다.
IDistributedCache API
.NET 측에는 아직 그런 것이 없습니다. 최근까지 연결할 수 없었던 ASP.NET 캐시 개체가 있습니다. 따라서 ASP.NET 캐시에 프로그래밍하면 플러그인할 수 없습니다. NCache 대신에. 따라서 타사 캐시를 연결할 수 없습니다. 독립 실행형 캐시일 뿐입니다. .NET 4.0에서 그들은 결코 실제로 선택되지 않은 .NET 캐시를 시작했습니다. 이제 ASP에서.NET core 그들은 가지고 iDistributedCache 상호 작용. 다시 말하지만 매우 기본적인 get 입력 방법입니다.
따라서 표준 API의 문제는 좋은 캐시가 제공해야 하는 모든 기능을 활용할 수 없다는 것입니다. 정말 기본적인 get 입력으로 제한됩니다. 그러나 대부분의 고객은 어쨌든 캐싱 계층을 캡슐화합니다. 그래서 그들이 모든 것을 만든다고 해도 NCache 호출하면 전체 응용 프로그램이 노출되지 않습니다. 어쨌든 API는 다음과 같습니다.
앱 데이터 캐싱 기능
이제 몇 가지 중요한 기능을 살펴보겠습니다. 그래서 그들 대부분은 … 계속하십시오. 간단한 질문입니다. 삽입과 추가 사이에 차이점이 있습니까? 예, 삽입은 추가 또는 업데이트를 의미합니다. 데이터가 이미 있으면 업데이트하고 없으면 추가합니다. 데이터가 이미 존재하는 경우 추가가 실패합니다. 그리고 다시 말하지만 그것은 우리가 고수했던 ASP.NET 캐시 API입니다. 왜냐하면 우리는 당시의 표준이 무엇이든지 간에 최대한 근접하기를 원하기 때문입니다. 아니, 그렇지 않아. 내 말은, 우리는 그것을 지켰습니다. ASP.NET 캐시 개체는 이제 사라졌습니다..NET Core 더 이상 존재하지 않습니다. ASP.NET에는 여전히 있지만 ASP.NET Core 하지 않습니다.
절대 만료
따라서 가장 먼저 염두에 두어야 할 것은 우리가 이야기한 캐시를 최신 상태로 유지하는 것입니다. 그 최고의 기술은 만료입니다. 만료는 다음과 같습니다. 다시 돌아가 보겠습니다. 자, 제가 가지고 있다고 가정해 보겠습니다. 여러분, 이것을 볼 수 있습니까? 당신은 이것을 볼 수 있습니까? 좋아요. 키와 값 또는 일부 개체가 있다고 가정해 보겠습니다. 캐시에 추가하고 1분 만료를 지정하겠습니다. 그래서 이것을 일컬어 절대 만료.
public static void AddObjectToCache(string key, Customer customer)
{
DateTime expirationInterval = new DateTime();
expirationInterval.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
_cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Console.WriteLine("\nObject is added to cache");
}절대 만료는 1분이 지나면 어떤 일이 있어도 만료됨을 의미합니다. 즉, 캐시에 말하고 있는 것입니다. XNUMX분 이상 캐싱하는 것이 정말 불편합니다. XNUMX분 동안 캐시에 보관하는 것이 안전하다는 교육적인 추측을 하고 있기 때문입니다.
슬라이딩 만료
반면에 슬라이딩 만료는 완전히 다른 목적을 가지고 있습니다. 세션과 같은 것을 정리하기 위한 것입니다. 동기화 또는 캐시를 최신 상태로 유지하는 것과는 아무런 관련이 없습니다. 따라서 절대 표현은 거의 모든 캐시에 있는 것입니다. 사실 ASP조차도.NET Core IDistributed Cache Interface에는 절대적인 표현이 있습니다.
데이터베이스와 캐시 동기화
그러나 표현이 캐시를 만들거나 캐시를 최신 상태로 유지하는 유일한 방법인 것이 잘못된 점은 무엇입니까? 이 데이터가 변경되지 않을 것이라고 추측하고 있다는 것입니다. 만약 그렇다면? 일반적으로 데이터가 업데이트되는 곳이 두 곳 이상인 엔터프라이즈에서 데이터를 수정하는 다른 응용 프로그램, 다른 스크립트가 있는 경우 어떻게 됩니까? 따라서 데이터가 얼마나 자주 업데이트될지 예측할 수 없다면 식은 시작점일 뿐입니다. 캐시를 데이터베이스와 동기화하는 다음 단계로 이동해야 합니다. 따라서 기본적으로 다음과 같은 경우 캐시를 데이터베이스와 동기화합니다. NCache SQL 종속성이라는 ADO.NET .NET의 일부인 이 기능을 사용합니다.
기본적으로 SQL 종속성은 어떻게 생겼는지 보여드리겠습니다. 따라서 SQL 종속성의 경우 동일한 캐시를 수행하고 있습니다. 맞습니다. 나는 키를 가질 것이고 값을 갖는 대신에 우리가 실제 개체를 넣는 자체 구조인 캐시 항목을 갖게 될 것입니다. 이제 우리는 이것을 가지고 있고 SQL 종속성, SQL 서버 종속성이라는 것을 지정합니다. 이것은 본질적으로 SQL 문을 생성하는 이 변수입니다.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}이 코드는 바로 여기 클라이언트 상자에서 실행됩니다.
캐시 서버와 통신합니다. 캐시 서버에 ADO.NET SQL 종속성 기능을 사용하여 내 데이터베이스에 연결하도록 지시합니다. 따라서 실제로 데이터베이스에 대한 연결 문자열을 제공합니다. 이제 응용 프로그램은 캐시에 이 캐시된 항목에 대한 내 데이터베이스가 있고 데이터베이스에서 해당 데이터를 나타내는 SQL 문이 있음을 알려줍니다.
Entity Framework/ Entity Framework 핵심 통합
좋은 질문. Entity Framework의 경우 Entity Framework에 대한 구현이 내부에 구현되었습니다. Entity Framework를 사용하는 경우에도 캐시를 사용하는 두 가지 방법이 있습니다. EF Core의 경우 이제 새 아키텍처에서 타사 캐시를 연결할 수 있지만 EF6까지는 캐시를 연결할 방법이 없었습니다. 따라서 어쨌든 이러한 API 호출을 수행해야 합니다. 예를 들어, 엔터티 컬렉션을 되찾았고 이를 캐싱할 때 SQL 종속성을 지정할 수 있습니다. 내가 의미하는 바를 이해 했습니까?
의 경우 NCache 당신이 말하는 NCache 여기 내 SQL 문이 있습니다. NCache ADO .NET을 사용하여 데이터베이스에 연결하고 ADO.NET SQL 종속성 기능을 사용하여 해당 데이터 세트를 모니터링합니다. 그래서, NCache 이 데이터 세트가 변경되면 알려주십시오. 그런 다음 SQL 서버는 데이터베이스 알림을 NCache 때문에 NCache 데이터베이스의 클라이언트가 아닌 경우 NCache 이제 이 데이터가 데이터베이스에서 변경되었음을 알고 있습니다. 따라서 EF가 있어도 이를 우회하는 것입니다. NCache 이 데이터가 변경되었음을 알고 있습니다. NCache 두 가지 옵션이 있습니다. 하나는 캐시에서 해당 항목을 제거할 수 있고 제거할 때 다음에 누군가가 필요하면 캐시에서 찾을 수 없으므로 데이터베이스에서 가져와야 합니다. 그래서 어떤 면에서 당신은 그것을 신선하게 만들거나 NCache 데이터베이스 자체에서 해당 데이터를 다시 로드할 수 있으며 read-through라는 다른 기능을 사용하지 않는 한 불가능합니다.
따라서 SQL 종속성은 기본적으로 데이터가 언제 변경될지 예측할 수 없는 경우 NCache 또는 귀하의 캐시가 저를 위해 데이터베이스를 모니터링하시기 바랍니다.
SQL 종속성에는 조인을 가질 수 없다는 제한이 있습니다. 그래서 XNUMX인용 테이블입니다. 모니터링할 수 있는 다른 방법이 있습니다. 예를 들어, NCache 라는 기능이 있습니다 사용자 지정 종속성, 귀하의 코드입니다. NCache 코드를 호출하고 데이터 소스를 모니터링하고 데이터가 변경되었는지 확인하십시오. 그래서 그것은 투표와 비슷합니다. 그래서, NCache 사용자 지정 종속성을 통해 폴링하면 복잡한 구조가 될 수 있습니다.
예 바로 그 거예요. 실제로 SQL 종속성을 수행할 때 캐시는 데이터베이스와 자주 통신하지 않습니다. 이벤트 기반 아키텍처입니다. 따라서 데이터베이스는 데이터가 변경될 때마다 이벤트를 보냅니다.
실제로 SQL 서버에는 데이터 세트를 모니터링한 다음 데이터베이스 알림을 클라이언트에 보내는 이 기능이 있습니다. 그래서, NCache 데이터베이스 클라이언트가 됩니다.
따라서 한 가지 옵션은 캐시에서 해당 항목을 제거하는 것이었습니다. 다른 하나는 그냥 다시 로드하는 것입니다. 음, 다시 로드한다는 것은 NCache 어떻게 이동하고 해당 데이터를 가져오는지 알 수 있는 방법이 있어야 합니다. 즉, 캐시 서버인 캐시 클러스터에 작성하고 등록하는 코드인 read-through라는 기능이 있습니다. 그 코드가 어떻게 생겼는지 빠르게 보여드리겠습니다.
읽기-스루 캐시
아니요, 실제로는 사용자 지정 코드일 뿐입니다. 따라서 해당 코드 내에서도 ORM 호출을 할 수 있습니다. 모든 코드는 다음과 같습니다. 바로 여기에 IReadThruProvider 인터페이스가 있습니다.
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...따라서 IReadThruProvider 인터페이스가 있습니다. 세 가지 방법이 있습니다. 캐시가 시작될 때만 호출되는 Init이 있습니다. 따라서 데이터 소스에 연결해야 합니다. 끝에 있는 처분이 있고 부하가 있습니다. 따라서 load는 키를 제공하고 캐시 항목을 돌려줘야 합니다.
따라서 해당 키를 기반으로 코드는 이미 데이터 소스에 연결되어 있기 때문에 어디로 가야 하는지 알아야 합니다. 따라서 ORM을 사용하든, EF 호출을 수행하든, NHibernate 호출을 수행하든, ADO.NET 호출을 수행하든, 그게 모든 코드입니다. 그것을 입력하고 만료 또는 원하는 다른 메타데이터를 입력하고 다시 전달합니다. NCache. NCache 그런 다음 응용 프로그램에 다시 제공하기 전에 캐시합니다.
따라서 전체 읽기의 목적은... 이 읽기 자체에 대해 설명하겠습니다. Read-through는 캐시가 데이터베이스에서 데이터를 로드할 수 있는 방법입니다. 따라서 실제로 일부 지속성 코드를 캐싱 계층으로 이동하고 있습니다. 그리고 캐시를 공유하려는 여러 응용 프로그램이 있는 경우 읽기 및 쓰기 메커니즘이 있으면 완벽합니다. 통합하기 때문에 응용 프로그램을 만들고 있습니다. 일종의 코드가 적습니다. 따라서 점점 더 많은 지속성 코드가 캐싱 계층으로 이동하기 때문에 더 적은 코드를 갖게 됩니다. 그것은 하나의 이점입니다. 알다시피, 캡슐화 및 통합.
read-through의 두 번째 이점은 방금 다시 로드에 대해 이야기한 것입니다. 따라서 재로드는 두 가지 경우에 발생합니다. 하나는 데이터베이스 동기화 중이고 다른 하나는 만료 중입니다. 트래픽이 정말 많은 응용 프로그램이 있는 경우 만료는 좋은 경우입니다. 예를 들어 조회 테이블이나 가격 테이블이 변경되고 거기에 수천 건의 요청이 들어오는 경우입니다. 다시 로드 기능을 사용하면 데이터가 만료되면 수천 개의 요청이 데이터베이스에 도달합니다. 그리고 모두 동일한 개체를 캐시에 로드합니다. 결국 데이터베이스에 대한 많은 트래픽입니다. 데이터베이스에 있는 수천 개의 항목을 곱하면 불필요한 트래픽이 많이 발생합니다.
실제로 우리 고객 중 한 명은 미국의 화훼 비즈니스에서 정말 고급 전자 상거래 고객인데 그 문제가 있었습니다. 따라서 재로드 기능을 구현했을 때 갑자기 모든 문제가 사라졌습니다. 이제 해당 항목이 캐시에서 제거되지 않기 때문입니다. 따라서 이전 사본은 특정 시점까지 유지되고 새 사본이 그 위에 업데이트됩니다. 따라서 애플리케이션은 데이터베이스로 이동할 필요가 없습니다. 따라서 탐색 중에도 새 복사본만 업데이트하기 때문입니다. 그래서, 그것은 많은... 그래서, 그것들은 당신이 이 동기화와 결합할 수 있는 두 가지 이점입니다.
연속 기입 캐시
다른 측면은 write-through로, 쓰기를 위한 경우를 제외하고는 read-through와 동일하게 작동하며 쓰기는 추가, 삽입 또는 삭제 또는 제거가 될 수 있습니다. 다시 말하지만, Init이 있는 것과 같은 방식으로 Dispose가 있고 이제 데이터 소스에 쓰기. 그것은 작업이 무엇인지 말하고 데이터도 가지고 있고 당신은 가서 데이터베이스를 업데이트합니다. 따라서 write-through는 캐시를 업데이트하고 캐시가 데이터베이스를 업데이트함을 의미합니다.
그렇다면 write-through의 이점은 무엇입니까? 음, 한 가지 이점은 읽기와 동일합니다. 모든 지속성을 통합합니다. 둘째, 장점은 write-behind입니다. 왜냐하면 데이터베이스 업데이트가 그만큼 빠르지 않기 때문입니다. 데이터베이스 업데이트가 성공할 것이라고 믿는다면 캐시를 업데이트하고 캐시가 데이터베이스를 비동기적으로 업데이트하도록 하십시오. 물론 어떤 것이 실패하면 알림을 받을 수 있지만 계속해서 다른 작업을 수행할 수 있으며 애플리케이션의 업데이트 성능도 향상됩니다. 이제 데이터베이스 업데이트가 모두 대기열에 있기 때문에 완료될 때까지 기다릴 필요가 없습니다. 그래서 그것은 write-behind 부분입니다. 그리고 write-behind 대기열은 다시 둘 이상의 서버에 복제됩니다. 따라서 하나의 서버가 다운되더라도 작업이 손실되지 않습니다. NCache.
그러나 그것은 당신의 코드입니다. 내 말은 NCache 당신을 부릅니다. 따라서 이 모든 것이 귀하의 코드입니다. 그래서, NCache 전화를 걸면 쓰기가 무엇을 의미하는지 또는 읽기가 무엇을 의미하는지 알아낼 수 있습니다.
따라서 read-through, write-through는 만료 및 동기화와 결합할 수 있는 또 다른 매우 강력한 기능입니다. 따라서 캐시가 최신 상태로 유지되는지 확인한 다음 읽기, 쓰기를 사용하는지 확인해야 합니다. 이제 이 작업을 시작했으므로 많은 데이터를 캐시할 수 있습니다. 이제 캐시가 데이터베이스처럼 보이기 시작했습니다. 즉, 키만으로는 충분하지 않습니다. 검색을 할 수 있어야 합니다. 보다 지능적인 방식으로 항목을 가져올 수 있어야 합니다. 따라서 캐시에 대해 SQL 유형의 쿼리를 수행할 수 있어야 합니다. 예를 들어 고객 도트 City가 London과 같은 선택 고객과 같은 것입니다. 해당 기준과 일치하는 모든 고객 개체의 컬렉션을 다시 제공합니다. 그리고 캐시는 예를 들어 도시 속성을 기반으로 해당 개체를 인덱싱합니다. 그래서, 그것이 당신이 검색할 수 있도록 하는 방법입니다.
따라서 이 작업을 수행할 수 없다면 키에 대한 항목만 검색할 수 있기 때문에 응용 프로그램이 더 복잡해집니다. 캐시로 하세요.
캐시에는 조인이 없지만 그룹화는 가능합니다. 그런 종류의 서비스는 데이터를 얻은 다음 그룹화한 다음 해당 그룹을 기반으로 이러한 그룹, 하위 그룹, 태그, 이름 태그에 속하는 모든 것을 제공한다고 말할 수 있습니다. 따라서 사물을 논리적으로 그룹화하기 위해 수행할 수 있는 다른 작업이 있으며 캐싱 중인 데이터 자체는 조인을 통해 가져올 수 있습니다. 캐시가 될 수 없다는 것입니다. 캐시는 검색 기반 엔진이 아닙니다. 따라서 조인 데이터가 있으면 그룹화하면 됩니다.
캐시 종속성
이 시간에 실제로 다룰 수 없는 기능이 너무 많기 때문입니다. 그래서 라는 기능이 있습니다. 캐시 종속성 그건 그렇고 ASP.NET 캐시 객체에서 오는 것입니다. NCache 허용하는 항목도 구현했습니다. 캐시에 이 항목이 이 항목에 종속되어 있음을 알립니다. 이 항목이 업데이트되거나 제거되면 자동으로 제거됩니다. 따라서 그러한 관계를 생성함으로써 일대다를 가질 수 있습니다. 예를 들어 일대다 관계가 있는 경우 일방 없이는 다방면이 존재할 수 없습니다. 예를 들어 고객과 주문입니다. 따라서 고객을 제거하면 주문도 제거해야 합니다. 따라서 캐시가 처리하도록 할 수 있습니다. 마찬가지로 캐시할 때 개체 모음을 얻었다고 가정해 봅시다. 전체 모음을 하나의 개체로 캐시하거나 개별 개체로 나눌 수 있습니다. 그것들을 분해하면 캐시 종속성을 원할 것입니다. 따라서 하나의 개체가 제거되면 해당 컬렉션은 더 이상 유효하지 않습니다.
네, 그게 제가 이야기할 전체 주제입니다. 저희 웹사이트에 오실 수 있습니다. 빨리 보여드리겠습니다. 그래서 그것에 대한 전체 이야기가 있습니다. 제 생각에는 캐시에서 관계형 데이터 처리. 그래서, 그것은 모든 일대다, 일대일, 다대다, 당신이 방금 이야기한 모든 것들에 대한 컬렉션을 다룹니다. 그냥 가서 보세요. 시간이 얼마 남지 않았기 때문에 빨리 넘어가겠습니다.
그래서 캐시를 왜 사용해야 하는지, 어떻게 활용해야 하는지, 이를 통한 이득은 어떻게 극대화해야 하는지 사례를 만들어 보았습니다. 건너뛰겠습니다 런타임 데이터 공유 부분, 나는 충분히 다루었다고 생각합니다. 저희 웹 사이트로 이동하여 자세한 내용을 읽을 수 있습니다. 나는 클라이언트 캐시에 대해 이야기했고 파티셔닝을 통한 고가용성에 대해 이야기했습니다.
분산 캐시의 WAN 복제
또한 여러 데이터 센터가 있습니다. 아시다시피 데이터베이스가 여러 데이터 센터를 처리할 수 있을 것으로 예상하므로 캐시가 아닌 이유는 무엇입니까? 그래서, 다시, NCache 이 기능을 제공합니다. Java 측에는 이를 수행하는 캐시가 있습니다. .NET 측 NCache 유일한 것입니다. 따라서 활성-수동 또는 활성-활성 데이터 센터를 가질 수 있으며 캐시가 동기화됩니다. 다시 말하지만 성능이 떨어지기 때문에 WAN에 걸쳐 있는 클러스터를 가질 수 없습니다. 두 개의 데이터 센터가 있는 경우 동일한 위치에 있지 않을 수 있으므로 WAN을 통해 비동기 복제 또는 동기화를 수행해야 합니다.
우리 중 하나 고객 이곳의 대형 항공사인 Ryanair는 런던 더블린과 프랑크푸르트에 데이터 센터를 두고 있습니다. 따라서 동기화할 수 있는지 확인해야 합니다. 의 경우 NCache 우리도 가지고있다 WAN 복제. 세션이 한 데이터 센터에서 다른 데이터 센터로 이동할 수 있는 다중 데이터 센터 세션 개념도 있습니다. 그러나 어쨌든 캐시는 여러 데이터 센터를 지원할 수 있어야 합니다. 그래서, 당신이 그것을 조사했는지 확인하십시오.
NCache vs Redis
대부분의 .NET 사용자는 Redis. NCache, 죄송합니다. Microsoft는 Azure에 대한 선택 항목으로 선택했지만 Redis Linux 배경에서 나옵니다. 마이크로소프트가 그들을 선택한 주된 이유는 그들이 여러 언어를 갖고 싶어했기 때문이라고 생각합니다. 그래서, Redis 많은 언어를 다룹니다. NCache 거의 .NET에 중점을 둡니다. Java API도 있지만 NCache 자체는 .NET에 중점을 둡니다. 이것이 무엇을 의미하는지 알 수 있도록 두 가지에 대한 매우 빠른 개요를 만들고 싶습니다. 그런 다음 우리 웹 사이트에 올 수 있습니다. 비교. 여기에서 기능 비교를 수행할 수 있습니다. 그런 다음 이것을 다운로드할 수도 있습니다. 자, 이것 좀 보세요. 그들의 문서와 우리의 문서를 기반으로 합니다. 그래서, 그것은 아무것도 아닙니다... 여기에 스핀이 없습니다.
NCache 또한 오픈 소스이므로 Redis. 의 경우 NCache 당신은 … 당신은 우리 웹사이트에 올 수 있고 당신은 할 수 있습니다 다운로드 Enterprise Edition 또는 오픈 소스 또는 GitHub로 이동할 수도 있습니다. NCache? 바로 여기 GitHub의 그리고 당신은 볼 수 있습니다 NCache 여기에도.
따라서 이 엔터프라이즈 에디션은 완벽하게 지원됩니다. 의 경우 Redis 마이크로소프트 포팅 Redis 리눅스에서 윈도우로. 따라서 Microsoft가 Azure의 포트를 사용한다고 생각할 수 있지만 실제로는 그렇지 않습니다. 따라서 그들이 가지고 있는 항구에는 많은 문제가 있습니다. 많은 고객들이 그것에 대해 우리에게 불평했습니다.
그래서, 당신이 사용한다면 Redis Azure에서는 안정적인 Linux 버전을 사용하고 문제가 없지만 방금 이야기한 모든 기능을 잃게 됩니다. 온프레미스 지원을 수행하려는 경우, NCache 오픈 소스는 모두 무료이며 기업은 지원 비용보다 더 많은 기능을 얻을 수 있습니다. 온프레미스를 원하는 경우 Redis, 당신이 가진 유일한 옵션은 Linux 버전으로 이동하는 것입니다 Redis 실험실. 그들은 또한 이제 이것을 도커에 가지고 있습니다. 따라서 기술적으로는 Windows에서 실행할 수 있지만 여전히 Linux 환경에서 실행할 수 있습니다. Windows의 온프레미스는 Microsoft에서 가져온 것으로 제가 말했듯이 불안정하고 지원이 없습니다.
Azure에서 Redis 캐시 서비스 모델을 제공하고 NCache VM 모델을 제공합니다. VM 모델은 훨씬 더 많은 제어 기능을 제공합니다. read-through, write-through, 캐시 로더, 데이터베이스 동기화에 대해 방금 이야기한 이 모든 항목을 제어할 수 있으며 클라이언트 API만 있습니다.
두 사람에 대한 간략한 개요입니다. 언급하고 싶었습니다. 원래, NCache .NET 공간에서 가장 오래된 캐시입니다. 우리는 수많은 고객들이 사용하고 있습니다. NCache. 또한 그들 중 많은 수가 영국에 있습니다. 아시다시피 영국은 우리의 두 번째로 큰 시장이며 .NET 애플리케이션이 있다면 전체 스택이 .NET이기를 바랍니다. NCache .NET 스택을 제공합니다. Redis 하지 않습니다.
이 강연을 마치기 전에 질문이 있습니까? 하지만 파티셔닝을 직접 노출하고 있습니다. 왜냐하면 관계형 데이터베이스에서는 데이터가 둘 중 하나에 상주하는 방식으로 애플리케이션을 프로그래밍해야 하기 때문입니다. No SQL의 전체 개념은 모든 것이 키를 기반으로 하기 때문에 그들이 당신을 위해 샤딩을 한다는 것입니다. 관계형에서는 훨씬 더 복잡하며 지금까지 어떤 관계형 데이터베이스도 확장성 문제를 해결할 수 없었습니다. 그들은 매우 열심히 노력해 왔으며 성능이 엄청나게 향상되었습니다. 메모리 내 옵션이 많기 때문에 메모리 내 데이터베이스도 있고 메모리 내 테이블 등을 많이 수행합니다. 따라서 성능이 상당히 향상되었지만 여기서 성능은 문제가 아닙니다. 문제는 확장성입니다. 당신은 그 짐을 처리할 수 있고 지금까지는 그들은 할 수 없습니다.
따라서 인덱싱을 사용하는 이유는 해당 속성을 검색할 수 있도록 하기 위함입니다. 따라서 SQL 문을 수행하고 인덱싱된 객체의 속성을 검색할 수 있습니다.
따라서 색인을 생성하지 않으면 검색을 허용하지 않습니다. 그래서 검색을 해보면 NCache 이 속성이 인덱싱되지 않았다는 예외가 발생합니다. 그래서 좀 더 고통스러운 방식으로, 네. 그러나 우리가 고객에게 말하는 것은 무엇을 검색하려고 하든 인덱스를 만들어야 한다는 것입니다. 그리고 모든 것이 SQL인 데이터베이스와 달리 여기에서는 모든 것이 SQL을 거치지 않습니다. 다시 말하지만, API만으로 많은 작업을 수행하고 있으며 그 중 일부는 SQL을 통해 이루어집니다.
캐시 이름을 의미합니까? 키에 유형 정보가 있어야 한다는 규칙이 있습니다. 예를 들어 개별 객체이고 유형이고 기본 키 값 또는 기본 키 속성 이름이고 그 다음 값인 경우 이것이 일반적이며 전체 컬렉션을 저장하는 경우 고객에 대한 다른 모든 주문을 저장한 다음 고객을 기반으로 가져오고 싶을 수 있습니다. 그런 다음 키는 고객, 고객 ID, 내 주문 또는 이와 유사한 것이 될 수 있습니다. 따라서 키는 데이터를 가져오는 방법에 따라 의미가 있어야 합니다.
예, 모두 선택할 수 있는 옵션입니다. 내 처리 관계형 데이터 비디오를 보면 이러한 모든 옵션을 살펴봅니다. 그리고 다시 캐싱을 사용하여 데이터베이스에 다대다 관계가 있다고 가정해 보겠습니다. 애플리케이션 수준에는 다대다(多對多)가 없습니다. 응용 프로그램에서 이쪽 또는 이쪽에서 접근합니다. 항상 일대다입니다. 그래서 그런 것들이 갑자기 관점이 바뀝니다.
전체 데이터베이스를 메모리에 다시 만들려고 하지 않습니다. 분산 캐시 사용의 이점을 요약할 수 있습니까? 확장성이라고 하셨습니다. 다른게 있나요? 가장 중요한 이점은 확장성이라고 생각합니다. 두 번째 이점은 성능이며 사용 사례, ASP.NET 특정 사용 사례, 세션의 경우 큰 이점이 있습니다. 분산 캐시에 대한 대안은 모두 매우 느리거나 확장할 수 없기 때문입니다. 따라서 In-Proc을 수행하면 확장할 수 없습니다. 매번 같은 과정을 거쳐야 하기 때문이다.
나는 또한 이것을 녹음하고 있으며 SDD Conf도 마찬가지라고 생각합니다. 우리는 이 이야기를 YouTube에 올릴 것입니다. 당신이 우리 부스에 와서 우리가 당신을 스캔하게 하면 우리는 당신에게 이야기에 대한 링크를 이메일로 보낼 수 있고 당신은 이것을 당신의 동료들과 공유할 수 있습니다. 기다려 주셔서 대단히 감사합니다.