이 질문은 아키텍처의 모범 사례에 관한 것입니다.
우리의 현재 아키텍처
사용자 정보를 위해 MySQL에 액세스하는 PHP 클래스가 있습니다. 그것을 호출하자 User
. User
여러 번 액세스되므로 부하를 줄이기 위해 캐싱 계층을 구현했습니다.
첫 번째 계층은 "요청 당"캐시라고합니다. MySQL에서 데이터를 검색 한 후의 개인 속성에 데이터를 저장합니다 User
. 이후의 데이터 요청은 MySQL에서 데이터를 다시 요청하는 대신 속성을 반환합니다.
웹 요청은 요청에 따라 작동하고 종료되므로이 캐시는 애플리케이션이 단일 요청에서 MySQL에 두 번 이상 액세스하지 못하도록합니다.
두 번째 계층은 Memcached입니다. private 속성이 비어 있으면 먼저 Memcached에서 데이터를 확인합니다. Memcached가 비어 있으면 MySQL에 데이터를 쿼리하고 Memcached를 업데이트하고의 private 속성을 업데이트합니다 User
.
질문
우리의 응용 프로그램은 게임이며 때로는 일부 데이터를 가능한 한 최신 상태로 유지해야합니다. 약 5 분 동안, 사용자 데이터에 대한 읽기 요청은 10 회 또는 11 회 일어날 수있다. 업데이트가 발생할 수 있습니다. 후속 읽기 요청이 최신 상태 여야하거나 게임 메커니즘이 실패합니다.
우리가 한 일은 데이터베이스 업데이트가 발생할 때 실행되는 코드를 구현하는 것입니다. 이 코드는 업데이트 된 데이터로 Memcached의 키를 설정하므로 Memcached에 대한 모든 후속 요청은 최신 상태입니다.
이것이 최적입니까? 이런 종류의 "살아있는 캐시"를 유지하려고 할 때 알아야 할 성능 문제 나 다른 "gotchas"가 있습니까?