Match Making using GAE + ndb

Question

У меня есть игра, в которой пользователи обращаются к серверу, чтобы найти пользователя своего уровня, который хочет играть в игру. Вот основная архитектура игрового запроса.

Я использую ndb для хранения очереди ожидания для каждого уровня пользователя в Google DataStore.

Я обращаюсь к этим очередям по их ключам, чтобы обеспечить прочную согласованность (за this article). Объекты хранятся в очереди с использованием повторного (списка) LocalStructuredProperty.

Вопросы:

1. Объект удаляется из очереди ожидания, потому что она соответствует к запросу. Сделка совершена, но пока не применяется. Тот же объект сопоставляется с другим запросом и удаляется. Это будет ошибка?
2. Эти строго согласованные обращения ограничены ~ 1 записью/сек. Есть ли лучшая архитектура, которая устранит это ограничение?

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

Answer 1

Не уверен в вашем первом вопросе, но вы можете смоделировать его с помощью оператора сна в своей транзакции.

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

Answer 2

1.- Если вы делаете сущность get и сообщение внутри транзакции, то одно и то же сущность не может быть сопоставлена ​​для игры и, следовательно, отсутствует ошибка, и она остается непротиворечивой.

2.- 1 запись в секунду является лимитом для транзакций внутри одной и той же группы сущностей. Если вам нужно больше, вы можете очертить объект очереди.

Вы можете использовать выделенный memcache или экземпляр redis, чтобы избежать конкуренции. Это намного быстрее, чем хранилище данных.

Посмотрите, как эти парни используют узлы дерева, чтобы сделать изготовление матча: https://www.youtube.com/watch?v=9nWyWwY2Onc