Как сохранить постоянные глобальные переменные в нескольких экземплярах Google Appengine?

Question

Наша ситуация выглядит следующим образом: Мы работаем над школьным проектом, цель которого состоит в том, чтобы несколько команд ходили по городу с умными телефонами и играли в городскую игру во время прогулки. Таким образом, у нас может быть 10 активных умных людей, которые гуляют по городу, все публикуют информацию о своем местонахождении и запрашивают данные из Google Appengine.

Кто-то стоит за веб-браузером, наблюдает за тем, как все эти команды ходят вокруг, и отправляет им сообщения и т. Д.

Мы используем хранилище данных, предоставляемое Google Appengine, для хранения всех данных, которые эти команды отправляют и запрашивают, для хранения сообщений, их извлечения и т. Д. Однако вскоре мы выяснили, что достигли максимального предела числа операций чтения и записи, поэтому мы искали решение, позволяющее извлекать периодические обновления (которые стоят больше всего операций чтения и записи) без использования ограниченных ресурсов, предоставляемых Google. И, очевидно, потому что это школьный проект, мы не хотим платить за дополнительные чтения и записи.

Сохранение этой информации в глобальных переменных казалось простым и быстрым решением, которым оно и было ... но когда мы начали действительно тестировать, мы заметили, что некоторые из наших данных отсутствовали, а затем снова появились. Это произошло из-за того, что к облаку было сделано так много запросов, что был создан новый экземпляр, и эти экземпляры не сохраняют эти глобальные переменные постоянными.

Итак, наш вопрос: Можем ли мы каким-то образом убедиться, что эти глобальные переменные всегда одинаковы на каждом работающем экземпляре google appengine. ИЛИ ЖЕ Можем ли мы ограничить количество запущенных экземпляров, независимо от того, сколько запросов сделано до «1». ИЛИ ЖЕ Возможно, есть другой способ сохранить эти данные лучше, без использования хранилища данных и без использования глобальных переменных.

Answer 1

Вы должны использовать memcache. Если вы используете библиотеку ndb (новая база данных), вы можете автоматически кэшировать результаты запросов. Очевидно, это не сильно улучшит ваши записи, но должно значительно улучшить количество операций чтения, которые вы можете выполнить.

Вам необходимо сохранить его в хранилище данных, поскольку данные могут быть извлечены из кэша памяти в любое время. Если вы готовы воспользоваться (небольшим) шансом потерять обновления, вы можете просто использовать memcache. Вы можете сделать что-то вроде сохранения только идентификатора сообщения в хранилище данных, и контроллер периодически проверяет, что каждому идентификатору сообщения соответствует запись в memcache. Если один из них отсутствует, контроллер должен будет повторно ввести его.

Answer 2

Во-первых, обязательно используйте memcache, как сказал Тим Делани.Это само по себе, вероятно, решит вашу проблему.

Если нет, вы должны рассмотреть модель push.Преимущество заключается в том, что ваши клиенты не будут постоянно запрашивать у вас новые данные, только когда что-то действительно изменилось.Если обновление достаточно мало, чтобы вы могли доставить его в push-сообщении, вам не нужно беспокоиться о чтениях из хранилища данных при пропаданиях memcache или о любой другой дублирующей работе для всех этих клиентов: вы читаете данные один раз при их измененииотправить его всем.

Первый вариант push - это C2DM (Android) или APN (iOS).Они ограничены количеством отправляемых данных и частотой обновлений.

Если вы хотите стать более любопытным, вы можете вместо этого использовать XMPP.Это позволило бы вам делать более частые обновления с (как мне кажется) большими полезными нагрузками, но может потребовать больше инженерных разработок.Для начала см. Вопросы переполнения стека о Android и iOS .

Веселитесь!

Answer 3

Рассмотрим протокол Jabber для связи между пирами. Свободные лимиты находятся на достаточно высоком уровне.

Answer 4

Интересный вопрос. Сначала плохие новости, я не думаю, что есть лучший способ хранения данных; нет, вы не сможете остановить появление новых экземпляров, и нет, вы не можете сделать так, чтобы отдельные экземпляры всегда имели одинаковые данные.

То, что вы могли бы сделать, - это сделать так, чтобы экземпляры периоидически синхронизировались с основной записью в хранилище данных, выбирая частоту этого интеллектуально и загружая / выгружая информацию одним комком, вы могли бы ограничить количество операций чтения / записи до уровня это работает для вас. Это твердо на территории Kludge, хотя.

Несмотря на то, что я нахожу квоту почти для всего остального, я не могу найти ограничения для свободного чтения / записи, поэтому возможно, что они смешно малы, но тот факт, что вы бьете их всего лишь 10 смартфонами, повышает красный флаг для меня. Вы уверены, что смартфоны опрашиваются (или звонят) с разумной частотой? Звучит так, как будто вы можете их излишне стучать.