Архитектура MMO сервера
Есть желание попробовать написать ММО клиент-сервер и хотелось бы начать с правильной архитектуры. Есть ли у кого опыт в таких делах?
Пока выделил следующие составляющие (деление на сервера): 1. Авторизация, лодбалансер, бизнес логика 2. Сервера зон/комнат 3. База данных Как-то так: Основной вопрос состоит в правильной структуре каждого из серверов. Тут пока опыта почти нет. Хотелось бы услышать мнение об этом у участников сообщества. |
Ответ: Архитектура MMO сервера
|
Ответ: Архитектура MMO сервера
pax
у меня есть некий опыт написания серверов которые работают, потому расскажу всякое сначала по терминам PCU - Peak Concurrent user, грубо говоря сколько сокетов переварит ваш сервак RPS - Requests Per Second, если обработка не упирается в цпу то это bandwidth/packet_size, при пакете в 5 кб и канале 100 мбит, RPS будет 2.5k (тысяч ! не миллионов) 1) собсно PCU это грубо говоря сколько сокетов может держать ОС, линукс сразу идет НАХ*Й, ибо говно там в сетевом стеке, берем FreeBSD, на всяких ерлангах одна машина (12 ядер, 128 гб рамы) тянет 2kk PCU 2) внизу сервер БД, замечательная штука да, а теперь представим что сверху у нас 100500 серверов, одновременно пытается играть 5 млн юзеров, везде что-то двигается, такая байда может нагенерить трафика на бд в районе 200-400 гб\s, можно конечно взять один йоба сервак, вставить туда 64 ядра, 512-1024 гб рамы и пидорасить тупо 10 ethernet карт по 40 гб\с, но это не выход =) а каналов по 400 гб\с щас ни у кого толком нету выход это использовать горизонтально масштабируемую бд, разделить их использование по контексту, например база профилей игроков для статистики, база профилей персонажей и их инвертаря и квестов, для каждого сектора локации отдельная бд плюс каждая бд должна бекапится, скажем если дядя дима прийдет к стойке с ломом и начнет пидорасить все серваки то хороший кластер должен это пережить, для этого используем взаимозаменяемые на лету серваки бд с полной репликацией для такой цели я рекомендовал бы большинство серверов ставить NoSQL, например MongoDB, и делать там реплики по 3 сервера и обязательно покупать реалтайм бекап (http://www.mongodb.com/press/10gen-a...backup-service мы этот юзаем, он бекапит журнал и потом можно восстановить любую точку во времени), но некоторые (статистика точно) должны быть SQL ибо к ним идут пидорские запросы наподобие "а дай мне топ 10 юзеров" который NoSQL не переваривает 3) авторизация и лобби, они ОЧЕНЬ топорные на логике, по-сути логики там нету, там даже не нужно постоянное подключение, это просто REST API, а если так то юзаем мощный веб-сервер, например Mongrel2 или NGINX, надо отдать должное этим монстрам и на среднем серваке они займут канал 10 гб\с полностью с всего ~10-25% CPU думаю тут описывать сильно не надо, код авторизации тупо является посредником между веб сервером и бд, лучше всего его написать на C и вшить прямо в код веб сервера (в то место где он CGI делает) делать балансер тут вообще нету смысла, разве что у тебя будет ОТДЕЛЬНАЯ СТОЙКА И ОТДЕЛЬНЫЙ СВИТЧ на это, единственный тип балансировки который взлетает на highload - ethernet balancing, то есть у нас N серваков у которых по две сетевые карты, одни карты торчат аплинком в мир, вторые карты торчат тупо в один лоу-латенси свитч, в этот свитч торчат все обработчики запросов, обработчики запросов тоже имеют по две карты (одна в свитч, другая аплинк), и когда на балансер приходит ip пакет с запросом то он у него меняет ethernet адресс ! таким образом наш чудо свитч по матрице комутации перекидывает пакет очень быстро, с помощью round-robin можно так забалансировать очень много трафика 4) сервера комнат, думаю надо банально ставить монстро-серваки по много ядер и много рамы, клиенты будут с ними конектится постоянно, потому тут всё зависит от контекста использования - ведь игровая логика бывает разная, всяким MMORPG надо коллизии считать например этим серверам нужно кешировать состояния мира чтобы не лазить в бд иначе слишком сильно увеличится латентность обработки запросов верх эволюции это горизонтальное масштабирование в рамках одной комнаты, но я такого не видел, например в EVE Online у них по серверу на звёздную систему, если в какой системе будет происходить бой то они вытягивают сервер помощнее из пула и запускают на нем эту систему думаю можно это отдельно обсудить если скажешь какой жанр игр нужно =) |
Ответ: Архитектура MMO сервера
Я сейчас изучаю эту тему. Сделал простенький сервер на node.js + socket.io
Клиент Unity3D + UnitySocketIO А вообще для MMO есть готовое решение на node.js Pomelo framework (схемы архитектуры) В Pomelo не вникал, показалось сложно. |
Ответ: Архитектура MMO сервера
Данных, которые нужно сохранять периодически в БД на самом деле не так и много- покупка чего то там, левел ап, шмот. Все остальные данные в реалтайме можно держать в комнате на аватаре игрока, и писать в бд при дисконнекте. http://habrahabr.ru/company/mailru/blog/182088/ тут интересно написано. socket.io юзает веб сокеты, как то не тру. Pomelo удобоваримо только для сессионных игр.
|
Ответ: Архитектура MMO сервера
Если использовать node.js для серверной логики, то тут есть плюсы и минусы. Плюсы начнём с того что это лёгкость в модифицируемости и скорость разработки - минусы, конечно C++ с правильными руками будет намного мощнее.
Но критические зоны, например коллизия и математика без проблем может быть вынесена в C++ Addon'ы (модули) для node.js, что также можно делать позже (но не слишком). Относительно сетевого трафика, тут по любому нужно писать свой сериализатор а не использовать тот же socket.io, т.к. унаследуешь кучу проблем от него, которые например Unity вообще не упали. Плюс если писать свой протокол, то можно нормально стримы заюзать от TCP, а не пакетно обрабатывать всё. Парсер снова, может быть вынесен на C++, и там уже генерить V8 объекты (JSON), которому node.js будет рад. Есть вот такой протокол, очень многообещающий: http://kentonv.github.io/capnproto/ Также очень зависит от архитектуры твоего игрового сервера. "ММО, МООшке рознь". Ты упомянул комнаты/зоны, речь идёт о разбиении мира на зоны (как в давние времена в WoW с предзагрузкой при переходах), или как в EVE, или речь идёт о матчах, как в LoL / Dota 2 / BF3 и т.п. играх? БД, как jimon сказал нужно качественно кластерить и иметь возможность восстановления реплик. БД использовать для редко нужных данных и периодическом сохранении данных, необходимых для восстановления игрового состояния. Большинство данных должно держаться в раме и там же оперироваться игровыми серверами, периодически паралельно сохраняя то что нужно в бд. Если сервера должны обмениваться данными между собой (сервера в плане процессов), то заводи redis, т.к. он очень эффективен для реалтайм быстрых транспортов. Redis - это реалтайм хранилище, подобно простой бд с разными плюшками. Если тебе нужно общаться между серверами напрямую - например lobby сервер может поискать игровые сервера, и если lobby имеет приоритет на игровыми, попросить игровой сервер на создание игровой комнаты. В подобной ситуации тебе нужно напрямую общаться между серверами. Тут я бы посоветовал ZeroMQ, он и прост и сложен. Просто для старта, и сложность заключается не в самой либе, а возможностях для сложных архитектурных решений коммуникации между процессами. Даже логин сервер - должен скейлиться. Авторизация - это побочный процесс, как addon в процессе, его задача получить данные логина, авторизировать/отклонить, и закинуть данные сессии в redis чтобы другие сервера/процессы могли получить эти данные, также сообщить запрашивающему процессу о статусе авторизации. Я бы также совмещал RESTful с Real-Time. Большинство должно быть как раз RESTful до игры, а сама игра Real-Time. Отличная практика для развития в этой сфере - это анализ существующих игр и их архитектуры. Вот список рекомендуемых примеров: EVE; FireFall; Dota 2 / LoL; BF3. Каждый из этих примеров утилизирует REST и RT везде. Что-то на REST'е, что-то на RT (realtime). |
Ответ: Архитектура MMO сервера
Спасибо отписавшимся, я пока не преследую планы по глобальному завоеванию мира, поэтому мои запросы примерно такие:
1. Допустим 5к игроков одновременно максимум. 2. Игровой мир это комнаты с загрузкой, не единый мир. 3. Сессии не длинные, по трафику допустим это шутер с числом игроков в комнате не превышающим 50-100 (в большинстве случаев будет меньше). 4. Основной геймплей - бои длительностью до 20-30 минут (к примеру WoT). |
Ответ: Архитектура MMO сервера
Цитата:
сетевые реалтайм шутера это как бы верх сетевых технологий, нужно будет юзать UDP, писать сложный предикшен и сервак с возможностью отката времени и тд, да и еще 100 человек, будет очень сложно обеспечить комфорт в игре, хотя написать чтобы заработало хоть как-то можно за пару недель всякие сетевые танки и самолетики куда проще делать ибо там игрок не меняет положение в пространстве очень резко |
Ответ: Архитектура MMO сервера
Цитата:
|
Ответ: Архитектура MMO сервера
Шутер я предположил по трафику, шутер я писать не буду. Я уже на проекте с роботами понял что синхронизация topdown шутера очень сложная. Надо делать всякие обманы чтобы выглядело нормально. Допустим это космосим (опять же к примеру) и летать надо не на истребителях, а на более тяжелых кораблях.
Цитата:
|
Ответ: Архитектура MMO сервера
pax
ну реально, если тебе хватит латентности в 200-500 мс для космосима типа EVE, то вполне можно напедалить простенький сервер на 100 человек на банальном C и сокетах, это ни какой либо rocket science уже, думаю 1 средний дедик потянет всех твоих 5к игроков (50 комнат) технологии довольно банальные, можешь взять TCP, вся игра происходит на сервере, а клиент просто отправляет на него действия, и потом их воспроизводит, нужно только добавить визуальную видимость того что действие типа началось происходить сразу после того как нажал так делают в большинстве MMO где не требуется моментальная реакция на перемещение игрока |
Ответ: Архитектура MMO сервера
Latency критичен только в играх где есть прямое взаимодействие между игроками - шутеры, топ-даун и т.п.
А игры с например целями Lineage, EVE и т.п. Latency не так критичен. Там даже можно иметь интерполяцию заместо экстраполяции, если нету никаких действий между игроками с элементами реакции, где от скорости реакции зависит прогресс игроков. Если это комнаты, то нужно думать над развёрткой серверов в разных регионах (дата-центрах), и обслуживать эти регионы по отдельности (по стандарту) с возможностью и на глобальных сервах играть. Если у тебя будет матч-мейкинг, то тут всё проблематично, т.к он с таким числом игроков просто не будет толком работать, нормальных матч-мейкинг с учётом рейтингов игроков и разными режимами игр и регионами требует миллионы игроков онлайн, чтобы не ждать по часу пока наберутся люди. Следственно изначально, либо без режимов игры и учёта рейтинга, и вообще на одном сервере, а потом если поднимается число пользователей, добавлять регионы и уже по стандарту обслуживать игроков с этих регионов. Так будет ниже Latency и игроки довольны будут. Либо сделать комнаты, в которые тупо можно присоединяться, заместо матчей где требуется набор игроков до начала игры. Но это зависит от гейм-дизайна, контра например такое позволяет, а вот LoL или Dota 2 или стратежки - уже нет. |
Ответ: Архитектура MMO сервера
Еще появилось два вопроса (не совсем связанных с mmo):
1. TCP пакеты доходят медленно. При пинге 32 мс пакеты доходят за ~270мс. Это так и должно быть или в коде вероятно проблемы? На локалхосте пакеты доходят за 5 мс. 2. Есть ли где статьи по реализации reliable udp? Есть желание попробовать написать такой протокол самому. |
Ответ: Архитектура MMO сервера
pax
1) не должно быть, разве что у тебя 50+% потерь пакетов, может ты просто буфер не флашишь чтобы ОС сразу отправляла пакеты ? 2) есть разные готовые реализации, посмотри на гитхаб к примеру https://github.com/search?q=reliabil...al&ref=cmdform |
Ответ: Архитектура MMO сервера
Есть ещё вариант с плохой сетью в которой пропадают пакеты, тогда пинг будет расти, из-за повторной отправки пропавших пакетов.
|
Часовой пояс GMT +4, время: 03:00. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot