Как оповещать большое количество клиентов о событиях?
Здравствуйте.
Имею около 500 клиентов [приложение на go] (их количество растет очень быстро, через неделю уже будет 1000, а по прогнозам аналитики через полгода >50.000). Для каждого из них создается действие извне пользователем, либо клиент сам что-то делает без ведома пользователя и передает результат в сервер очередей, а worker отдает результат конечному пользователю. Проблема состоит на этапе эффективной передачи задания с worker - клиенту.. В данный момент все worker связаны по TCP с клиентами. И когда worker видит в сервере очередей задание - он передает задание клиенту.
Частота событий от раза в секунду до полного застоя в течении месяца. То есть абсолютно непредсказуемо и независимо.
Вопрос: как уведомлять такое количество клиентов о новых событиях?
Какие варианты вообще есть?
1. TCP в ACCEPT mode, как в Push уведомлениях? Как балансировать там нагрузку?
2. Использовать Redis в качестве хранилища и дать доступ всем клиентам изначально? (слишком много ресурсов требуется и не всем клиентам надо иметь доступ ко всем заданиям)
3. Создать каждому клиенту свой sqlite-файл с заданиями. Разрешить worker записывать задания внутрь? периодически раз в секунду подключать клиента - проверять - не появилось ли новое задание? (мезозойская эра какая-то, но это лидер №1 на первое время до полного капца)
4. Плодить worker. На каждого worker вешать по, грубо говоря, 1000 клиентов, и пусть он отвечает за эту тысячу? (это лидер №2)
5..?
MrDickson, В целом я так понял вам нужен комет сервер. Погуглите Dklab_Realplexor не единственный.
Я на пример развиваю аналогичный проект https://github.com/CppComet/comet-server тоже возможно подойдёт
MrDickson, это не оно.
Если у вас есть полноценный TCP, то убогий Comet вам не нужен.
Comet - это обход недостаточного функционала HTTP.
Вы же, на своем голом TCP можете сделать все что угодно.
Если уж сильно хочется на базе HTTP, то это имеет смысл на сегодня делать на websocket, а не на comet - это эффективнее, экономичнее по ресурсам.
да longpolling и fast polling уже почти не кто не использует. но сам поход когда для поддержания соединений используется специальизированное приложение с апи которое может быть вызвано из бизнес логики других сервисов вполне жив и я не вижу причин от него отказываться.
так что если загуглить комет сервер то большенство решений которые не были заброшены давным давно будут работать по вебсокетам.
4 - запустить воркер чтоб чекал задания, при появлении нового/новых этот воркер запускает себя уже с конкретным заданием (если заданий появилось много - запускает сразу несколько воркеров с несколькими заданиями) - ждет. потом снова повторяет процесс.
