Сохранение постоянного количества в Google App Engine

Question

Я ищу предложения по очень распространенной проблеме на платформе Google App Engine для поддержания согласованных счетчиков. У меня есть задача загрузить группы домена, а затем создать задачу для каждой группы для загрузки ее членов группы в отдельную задачу. Теперь, когда есть тысячи групп и членов, будет слишком много задач. Я создам одну задачу, чтобы получить одну страницу групп, и в рамках этой задачи я буду создавать несколько задач для каждой группы, чтобы получить ее членов. Теперь, чтобы узнать, загружена ли я всеми группами или нет, у меня есть логика просто проверьте nextPageToken, а затем установите флаг загрузки групп в законченный.

Однако, поскольку для каждой группы будут выполняться отдельные задачи для загрузки участников, мне нужно отслеживать все, закончились ли все задачи члена группы или нет. Теперь у меня есть проблема, что различные задачи, получающие доступ к одному счету numGroupMembersFinished, будут создавать проблемы параллелизма и где-то счет будет поврежден и не вернет правильные данные.

Answer 1

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

Многие статьи в Интернете охватывают это. Google для «подсвечивающих счетчиков» для полумасштабируемого способа подсчета объектов хранилища данных в течение O (1) времени.

более важно взглянуть на memcache api. Он имеет функцию для атомарного приращения/уменьшения счетчиков, хранящихся там. У этого никогда не будет проблем с параллелизмом, однако вам все равно потребуется какой-то способ восстановить и/или дважды проверить, что запись memcache не была выселена, возможно, также сохраняя счет, хранящийся в сущности, которую вы устанавливаете асинхронно, и «получите по ключу ", чтобы всегда получать свою последнюю ценность.

все еще не является 100% -ным пуленепробиваемым, поскольку кэш может быть выдворен в тот же момент, когда у вас есть много одновременных попыток его изменить, поэтому ваш объект резервного хранилища данных может пропустить «набор».

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

Answer 2

можно использовать MapReduce или Pipeline API:

https://github.com/GoogleCloudPlatform/appengine-mapreduce https://github.com/GoogleCloudPlatform/appengine-pipelines

позволяет разделить проблему на более мелкие управляемые части чего библиотека может обрабатывать все детали сигнализации/блокировки между задачами, сбор результатов, и передавая их обратно к вам, когда это сделано

Google I/O 2010 - трубопроводы данных с Google App Engine:

https://www.youtube.com/watch?v=zSDC_TU7rtc

Google I/O 2011: Масштабный анализ данных с помощью API App Трубопроводный двигателя:

https://www.youtube.com/watch?v=Rsfy_TYA2ZY

Google I/O 2011: App Engine MapReduce:

https://www.youtube.com/watch?v=EIxelKcyCC0

Google I/O 2012 - Строительство данных Трубопроводы в Google Масштаб:

https://www.youtube.com/watch?v=lqQ6VFd3Tnw

Answer 3

Zig Mandel упомянул, вот ссылка на собственный рецепт Google для реализации счетчика:

https://cloud.google.com/appengine/articles/sharding_counters

Я скопировал (переименовал некоторые переменные и т. Д.) Настраиваемый оверенный счетчик в мое приложение, и он отлично работает!

Answer 4

Я использовал этот учебник: https://cloud.google.com/appengine/articles/sharding_counters вместе с Хашидом библиотеки и создал эту библиотеку golang:

https://github.com/janekolszak/go-gae-uid

gen := gaeuid.NewGenerator("Kind", "HASH'S SALT", 11 /*id length*/) 
c := appengine.NewContext(r) 
id, err = gen.NewID(c) 

Такого же подход должен быть легким для других языков.