Как мы перестали терять игроков/пользователей при рестарте сервера: Thin WebSocket Gateway + Redis»

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

Контекст: 

В realtime мультиплеер игре позиции и действия игроков передаются через сервер, посредством сокета (и websockets). Online игроки есть всегда, и при обновлении сервера или перезапуске, все игроки теряли соединение и соответственно игровой процесс рушится, то есть это негативное влияние на UX

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

Казалось бы, ничего страшного. Но ведь можно по-другому, верно?

Этот опыт применим не только для игровых серверов, но и для любых проектов, в которых используются сокетные соединения и разрыва соединения влияет на UX

Что было сделано:

Перебрав много вариантов, я остановился на архитектурном решении с созданием тонкой прослойки, которая будет принимать и держать соединения, и все данные из/в сокеты будет транслировать в производительный Redis Pub/Sub, к которому уже будет подключен backend с бизнес-логикой. 

Вот схема

Результат:

В итоге это дало возможность обновлять backend сервер практически безболезненно и решило основную проблему. 

Как следствие UX улучшился, что уменьшает количество недовольных пользователей (игроков) и негативных отзывов в сторах приложений

Конечно, есть и минусы.

Несуществует идеальных вариантов, но в данном случае получаемый профит от этой фичи был выше, чем получаемые недостатки

И так, недостатки:

• Увеличивает задержку, в нашем случае добавило 1-5ms задержки для игроков. Но есть пространство для оптимизации и улучшения. И в нашем случае эта задержка была незначительна

• Усложняется архитектура. Как говорят инженеры “Лучшая деталь та, которой нет”, так как если детали нет, то и ломаться нечему 🙂 В нашем случае добавляется дополнительный слой, о котором нужно помнить. Но при наличии хороших IT-процессов проблем будет очень мало

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

Повторюсь, что в нашем случае самым значимым недостатком была задержка, но и она незначительна для нас.

А это значит что получаемый профит от этой фичи больше, чем цена, которую заплатили за нее. Именно к таким техническим решениям я стремлюсь, в ходе работы

Кто сталкивался с подобной проблемой? Как решали?