Комментарии 76
Тематика очень интересна. Нещадно плюсую.
да, пожалуй будет интересно почитать продолжение
Тема интересная, статья ниочём.
Было бы интересно почитать про реализацию work-демона и то, как он общается с обработчиком запросов.
Было бы интересно почитать про реализацию work-демона и то, как он общается с обработчиком запросов.
Тема очень интересна, всеми руками за цикл статей.
тема очень интересная, хотелось бы увидеть статьи с примерами кода, по возможности.
Интересно!
Интересно мнение автора о использовании в качестве сервера связки php-java, php для магазинов и прочего, что требует сравнительно небольшого числа запросов к серверу, а java для закликивания монстров, беготне по картам и прочего.
ИМХО
если игра браузерная, java имеет смысл использовать для чата и боёвки. Эти «модули» требовательны к синхронизации и держанию в памяти большого числа объектов. Хотя можно обойтись без java совсем.
Если игра имеет клиент — самое просто использовать Servlets — не надо писать сетевую часть — только протокол.
Кстати, применение key-value хранилищь с кэшированием избавлят от надобности хранить состояние игроков. При этом нужно не забывать, что если вы в своём приложении храните состояние какого либо объекта — вы должны гарантировать, что при падении приложения состояние будет сохранено. В случае игр — это критично, потому что, если потеряется артовая вещь купленная за реальные деньги, получится как то некрасиво.
если игра браузерная, java имеет смысл использовать для чата и боёвки. Эти «модули» требовательны к синхронизации и держанию в памяти большого числа объектов. Хотя можно обойтись без java совсем.
Если игра имеет клиент — самое просто использовать Servlets — не надо писать сетевую часть — только протокол.
Кстати, применение key-value хранилищь с кэшированием избавлят от надобности хранить состояние игроков. При этом нужно не забывать, что если вы в своём приложении храните состояние какого либо объекта — вы должны гарантировать, что при падении приложения состояние будет сохранено. В случае игр — это критично, потому что, если потеряется артовая вещь купленная за реальные деньги, получится как то некрасиво.
>и этом нужно не забывать, что если вы в своём приложении храните состояние какого либо объекта — вы должны гарантировать, что при падении приложения состояние будет сохранено.
Тоже думал над этой проблемой. Причём не только приложения падения, а сервера в целом (электричество кончилось). Пока пришёл к логированию всех запросов (протокол HTTP) на раздел/диск с отключенным кэшированием записи. Если сервер падает, то после подъёма блокируем входящие запросы (клиентам выдаём 503), находим последний обработанный (результаты транзакции сохранены в БД) запрос и обрабатываем оставшиеся, после чего включаем фронтенд.
Тоже думал над этой проблемой. Причём не только приложения падения, а сервера в целом (электричество кончилось). Пока пришёл к логированию всех запросов (протокол HTTP) на раздел/диск с отключенным кэшированием записи. Если сервер падает, то после подъёма блокируем входящие запросы (клиентам выдаём 503), находим последний обработанный (результаты транзакции сохранены в БД) запрос и обрабатываем оставшиеся, после чего включаем фронтенд.
Про java ничего не могу сказать, опыт работы с ней не позволяет ее сравнить с другими языками.
В целом, используемый язык не сильно решает, гораздо важнее опыт и навыки его использования.
В целом, используемый язык не сильно решает, гораздо важнее опыт и навыки его использования.
На чистой джаве если писать — то достаточно быстро и разрабатывать, и по ресурсо-затратам мало выйдет.
Если же брать application server (Jboss, Glassfish) — то тут потребуется более дорогой сервер (не сильно, но всё же)
Оптимально взять apache, jetty — быстро, надёжно, требуется меньше ресурсов чем для AS.
Если же брать application server (Jboss, Glassfish) — то тут потребуется более дорогой сервер (не сильно, но всё же)
Оптимально взять apache, jetty — быстро, надёжно, требуется меньше ресурсов чем для AS.
Есть решение на Java — RedDwarf Server, в прошлом, когда Оракл еще не купил Сан и не закрыла проект, он назывался Project Darkstar. Достаточно интересная штука.
>Самый главный недостаток реализации: PHP течет.
unset делается где нить в коде? ;)
unset делается где нить в коде? ;)
Конечно интересно, пишите! Хотелось бы конечно побольше про Эрланг.
>Самый главный недостаток реализации: PHP течет.
Мы одно время тоже боролись с утечкой памяти. В результате уяснили следующее. Сам интрпретатор как приложение не течёт (ну по крайней мере тот, что был у нас). Утекает только память выделяемая для работы скрипта. Мы влючили логирование в конструкторах и деструкторах и обнаружили забавную вещь — не вызываются деструкторы некоторых объектов на которые больше нет ссылок. Однако если сделать unset всем полям объекта, то объект разрушается. Потому мы дописали объектам вот такой метод. Перед unset дёргаем его
После добавления такого костыля память перестала течь
Мы одно время тоже боролись с утечкой памяти. В результате уяснили следующее. Сам интрпретатор как приложение не течёт (ну по крайней мере тот, что был у нас). Утекает только память выделяемая для работы скрипта. Мы влючили логирование в конструкторах и деструкторах и обнаружили забавную вещь — не вызываются деструкторы некоторых объектов на которые больше нет ссылок. Однако если сделать unset всем полям объекта, то объект разрушается. Потому мы дописали объектам вот такой метод. Перед unset дёргаем его
function _destroy() {
foreach($this as $propName => $propValue) {
unset($this->$propName);
}
} После добавления такого костыля память перестала течь
В своей первой версии обработчика у меня, как ни странно, PHP тоже не тек, потом черт дернул его переписать и для работы с БД использовать Doctrine 1.2, после чего началось. На текущий момент произвожу рефакторинг и отказ от ORM — посмотрим, что выйдет.
Основной демон (который не работает с БД), кстати, не течет, а вот worker's…
Основной демон (который не работает с БД), кстати, не течет, а вот worker's…
Считаю, реализацию демонов на скриптовых языках не верной: зачем тратить ресурсы на интерпретатор, когда можно написать свой демон на C/C++.
Для игры по сути нужены: сокеты, конекшен к базе и мьютексы. В пхп — это обёртки и не всегда хорошо реализованные драйвера БД.
Для игры по сути нужены: сокеты, конекшен к базе и мьютексы. В пхп — это обёртки и не всегда хорошо реализованные драйвера БД.
Согласен, только есть пару минусов:
— гораздо большие трудозатраты
— для этого нужно, как минимум, несколько лет опыта разработки на языке, чтобы гарантировать качественный код, который не будет падать в segmentation fault от любого чиха
— гораздо большие трудозатраты
— для этого нужно, как минимум, несколько лет опыта разработки на языке, чтобы гарантировать качественный код, который не будет падать в segmentation fault от любого чиха
Ну… что бы писать программы надо быть программистом =)
Да и для построения демонов на С++, я думаю, если библиотеки
Да и для построения демонов на С++, я думаю, если библиотеки
Для серверной части можно использовать Charm++ — надмножество С++. Тут и Load Balancing, и миграция объектов, и Message Passing, и чего только нет. Плюс очень масштабируемое решение.
А вы попробуйте на достаточно высокоуровневом frameworke написать. Тот же Qt даже.
Был опыт переписывания демона с php на Qt. Итоговый вариант содержал даже меньшее количество строк кода.
Был опыт переписывания демона с php на Qt. Итоговый вариант содержал даже меньшее количество строк кода.
А мьютексы зачем?
Да, продолжение было бы интересным.
На данный момент из виденных мною архитектур мне больше всего нравится RedDwarf. Но почитать другой взгляд тоже будет интересно и полезно.
Правильно ли я понимаю, что в вашей игре монстры не двигаются и все происходит пошагово? Если нет, то расскажите, плз, в т.ч. и о том, как вы программировали изменения мира, которые не зависят от игрока. Ну или как программировали бы, если бы стали добавлять это в вашу архитектуру.
На данный момент из виденных мною архитектур мне больше всего нравится RedDwarf. Но почитать другой взгляд тоже будет интересно и полезно.
Правильно ли я понимаю, что в вашей игре монстры не двигаются и все происходит пошагово? Если нет, то расскажите, плз, в т.ч. и о том, как вы программировали изменения мира, которые не зависят от игрока. Ну или как программировали бы, если бы стали добавлять это в вашу архитектуру.
Нити в PHP? С каких пор? Или вы подразумеваете все же процессы/форки? Если процессы, то как организовано взаимодействие между ними?
Прощу прощения за некоторую путаницу. Форки, конечно, PCNTL.
Взаимодействие непосредственно между воркерами не происходит, в этом нет необходимости.
Подробнее про взаимодействие я расскажу в следующих постах.
Взаимодействие непосредственно между воркерами не происходит, в этом нет необходимости.
Подробнее про взаимодействие я расскажу в следующих постах.
расставить unset, заменить все foreach, отслеживать циклические ссылки, логировать память при всех созданиях и уничтожениях объектов (сколько пришло — столько ушло). и бить разработчикам по рукам, если они не делают этого. при соблюдении таких не хитрых техник все течи исчезнут.
проверено — демоны на либевенте не текут (ничего не могу говорить за phpDaemon, мы делали сами свою реализацию).
проверено — демоны на либевенте не текут (ничего не могу говорить за phpDaemon, мы делали сами свою реализацию).
У меня тоже своя реализация.
Основной обработчик не течет, текут воркеры, которые работают с БД.
Из тестов — течет используемая ORM (Doctrine 1.2). Пытался ее пилить вдоль и поперек, но никак… оказалось проще от нее отказаться.
Основной обработчик не течет, текут воркеры, которые работают с БД.
Из тестов — течет используемая ORM (Doctrine 1.2). Пытался ее пилить вдоль и поперек, но никак… оказалось проще от нее отказаться.
зачем орм в таких проектах?? если течет доктрина, почему пишите, что течет РНР?
и вообще — есть ли реальная необходимость форкаться? нам производительности однопоточного демона вполне хватало даже на обсчет боев. к тому же форк не позволяет воспользоваться преимуществом использования уже готовых объектов, которые не нужно инициализировать. мы вообще в базу ходили фактически только при логине нового игрока, да когда сохраняли состояния измененных объектов (раз в N минут).
и вообще — есть ли реальная необходимость форкаться? нам производительности однопоточного демона вполне хватало даже на обсчет боев. к тому же форк не позволяет воспользоваться преимуществом использования уже готовых объектов, которые не нужно инициализировать. мы вообще в базу ходили фактически только при логине нового игрока, да когда сохраняли состояния измененных объектов (раз в N минут).
Согласен, ORM не нужен, но это те грабли, на которые я наступил.
Про текучесть PHP — это скорее крик души, так как были проблемы в других проектах.
А какая нагрузка у вас? Какого рода приложение?
Необходимость форкаться есть тогда, когда повышается нагрузка. Конечно, все зависит от ситуации и наличия узких мест.
Про текучесть PHP — это скорее крик души, так как были проблемы в других проектах.
А какая нагрузка у вас? Какого рода приложение?
Необходимость форкаться есть тогда, когда повышается нагрузка. Конечно, все зависит от ситуации и наличия узких мест.
у нас была mmorpg. однопоточный демон вполне способен был держать до нескольких тысяч человек в онлайне (демон боев — может чуть меньше), далее — мы закладывали баллансировку нагрузки по идентичным демонам (например, когда бы демон локаций перестал бы справляться — подняли бы второго и часть локаций обслуживал бы уже новый). а необходимость форкаться — это следствие выбранной архитектуры, для реализаций игр, исходя из нашей практики, она не нужна.
сам по себе php не течет. Тоже как и другие удивился использованию ORM — это же такой удар по памяти. Я бы даже задумался насчет целесообразности использования PDO, а уж про обертки поверх него можно сразу забыть. Кстати, драйверы PDO тоже надо проверять на лики. MSSQL драйвер для PDO течет как х.з. что — решето.
в качестве DB можно было что-то не реляционное посмотреть, кстати. Mongo, например, быстрая и гибкая штука, которая легко маcштабируется.
в качестве DB можно было что-то не реляционное посмотреть, кстати. Mongo, например, быстрая и гибкая штука, которая легко маcштабируется.
… выстрелить себе в ногу.
Мне выпало однажды испытание написать сервер для маленькой ММОРПГ на однопоточном PHP-демоне. Мало того что я был полным нубом в этом деле, так эта проблема помножилась на уродство PHP. Не делайте этого, пишите на яве, даже если её не знаете. Ну или на каком-нибудь Go, говорят он заточен для этого.
Эх… немного опередили меня… )))
Готовил похожую статью только с реализацией на Scala…
Теперь вот даже не знаю, стоит ли постить…
Готовил похожую статью только с реализацией на Scala…
Теперь вот даже не знаю, стоит ли постить…
Тема интересная, статья тему не реализует. Вот если бы кто действительно написал про написание серверной части для сетевых игр, с расчётом на _действительно_ высокие нагрузки, используя, мхм, более подходящий язык, объясняя какие-либо неочевидные для выходца из другой специфики вещи… Ах, вот это было бы чтиво!
проблема не в языке, а в других частях тела :)
Не имею ничего против PHP, но, пардон, уместность этого инструмента для высоконагруженного сервера? Мне кажется, на борьбу за производительность уйдёт больше усилий, чем на хороший стиль в том же С++. Опять же, Erlang был бы любопытен.
Дело, опять же, не в языке, а в том, что сервер как таковой — это скучно и тривиально. Интересно было бы почитать про нюансы архитектуры при нагрузках в духе WoW ( сотрудники Blizzard нигде не распространялись, кстати? :) ).
Дело, опять же, не в языке, а в том, что сервер как таковой — это скучно и тривиально. Интересно было бы почитать про нюансы архитектуры при нагрузках в духе WoW ( сотрудники Blizzard нигде не распространялись, кстати? :) ).
а что для вас "_действительно_ высокие нагрузки" в цифрах? :)
Думаю, начиная со 100 000 online + real-time gameplay ( браузерные пошаговки априори неинтересно )
наши демоны на связке php+libevent способны были держать несколько тысяч в онлайне. 100 тысяч — это десяток серверов, совсем не много. доходы от игры, где 100 тыс в онлайне, позволят сделать корпуса таких серверов из золота ;) технически сделать не так сложно, гораздо сложнее этих 100 тысяч привлечь и удержать.
а поддержка/отладка + развитие кода такой же игры на С++ обойдется гораздо дороже.
а поддержка/отладка + развитие кода такой же игры на С++ обойдется гораздо дороже.
Так организация масштабируемого кластера и есть один из пунктов «интересного»: ) Вне зависимости от языка. Так, чтобы с ростом количества нодов, накладные расходы на коммуникации не испортили всё. Особенность MMORPG при этом ещё в жестких требованиях к времени отклика.
Поддержка на С++ обойдётся дороже исключительно на разницу в зарплате программистов — это вполне себе его стихия. Впрочем, заметьте, я предлагал именно в контексте Erlang писать, а не учить С++ :) ( Кто сказал D? )
Поддержка на С++ обойдётся дороже исключительно на разницу в зарплате программистов — это вполне себе его стихия. Впрочем, заметьте, я предлагал именно в контексте Erlang писать, а не учить С++ :) ( Кто сказал D? )
По поводу Erlang в игровых серверах — вот интересная свежая презенташка есть www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf и в этом отчете пару упоминаний про игры есть erlanger.ru/page/1607/erlang-factory-2011-london-otchet-part-i
100К онлайна есть у очень небольшого количества игр. Обычно такого масштаба проекты или на коммерческом движке, или самописном иногда.
Снова таки, смотря о каких играх говорить. Браузерки это одно, социалки флешевые — другое. Да и от жанра зависит много — эконом-стратегия может легко работать на обычной LAMP связке, 3д мультиплеерный шутер уже совсем другое.
Снова таки, смотря о каких играх говорить. Браузерки это одно, социалки флешевые — другое. Да и от жанра зависит много — эконом-стратегия может легко работать на обычной LAMP связке, 3д мультиплеерный шутер уже совсем другое.
Именно поэтому про это было бы интересно почитать — практический опыт такого рода на дороге не валяется. Про жанр я же сказал — real-time gameplay, необходимость обновления остояния по нескольку раз в секунду. Шутер, рпг, ртс.
Почитайте блоги CCP про EVE Online — возможно будет интересно, есть русские переводы на фан-форуме. 100к кажется онлайна не было, но 50к+ было (на одном «сервере» — афаик, многие популярные MMOG считающиеся с онлайном в десятки к на самом деле представляют собой несколько невзаимодействующих миров — в Еве не так, все на одном сервере и могут взаимодействовать, находясь на разных концах вселенной).
Ха-ха-ха. Вы бы сначала озадачились вопросом синхронизации в релтайм играх, а потом уже про балансировку нагрузки и архитектуру спрашивали. Поверьте уж, «сервер как таковой — это скучно и тривиально.» — очень далеко от истины в случае релтаймовых игр. Сделайте хотя бы «сервачок» для 16 игроков релтаймовых и потом уже можно будет начинать разговоры в духе — «хех, сервер это тривиально».
вы вообще представляете, что такое синхронизации и десинхронизация? А насколько качественно реализована интерполяция?
вы вообще представляете, что такое синхронизации и десинхронизация? А насколько качественно реализована интерполяция?
Многих от опиания подробностей останавливает количество копипастящей школоты…
По крайней мере так высказывалось несколько моих знакомых:
«Сегодня ты им со всеми подробностями разложишь про сервер для игры, а завтра количество говноигр вырастет в разы...»
«Дело, опять же, не в языке, а в том, что сервер как таковой — это скучно и тривиально.»
Сам сервер (т.е. часть отвечающая за авторизацию, обмен информацией с клиентами, хранение данных игры) действительно скучно и тривиально…
А вот когда в реалтайме пытаешься заставить работать тысячи клиентов… и что бы без телепортов и успеть обсчитать кучу всего от читеров и т.д. и т.п. вот тут уже одной статьей просто так не опишешь…
Борьба с читерами это вообще почти как вид спорта… кто кого )))
По крайней мере так высказывалось несколько моих знакомых:
«Сегодня ты им со всеми подробностями разложишь про сервер для игры, а завтра количество говноигр вырастет в разы...»
«Дело, опять же, не в языке, а в том, что сервер как таковой — это скучно и тривиально.»
Сам сервер (т.е. часть отвечающая за авторизацию, обмен информацией с клиентами, хранение данных игры) действительно скучно и тривиально…
А вот когда в реалтайме пытаешься заставить работать тысячи клиентов… и что бы без телепортов и успеть обсчитать кучу всего от читеров и т.д. и т.п. вот тут уже одной статьей просто так не опишешь…
Борьба с читерами это вообще почти как вид спорта… кто кого )))
Многовато копипастить придётся бедной школоте, может в процессе чему и научится :)
боюсь что про реалтайм сервер даже для сотни игроков одной статьей не отделаться. слишком много моментов которые надо предусмотреть. обычно «напиши статью как сделать сервер» говорят те, кто ни разу не пробовал писать. Пошаговые штуки куда проще делать и для этого общими словами в виде одной статьи можно.
интересно также прочитать про создание TCP сервера для высого нагружённых серверов (eve-online, WOW, ...). Там тоже всё весьма запутано, я так и не нашел нормального примера на просторах инета.
Мы в нашей игре используем точно такой же подход. Все операции, для которых строго важна очерёдность, выполняем на едином однопоточном сервере, который назвали sync (сервер для синхронных действий). Надо понимать, что, построив такую архитектуру, мы навсегда гарантированно избавились от гонок, но, с другой стороны, ввели в систему узкое место — теперь если какой-то запрос выполняется с задержкой, то эту задержку испытывают ВСЕ игроки, которые в то же время что-то хотят от игры. Субъективное ощущение у игроков — что игра тормозит.
Теперь о том, как это получилось. После того, как был сделан прототип архитектуры, синтетические тесты показывали отличные результаты — десяток тысяч пользователей на одном шарде — как нечего делать. Но дело в том, что в онлайн-игре синхронизации потребовало огромное количество самых различных действий. Например, один персонаж нападает на другого, а последний успел в последний момент слинять в соседнюю локацию. Система должна обеспечить жёсткую синхронизацию этих действий — либо успел уйти, либо начался бой. И никак иначе. Другая ситуация — игрок A видит, что игрок B ходит голый и решает его побить. В момент нападения A внезапно одевается. И должна быть чёткая последовательность — либо A успел одеться, либо в бою у него низкие характеристики, и никак иначе. Потом ситуация с ограблением — если один персонаж нападает на другого с целью ограбить, а последний прямо перед боем покупал что-то в магазине. Должна быть соблюдена чёткая очерёдность — либо деньги успели списаться со счёта, товары попасть в инвентарь, и ограбление удалось, либо торговля не успела пройти и грабитель остался без добычи. Ну и т.д.
Количество различных действий, которые требуют синхронизации, росло в таких немыслимых количествах, что наш sync начал захлёбываться под нагрузкой. И в реальности на онлайне 300 сервер начинает адски тормозить. Точнее работает, но на любой затормозившей операции (транзакции по передаче большого количества предметов, например) сервер блокирует игру на несколько секунд.
Сейчас приходится разбирать этого монстра обратно — отпиливать все тяжёлые операции, выносить их на фронтенды. Фронтенды синхронизируем мьютексами на memcached. И хотя в систему вносится потенциальная возможность гонок (в редких случаях), успешному оперированию игры это не мешает.
В общем, архитектура жизнеспособная, но очень важно, чтобы синхронные операции были крайне лёгкими, а при расширении мира можно было этот сервер горизонтально отмасштабировать, перебросив на него часть нагрузки. Возможно, для этого придётся мир разделить на условные зоны, между которыми персонажи взаимодействовать не могут.
Теперь о том, как это получилось. После того, как был сделан прототип архитектуры, синтетические тесты показывали отличные результаты — десяток тысяч пользователей на одном шарде — как нечего делать. Но дело в том, что в онлайн-игре синхронизации потребовало огромное количество самых различных действий. Например, один персонаж нападает на другого, а последний успел в последний момент слинять в соседнюю локацию. Система должна обеспечить жёсткую синхронизацию этих действий — либо успел уйти, либо начался бой. И никак иначе. Другая ситуация — игрок A видит, что игрок B ходит голый и решает его побить. В момент нападения A внезапно одевается. И должна быть чёткая последовательность — либо A успел одеться, либо в бою у него низкие характеристики, и никак иначе. Потом ситуация с ограблением — если один персонаж нападает на другого с целью ограбить, а последний прямо перед боем покупал что-то в магазине. Должна быть соблюдена чёткая очерёдность — либо деньги успели списаться со счёта, товары попасть в инвентарь, и ограбление удалось, либо торговля не успела пройти и грабитель остался без добычи. Ну и т.д.
Количество различных действий, которые требуют синхронизации, росло в таких немыслимых количествах, что наш sync начал захлёбываться под нагрузкой. И в реальности на онлайне 300 сервер начинает адски тормозить. Точнее работает, но на любой затормозившей операции (транзакции по передаче большого количества предметов, например) сервер блокирует игру на несколько секунд.
Сейчас приходится разбирать этого монстра обратно — отпиливать все тяжёлые операции, выносить их на фронтенды. Фронтенды синхронизируем мьютексами на memcached. И хотя в систему вносится потенциальная возможность гонок (в редких случаях), успешному оперированию игры это не мешает.
В общем, архитектура жизнеспособная, но очень важно, чтобы синхронные операции были крайне лёгкими, а при расширении мира можно было этот сервер горизонтально отмасштабировать, перебросив на него часть нагрузки. Возможно, для этого придётся мир разделить на условные зоны, между которыми персонажи взаимодействовать не могут.
Хм… а вы не перемудрили с синхронными операциями, что у вас на 300 ccu сервер не тянет?
Какова конфигурация сервера и на чем писали?
Какова конфигурация сервера и на чем писали?
У нас вся передача предметов, расчёт характеристик персонажей перед боем (а это тоже загрузка инвентаря, характеристик предметов), появление на локации растений, их удаление, перемещение персонажей, включая рассылку остальным клиентам информации о перемещениях — всё это легло на sync. По поводу «не тянет» я неправильно выразился. Тянуть оно тянет и 1000 — и наверное и выше сможет. Проблема в том, что задержка в 2-3 секунды у одного игрока автоматически блокирует всех остальных игроков на 2-3 секунды. А чем больше игроков, тем чаще эти провисания случаются. И это системный недостаток архитектуры. Железо нормальное — Xeon 3.2 ГГц.
Вообще да, перемудрили однозначно. Я поэтому и предостерегаю читателей, чтобы по нашим граблям не пошли. Ничего тяжёлого, никакого доступа к нагруженной БД там быть не должно.
С интересом жду следующей части.
картинки не видны (
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация серверной части в многопользовательских онлайн играх