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

Tarantool на сколько знаю умеет

GitHub - tarantool/websocket: A websocket implementation for Tarantool
https://github.com/tarantool/websocket

а ну тогда можно и целиком на тарантуле, хотя и не фанат такого подхода)

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

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

В целом websocket один из вариантов, но я смотрю в сторону google firebase от google. По идее от тарантула при получении сообщения нужно лишь инициировать уведомление в firebase, а далее google сам перешлет его в приложение. Тут важный момент, приложение на стороне клиента может быть в спящие режиме, а значит оно не может поднять соединение саиостоятельно! Для этого и нужен обратный триггер через firebase, которое его "будит" и инициирует функцию загрузки новых сообщений.

Поэтому websocket-ы тут не самое лучшее решение.

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

Тарантул может послать туда сигнал по любому протоколу, по http элементарно это делается даже без внешних библиотек

Внутри Тарантула достаточно иметь некий постоянно работающий процесс, который например читает очередь уведомлений и посылает эти сигналы. Написать его не сложно, читать сигналы можно из любой очереди — хоть тарантульной, хоть внешней типа mq или кафки. Для специфических протоколов mq могут потребоваться коннекторы, некоторые из них есть у нас в enterprise версии.

Тут больше сложностей именно в доставке сигнала клиенту, смартфон в нормальном случае не будет открывать свои порты всему миру, для этого используются уже готовые решения для получения пуш-уведомлений

Я об этом и говорю, приложение в виду высокого/постоянного потребления траффика, операционной системой android например может быть помещенно в спящий режим! От туда оно никаких портов не откроет и соединений не сделает! Из спящего режима его может вызвать только push уведомление!

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

Да, для этого использовать буду google firebase. Тут вопрос скорее не в сервисе google, а например на один инстанс тарантула пришло 10000 сообщений в секунду. И например, они помещаются в queues на то, что бы соединиться в google firebase и через него уже уведомить приложение полусателя. Насколько быстро очередь сможет переварить 10000 https соединений с сервисом google? Пока поднялось односоединение, отправлена команда на push уведомление из очереди тарантула, потом второе потом третье... 10000-е. Не думаю что это произойдет моментально! Очереди же работают последовательно. И еще самый главный вопрос: очереди как то отказоустойчивы в пределах кластера?

Или проще написать файбер на каждом инстансе, который пачками (по 1000) раз в секунду шлет (скопишиеся) задачи на формирование push-ей в сервисе firebase  от googl-a?

так шардинг же..

Почему 10000 соединений? Мне кажется не более десятка потребуется

Ну я вот с тарантулом пока не очень знаком, поэтому и спрашиваю у знающих.

так это не протарантул же