Яка найкраща архітектура сервера для ігор у режимі реального часу?

Я розробляю гру в режимі реального часу, яка повинна містити тисячі гравців у режимі реального часу (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 лише тому, що це зроблено у великих системах. Хоча я особисто схвалюю їх використання в онлайн-іграх, краще переглянути ваші вимоги та розібратися з вашою стратегією наполегливості, а не брати бажану базу даних, а потім намагатися підлаштувати її кешами та реплікацією, щоб вона відповідала вашим додаток Ви можете виявити, що все, що вам потрібно, - це можливість звітування в режимі офлайн, і в цьому випадку, мабуть, найкраще мати фоновий процес реєстрації із механізму збереження ігор у віддалений RDBMS десь в іншому місці.

— Kylotan
джерело

Відмова: мій досвід програмування ігор базується на іграх на базі одного гравця на стороні клієнта, але я маю досвід роботи в веб-додатках (зокрема, на стеку Microsoft), тому саме звідки я надходжу з цією відповіддю, я відчуваю, що багато чого застосувати, але без фактичного тестування справжнього ігрового сервера важко сказати, як це застосовуватиметься, але тут ідеться. Знайте це: я не розгорнув ігровий сервер, а лише веб-сторінки.

Я б запропонував дворівневий (серверний) рівень підходу. Рівень бази даних та рівень "програми"; третій (презентаційний) рівень - ваш ігровий клієнт.

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

У ярусі додатків, якщо ви робите "зонування" чи щось подібне, ви, ймовірно, можете піти, не налаштовуючи жодних кластерів, і просто налаштувати сервер на зону. Якщо ваші зони стануть великими, ви можете встановити кластер для кожної зони.

Ви хочете побудувати процес серіалізації для надсилання даних із рівня рівня програми -> бази даних. Ключовим є те, що триває кілька рівнів серіалізації. Що - то на кшталт цього:

Рівень 1: Зберігання в БД кожні X секунд, включає критичні дані:
- Здоров'я гравця
- Предмети гравця / пікапи
Рівень 2: Зберігання в БД кожні 2X секунди, включає середні дані:
- Місцезнаходження гравця
- Місце розташування NPC
Рівень 3: Все інше, як можна рідше

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

Для читання даних вам потрібно буде якомога більше завантажувати пам'ять у рівень додатків, а потім гарантувати, що весь ваш код використовує цей пул пам’яті, на задньому плані ви можете синхронізувати пул пам’яті з базою даних. Як зазначає Джо, буде час, коли вам знадобляться транзакції в режимі реального часу. Серіалізувавши більшість записів, у вас все одно має бути достатній IO у вашій базі даних, щоб робити операції в режимі реального часу, коли це необхідно, припускаючи достатнє обладнання на сервері / кластері бази даних.

— Нейт
джерело

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

Незважаючи на те, що я маю на увазі, до цього я йшов в останньому абзаці. Я рекомендую трохи гібрид, де ви використовуєте IN-пам'ять, де це можливо, та базу даних, коли це необхідно.

— Нейт

Проблема полягає в тому, що ви ознайомилися з тим, що є в пам'яті, що є цілою іншою базою даних, і ви не давали вказівки, як це реалізувати, що є фактично складним бітом.

Щоправда, хоч питання стосувалося великої архітектури зображень, а не деталей реалізації.

— Нейт

Щоправда, але ви залишили весь середній рівень. Це RDB з низькою затримкою? ОДБ? Ключ / цінність магазину? Немає БД і відмовитися від ACID? STM або блокування? Справедливо кажучи, дуже важко відповісти на це, оскільки в питанні не так багато інформації, але вся ця відповідь стосується діаграми архітектури - це взяти великий міхур посередині з "?" в ньому і підключіть до нього ще два сервіси, а не насправді заповніть те, що "?" є.