Я разрабатываю игру в реальном времени, которая должна вмещать тысячи игроков в режиме реального времени (FPS, как, макс. 1 с отставание). Какова будет лучшая инфраструктура для этого?
Моя идея заключалась в том, чтобы использовать 2 серверных кластера - один для серверной части (вся вычислительная сторона) и один для базы данных, где балансировщик нагрузки «отвечает» за каждый из кластеров. Один главный сервер будет получать запросы от пользователей и отправлять обратно IP-адрес соответствующего сервера, чтобы пользователь мог работать с этим.
Кластер базы данных будет использовать репликацию базы данных для согласованности между базами данных.
Должен быть также географический балансировщик нагрузки - так что он назначит региональный балансировщик нагрузки каждому пользователю для лучшего ответа.
Я использую .NET + MSSQL для игры.
Спасибо!
источник
Ответы:
Нет лучшей архитектуры, если вы не знаете больше о ваших требованиях, например. вид взаимодействий между персонажами, объем данных будет постоянным и т. д.
Если вы можете справиться с задержкой в 1 секунду, вы, вероятно, сможете без проблем разместить 1000 игроков на одном сервере - но это на самом деле противоречит идее FPS, поскольку они обычно требуют гораздо меньшую задержку, например. менее 100 мс Но система, которая может иметь дело с высокой задержкой, может позволить себе делать все через передачу сообщений, что делает последовательность довольно тривиальной. Предоставить свою логику довольно просто, то есть - сложная логика становится еще хуже, когда вы превращаете ее в систему, основанную на сообщениях, а не в систему с заблокированными объектами, - но все это зависит от потребностей вашего приложения.
Точно так же, если вы не сохраняете много данных, вам вообще не нужен компьютер базы данных, но, не зная этого, трудно сказать. Если вы сохраняете небольшие объемы данных и, возможно, делаете это только в конце турнира или еще чего-то, опять же вам не нужна отдельная база данных, конечно же, не их кластер. С другой стороны, если вы не много сохраняете, но много читаете, вот где вам могут помочь реплицированные базы данных, но это также указывает на то, что реляционная база данных может не совсем соответствовать вашей проблеме. Часто кэш в памяти является лучшим решением. Точно так же, если между персонажами нет взаимодействий в стиле транзакций, согласованность становится менее важной. (И если таких транзакций всего несколько, вы можете сделать их особым случаем.)
На самом деле, с осторожностью относитесь к внедрению СУБД только потому, что это делается в больших системах. Хотя я лично одобряю их использование в онлайн-играх, лучше взглянуть на ваши требования и выяснить вашу стратегию сохранения, а не брать предпочитаемую базу данных, а затем пытаться настроить ее с помощью кешей и репликации, чтобы она соответствовала вашим требованиям. приложение. Вы можете обнаружить, что все, что вам нужно, - это возможность создания отчетов в автономном режиме, и в этом случае, вероятно, лучше всего иметь фоновый процесс, регистрирующий ваш механизм сохранения игры в удаленной RDBMS где-то еще.
источник
Отказ от ответственности: мой опыт программирования игр основан на однопользовательских играх на стороне клиента, но у меня есть опыт работы с веб-приложениями (особенно в стеке Microsoft), так что вот откуда я пришел с этим ответом, я чувствую, что многое применить, но без реального тестирования реального игрового сервера трудно сказать, как он будет применяться, но здесь идет. Знайте это: я не развернул игровой сервер, только веб-приложения.
Я бы предложил двухуровневый (серверный) подход. Уровень базы данных и уровень «приложения»; третий (презентационный) уровень - ваш игровой клиент.
Реляционные базы данных хороши при запросе данных и хороши при записи данных. Ключ заключается в том, чтобы сериализовать записи в базу данных в куски управляемого размера, которые может обрабатывать ваш кластер. Более продвинутые выпуски (Центр обработки данных / Предприятие) SQL Server поддерживают кластеризацию и репликацию. Я бы начал с создания небольшого кластера и запуска нескольких запросов к нему, чтобы посмотреть, как он работает.
На уровне приложений, если вы делаете «зонирование» или что-то подобное, вы, вероятно, можете обойтись без настройки каких-либо кластеров и просто настроить сервер для каждой зоны. Если ваши зоны становятся большими, вы можете настроить кластер для каждой зоны.
Вы захотите построить процесс сериализации для отправки данных с уровня приложения -> уровня базы данных. Ключ должен иметь несколько уровней сериализации. Как то так :
Это будет держать ваши записи последовательными и предсказуемыми, в зависимости от характера вашей игры, вы можете иметь редкие записи в базу данных. Ключевым моментом является осознание того, что в случае сбоя сервера приложений вам придется возвращаться в оперативный режим из состояния вашей базы данных, поэтому сериализация инвентаря игроков каждые 90 минут может расстроить игроков.
Для чтения данных вы захотите загрузить как можно больше в память на уровне приложения, а затем убедиться, что весь ваш код использует этот пул памяти, в фоновом режиме вы можете синхронизировать пул памяти с базой данных. Как указывает Джо, будут моменты, когда вам понадобятся транзакции в режиме реального времени. Посредством сериализации большинства ваших записей у вас все еще должно быть достаточно ввода-вывода в вашей базе данных для выполнения транзакций в реальном времени, когда это необходимо, при условии наличия достаточного оборудования на сервере / кластере базы данных.
источник