Сервер веб-сокетов Node.js: моя идея управления данными стабильна / масштабируема? - PullRequest
2 голосов
/ 15 августа 2010

Я разрабатываю многопользовательскую RPG-версию браузера html5 с node.js, запущенным в бэкэнде с плагином веб-сокетов для передачи клиентских данных.Проблема, с которой я сталкиваюсь, заключается в доступе и обновлении пользовательских данных, так как вы можете себе представить, что этот процесс будет происходить много раз в секунду даже при подключении нескольких пользователей.

Я провел некоторый поиск и нашел только 2 штекера.-in для node.js, которые включают возможности MySQL, но они оба находятся на ранней стадии разработки, и я решил, что запрашивать базу данных для каждого небольшого действия, которое делает пользователь, неэффективно.

Моя идея - получить узел.js для доступа к базе данных с использованием PHP, когда пользователь подключается и получает всю информацию, связанную с этим пользователем.Собранная информация будет затем сохранена в объекте JavaScript в node.js.Это произойдет для всех пользователей, играющих.Обновления будут применены к объекту.Когда пользователь выходит из системы, данные, хранящиеся в объекте, будут обновлены в базе данных и удалены из объекта.

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

Я хотел бы знать, если это хорошая идея.Значительно ли замедлило бы наличие больших объектов сервер node.js?Если у вас есть какие-либо идеи относительно других возможных решений для моей ситуации, я приветствую их.

Спасибо

Ответы [ 2 ]

4 голосов
/ 15 августа 2010

Что касается вашей стратегии, то для хранения данных в промежуточных объектах в php вы добавляете в приложение очень высокий уровень сложности.

Просто взаимодействие между node.js и php кажется сложным, и нет никакой гарантии, что это будет быстрее, чем просто исправить все в mysql.Если между вами и вашими данными возникнет ненужный барьер, это затруднит управление.

Похоже, вам нужно более быстрое решение для обработки данных.Вы могли бы рассмотреть возможность использования асинхронной базы данных, такой как mongodb или redis, которая будет читать и писать быстро (redis будет писать в память, должна быть невероятно быстрой)

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

На самом деле Redis - это то, что вы действительно просите, он на самом деле сохраняет данные в памяти, а затем периодически сохраняет их на диск.Вы не можете получить быстрее, чем это, но вам понадобится достаточно оперативной памяти.Если баран выглядит как проблема, используйте mongodb, который по-прежнему очень быстр.

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

1 голос
/ 03 ноября 2010

У меня есть приложение, которое делает все, что вы описываете - я решил сделать это таким образом, поскольку драйверы MYSQL для узла были нестабильны / недокументированы во время разработки.

У меня есть 200 подключенных пользователей - они запрашивают данные 3-5 раз в секунду и извлекают целые таблицы через страницы php (каждые 200-800 мс), возвращая JSON из apache, приблизительно с 1000 строками и помещают содержимое в массивы. Я перебираю массивы и нахожу соответствующие данные по запросу - он работает и работает быстро - без значительной нагрузки на процессор и память.

Все вставки / обновления данных, которые ограничены, проходят через php / mysql.

Преимущества: 1. это простое решение с известными стабильными сервисами. 2. Только 1 клиент подключается к apache / php / mysql каждые 200-800 мс 3. все клиенты узла получают преимущество неблокирования. 4. Работает на 2 небольших серверах в стиле «ПК» и обрабатывает около 8000 запросов в секунду. (apache скамейка)

Недостатки: 1. много - но это делает работу.

Я обнаружил, что мой сценарий узла МОЖЕТ останавливаться -1-2 раза в неделю - возможно, из-за некоторых проблем с подключением (нерешенных) - но в сочетании с Upstart и Monit он перезапускается и выдает предупреждения без проблем .....

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...