Google App Engine 또는 클라우드 기반 애플리케이션에서 캐싱이 작동하는 방식에 대해 궁금합니다. 요청이 동일한 서버로 전송된다는 보장이 없기 때문에 데이터가 서버 A의 첫 번째 요청에 캐시 된 다음 두 번째 요청이 서버 B에서 처리되면 캐시에 액세스 할 수 없게됩니다.Google App Engine/클라우드 기반 호스팅에서 캐싱
이 경우 (서버에만 로컬 캐시), 요청이 캐시를 사용하는 것 같지 않습니까 (사용자 수에 따라 다름)? 예. Google에는 수천 개의 서버가있을 것입니다.
memcached를 사용하여 App Engine을 사용하여 캐시하십시오. 즉, 캐시 서버는 각 응용 프로그램 서버가 아닌 메모리에 데이터를 보유합니다. 응용 프로그램 서버 (주어진 응용 프로그램 용)는 모두 동일한 캐시 서버를 말합니다 (개념적으로, 후드에서 샤딩 또는 복제가 진행될 수 있습니다).
응용 프로그램 서버 자체에서 메모리 내 캐싱은 두 개 이상 있기 때문에 잠재적으로 그다지 효과적이지 않습니다 (해당 응용 프로그램에 대해 몇 개의 인스턴스가 활성화되어 있지만 모두 구글의 서버), 또한 언제나 구글을 폐쇄 할 수 있기 때문에 (이는 다시 부팅하는 데 시간이 걸리는 자바 애플리케이션의 실제 문제이므로 유휴 인스턴스를 유지하기 위해 비용을 지불 할 수있다).
이러한 성능/효율성 문제 외에도 응용 프로그램 서버의 메모리 내 캐싱은 일관성 문제를 일으킬 수 있습니다. 캐시가 동기화되지 않을 때마다 모든 새로 고침이 다른 데이터를 표시합니다.
달성하려는 캐싱 유형에 따라 다릅니다.
데이터베이스에서로드 된 데이터로 재구성하는 데 복잡한 인 메모리 오브젝트 구조가있는 경우 응용 프로그램 서버 자체에서 캐싱이 재미있을 수 있습니다. 이 경우 계산 결과를 캐시 할 수 있습니다. 구조가 큰 경우 공유 memcache보다 로컬 캐시를 사용하는 것이 더 빠릅니다.
메모리와 데이터베이스간에 일관된 값을 유지하는 것이 중요 할 경우 캐시 된 값을 사용할 때마다 데이터 저장소의 저장된 값으로 일부 체크섬/타임 스탬프 확인을 수행 할 수 있습니다. 작은 객체 나 전역 캐시에 체크섬/타임 스탬프를 저장하면 프로세스가 고정됩니다.
글로벌 memcache를 사용하는 데있어서 한 가지 중요한 문제는 값이 아직 없거나 플러시 된 경우 "다시 채우는"것에 대한 적절한 동기화를 보장하는 것입니다. 정확히 같은 시간에 여러 개의 서버가 검사를 수행하고 캐시에서 값을 다시 채우는 경우 동시에 여러 가지 다른 서버로 리필을 수행하게 될 수 있습니다. 동작이 동일하다면 이것은 문제가되지 않는다. 그렇지 않은 경우 잠재적 인 버그를 추적하기가 매우 어렵습니다.
캐시 서버를 애플리케이션 서버와 구분하여 App Engine 토폴로지를 설명하는 참조가 있습니까? – systempuntoout
글쎄, 그들은 memcached를 사용합니다 (공식적인 문서에 나와 있습니다). 나는 memcache가 어디에서 실행되는지 (응용 프로그램 인스턴스와 동일한 실제 시스템에있을 수 있음)와 공유되는지 또는 복제되는지 여부를 알지 못합니다. 중요한 점은 응용 프로그램 인스턴스의 기본 프로세스 메모리에 있지 않으며 모든 인스턴스간에 공유된다는 것입니다 (모두 동일한 캐시 내용을 참조). – Thilo