Какова лучшая серверная архитектура для игр в реальном времени?

Я разрабатываю игру в реальном времени, которая должна вмещать тысячи игроков в режиме реального времени (FPS, как, макс. 1 с отставание). Какова будет лучшая инфраструктура для этого?

Моя идея заключалась в том, чтобы использовать 2 серверных кластера - один для серверной части (вся вычислительная сторона) и один для базы данных, где балансировщик нагрузки «отвечает» за каждый из кластеров. Один главный сервер будет получать запросы от пользователей и отправлять обратно IP-адрес соответствующего сервера, чтобы пользователь мог работать с этим.

Кластер базы данных будет использовать репликацию базы данных для согласованности между базами данных.

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

Я использую .NET + MSSQL для игры.

Спасибо!

server client-server .net

— Роман
источник

Когда вы говорите «инфраструктура», вы имеете в виду программное обеспечение, оборудование, услуги или вы просто хотите, чтобы мы критиковали ваш существующий план как есть?

— Тетрад

@Nate - мы планируем наращивать, а не дублировать, поэтому он должен быть полностью масштабируемым.

— Роман

-1 потому что teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html - Вы не покрываете какие-либо требования к емкости, вы говорите, что игра не разорвана, а зонирована и т. д. Характер оптимизации производительности, включая масштабируемость, требует конкретной информации, и не существует абсолютно лучшей архитектуры.

Я бы перефразировал ваш вопрос на что-то более конкретное. Что является «лучшим», фактическим, не субъективным способом? Вы имеете в виду самый простой в масштабировании, самый простой в управлении, самый легкий в работе, самый быстрый или что?

— Коммунистическая утка

«Самый простой» тоже субъективен. Легче всего для кого, за какой срок, с учетом каких ресурсов? Обмен стеками лучше всего работает с конкретными вопросами: «Я построил этот сервер с использованием LINQ и MSSQL, но он упал после 70 транзакций в секунду. Вот мои две верхние транзакции составляют 73% времени выполнения, как мне увеличить пропускную способность? "

Ответы:

Нет лучшей архитектуры, если вы не знаете больше о ваших требованиях, например. вид взаимодействий между персонажами, объем данных будет постоянным и т. д.

Если вы можете справиться с задержкой в 1 секунду, вы, вероятно, сможете без проблем разместить 1000 игроков на одном сервере - но это на самом деле противоречит идее FPS, поскольку они обычно требуют гораздо меньшую задержку, например. менее 100 мс Но система, которая может иметь дело с высокой задержкой, может позволить себе делать все через передачу сообщений, что делает последовательность довольно тривиальной. Предоставить свою логику довольно просто, то есть - сложная логика становится еще хуже, когда вы превращаете ее в систему, основанную на сообщениях, а не в систему с заблокированными объектами, - но все это зависит от потребностей вашего приложения.

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

На самом деле, с осторожностью относитесь к внедрению СУБД только потому, что это делается в больших системах. Хотя я лично одобряю их использование в онлайн-играх, лучше взглянуть на ваши требования и выяснить вашу стратегию сохранения, а не брать предпочитаемую базу данных, а затем пытаться настроить ее с помощью кешей и репликации, чтобы она соответствовала вашим требованиям. приложение. Вы можете обнаружить, что все, что вам нужно, - это возможность создания отчетов в автономном режиме, и в этом случае, вероятно, лучше всего иметь фоновый процесс, регистрирующий ваш механизм сохранения игры в удаленной RDBMS где-то еще.

— Kylotan
источник

Отказ от ответственности: мой опыт программирования игр основан на однопользовательских играх на стороне клиента, но у меня есть опыт работы с веб-приложениями (особенно в стеке Microsoft), так что вот откуда я пришел с этим ответом, я чувствую, что многое применить, но без реального тестирования реального игрового сервера трудно сказать, как он будет применяться, но здесь идет. Знайте это: я не развернул игровой сервер, только веб-приложения.

Я бы предложил двухуровневый (серверный) подход. Уровень базы данных и уровень «приложения»; третий (презентационный) уровень - ваш игровой клиент.

Реляционные базы данных хороши при запросе данных и хороши при записи данных. Ключ заключается в том, чтобы сериализовать записи в базу данных в куски управляемого размера, которые может обрабатывать ваш кластер. Более продвинутые выпуски (Центр обработки данных / Предприятие) SQL Server поддерживают кластеризацию и репликацию. Я бы начал с создания небольшого кластера и запуска нескольких запросов к нему, чтобы посмотреть, как он работает.

На уровне приложений, если вы делаете «зонирование» или что-то подобное, вы, вероятно, можете обойтись без настройки каких-либо кластеров и просто настроить сервер для каждой зоны. Если ваши зоны становятся большими, вы можете настроить кластер для каждой зоны.

Вы захотите построить процесс сериализации для отправки данных с уровня приложения -> уровня базы данных. Ключ должен иметь несколько уровней сериализации. Как то так :

Уровень 1. Сохранение в БД каждые X секунд, включая критические данные:
- Здоровье игрока
- Предметы игрока / пикапы
Уровень 2. Сохранение в БД каждые 2X секунды, включает средние данные:
- Расположение игроков
- Локации NPC
Уровень 3: Все остальное, как можно реже

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

Для чтения данных вы захотите загрузить как можно больше в память на уровне приложения, а затем убедиться, что весь ваш код использует этот пул памяти, в фоновом режиме вы можете синхронизировать пул памяти с базой данных. Как указывает Джо, будут моменты, когда вам понадобятся транзакции в режиме реального времени. Посредством сериализации большинства ваших записей у вас все еще должно быть достаточно ввода-вывода в вашей базе данных для выполнения транзакций в реальном времени, когда это необходимо, при условии наличия достаточного оборудования на сервере / кластере базы данных.

— Nate
источник

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

В то время как разреженный, это - то, к чему я шел в последнем параграфе. Я рекомендую немного гибрид, где вы используете IN-Memory, где это возможно, и базу данных, когда это необходимо.

— Nate

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

Правда, хотя речь шла об архитектуре больших картинок, а не о деталях реализации.

— Nate

Правда, но вы оставили весь средний уровень. Это RDB с низкой задержкой? ODB? Ключ / значение хранилища? Нет БД и отказаться от ACID? СТМ или блокировка? Чтобы быть справедливым, очень трудно ответить на этот вопрос, потому что в вопросе не так много информации, но все, что этот ответ делает с диаграммой архитектуры, - это взять большой пузырь в середине с "?" в нем и подключите к нему еще две службы, а не на самом деле заполните, что "?" является.