Главное Авторские колонки Вакансии Образование
444 2 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Распределение нагрузки или как избежать неприятных падений

Наш опыт разработки серверных решений для высоконагруженных MMO
Мнение автора может не совпадать с мнением редакции

Немного истории

В 2013 году, занимаясь разработкой эмулятора сервера одной популярной MMO-FPS, перед нашей командой встал вопрос распределения нагрузки на сервер.

Спустя несколько недель дискуссий мы решили разделить три основных сервера(Auth/Game/Battle) на множество мелких серверов, падение которых было бы не смертельным для игрового клиента.

Ближе к делу

Таким образом, у нас появились следующие сервера:

  • LoginServer(TCP)

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

  • MasterServer(TCP)

На мастер-сервер клиент попадает только в случае успешной авторизации на LoginServer. И... сразу же перенаправляется на ближайший к себе(клиенту) GameServer.

  • GameServer(TCP)

Самый нагруженный среди всех серверов. На нем игрок попадал к списку каналов сервера, после выбора канала - в лобби.

  • ShopServer(TCP)

"Исчезновение предметов из игрового магазина в случае падения ShopServer'а особо никого не может напугать, да и поднять если что - успеем." - примерно с таким лозунгом мы приняли решение о создании отдельного сервера для внутриигрового магазина.

  • ClanServer(TCP)

Подключение происходило при входе в меню кланов - клиенту отправлялась информация о его клане(в случае, если игрок находился в клане) или список кланов(в случае, если игрок не находился в клане). Так-же было доступно создание клана/Управление кланом/Удаление клана.

  • ChatServer(TCP)

Обмен сообщениями как в лобби/комнате, так и прямо во время боя.

  • BattleServer(UDP)

На боевой сервер отправлялась информация о созданной на канале GameServer'а комнате, информация о лидере. Так-же происходил обмен пакетами с информацией о местонахождении игроков в бою.

Одна важная деталь

Все сервера, помимо LoginServer'а и MasterServer'а дублировались для каждого "мира", а так-же работали синхронно между "мирами" - игрок мог перейти с одного "мира" на другой без потери какой-либо информации.

Извлекаем важное

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

Плюсы

  • Падение одного сервера из цепи не смертельно
  • Распределение нагрузки
  • Небольшие обновления/хотфиксы без отключения всего проекта на тех.работы
  • Риск падения серверов от высокой нагрузки уменьшается в разы

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Art-Booking
Платформа для организации мероприятий
Dmitriy Mandrika
Вода какая то. Ни слова о методиках балансировки (Round robin, Observed, Fastest и т. д.), причинах выбора стратегии и т. д.
Есть старенькая, но более познавательная статья "A Distributed Architecture for Online Multiplayer Games" https://www.cs.cmu.edu/~ashu/papers/nsdi2006.pdf
Ответить
Офисофф
Онлайн сервис для бизнеса и бухгалтерии
Виталий 18511
Не зацепило. И на спарке не так много мощных стартапов, которым нужна связка серверов. Основная масса обходится виртуальным или vps.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.