Comments 13
одно уведомление для пользователя будет обрабатываться всеми инстансами нашего микросервиса
Мастер поток коннектится к rabbit, форки держат подключения пользователей, мастер пересылает сообщения форкам, а те уже определяют подключен к ним нужный пользователь или нет.
Почему это будет работать так же медленно?
А почему было бы не взять готовое решение? Есть немало работающих из коробки и требующих минимум времени.
Если бывают наплывы пользователей - то значит стартап не такой уж и провальный =)
Аппратный или программный балансировщик с передачей запроса на нужную ноду кластера (на которую самый первый запрос отправлялся) + любая in-memory база для инстансов внутри одной ноды. Со входящими совсем всё просто - даже писать лень. Работает с 2003 года.
Простите, но все это можно сделать не хватаясь за другой язык:
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены
Все worker получают сообщения из RabbitMQ, но только worker, который имеет соединение с конкретным пользователем делает acknowledgment для сообщения, иначе игнорит.
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены.
А то что в потоках нельзя шарить сокеты это не зря сделано. Многопоточное программирование двигается в сторону общения сообщения как в Erlang/Elixir, а не в шаринге всего подряд, что ведет к сложноуловимым ошибкам и использованию блокировок, которые убивают перфоманс
всё верно не нужно оправдыват ь технологию и пытаться с помощью костылей чтото к ней привернуть , если есть всё из коробки .
Добро пожаловать в цивилизованный мир .net
Но многопоточность всё же не заканчивается на параллельности. Помимо неё нам нужна общая память между потоками,
И SharedArrayBuffer не подходит?
а ведь можно было просто установить пару плагинов на кролика и не мучаться: webstomp и oauth jwt и уже поверх этого масштабироваться инстансами ноды
Ну раз уж взяли дотнет, еще можно было взять и SignalR. И получить сразу из коробки кучу транспортов (WebSocket, Long poling etc) + потенциальную возможность масштабирования на несколько серверов (через редис)
Тем, кто пишет на десктопе намного легче. Берешь маслаешь UDP multicast.
Надеюсь, что с продвижением http3 такие штуки возможно будет проворачивать
SSE, нотификации, Node.js и при чём тут C#?