내 GAE 앱 중 하나에서 스폰서 이미지를 구현하는 솔루션을 찾고 있습니다.비용 효율적인 방식으로 이미지 뷰 추적
약 5000 명의 사용자가 앱을 사용하고 있으며 이러한 스폰서 이미지는 사용자가 볼 때마다 그리고 누군가가 클릭 할 때마다 추적해야합니다.
누군가가 카운터에 대해 여러 항목을 제안한 다음 데이터 저장소 쓰기 제한을 통과하기 위해 이러한 카운터를 무작위로 증가 시키겠다는 제안을 받았지만 정확히 동시에 두 개의보기가 있고 둘 다 데이터 저장소에 쓰려고하면 같은 시간에 두 번째 쓰기는 첫 번째 쓰기를 덮어 쓰며 한 개의보기를 잃게됩니다.
현재 모든보기와 모든 클릭에 대해 새로운 데이터 저장소 항목을 만들고 모든보기를 추가하고 통계 엔티티에서 통계를 저장하는 큐로 스케줄러를 전달하는 것은 그리 효율적이지 않습니다.
제안하신 분산 카운터를 사용하지 않는 이유는 무엇입니까? 20 열 카운터에 배포 할 수 있습니다. 즉, 매우 신뢰할 수 없도록하기 위해 초당 20 히트 (많이)에 도달해야합니다. – MeLight
우리는 20 초당 20 히트 이하로 논의. 하나의 인스턴스 만 실행 중이면 작동해야하지만 두 인스턴스가 실행되는 즉시 두 인스턴스가 같은 항목에 쓰려고 시도하는 1/20의 기회가 생깁니다 (따라서 동일한 항목을 증가시키기 때문에 해당 트랙이 누락됩니다) 동시에 많은 항목들). 정확성을 희생해야하는 패스를 얻는 데 사용할 수있는 일종의 "행 수준 잠금"이 있습니까? distrubuted-counter + entity-locking은 완벽한 해결책이 될 것입니다. –
저는 확률 전문가는 아니지만, 20에서 같은 카운터 행을 치려고하는 두 개의 인스턴스가 합쳐져서 1/400의 확률로 합쳐질 것이라고 생각합니다. 잠금에 대한 질문에 관해서는, 나는 그런 메커니즘을 알지 못합니다 (정말 좋을 것입니다). – MeLight