Насколько оправдано передавать данные пользователя из пхп в ноду через мемкеш?

Question

[Алексей]

День добрый.
Ситуация такая, пхп генерирует токен для юзера, который записывается в базу Основной информацией по аутентификации пользователя в ноде является ид + токен. Они отправляются вместе с подключением в сокет.ио (из хендшейка берет) и соответственно нода лезет в базу для проверки есть ли вообще такой пользователь и какие у него права или данные.
Была мысль просто хранить массив пользователей уже в самой ноде, создав просто массив и после каждого обращения к базе, забивать этот массив с инфой о пользователей. Но нода тогда сама превратится в базу данных и не вижу возможности обновить эту информацию при выполнении пхп скрипта с пользователей (например забанить).

Ну и вопрос из сабжа. Насколько оправдано передавать данные пользователя из пхп в ноду через мемкеш ? Либо же проще оставить подключение к базе ?
Большинство запросов формата:

SELECT `name`,`age`,`something`
FROM `users`
INNER JOIN `more info` on (`id`=`id`)
...
WHERE `id`=1 AND `token`='fsdjfkkasfhklasdjfhlkasdfjhalsdk' LIMIT 1

Уточню немного вопрос. Что в таком случае будет менее накладно по памяти и быстродействию ? При условии, что в ноде используется пул подключений к mysql.

И еще тогда пример добавлю при использовании чата. Подключается пользователь как описал выше, через сокетио добавляется в прослушку на on.('chat'), и перед отправкой или получением сообщения, каждый раз проверяет в базе не изменились ли данные через socket.handshake.userid и socket.handshake.token

Comments

[Alex XYZ]

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

[Алексей]

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

[Alex XYZ]

>> почему бы сразу не разрабатывать с оптимизацией
Это риторический вопрос. Удачно выбранная архитектура изначально много чего позволяет. Думаю, что затраты на подключение что к mysql, что к мемкешу должны быть одинаковы, и могут значительно превышать скорость получения самих данных в обоих системах. Меня одна эта мысль уже остановила бы от дальнейших разборок по оптимизации до момента настоящих лагов. Кроме того, если у системы проблемы с аутентификацией по задержке, то что говорить тогда про бизнес логику, если на неё уже возможностей не осталось, а аутентификация - это самое простое? Но это только мои личные рассуждения ))).

[Смотритель]

Честно говоря, я бы воспользовался не мемкешем, а банально внутренней прямой связью... Технически есть разные варианты, но в голову навскидку приходит самый простой:
- в ноде вешаем на 127.0.0.1 еще один сервер-сокет с разрешением коннекта только с локалхоста
- пых при работе с данными юзера после записи данных в бд коннектится на этот сокет и простым упакованным приготовленным JSON-пакетом кидает в этот сокет инфу по юзеру/любым его изменениям/входу/бану и т.д.
- нода получает эти данные что называется realtime вообще без каких-либо дозапросов к БД и т.п.

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

К слову, тогда сразу уйдут издержки не только на коннекты/запросы и т.п. что сразу бросается в глаза, но и на обработку данных, выделение только нужных, их структуризацию...

[Алексей]

zuart: дак тогда этот дополнительный демон на ноде и является мемкешем, разве нет ? он также хранит данные джосна точно также, как и в случае мемкеша. Тоесть для получения данных, нам в любом случае нужно делать запрос на этот "кубик", просто с использованием localhost, no password.
Вобщем, помойму это самое ошибочная архитектура масштабирования. Но, раз у тебя работает так целый комплекс, возможно я и не прав.

[Смотритель]

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

Если я все верно понял, то никаких доп. демонов не нужно делать. Ничего не мешает на сервисе чат-сервера открыть еще один сокет для ПРЯМОГО приема данных юзера вместе с токеном от пхп-скрипта авторизации. В таком случае при коннекте клиента не нужно никуда больше лезть, эти данные УЖЕ прилетели от пыха прямо в сервис через сокет.

[Смотритель]

ЗЫ. тут даже как таковая технология чат-сервера неважна - нода это или питон или еще какой-то язык...

[Алексей]

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

[Смотритель]

Ну прямо "базой" я бы не называл... Все-таки база - это более широкое понятие, тем более что прямо ХРАНИТЬ ключи в ноде тебе не нужно =)

- авторизация на пыхе => отправка в ноду нового токена
- нода приняла и сунула в какой-то свой массив с таймером очистки секунд через 30-60
- клиент подключился к сокету с передачей токена => нода по этому ключу авторизовала юзера, привязала минимальный блок данных к сокету (ЗЫ. объекты сокет-клиентов позволяют добавлять "налету" свойства и оперировать ими как угодно, сохраняя их состояние на протяжении всего существования соединения)
- клиент отключился => сокет закрыл соединение и очистил объект (соответственно память от ненужных данных юзера)

[Смотритель]

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

[Алексей]

zuart: Теоретически мысль я понял, мы просто сравниваем скрытый токен, отправленный пхп страницей при ее загрузке с токеном отправленным через например хендшейк сокетио, но записывать то всеравно придется в глобальный массив. Только вот как тогда вытащить из него токен, если например пришел коннект с id+token через сокет ио, как найти этот конкретный ид из массива. Пока я вижу такие массивы:

var phpTokens = { phpUser_id: 1, phpUser_token: 'lkasdlkasldk' };
var connectQuery = { user_id: 1, user_token: 'asdasdasdasd' };

Как при этом правильно найти indexOf юзер_ид присланого из пхп ? Или же я кудато не туда копаю ?

[Смотритель]

если ты используешь в качестве сокет-либы ws, то достаточно использовать следующий подход:
- socketPhp - это сокет приема данных от PHP
- socketClient - сокет приема клиентских соединений

1. заводим глобальную переменную usersPhp = {};
2. приходит информация в socketPhp c id + token + userinfo => пишем usersPhp[token] = {id: id, info: userinfo, timeout: (new Date().getTimeout() + 3600000)};
3. приходит коннект на socketClient с передачей токена:
- проверяем по пришедшему токену: if(typeof usersPhp[token] !== 'undefined'){...}
- если элемент есть, то прямо объекту самого соединения добавляем свойство: client._user = {id: usersPhp[token].id, info:usersPhp[token].info, token: token}
- удаляем элемент массива: usersPhp[token] = ''; delete usersPhp[token];
4. собственно при приходе в сокет любых данных на входе ты имеешь объект этого соединения, и в нем можешь обратиться к новому свойству client._user

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

ну и чтобы не копились устаревшие данные в памяти, запусти setInterval(...) который будет чистить устаревшие строки из массива usersPhp

В первом приближении дел минут на 10-15, думаю, не больше...

[Смотритель]

ЗЫ. Под понятием "глобальной" я подразумеваю в конкретном посте либо реальную переменную глобального типа, либо свойство класса-оболочки чат-сервера - в зависимости от способа реализации кода =)

[Смотритель]

Кстати, если интересно, да, я немного "изобрел велосипед" для своей архитектуры - в плане документоориентированной базы в памяти, но только с рядом небольших фишек, которых нет ни в мемкеше, ни в редисе ни в какой-либо иной системе (по крайней мере я не нашел)...

Что-то типа чата, собственно говоря и вышло, с задокументированным протоколом - реализация функция непосредственного хранения/удаления данных из памяти + уведомления об изменении данных всех/определенных клиентов, синхронизации данных и много всяких мелочей. Система на тестах легко удержала примерно 1000 одновременных соединений с учетом довольно активной работы с данными как со стороны клиентов, так и широковещательных уведомлений/данных от сервера.

Answer 1

[Boris Köln]

Если вопрос теоретический, то Memcache быстрее Mysql.

Если практический, то при правильной бизнес-архитектуре разницы по скорости почти не заметите. Работать с Mysql проще и надежнее.
Я бы все-таки кэшировал в самой ноде логины-пароли после обращения к БД. А про обновлении пароля или бане юзера - эту информацию из PHP пушить напрямую в Node с помощью https://github.com/Wisembly/elephant.io . Но эту оптимизацию можно оставить и на потом. Пока сделайте работающий прототип без кэширования с запросом в БД на каждый коннект.