Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Российский разработчик игр
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
31
Эбиа

Эбиа

www.ebia.ru

23
Enlite

Enlite

enlited.ru

22
YAGLA

YAGLA

yagla.ru

15
likearea

likearea

smm.li

15
SE Ranking

SE Ranking

seranking.ru

14
Cookiezz

Cookiezz

cookiezz.com.ua

13
Venyoo

Venyoo

venyoo.ru

12
Perezvoni.com

Perezvoni.com

perezvoni.com

12
Reader

Reader

Интернет-журнал о современных технологиях.

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

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

196 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
Ответить
Офисофф
Онлайн сервис для бизнеса и бухгалтерии
Виталий
Не зацепило. И на спарке не так много мощных стартапов, которым нужна связка серверов. Основная масса обходится виртуальным или vps.
Ответить
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать