Создание совпадений с использованием GAE + ndb

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

введите здесь описание изображения

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

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

Вопросов:

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

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


python google-cloud-datastore google-app-engine app-engine-ndb
person Alex    schedule 06.10.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

person Brent Washburne    schedule 06.10.2016
comment
Ага, надеялся, что кто-то знает теорию :). Был обеспокоен кешем памяти. Есть идеи, как часто это происходит? - person Alex; 07.10.2016
comment
Я не знаю, как часто сбрасывается memcache, я понимаю, что это зависит от общей нагрузки / спроса на memcache (включая других пользователей). Вы можете управлять этим, записывая данные как в NDB, так и в memcache. Если ваша очередь не имеет предков в ключе, вы не должны ограничиваться ограничением 1 запись / сек, оно применяется только к родительским ключам. - person Brent Washburne; 07.10.2016

arrow_upward
1
arrow_downward

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

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

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

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

person janscas    schedule 07.10.2016
comment
Беспокоился о кэше памяти. Есть идеи, как часто это происходит? - person Alex; 07.10.2016
comment
Система подбора игроков в этом видео (с использованием групп уровней игроков) похожа на то, что предлагается в вопросе (разные очереди для каждого уровня). Что-то мне не хватает? - person Alex; 07.10.2016
comment
Memcache сбрасывает ключи по мере заполнения. Вы не можете контролировать это, если не заплатите за выделенный сервер только для себя. - person janscas; 08.10.2016
comment
система на видео отличается, потому что она не использует повторяющиеся свойства для хранения фактических очередей. - person janscas; 08.10.2016
comment
По моему опыту, оплата выделенного кэша памяти приведет к тому, что упадут гораздо меньше элементов. - person marcadian; 09.10.2016