Счетчик транзакций со скоростью 5+ записей в секунду в хранилище данных Google App Engine

Question

Я разрабатываю турнирную версию игры, в которой я ожидаю более 1000 игроков одновременно.Когда турнир начнется, игроки будут устранены довольно быстро (возможно, более 5 в секунду), но процесс будет замедляться по мере продвижения турнира.В зависимости от исключения игрока из турнира присуждается определенное количество очков.Например, игрок, который падает первым, ничего не получает, а игрок, который занимает 500-е место, получает 1 очко, а победитель, занявший первое место, получает, скажем, 200 очков.Теперь я хотел бы начислять и отображать количество очков сразу после удаления игрока.

Проблема в том, что когда я помещаю новый ряд в хранилище данных после удаления игрока, рядсущность должна находиться в отдельной группе сущностей, поэтому я бы не стал превышать ограничение хранилища данных gae, равное 1-5 операций записи в секунду для 1 группы сущностей.Также мне нужно иметь возможность последовательно читать и записывать количество строк, чтобы я мог правильно определить приз для всех выбывших игроков.

Каков наилучший способ реализации модели данных для поддержки этого?

Answer 1

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

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

Честно говоря, я бы предложил первое: даже если половина ваших турниров на 1000 человек прошла в первые 5 минут - нелепо маловероятное событие - вы по-прежнему смотрите менее 2 исключений в секунду. В действительности, любые шипы будут меньше и короче, чем это.

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

Answer 2

существующие комментарии и ответы достаточно хорошо отвечают конкретному вопросу.

на более высоком уровне, посмотрите этот пост и библиотеку с открытым исходным кодом от команды google code jam. у них была похожая проблема, и в итоге они разработали масштабируемое табло на основе хранилища данных, которое эффективно обрабатывает обновления и запросы на произвольные страницы.