Пользователей у нашего проекта становится всё больше, поэтому мы продолжаем масштабироваться. На этот раз настала очередь WebSocket'ов.
Есть много готовых решений, таких как Redis, Kafka или Nats, и по началу казалось хорошей идеей использовать какое-нибудь из них. Но когда я стал разбираться в этой теме, выяснилось, что 21 марта Redis Ltd. объявила, что, начиная с Redis 7.4, её in-memory data store будет выпускаться под несвободными лицензиями с доступным (source-available) исходным кодом.
Обсудив этот вопрос с нашим Solution Architect, мне было предложено попробовать написать собственное решение для масштабирования WebSocket'ов, поскольку благодаря этому мы не добавляем стороннюю зависимость в наш проект на его основополагающий функционал. К тому-же, тот же Redis для нас на данный момент сильно избыточен и требует тонкой настройки для оптимального потребления ресурсов, поэтому от сторонних решений в данном вопросе мы отказались.
Моя реализация построена на всем известном паттерне PubSub с возможностью гибкого временного хранения передаваемых событий. Вообще, вариантов масштабирования WebSocket'ов не так много, выбор стоял между PubSub и липкими сессиями, в нашем случае именно PubSub является оптимальным решением.
На своей локальной машине в режиме отладки единомоментно удалось прогнать более более миллиона эвентов, данной пропускной нам достаточно с избытком.
Немаловажной является и скорость доставки. Во многих проектах время доставки уведомлений через WebSocket'ы не имеет особого значения, но это не наш случай. В нашей системе всё взаимодействие происходит в реальном времени, поэтому любая задержка станет сразу заметна пользователю. К счастью, проблем с этим в моей реализации не обнаружено.
В целом, задача оказалась очень полезной и интересной. Благодаря ей мне удалось ещё больше прокачаться в темах асинхронности и многопоточности, а также лучше разобраться во многих других интересных аспектах. Даже нашлось применение для моего экспериментального NuGet пакета, который позволяет использовать несколько фоновых задач (или «раннеров») для обработки задач из очереди. Классические раннеры обычно не ждут, а постоянно проверяют очередь на наличие задач. Текущая реализация построена с помощью того-же шаблона PubSub для ожидания новых задач, что делает этот подход более реактивным, но менее ресурсоемким.