Если ради снижения нагрузки сохранять прогресс раз в несколько минут, то при падении сервера в промежутке прогресс пропадает.
Почему Состояние персонажа сохраняется раз в несколько минут → Следствие В промежутке сервер падает или происходит сбой → На экране После перезахода персонаж в состоянии нескольких минут назад (роллбэк)
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Инфраструктура БД
Команда разработки: задачи
Важные события (обмен, редкая добыча) сохранять сразу, вести журнал изменений.
Команда инфраструктуры: задачи
Проверить, хватит ли у БД запаса IOPS и CPU на рост записи при сокращении интервала сохранения.
На графике
Массовый обрыв соединений · число подключений, число жалоб на роллбэк
Где смотреть
Сопоставить время падения или сбоя и время последнего сохранения персонажей, на которых пожаловались из-за роллбэка (лог сохранений игрового сервера или столбец времени изменения в БД)
Подтверждает
Момент, к которому вернулся персонаж, совпадает с последним сохранением перед падением, а потерянное время меньше интервала сохранения
Опровергает
Если в логе игрового сервера сохранение отмечено как завершённое, а прогресс всё равно вернулся назад, это потеря данных при переключении БД на резерв (db-failover) или старое значение, прочитанное с реплики (db-replica-lag)
Чем проверить
Нужны логи и метрики игрового сервера или клиента
Источники
Asynchronous Commit (PostgreSQL Documentation)PostgreSQL Если накапливать записи и сбрасывать их позже, производительность растёт, но при сбое могут пропасть самые последние транзакции (тот же компромисс)
Redis persistenceRedis Если делать снапшоты RDB раз в несколько минут, при аварийном завершении нужно быть готовым потерять данные за последние несколько минут