Как хранить в бд id socket'a для отправки сообщений?
Приветствую. Проблема такая - при каждом коннекте к серверу Socket.IO для клиента создается на моменте handshake уникальный айди, чтобы отправить этому клиенту какое-либо сообщение - нужно знать его id.
Как быть? Записывать его в базу при каждом коннекте?
У меня лишь идея сделать в Redis что-то вроде users_online и хранить в виде user_id => socket_id. В Redis потому что он работает же в памяти, поэтому все обращения к нему будут быстрее.
P.S. Redis же сохраняет данные на диск периодически, как быть чтобы она была Only-Memory?
Не нужно хранить в базах, храните в памяти, нода тоже всегда в памяти, не обязательно обращаться к внешнему процессу типа редиса. Если же процесс парадет, то и его соединения падают и эти ID уже ни кому не нужны. Если процессов несколько, то используйте шины сообщений, ZeroMQ, RabbitMQ и т.д.
Но ведь Redis и работает в памяти, поэтому вот на него и подумал. А хранить в памяти инстанса Ноды - нужно будет еще и между собой их связывать.
Если даже не Redis, может быть Memcache? Он работает только в памяти.
Просто даже вот пример, у нас есть комната, в ней есть clients[usersid], т.к. в socket.io есть возможность посылать выбранному клиенту по его socket.id мы просто будем циклом проходить по всем userID, искать этот userID в нашей memory базе и брать оттуда socket.id соответственно
Хранить в памяти другого процесса накладнее, туда еще обращаться нужно через TCP/IP. Взаимодействие между процессами ноды все равно будет, от этого не уйти. Но так у нас каждый процесс будет получать сообщение и искать внутри своей памяти по хешу, не по всему, а только по своему небольшому, т.е. выполняет часть задачи. А если делать через общую таблицу да еще и во внешнем процессе. В добавок к передаче сообщения между процессами, мы еще добавляем поиск по этой таблице (тоже с обращением в другой процесс по TCP/IP). Межпроцессовое же взаимодействие в ноде можно сделать через IPC (child_process, cluster) если в рамках одной машины или ZMQ, это будет значительно быстрее.
А в чем трудозатратность? С ZMQ будет не больше строк, чем с базой, а IPC вообще встроенное решение, если в пределах одной машины то подходит. Если с ZMQ напряжно разбираться, то передавайте сообщения по редису. Вам же все равно нужно пересылать сообщения между процессами, вот только общая таблица ID не нужна.
Тимур Шемсединов: Между процессами сообщения передает socket-io.redis-adapter. Мне для отправки лишь нужно знать socket.id для отправки сообщения выбранному клиенту
А в чем более общая задача? Вы хотите рассылать всем пользователям одно сообщение и для этого нужна таблица? Для широковещательных есть socket.broadcast.emit(eventName, data);
Тимур Шемсединов: Общая задача в том, чтобы какому-либо пользователю который online - отправить сообщение, но чтобы отправить юзеру сообщение - нужно знать его socket.id. Socket.id создается каждый раз новый, при подключении.
Поэтому я и предложил хранить его как user_id => socket_id в общем виде как онлайн юзеры
С таблицей будет куча проблем:
1. Ее нужно поддерживать в актуальности, а если процесс, породивший сокет, уже вылетел, то в базе будут неактуальные ID.
2. Когда у одного пользователя есть несколько устройств или открытых окон, то у него будет несколько ID, понятно, что в базу запишется последний, он затрет все предыдущие и работать будет только последний подключившийся клиент этого юзера.
3. Откуда мы узнаем, в каком процессе ноды нужно отправлять сообщение, если в базе есть ID, но нету идентификатора процесса? Получится, что все процессы будут пробовать отправлять вновь пришедшее сообщение. Вы вообще ноду в многопоточном режиме (cluster) запускаете? На одной машине или на нескольких?
Тимур Шемсединов: 1. В принципе, актуально не актуально - без разницы, тут лишь проблема будет в том что если вытелетел - то все юзеры дисконнектнулись, а значит они в offline уже, и наличие записи в таблице будет означать что они в сети. А так, при каждом новом коннекте все равно же будет новый id.
2. Хм, а если сделать просто массив с socket.id клиентов?
3. Этим же занимается socket.io-adapter. Он обеспечивает доставку по socket.id, насколько я знаю
1. Я вот не в курсе, будут ли лететь ошибки, если отправлять на неактуальные ID, но как минимум это будет плохо для производительности, отправляться то оно будет пробовать, если не узнает, что клиент отпал.
2. Можно массив, но этот массив лучше хранить в памяти нодовского процесса.
3. Если он обеспечивает такую доставку, то наверняка у него есть и список ID, иначе как бы он мог находить нужные сокеты по ID. К сожалению с адаптером не знаком. Советую посмотреть его исходники или поискать именно в адаптере документацию как он хранит в памяти с своих структурах данных эти таблицы ID. Он явно должен хранить их в памяти ноды, а редис использовать для трансляции сообщений, как mq.
Простой
