.Net 플랫폼의 분산 캐시 설계

7178 단어 .NET캐시
캐시 메모리는 정말 좋은 물건이다. 대형 시스템에서 시스템의 속도를 효과적으로 향상시킬 수 있다. 이것은 쓸데없는 말은 하지 않겠다.Net 플랫폼 아래에서 나는 캐시를 공용에서 크게 두 가지로 나눈다. 데이터 대상 캐시와 페이지 출력 캐시이다.데이터 캐시에는 System이 사용됩니다.Web.Caching.Cache라는 클래스는 상하문 대상의Context에서 실현할 수 있습니다.Cache에서 이 객체의 참조를 가져옵니다.페이지/컨트롤 출력 캐시는.Net 환경은 실행 시 헤더의 캐시 설명에 따라 캐시 정책을 제어합니다.본고는 주로 데이터 캐시와 관련된 일부 응용과 문제점을 논증한다.
어떤 사람은'웹 정원에서 데이터를 공유할 수 없는 문제'를 언급했다. 해결 방안은 XML 파일을 사용하여 캐시된 키 값을 저장하는 것이지만 여기서 의문점이 하나 있다.Net의 웹 파크는 프로세스가 독립된 이상 어떻게 공유할 수 있겠는가. 만약 그렇다면 XML 문서를 통해 캐시 키 값을 캐시하는 대상도 두 프로세스에서 동시에 공유할 수 없다. 다른 프로세스에서 현재 프로세스에서 효력을 상실한 '더러운' 캐시 데이터를 읽는 것을 피하는 것이 장점이다.이렇게 하면 웹 파크를 몇 개 열면 캐시 대상이 몇 개 생겨서 시스템 자원에 대한 이용계가 비교적 낮아진다.웹 게시판이라면 낭비가 더 많을 것이다. 아마도 이런 규모에 이르는 포럼이 드물기 때문에 디자인 능력의 범위에 있지 않을 것이다.
Community Server도 이 시스템의 대상을 사용하고 이를 포장하여 Community Server를 형성했다.Components.CSCache 클래스는 프로젝트에서 선택할 수 있는 괜찮은 클래스입니다.
이러한 유형의 응주를 바탕으로 Enterprise Library의 Cache Block 안의 Null Backing Store 방식을 실현하지만 다중 프로세스/서버 공통 캐시 데이터의 수요를 만족시키기 위해 EntLib은 SQL SERVER를 백엔드 저장 장치로 하는 방안을 제공했다. 이렇게 하면 성능 요구가 너무 엄격하지 않고 클라이언트 연결이 많지 않은 상황에서도 이런 방식을 사용할 수 있다.EntLib을 공유 데이터베이스 구역으로 설정하는 작업만 하면 됩니다. 모든 CacheManager 실례는 캐시 블록에 대한 읽기와 쓰기 권한을 가지고 있습니다. 물론 하나의 실례만 허용하고 다른 것은 읽을 수 있도록 설정할 수 있습니다.
그럼 더 좋은 방법이 없을까요, 사실은 있어요.근데 내가 이상해.Net 플랫폼에'원생태'의 분포식 캐시 솔루션이 없다니, 아마도 내가 견문이 좁은 것일 것이다. 어떤 달인이 알고 있는지 공유해 주십시오.다행히도 우리는Memcached라는 물건을 가지고 있다. 이것은 PHP 플랫폼에서 이미 큰 성공을 거두었고 우수한 분포식 캐시 해결 방안이다. 이 글을 참고할 수 있다. 대형 사이트에서 없어서는 안 될 것이다.어떤 학생이 가서 볼 수 있고 또 하나의 아이디어를 생각해 볼 수 있다. 바로 EntLib을 바탕으로 IBAckingStore 인터페이스를 확장하여 BaseBackingStore에서 파생시켜 실현한 다음에 Remoting이나 ICE 같은 분포식 중간부품 기술을 통해 비슷한 기능을 실현할 수 있을 것이다.
XML을 캐시 키로 저장하는 방식은 좋은 생각이다. 이렇게 하면 캐시 항목을 대량으로 제거할 때 스캔을 하지 않고 해당하는 캐시 키 값을 직접 얻을 수 있기 때문에 분포식 캐시와 통합하는 것이 좋은 방안이 될 것이다.
자, 다시 한 번 Discuz를 돌아봅시다!NT가 페이지 캐시에 어떤 팁을 가지고 있습니까?
전반적으로 말하면 나는 그다지 좋아하지 않는다.Net2.0에서 제공하는 페이지 출력 캐시 기능은 주로 페이지 캐시가 만료되는 것을 수동으로 제어할 수 없기 때문에 캐시 의존항이 있는 것도 불편한 것 같다.사실 데이터 바인딩 컨트롤을 사용하는 것은 상대적으로 자원을 소모하는 것이다. 같은 데이터는 내가 StringBuilder로 직접 출력하는 속도가 훨씬 빠르고 테스트 코드가 비교적 간단하기 때문에 나는 여기서 주지 않을 것이다. 모두가 직접 측정할 수 있다. Discuz!NT는 디자인에서도 이런 방법을 대량으로 채택했다. (어쩐지 속도가 이렇게 빠르더라니.)일반적으로 템플릿이 저장된 후 백엔드는 aspx 디렉터리에 대응하는 페이지 파일을 생성합니다. 예를 들어 한 페이지가 있는데 그 위에 방문자의 이름을 표시해야 합니다. 위조 코드가 이럴 수도 있습니다.
템플릿 파일 내용 show.html:
다음은 참조된 내용입니다.
   
   
   
   
<html>
<body>
Hello, Your name
is % yourname %
/ body>
/ html>

생성된 파일 show.aspx
   
   
   
   
templateBuilder.AppendLine( " <html> " );
templateBuilder.AppendLine(
" <body> " );
templateBuilder.AppendLine(
" Hello, Your name is " + this .yourname);
templateBuilder.AppendLine(
" </body> " );
templateBuilder.AppendLine(
" </html> " );

생성된 파일 show.aspx
다음은 참조된 내용입니다.
   
   
   
   
templateBuilder.AppendLine( "" );
templateBuilder.AppendLine(
"" );
templateBuilder.AppendLine(
" Hello, Your name is " + this .yourname);
templateBuilder.AppendLine(
"" );
templateBuilder.AppendLine(
"" );

여기의this.rname은 해당 페이지 백엔드 클래스의 속성에 대응하여 프로그램이 실행할 때 초기화하여 값을 부여한다. 이렇게 하면 마지막으로 얻은 페이지 실행 결과는 이templateBuilder 대상의 Tostring() 방법에서 얻을 수 있다.templateBuilder는 바로 페이지 백엔드 클래스의 StringBuilder 클래스의 실례이다. 마지막으로 페이지가 실행된 후의 OnLoad 이벤트에서 서로 다른 페이지 유형, 예를 들어 첫 페이지, 채널 첫 페이지,내용 페이지 등 서로 다른 캐시 정책을 사용하여 페이지 실행 결과의 HTML 코드를 캐시에 삽입하고 다음 요청이 들어올 때 페이지의 생명주기에 들어가기 전의 HttpModule(이 안에 주소 리셋 기능 코드도 포함)에서 이 캐시가 유효한지 판단하여 메모리에서 캐시를 읽고 클라이언트에게 돌려보냅니다.
이렇게 하면 당연히 속도가 빨라지고, 페이지에서 본 실행 시간은 당연히 0ms이다.그러나 로그인 사용자에게 서로 다른 로그인 정보를 표시해야 하기 때문에 익명의 캐시 파일 버전을 사용할 수 없기 때문에 로그인을 해야만 진정으로 한 번 실행할 수 있다. 그러나 위에 표시할 데이터는 모두 독립된 캐시 항목이 있기 때문에 페이지 코드를 다시 조립하는 것일 뿐이다. 속도는 비교적 빠르다. 공식 포럼에서 첫 페이지의 마운트 시간은 15ms로 매우 빠르다.
나는 이 시간조차도 사실 더 절약할 수 있을 것이라고 생각했다.예를 들어 사용자 로그인 정보라는 부분은 JS를 생성할 수 있다. 브라우저에 익명의 사용자의 캐시 버전을 보냈을 때 만약에 사용자가 로그인하면 이런 JS 코드를 추가한다고 판단하고 그 안에 해당하는 HTML를 바꾸면 된다. 또한 AJAX 기술을 사용하여 클라이언트에서 찾을 수 있다. 그러면 이미 로그인한 사용자와 로그인하지 않은 사용자가 공유한 캐시 버전의 문제를 해결할 수 있다.적어도 첫 페이지의 이 등급은 가능하죠. 다른 주요 페이지는 말하기 어렵고 차이가 많지 않을 거예요. 저는 포럼 프로그램의 절차에 대해 잘 몰라요.
다른 측면에서 볼 때 이미 로그인한 사용자는 익명 사용자보다 속도가 더 느려서는 안 된다.

좋은 웹페이지 즐겨찾기