В режиме реального времени приложение newbie - Node.JS + Redis или RabbitMQ → клиент/сервер как?

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

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

LAMP + RabbitMQ
Node.JS + Redis + Pub-Sub

Я считаю, что я начинаю учиться, основываясь на этом. Тем не менее, мои (серьезные n00b) вопросы:

Как мне взаимодействовать с конечным пользователем → Клиент на/из Сервера в обоих этих? Будет ли это простой Javascript длинный/бесконечный опрос?
Из двух, которые могут быть более эффективными для создания и управления с одного фрагмента (предположительно 100 - 1000 пользователей)?
Должен ли я просто построить все с помощью jQuery в парадигме старой школы, а затем определить, какой стек может иметь больше смысла? Просто чтобы я мог получить продукт в виде прототипа, а затем "оптимизировать" его. Или пишет в одном над другим больше, чем просто оптимизацию? (Я так чувствую, но на этом лично я не на 100%).

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

Спасибо.

Ответ 1

Архитектурно оба ваших варианта совпадают с хранением данных на сервере базы данных Oracle для получения другого приложения.

Оба решения RabbitMQ и Redis требуют, чтобы ваши приложения подключались к промежуточному серверу, который обрабатывает передачу данных. Redis больше похож на Oracle, потому что его можно использовать просто как постоянную базу данных с сетевым API. Но RabbitMQ немного отличается от того, что MQ Broker не несет ответственности за сохраняющиеся данные. Если вы настроите его правильно и используете правильные параметры при публикации сообщения, то RabbitMQ фактически сохранит данные для вас, но вы не сможете получить данные, кроме как часть обычного процесса очередности сообщений. Другими словами, RabbitMQ предназначен для обмена сообщениями и обеспечивает постоянство только как способ восстановления из-за сетевых проблем или сбоев системы.

Я бы предложил использовать RabbitMQ и любые языки программирования, с которыми вы уже знакомы. Поскольку M в LAMP обычно интерпретируется как MySQL, это означает, что вы либо не будете использовать MySQL вообще, либо используете его только для долговременного хранения данных, а не для обмена в реальном времени.

На сайте RabbitMQ имеется огромное количество документации по созданию приложений с AMQP. Я предлагаю, чтобы после установки RabbitMQ вы читали документы для rabbitmqctl, а затем создавали vhost для экспериментов. Таким образом, вы легко можете очистить свои эксперименты, не перезагружая все. Я также предлагаю использовать только обмен темы, потому что вы можете эмулировать поведение прямых и разветвленных обменов с помощью подстановочных знаков в routing_key. Помните, вы публикуете сообщения только на биржах, и вы получаете только сообщения из очередей. Обмен отвечает за сопоставление шаблона сообщения routing_key с ключом bind_key очереди, чтобы определить, какие очереди должны получить копию сообщения. Стоит изучить всю модель AMQP, даже если вы планируете отправлять сообщения только в одну очередь с тем же именем, что и routing_key.

Если вы создаете своего клиента в браузере и хотите создать прототип, то вам стоит подумать только об использовании XHR сегодня, а затем перейти к чему-то вроде Kamaloka-js, который является чистой реализацией JQuery AMQP (AMQ Protocol), который является стандартным протоколом, используемым для связи с брокером сообщений RabbitMQ. Другими словами, постройте его с тем, что вы знаете сегодня, а затем ускорите его позже, что-то (AMQP), которое имеет долгосрочное будущее в вашем ящике инструментов.

Ответ 2

Должен ли я просто построить все с помощью jQuery в парадигме "старой школы", а затем определить, какой стек может иметь больше смысла? Просто чтобы я мог получить продукт в виде прототипа, а затем "оптимизировать" его. Или пишет в одном над другим больше, чем просто оптимизацию? (Я так чувствую, но на этом я лично не на 100%)

Обычно это называется RAD (быстрый дизайн/разработка приложений), и это то, что я бы рекомендовал прямо сейчас. Это позволяет вам построить доказательство концепции, которое вы можете использовать, чтобы потом работать, чтобы получить то, что вы хотите.

Что касается того, как разговаривать с клиентами с сервера, и наоборот, читаете ли вы вообще на веб-сайтах?

Учитывая выбор между LAMP или программированием на основе событий, для того, что вы предлагаете, я бы сказал вам пойти с программированием на основе событий, поэтому nodejs. Но это мнение только одного человека.

Ответ 3

Ну,

LAMP. Apache создает новый процесс для каждого запроса. RabbitMQ может быть полезен со многими функциями. Node.js. Использует единый процесс для асинхронного обращения с запросом асинхронно с помощью цикла событий. Таким образом, никакого дополнительного процесса создания надбавок, такого как apache, не требуется. Для асинхронного чата, socket.io + Node.js + redis pub-sup - лучший стек. Я уже использовал уведомление в режиме реального времени, используя вышеуказанный стек.