Всем привет. Я тут с холиварным/философским вопросом про архитектуру и реализацию. Кому нечего делать, читайте дальше)

В общем, на спринге хочу написать онлайн игрушку. Есть вебсокеты. Есть игровые комнаты.
Первый вопрос такой: хочется сохранять всю игровую информацию в бд(а не держать в памяти), чтобы в последствии если что можно было расширять в ширину сервера итд. Все комнаты обновляются раз в секунду. И я вот думаю: оправдано ли по скорости и нагрузке каждую секунду брать из базы все данные по игровым комнатам, обрабатывать их, делать какие/то манипуляции и сохранять? Просто такой подход не очень тяжёлый в реализации по сравнению с подходом комбинирования in-memory с бд. Я пытался второй реализовать, но как-то все у меня плохо пошло с транзакциями, spring jpa, но если такой подход более правильный, то буду копать в его сторону.


И второй вопрос: очень удобно было бы представлять комнату как отдельный экземпляр класса с логикой и данными. Но у меня же спринг, объекты созданные с new он не менеджерит, а создавать бины в рантайме - это вроде как моветон. Поэтому пришлось сделать сервис, в котором на вход каждому методу подаётся экземпляр игровой комнаты(читай данные) для манипуляций. Посмотрев на это сверху, кажется что все приложение построено на статик методах, мне кажется что это совсем не тот подход. Что можете посоветовать?

Жесть, имхо такая путаница.
"что можно было расширять в ширину сервера"
поясните почему для этого обязательно все хранить в памяти? Как эти две вещи связаны?
"у меня плохо пошло с транзакциями, spring jpa"
что у вас плохо пошло? Тут вообще ничего без деталей не понятно, в чем проблема?
"создавать бины в рантайме - это вроде как моветон"
Не обязательно создавать бины в рантайме, можно просто создавать объекты в рантайме(wow). Почитайте про Rich Model/Anemic model и ООП/Процедурное программирование

Непонятно, зачем брать сразу все комнаты и что-то со всеми что-то делать. Ты обычно достал объект и что-то сделал. Echcache как бы есть и те объекты с которые ты не меняешь, будут быстро достаются и не из базы, а из кеша

Второй вопрос непонятен

Для расширения наоборот информация должна храниться в бд, чтобы несколько серверов могли обрабатывать.

Я хочу чтобы сущности менеджерил спринг, так как @Transactional работает только в бинах, насколько мне известно

Echcache с терракотой много проблем, редис тупо быстрее и проще

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

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

Да @Transactional может быть например над методом application сервиса, который возьмет к примеру из репозитория ваш объект "Комната" и скажет ему, что нужно сделать (вызовет его метод)

Я подозреваю что вы решаете проблемы не тем способом, но без знаний механики игры трудно судить

1) Ну т.е. кэш, который я сам руками не буду менеджерить, как я делаю сейчас?(есть мапа с комнатами, беру, обновляю в ней значения, сохраняю, апдэйчу)

2) Если я НЕ из бина вызову метод сервиса (бина), помеченного аннотацией @Transactional, то транзакция создастся ?

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

1) Не понял вопроса, но да кеш конечно можно и в ручную создать, а можно юзать готовые решения. С кешом обычно встает вопрос консистетности, а ответ нужно искать в вашей предметной области, что именно является консистетным состоянием, а что нет. Может ли и сколько система может быть в несогласованном состоянии (итоговая согласованность)

Как правило есть смысл что-то почитать из закешировать, а не ходить постоянно в бд, и что за бд кстати

2) Наоборот - вы можете вызвать из бина-сервиса с  @Transactional - метод своего объекта

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

MariaDB, возможно перейду на Postgre, но без каких-то обоснованных тезисов.

Судя по вопросу 2 вы не очень представляете как устроен спринг. Нет работать не будет.

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

Наоборот да, ок, без вопросов.
Но вот я говорю, что есть кейс, когда нужно в обратную сторону сделать вызов. Вот кейс:
Есть класс, в котором есть лист с комнатами.
Есть метод в этом классе, который шедулится каждую секунду и для каждой комнаты из листа вызывает метод update(). В этом методе апдейт состояние комнаты может обновится и нужна будет синхронизация сбд, чтобы сохранить актуальные данные

Ну какое тогда масштабирование? Упретесь в rw бд  просто, если ещё хибернейт то тупить будет ппц как со временем