0

У меня есть приложение Python для App Engine, где игроки публикуют свои ответы на вопросы, и команда судей голосует за них как правильно или неправильно. Голоса отливаются судей с использованием этой модели:Подсчет голосов Google App Engine

class vote(ndb.Model): 
    judge = ndb.KeyProperty(justice) 
    value = ndb.BooleanProperty() 
    timestamp = ndb.DateTimeProperty(auto_now_add = True) 
    question = ndb.KeyProperty(game_has_question_has_player) 

А вопросы есть эта структура:

class game_has_question_has_player(ndb.Model): 
    match = ndb.KeyProperty(game) 
    challenge = ndb.KeyProperty(questionList) 
    gamer = ndb.KeyProperty(player) 
    answer = ndb.StringProperty() 
    passed = ndb.BooleanProperty() 

Как только число положительных или отрицательных голосов составляет 1/2 +1 из судей вопрос считается пройденным или неудачным. Это может произойти до того, как все судьи проголосовали и являются ключевыми для приложения, занимающегося остальными проблемами для продолжения игры.

Моя проблема связана с этим моментом. Как я могу надежно узнать, когда вызов/вопрос только что был принят? Подводя итог, где я застрял, это есть варианты я могу увидеть:

  • Метод голосования запрашивает предыдущие голоса и принимает решение (с учетом голосов отливаемым) Wether обновить «прошел» поле "game_has_question_has_player". Проблема здесь в том, что запросы на подсчет предыдущих голосов могут дать неправильный ответ из-за того, что другие голоса одновременно подаются остальными судьями и другие подсчеты одновременно и одновременно.

  • Я изменяю модель вопроса, чтобы добавить счетчик голосов. Я вижу конфликтную проблему, поскольку судьи одновременно уведомляются о проблемах, связанных с голосованием, и поэтому могут голосовать очень близко друг к другу. Я могу использовать транзакции, но я не совсем понимаю, что это ограничения в производстве (сейчас я на сервере разработки). В определенной игре может быть легко 10 судей, но если в играх учитываются тысячи голосов, масштаб * = ~ 10 * количество вопросов * количество игроков.

  • Я откладываю пересчет с очередью задач. Если каждый голос делает то же самое: разве мы не в том же случае, что и в первом пункте, только откладываем?

Я читал про осколочные счетчики, но я не вижу, чтобы они соответствовали этому; Голоса правильны, это просто «событие» прохождения теста, которое кажется мне сложным.

Большое спасибо за любые идеи и идеи.

ответ

1

Сделки должны работать здесь и не будут проблемой в будущем. Они только «блокируют» затронутые группы Entity Groups и не будут препятствовать масштабированию.

Ваш третий пункт должен работать, если вы задерживаете запуск своих задач достаточно (я бы сказал, от 3 до 5 секунд). Хранилище данных должно быть обновлено во время этой проверки.

Но ничто не позволяет вам попробовать эти 2 решения вместе, просто чтобы быть «уверенным».

+0

Большое спасибо. Я думаю, что я пойду первым для этой задачи, потому что это не подразумевает соперничество и поэтому может быть более «экономическим», –

 Смежные вопросы

  • Нет связанных вопросов^_^