Node.js(как вариант для хранения временных данных)?

Question

[Ростислав Игнатенко]

Добрый день.
Хочу разобрать интересующий меня вопрос на примере покера(так как большинство понимают его суть и правила).
Есть приложение Node+Express+Socket.io+другие вспомогательные библиотеки. Вот допустим в моем приложении уже существует БД, с помощью которой регистрируются пользователи. Выбор комнат со ставкой пользователем реализуется с помощью socket.io.
И вот сам вопрос, а сам процесс игры(какие карты сейчас на столе, какие карты у игроков в руках) лучше в БД записывать или можно с помощью массивов/объектов? И почему?

Answer 1

[Константин Китманов]

В БД (или быстрый кэш, типа Redis). Причин несколько:

• Ваше приложение может упасть. Игрокам не понравится, если у них вдруг пропадут карты. БД тоже падают, но вероятность этого гораздо меньше (у них больше разработчиков и тестеров).
  
• Массивы в памяти не масштабируются. Положим, пару десятков одновременных партий в памяти держать можно, но когда счет пойдет на тысячи, это будет жрать RAM, плюс тормоза на GC. А БД можно вынести на отдельный сервер и даже на отдельный кластер.
  

Ну, понятно, что в учебном примере пофиг на надежность и масштабируемость, но почему бы не делать сразу правильно?

Comments

[Ростислав Игнатенко]

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

[Константин Китманов]

Ростислав Игнатенко: я не согласен. Как раз таки если все данные в БД, то проще восстановиться в консистентное состояние. Если приложение падает, когда игрок ходит, для него это должно выглядеть, как временный лаг, а не как «все пропало, деньги списались, а партии как будто не было».

[Ростислав Игнатенко]

Константин Китманов: Возможно я чего то не понимаю, можете объяснить, что вы понимаете под "приложение падает"? У меня практики в этом еще нету, и для меня это выражение означает что приложение тупо вылетело с ошибкой и его нужно заново подымать через консоль.

[Константин Китманов]

Ростислав Игнатенко: не нужно вручную поднимать через консоль, для этого используется supervisord или pm2 или еще что-то, несть им числа.

[Ростислав Игнатенко]

Константин Китманов: Ага, хорошо, понял. Т.е. получается, для моего примера нужно запускать MySQL, Node, Redis. Если приложение падает, то это означает, что Node перезапустится с помощью выше указанных вами примеров, а данные с Redis никуда не пропадут же? Они только пропадут если я остановлю или перезапущу сам сервер, на котором стоит Redis?

[Константин Китманов]

Ростислав Игнатенко: ага, все так.

[Константин Китманов]

Кстати, перезапуск Redis не обязательно означает пропажу данных: https://redis.io/topics/persistence

Answer 2

[Иван]

Я бы сказал NoSQL или память.
Это от приложения конечно зависит, но если ляжет сервер, то думаю данные сессий один фиг надо обнулить. Хранить в память всегда быстрее.

Answer 3

[dummyman]

Есть вариант быстрее БД - это файлы записанные в раздел с tmpfs.
При загрузке сервера создаешь временный диск на N гигабайт.
Сохраняешь туда все что нужно. И не будет страшны падения ноды и серва БД.
Можно даже со всей статикой сервиса, если речь идет о web, хуже не будет.
Но важно следить за переполнением памяти и стабильностью ОС.
Лично у меня куча серверов в обслуживании с приложениями node, где uptime больше 365 дней. Полет нормальный.