Я вважаю, що загальна вимога MMO, що обробка для одного фрагмента або області може бути виконана на декількох серверах, щоб полегшити навантаження. Мені цікаво, як це можна зробити, підтримуючи єдиний послідовний світ, де можуть взаємодіяти всі гравці та всі NPC.
Моє запитання - як досягається балансування навантаження в ММО?
Вдячні також будь-які посилання, книги чи загальна інформація про те, як покращити свої знання з цього приводу.
Відповіді:
Постарайтеся, щоб це було максимально простим, а інтерфейси були чітко визначені та задокументовані. Утримання та налагодження складної системи у виробництві легко перетворюється на пекло. Тож якщо є простий і складний підхід, подумайте двічі, перш ніж перейти до складного.
Я думаю, що перший крок - виявлення послуг та їх залежностей : Статичний вміст, Аутентифікація, Локальний чат, Глобальні канали чату, Регіональні чатові канали, Список друзів, Гільдії, Сумка / Інвентар, Аукціонний дім, Глобальна карта, Світ, ...
Тоді для кожної з цих послуг вирішується, чи може клієнт спілкуватися з ними безпосередньо. Наприклад, досить просто дозволити клієнту спілкуватися безпосередньо з серверами, відповідальними за глобальні канали чату. Світові сервери взагалі не повинні брати участь у чатових повідомленнях. Регіональний чат може бути реалізований аналогічно, але світові сервери повинні повідомляти сервери чату, коли гравці змінюють регіони. Знову ж таки, їм не потрібно дбати про повідомлення.
Третій крок - продумати балансування навантаження в рамках послуги . Наприклад, глобальні та регіональні канали чату можуть бути розділені на декілька серверів залежно від їх імені. Це, мабуть, гарна ідея не важко кодувати цей розкол на клієнта, а надавати послугу пошуку.
Найскладніша частина зазвичай - це світові сервери , тому я починаю з простого підходу. Ймовірно, це гарна ідея дозволити клієнту спілкуватися безпосередньо з сервером, відповідальним за регіон, в якому він перебуває. Тож при вході в систему або перетині регіону клієнту потрібно повідомити, до якого сервера потрібно підключитися.
Простий підхід - розділити світ на незалежні регіони . Під незалежними регіонами я маю на увазі, що гравець не може переходити з однієї частини в іншу, а монстри не можуть перетинати частини. Ці регіони відрізняються від регіонів, які бачать гравці, виходячи з пейзажу та історії зовнішнього світу. Зазвичай більшість монстрів перебувають у підземеллях, і гравці, як правило, приймають, що їм потрібно пройти через шлюз, щоб увійти в підземелля. Особливо, якщо ці підземелля інсталюються на основі групової групи гравців. Інші приклади зовнішнього світу - це різні материки та долини, оточені високими горами.
Безперервний світ підхід стає складним дуже швидко, так що має сенс планувати це добре: Яку інформацію про необхідність клієнта? Якою інформацією сервери повинні ділитися? Гравець в основному буде взаємодіяти лише з об'єктами (включаючи монстрів та NPC) у тому ж регіоні. Можна обдурити, розмістивши предмети поза межами кліку від межі зони. Це означає, що клієнта в основному цікавить лише інформація для читання сусідніх зон. У цих випадках зональним серверам не потрібно нічого узгоджувати, крім дозволу перевірити, чи програвач достатньо близько, щоб підключитися до сусідньої зони.
Це залишає лише дуже малу кількість складних випадків, коли об’єкти або дії повинні перетинати межу сервера. Це добре, тому що такі випадки, як стріли та заклинання, є критично важливими. Можливо, буде гарною ідеєю розділити боротьбу на атаку та оборону. Таким чином, сервер заклинання визначатиме параметри атаки, включаючи позицію ролика. Сервер захисника отримає повідомлення про атаку та обчислить вплив. Сервер зловмисника не повинен знати про вплив; клієнт дізнається про це, використовуючи підключення лише для читання.
Залежно від того, наскільки складна ваша модель програвача, перенесення її на інший сервер може зайняти кілька секунд (Second Life має величезну проблему з цим). Проблему можна усунути, попередньо підготувавши передачу, коли гравець наблизиться до віртуальної межі. Так що більшість даних про програвач вже кешовані на сервері призначення, коли відбудеться фактична передача даних.
Розділіть проблему, визначивши різні сервіси, які можна розділити на сервери з невеликими залежностями. У наступному кроці подивіться, як зробити баланс завантаження в критичних службах. Делегуйте роботу з балансування клієнту, доручивши йому підключитися безпосередньо до відповідних серверів (очевидно, сервери повинні перевірити дозволи). Зберігайте це якомога простіше, добре документуйте обов'язки різних служб і серверів, надайте можливість ввімкнути вихід налагодження.
PS: Деякі з цих методів можна використовувати для підвищення надійності. І ви повинні пам’ятати про це, оскільки використання багатьох серверів означає набагато більший ризик зламання речей; не тільки в програмному, але і на апаратному рівні.
Взагалі світ розділений на ряд менших регіонів. Кожен з цих регіонів зазвичай є незалежним серверним процесом (світовими серверами WoW або вузлами Sol Sol) і може працювати на будь-якій з кількох машин. У деяких іграх є чіткі двері між картами (Eve, STO, Guild Wars), а інші намагаються замаскувати це більше (WAR, Free Realms). Ті, хто вибирає більш безпроблемний підхід, як правило, виявлять, коли ви наближаєтесь до кордону між двома серверами, і два процеси узгоджують передачу. Оптимальне місце, напевно, шукати опис цього - це те, як вежі стільників роблять передачі рухомих телефонів. Якщо завантаження однієї карти (Jita, Ironforge, Earth Space Dock) стає дійсно великим, ви можете іноді вивантажувати окремі функції на інші сервери (AI, певні частини управління гравцем), але це або має бути вбудовано з самого початку, або потребує серйозної модернізації. Практично завжди вигідніше просто придбати краще обладнання, присвячене цим кільком картам.
Я вважаю, що загальна вимога MMO, що обробка для одного фрагмента або області може бути виконана на декількох серверах, щоб полегшити навантаження. Мені цікаво, як це можна зробити, підтримуючи єдиний послідовний світ, де можуть взаємодіяти всі гравці та всі NPC.
Мабуть, це не так часто, як ви думаєте; принаймні, не, якщо ви думаєте, що одним безшовним світом керує кілька серверів одночасно.
Не рахуючи абсолютно окремих фрагментів, є два напрямки, за якими можна розділити онлайн-гру, яку можна вважати "горизонтальною" та "вертикальною":
Очевидно, що ці підходи є ортогональними, і ви можете поєднати два. Насправді майже обов'язковим є наявність окремого сервера баз даних, дуже поширеного для відключення входу / авт на окрему машину від геймплея, і все частіше також для чату та інших некритичних комунікацій, незалежно від того, яким є ваш ігровий світ ділиться.
Але в цілому, коли існує географічний розподіл, більшість ігор уникають того, щоб ви могли взаємодіяти через ці межі, оскільки це складно зробити добре. Натомість вони вдаються до інших способів зробити так , ніби ви все ще в одному шматку та на тому ж сервері, коли насправді ви цього не робите. напр. - завантаження екранів або іншої анімації, що приховує зміну сервера при переході між зонами або з одного континенту на інший. - окремі випадки підземелля або рейду, відокремлені від усіх інших. Вони схожі на осколок всередині фрагмента і їх можна легко запустити на окремому сервері, допомагаючи врівноважувати навантаження.
Я не можу говорити з владою щодо WoW, але я б припустив, що вони роблять майже все вищезазначене: інстанції, окремі географічні райони, які не можуть взаємодіяти, з'єднані якимись порталами, окремими задніми сторонами та аутентивними серверами. Я чув, що в WoW-сферах одразу є щось від 1000 до 10000 гравців онлайн у даній царині, що легко керується за допомогою вищезазначених схем.
Але, припустимо, у вас є єдиний масивний світ і вам потрібно дозволити гравцям один сервер взаємодіяти з гравцями на сусідньому сервері. Це легко зробити теоретично - спочатку сервери повинні співпрацювати, щоб ділитися деталями об'єктів уздовж кордонів (тому об’єкт на одному сервері може мати представлення проксі-сервера на іншому), а потім просто змінити всю вашу логіку на передачу повідомлень, з повідомлення, які перекладаються з проксі-сервера до авторитетного джерела, де це необхідно. Повідомлення можна передавати між серверами або на сервері досить прозоро, так що один підхід підходить для всіх систем.
Проблема тут полягає в тому, що раніше звичайна логіка може стати дуже складною при перекладі на повідомлення - наприклад. торгівля двома гравцями, яка може відбуватися безпечно та атомно, коли обидва гравці перебувають на одному сервері, стає більш тривалим процесом, коли повідомлення потрібно надсилати вперед і назад, підтверджуватись при кожному відправці та встановлювати гарантії, щоб один гравець не міг експлуатувати інший, змінюючи торгівлю під час подорожі повідомлення. Ви навіть не можете припустити, що інший гравець все ще буде існувати до моменту надходження повідомлення (оскільки вони можуть загинути, вийти з системи тощо), тому код стає дуже складним. І це стосуватиметься майже будь-якої системи, де 2 або більше суб'єктів можуть взаємодіяти або співпрацювати - торгівля, боротьба, групування, аукціони, розподіл багатства, навчання тощо.
Ці проблеми не є непереборними, але для більшості ігор вони занадто важкі, щоб їх варто було б спробувати, коли ви можете розділити навантаження за допомогою інших засобів і зберегти всю свою логіку гри на одному сервері. Тож майже всі поточні ігри замість цього йдуть по цьому маршруту.
Існує багато методів врівноваження завантаження сервера MMO, оскільки існує досить широкий спектр даних, що підлягають обробці. Я віддаю перевагу методу дерева бін процесу.
Глобальний сервер передає підключення користувача до процесорної скриньки, яка може обробляти відразу декількох користувачів. бункери процесів виконують всю складну обробку і реагують на глобальний сервер лише з даними, що мають глобальне значення, такими як глобальний чат та позиціонування. Цей метод врівноважує набагато краще, ніж регіональні сервери, оскільки регіони можуть сильно відрізнятися за кількістю населення, тоді як загальна обробка користувачів досить різноманітна, щоб вона, природно, здебільшого врівноважувала себе.
Просто виконайте балансування базового навантаження через глобальний сервер, щоб, коли процесорний кошик досяг певного використання пам'яті / процесора, ви запускаєте новий сервер бін процесів.