На текущий момент есть сервер с монолитной архитектурой, который разбит на псевдо-сервисы.
Общий сервис (ОС) занимается всей социальщиной (кланы, матчинг, чаты). Он запускается в единственном экземпляре.
Частные сервисы (ЧС) держат tcp-соединения с клиентами и выполняют бизнес-логику, которая касается только их. Их мы можем запускать несколько. Зависит от нагрузки.
Есть еще боевые сервисы (БС), но они к БД вообще никакого отношения не имеют.
БД, кстати, одна и это MySQL. К ней ходят и общий сервис и частные.
Проблема в том, что кластер ОС + ЧС разворачивается в одном регионе - Европе, поэтому игроки из Америки или Азии испытывают проблемы с установкой связи. Даже если они связь установили, то пинг до ЧС оставляет желать лучшего. Развернуть независимые кластеры мы не можем, так как есть требование матчить игроков со всего мира. Держать одну БД в Европе, а ЧС + ОС запускать в трех регионах тоже не комильфо. А с началом нового проекта добавилось еще одно условие : если рухнет один регион, то игрок должен иметь возможность подключиться к другому региону без потери данных.
Выходит, что нужно распределенное хранилище, с репликацией между нодами и возможностью писать в каждую ноду. Может быть это мнение ошибочно и подойдет какая-то более простая схема? Просвятите, пожалуйста
Еще вопрос вдогонку. Можно ли использовать распределенные кэши (типа Apache Ignite, Geode) без использования слоя с БД? И чем это чревато? делает ли кто-то так в продакшене?
Проблем у вас несколько. Первая с latency, вторая с source of truth.
Первая решается через CDN и репликацией инстансов с логикой. Гарантированно придёте к очередям и асинхронной обработке данных с событийной консистентностью.
По базам - либо полностью менять логику приложения и коммуникации, либо использовать распределенные базы, такие как AWS Aurora и AWS DynamoDB. Сами по себе они региональные, но есть интересные фичи, позволяющие выводить на весь мир.
Стоит добавить что непонятно нагрузка на чтение или запись, какие требования к консистентности. Можно решить просто гео-репликицией с CQRS или Event Sourcing
Операций на чтение, я думаю, будет больше чем на запись. Такой уж стиль сложился у команды разработчиков, что под рукой должно быть практически все, а если этого нет, то можно и в базу сходить. С устареванием данных мы готовы мириться. Исключением будут только данные аккаунта разве что.
protracer, тогда вам ставить read реплики в нужные регионы и соединять их с местной копией сервера. Самое простое и дешевле. А запись вести в основную базу и страдать только там от задержек. Обязательно научиться в случае потери мастера делать одну из реплик мастером и быстро переконфигурировать приложения (можно через dns)
А каким образом обычно осуществляется запись в БД при таком подходе? Напрямую или через брокеры сообщений?
И еще вопрос вдогонку продублирую. Можно ли использовать распределенные кэши (типа Apache Ignite, Geode) без использования слоя с БД? И чем это чревато? Делает ли кто-то так в продакшене?
protracer, брокеры тупые и умеют только отправлять сообщения в порядке очереди по группам в нужные обработчики. Kafka, RabbitMQ хорошие решения. Если кэш не локальный то это уже не кэш просто как класс. Поэтому никаких распределенных кэшей. Локальный это в той же подсети самое дальнее, а лучше как часть инстанса
А при чем здесь БД?
Используйте MySQL, как и раньше.
А чтобы улучшить отзывчивость, нужно оптимизировать саму игру. Это делается разными путями. Зависит от игры. Вы, кстати, даже не сказали, пошаговая стратегия или реального времени. От этого тоже многое зависит. Если реального и есть требование матчить игроков со всего мира, то в первую очередь нужно уволить геймдизайнера.
Что касается распределенного хранилища, то есть хитрые варианты, когда данные хранятся на устройстве пользователя и сервера им доверяют. Это убирает жесткое требование репликации, и даже добавляет возможно разгрузить сами сервера, но в замен придется много программировать т.н. арбитражную систему по принципу "доверяй, но проверяй".
А есть на данный момент какие-то вменяемые решения с мастер-мастер репликацией между дата-центрами, разбросанными по всему миру, на основе MySQL? Если да, то напишите. Оптимизировать игру бесполезно, если БД является узким местом во всех смыслах.
Привет, вам нужен tarantool, это лучшее решение для ваших запросов.
Из коробки:
2 в 1 Кеш и БД
Репликация и Шардинг (смотрите как просто сделать реплику и шардинг)
Все операции пишутся в логи, ничего не потеряется
Сервер приложений
Движки хранения в памяти и на диске (если данные не влазят в память, можно хранить на диске)
Консистентность данных (нет расхождения с БД и кешем)
Встроенные процедуры (экономия latency, не нужно таскать большие обемы данных по сети)
Транзакции
Вторичные индексы
Очереди
Нет проблемы холодного старта (данные всегда горячие)
Простой
Средний
Простой
