Push сервер, серверная часть, php+node.js, как правильно реализовать?

Question

[Сергей Шевцов]

задача стоит как построить свой сервер push уведомлений, сайт написан на php, часть подписчиков будет получать уникальные push сообщения, а так же массовые уведомления( к примеру оповещение всех подписчиков, возьмем число 100К подписчиков). После поиск вариантов, решил использовать node.js + web-push, обмен с php делать через redis(id пользователей, сообщения с сайта).

Интересуют такие моменты:

1) Необходим ли сервер очередей для такого большого количества сообщений или node.js с этим справиться, как это правильно реализовать, чтобы не упал сервер.
2) как правильно организовать передачу id пользователей и сообщение, когда личные уведомления - это малое количество данных, а справиться ли redis с 100К или спользовать mongodb для хранения пользователей и очереди сообщений на ноде и просто их синхронизировать с бд сайта, или лучше использовать иные способы передачи данных между node.js и php и хранения и обработки большого числа уведомлений.
3) стоит ли связывать подписку браузера с id пользователем на сайте, чтобы в оффлайн присылать ему уведомления личные или личные push уведомления отправлять, только когда пользователь онлайн?
4) может я вообще не правильно понял/придумал алгоритм push уведомлений, может тогда подскажите, как правильнее

ps сторонние ресурсы для этого не интересны, сервер реализовывать буду в целях изучения node.js и push для дальнейшего использования в проектах

Answer 1

[Philipp]

Первое, это то, что вам нужно разобраться, как именно работают push-уведомления.
Второе, ненужно порождать лишние компоненты.
Для PHP тоже имеются решения https://packagist.org/packages/minishlink/web-push

Для начала вам потребуется понять, что подписки браузеров нужно хранить в отдельной таблице или коллекции в зависимости от вашего основного хранилища.
Для личных сообщений необходимо будет реализовать опциональную, но включенную по умолчанию связь. Следует помнить о том, что один и тот же пользователь может заходить с разных устройств. Например с десктопа, ноута и таблетки. У одного пользователя может быть несколько подписок.
Вам потребуется сервер очередей, например RabbitMQ. У вас будет 2 вида задач - публичные и частные.
Публичная задача - это широковещательная задача, цель которой охватить всех пользователей.
Например, когда публикуется новый материал на сайте и сайт готов принять всех желающий.
Для него потребуется простая очередь. Задача воркера будет заключаться в том, чтобы найти всех подписчиков, создать задание для каждого из них и поместить это задание во вторую очередь со множеством воркеров, которые будут непосредственно отправлять пуши.
Первое задание будет содержать id - материала.
Второе будет содержать id материала и id подписки.
Данный подход позволит очереди работать очень быстро. Плюс выборка из базы по id практически мгновенна вне зависимости от движка + отлично кэшируется на уровне самой базы. Доставать из базы нужно только необходимый минимум полей.
Рассылка личных сообщений может быть сделана на основе второй очереди, дополнив задание несколькими полями. Т.е. воркерам будет все равно что они доставляют.
Записывать задание со всеми полями для глобальных публикаций не очень хорошая идея, т.к. это будет занимать много памяти и вызывать тормоза. Плюс такое решение не очень хорошо масштабируется.

Воркеры можно сделать и на Node.js, а можно на PHP. У RabbitMQ есть все необходимое для этого. Можно поискать и другие очереди, однако RabbitMQ достаточно популярное и проверенное решение.