Как при асинхронных запросах к базе сохранить последовательность?

Question

[Виталий]

Пример. У нас есть персонаж, которому можно наносить урон, но который восстанавливать здоровье.

Сценарий такой:
1. осталось 2 единицы здоровья
2. урон 1
3. восстановление здоровья
4. урон 1

Шаги 3 и 4 были вызваны почти одновременно, но сохранение последовательности критически влияет на исход. Предположим, что восстановление происходит по довольно сложному алгоритму, где нужно учесть много факторов. Тогда перед тем, как сохранить в базу результат, с персонажа будет списан последний хп, из-за чего он умирает и игра завершается поражением.

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

Answer 1

[Andrey]

Мне кажется тебе отлично подойдёт асинхронная работа с помощью очередей.

Например rabbitmq

Comments

[Виталий]

Спасибо, хочу уточнить как это работает. В начале обработки запроса создаётся соединение с базой в режиме очереди, дальше отправляются запросы, соединение закрывается. Остальные открытые соединения сохраняют запросы, но ждут закрытия предыдущего соединения, после чего последовательно обращаются к базе. Всё правильно?)

[Виталий]

Если всё правильно, сразу возникает следующий вопрос: можно ли разделить контекст очередей, чтобы не заставлять ждать те потоки, которые не могут помешать в конкретной ситуации? Иначе весь сервер будет зависать, пока один из сценариев не завершится полностью, чтобы передать очередь следующему.

[Andrey]

Виталий: я представлял себе это немного иначе.

Окей у нас есть клиент, бекенд, очередь, база.

И события типо ударов и пр у тебя сейчас

клиент->бекенд->база

я предлагал

клиент->очередь->бекенд->база.

Причём кол-во ондовременных бекенд рабочих можно контролировать...
То есть напирмер я уже как то делал подобную штуку и это выглядело как.

для общих событий отправляется тупо сообщение в очередь и сразу выполняется.

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

То есть при обычных собитиях очередь работает в push режиме а для таких о которых мы говорим - в pull режиме.

И если ещё и наплодить несколько таких штук - можно сделать параллельную обработку несколькими бекенд приложениями "последовательных" сообщений, но очереди и клиентов привязать между собой. что бы в итоге получилось что в pull режиме 1 клиента всегда обрабатывает один и тот же инстанс приожения. В результате получим асинхронную обработку с распределением нагрузки и без нарушений последовательности действий.

Answer 2

[Александр Филиппенко]

Самое простое - 4-й запрос выполнить в колбэке 3-го.

Comments

[Виталий]

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

[Александр Филиппенко]

Виталий: Да, я вопрос не правильно понял. Тогда конечно способ Виталия с очередью - самый оптимальный.
Либо использование NodeJS в качестве middleware, но это видимо не тот случай.

Answer 3

[Stac]

Обычно помогает помогает простая нумерация запросов.

Например у вас есть табличка или nosql документ с условным названием hp_history - история изменения здоровья.

id| hp | action | value | timestamp
1 | 2|...|...|nnnn1
2| 1 | урон | 1 |nnn28
3| 10| лечение | 10 |nnn34
4| 9 | урон | 1 | nnn35

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

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

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

Comments

[Виталий]

Спасибо, но сейчас я не ищу лёгких путей, я ищу правильные (т.е. универсальные) способы. Логирование действий уместно только когда в этом есть особая необходимость, иначе это большая трата ресурсов. Разность не подходит, когда мы имеем дело с текстом (да, в этом примере я использовал числа, но это пример). Дополнительные запросы тоже не дают гарантий (просто уменьшают вероятность ошибки), но дополнительно нагружают файловую систему.

[Stac]

Виталий: Тут уж извините, отвечаю по той исходной информации, что вы дали. Возможно вам не надо ничего логировать, хот я кажется у вас есть особая необходимость для этого - длительный процесс обсчета восстановления. Может надо логировать в памяти, а не в БД. Вам виднее. В любой случае, если вам нужен порядок запросов, вам его придется хранить явно или неявно (вычислять).

Answer 4

[Oleg]

В серверах которые я видел (lineage, ultima, rf и тп) - практически везде данные пишутся не сразу.
Т.е. обрабатываются в памяти, и пишут в базу раз в секунду, раз в 10 секунд и тп.