|
Professor Seleznov
|
Одной из задач, которую мне нужно было решить, являлась проблема обрыва соединений сокета от клиентов к серверу, при перезапуске сервера.
Контекст:
В realtime мультиплеер игре позиции и действия игроков передаются через сервер, посредством сокета (и websockets). Online игроки есть всегда, и при обновлении сервера или перезапуске, все игроки теряли соединение и соответственно игровой процесс рушится, то есть это негативное влияние на UX
Обычно, в играх и других неигровых приложениях, проихсодит переподключение в фоне, а если переподключиться не удалось, то отображается сообщение о перезапуске сервера и с просьбой подождать некоторое время.
Казалось бы, ничего страшного. Но ведь можно по-другому, верно?
Этот опыт применим не только для игровых серверов, но и для любых проектов, в которых используются сокетные соединения и разрыва соединения влияет на UX
Что было сделано:
Перебрав много вариантов, я остановился на архитектурном решении с созданием тонкой прослойки, которая будет принимать и держать соединения, и все данные из/в сокеты будет транслировать в производительный Redis Pub/Sub, к которому уже будет подключен backend с бизнес-логикой.
Вот схема
Результат:
В итоге это дало возможность обновлять backend сервер практически безболезненно и решило основную проблему.
Как следствие UX улучшился, что уменьшает количество недовольных пользователей (игроков) и негативных отзывов в сторах приложений
Конечно, есть и минусы.
Несуществует идеальных вариантов, но в данном случае получаемый профит от этой фичи был выше, чем получаемые недостатки
И так, недостатки:
- Увеличивает задержку, в нашем случае добавило 1-5ms задержки для игроков. Но есть пространство для оптимизации и улучшения. И в нашем случае эта задержка была незначительна
- Усложняется архитектура. Как говорят инженеры “Лучшая деталь та, которой нет”, так как если детали нет, то и ломаться нечему
 В нашем случае добавляется дополнительный слой, о котором нужно помнить. Но при наличии хороших IT-процессов проблем будет очень мало
- Усложняется отладка. Так как данные проходят больше компонентов, время на поиск проблемы незначительно увеличивается
Повторюсь, что в нашем случае самым значимым недостатком была задержка, но и она незначительна для нас.
А это значит что получаемый профит от этой фичи больше, чем цена, которую заплатили за нее. Именно к таким техническим решениям я стремлюсь, в ходе работы
Кто сталкивался с подобной проблемой? Как решали?-Источник
|
|
|
