Перейти до основного вмісту
Жива гра

Цю сторінку ще не перекладено — показано англійську версію.

Що лишається після втрати хоста

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

host Athe last snapshothost B declared state, on an intervalagainagain play since the last snapshot — what a failover costshost A stops answeringresume — the state whole, as of the snapshot
Новий хост продовжує з останнього снапшота; виділений відрізок — гра, яку втрачають під час перемикання на резерв

Стан кімнати не копіюють між хостами

У кожен момент сутність (entity) має рівно одного власника. Жодна друга машина не тримає напоготові живу копію, щоб її підхопити.

Якби дві копії прийняли той самий постріл, їм довелося б домовитися, в якому порядку влучили два постріли. Домовлятися про порядок тридцять разів на секунду між машинами — це консенсус, а консенсус додає затримку саме там, де гра її не терпить. Єдиний власник такої проблеми не має. Усі механізми нижче потрібні для того, щоб єдиний власник міг пережити збій.

Реплікують інше — присутність (presence): який актор на якому вузлі. Це невеликий факт, що змінюється рідко, тож маршрутизація може знати його всюди й не платити за узгодження всього, що рухається.

Оголошений стан живе поза хостом

Оголошений стан не належить лише тому процесу, що його тримає. Платформа робить його снапшот з оголошеним інтервалом. Коли попередній хост перестає відповідати, новий продовжує з останнього снапшота, а гравець повертається через звичайний пільговий період (grace window) кімнат.

Звідси випливають дві речі й одне застереження:

  • Новий хост отримує стан повністю, але на момент снапшота. Перемикання на резерв (failover) коштує тієї гри, що минула між останнім снапшотом і збоєм. Саме інтервал визначає цей найгірший випадок.
  • Зміна авторитетного джерела перериває безперервність тіку. Коли кімнату переносить платформа, стан тіку учасника зберігається; заміна авторитетного джерела цього не обіцяє. Обидва випадки оголошують на сторінці Rooms — разом із тим, що відбувається після завершення пільгового періоду.

Стан, що живе лише в рушії, не відновлюється

Усе, що ви тримали лише в акторах рушія, зникає разом із процесом. Цей стан ніхто не оголошував, тож поза тим хостом його ніколи не було.

Деплой іде тим самим шляхом, тільки без втрат

Вивести хост із роботи (drain) означає перестати розміщувати на ньому нові кімнати, дати поточним сесіям завершитися або передати їх і лише тоді відпустити хост. Це той самий шлях, що й під час перемикання на резерв, тільки пройдений навмисно й з попередженням. Тож щоб деплоїти, не обриваючи живих сесій, другий механізм не потрібен.

Хост кімнати дізнається про це так само, як і про все інше: платформа заздалегідь попереджає, що кімнату треба закрити або передати з причини на її боці.

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

Вибір машини не входить у ваш інтерфейс

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

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