Приветствую. Такая задача - есть у нас в MongoDB коллекция Rooms. В комнате у нас есть id участников этой комнаты, но т.к. SocketIO не позволяет создавать с определенным ID соединение, то приходится в Redis хранить user_id => socket_id.
При каждой отправке сообщения в какую-либо комнату, чтобы оповестить других участников, нужно считывать из Rooms id пользователей, искать их socket_id в Redis и по нему рассылать. Т.е. постоянное считывание данных с MongoDB.
Выход вижу такой: когда пользователь пишет в какую-либо комнату - мы считываем данные из MongoDB id_room clients и заносим их в Redis (Чтобы не хранить там эту комнату постоянно, наверное надо будет задавать lifetime этой записи с момента последнего сообщения туда) И при каждом следующем проверять создана ли эта комната уже в Redis и если да - работать с ней. Каждая перезапись каких-либо данных в комнате происходит сначала в MongoDB, потом перезаписывается в Redis.
Вопрос - как быть правильнее? Использовать полностью MongoDB, или же все таки Redis задействовать?
Эм... а почему в реддисе это хранить? Эффективнее прямо в основном потоке, нет? Ну да не суть.
Почему хранить айдишник сокета в монге (как и в любой другой СУБД) дурная затея вы поймете после первого ребута системы, отваливающихся соединений и т.д. То есть вам на каждый чих придется еще и базу дергать, относительно медленную к слову если сравнивать с key=>value в памяти или тем более просто мэпу в памяти.
Кешировать комнаты в реддисе тоже неплохая задумка. Все горячие данные стоит хранить в памяти и минимизировать время доступа. Но есть мнение что у вас не будет таких нагрузок что все будет плохо. Так что решайте по мере возникновения проблем.
В Redis хранить т.к. она как раз в оперативной памяти. Насчет того что соединение отвалиться и остальное - это понятное дело, поэтому и хранить я собирался это списком - user_id -> socket_id.
А насчет основного потока - а что делать если инстанса больше одного? У каждого инстанса свои клиенты и уже не прокатит их найти socket_id по user_id. Только если задействовать MQ.
Простой
