5
난 그냥 AppEngine documentation for Query Cursors에 다음 단락을 가로 질러 온은 :구글 AppEngine에 서버 인스턴스 클럭 동기화
커서의 흥미로운 응용 프로그램은 보이지 않는 변화에 대한 실체를 모니터하는 것입니다. 앱이 엔티티가 변경 될 때마다 현재 날짜 및 시간과 함께 타임 스탬프 속성을 설정하면 앱은 timestamp 속성으로 오름차순으로 정렬 된 쿼리를 데이터 스토어 커서 과 함께 사용하여 엔티티가 끝까지 이동 한 시점을 확인할 수 있습니다. 결과리스트 엔티티의 타임 스탬프가 업데이트 된 경우 커서가있는 쿼리는 업데이트 된 엔티티를 반환합니다. 쿼리가 수행 된 이후로 엔티티가 업데이트되지 않은 경우 결과가 반환되지 않고 커서가 으로 이동하지 않습니다.
안정적으로 작동하려면 여러 서버 인스턴스에서 시계 동기화에 대해 일종의 보장이 있어야합니다.
- 서버 인스턴스 1 (빠른 클럭) 1000
- 클라이언트 업데이트를 요청하고이 하나의 업데이트를 발견 타임 스탬프와 업데이 트를 저장합니다 그렇지 않으면 당신은 다음과 같은 시나리오를 얻을 수 있습니다.
- 서버 인스턴스 2 (느린 시계)는 시간 스탬프 950으로 다른 업데이트를 저장합니다.
- 클라이언트는 업데이트를 요청하고 타임 스탬프가 증가하지 않으므로이 업데이트를 찾지 못합니다.
내가 이해하는 한, 그러한 시계 동기화 보장은 전혀 없었습니다. 이게 바뀌 었습니까 ???
는 업데이트 :난 그냥 시계가 완벽를 싱크하더라도,이 방법으로 인해 쿼리의 최종 일관성에 결과를 놓칠 수 있음을 깨달았다. 최신 업데이트가 이전 업데이트보다 먼저 커밋되고 이전 업데이트가 동시에 수행되지 않는 경우 동시 쿼리가 수행되면 이전 업데이트가 숨겨집니다. 또는 나는 무엇인가 놓치고 있냐?
클럭 동기화에 대한 공식적인 진술을 한 번도 찾지 못했습니다. 구글 친구들과 함께 IRC에서 그들은 물건들이 동기화되었다고 말했고 나는 구글 친구들로부터의이 게시물이 아마도 게임 상태의 좋은 표시라고 믿습니다 https://groups.google.com/forum/#!searchin/google-appengine/clock $ 20sync/google-appengine/XKLp5Uehhr8/MlsdgGwOB-wJ. 개인적으로 appengine의 초기에 나는> 30 초를 넘는 clock skews를 보았다. 지난 번 확인한 바에는 중요한 스큐를 찾을 수 없었습니다 .-) –
이것은 (당신이 언급 한) 걱정할만한 많은 경우가 있기 때문에 문서의 나쁜 예입니다. 완벽한 시계 동기화와 강력한 일관성이 있더라도 시간 소인 필드를 지금()으로 설정하거나 데이터 스토어로 전송 될 때 지연 될 수 있습니다. –