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

Вот смотри есть сервис app1 - к нему подключаются по сокетам приложения. Например я начал его маштабировать и стало app1-1 и app1-2. Часть клиентов будет подключеной первому потоку часть ко второму. Дальше нужно отправить сообщение из  app2 в app1. Как понять к какому потоку подключаться? Перебирать все?

Ок, пойду редис покурю.

Попробовать разобрать его (слово). Отделить корень от суффикса и окончания
Есть исключения, но вообще суффиксов и окончаний в русском языке ограниченное количество

смотри
- каждый инстанс app1 подписывается на канал вида */app1...
- пусть у app1-1 подключены юзеры 1,3, а у app1-2 подключен юзер 2
- app2 шлет сообщение в канал app2/app1 для юзера 1

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

pub/sub - редиса, это не очередь, это скорее широковещательные каналы, тут нет подтверждения доставки/получения, тут нет контроля целостности и т.п. удобных фишек очередей, но на самом деле его возможностей часто более чем достаточно ;)

Можно pub/sub через Redis

Точно. Вообще отдельно нужно поднять сервис под эти сообщения. Тогда будет по одной шине на каждый  app1, ap2, и туда можно широковещательные пакеты  слать, а обробатывать будет тот процесс у которого есть клиент с нужный айди. Спасибо. Сложилось.

я правильно понимаю, [].find -  это дешевая операция?

А zeromq/nanomsg не дешевле и проще будет для такой задачи?

O(N)

Линейный же, конечно

но в целом можно эмулировать "гарантию получения" следующим путем...
- отправитель генерит ключ через микротайм + префикс (к примеру) и создает в редисе простую запись по этому ключу с заданным временем жизни (чтобы все-таки было самоудаление)
- а в канал отправляет не само сообщение, а только ключ записи
- получатель, который должен обработать данное сообщение, после его прочтения, удаляет из редиса этот ключ

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

но это так - в качестве мазохизма, если вдруг малой кровью захочется помудрить, т.к. pub/sub достаточно надежная доставка, по крайней мере там, где я такое юзал, потери пакетов не ловил ни разу

так то по идеи и обычных сокетов должно быть достаточно?

я же говорю - в качестве мазохизма =)))

все может быть - я лишь предложил вариант с учетом простоты и функциональности

не подскажете, что возможно нужно вводить в данные поля, чтобы например случайно не залить в рут файлы проекта. насколько мне известно хранят в /var/www/project_dir или в каком то /html

Привет всем. Хотел узнать ваше мнение - вам был бы интересен ежедневный дайджест с подборкой новостей и статей, посвященных веб разработке?

Таких энтузиастов тут не ты один был
Новостей по ноде нет- только гитхаб с ченджлогом, не более