Как обрабатывается запрос с помощью rails, redis и node.js асинхронным?

Question

Для веб-разработки я бы хотел смешать rails и node.js, так как я хочу получить максимум от обоих миров (rails для быстрой веб-разработки и node для параллелизма). Я знаю, что некоторые люди предпочитают просто использовать полный стек ruby ​​с eventmachine, который интегрирован в контроллер rails, чтобы каждый запрос можно было неблокировать с помощью оптоволокна в модели цикла обработки событий. Я смог понять, как это работает на большой картине.

Однако на данный момент я хочу попробовать выполнить неблокирующую обработку запросов с помощью rails и node.js с концепцией очереди сообщений. Я слышал, что это может быть достигнуто с помощью Redis в качестве посредника. У меня все еще есть проблемы, пытаясь выяснить, как это работает на данный момент. Из того, что я могу понять: у нас есть 2 приложения A (rails) и B (node.js) и Redis. Приложение rails будет обрабатывать запросы от пользователей, которые проходят через контроллеры в режиме REST, а затем оттуда rails будет передавать это через redis, а затем redis будет формировать очереди, а приложение node.js будет забирать эту очередь и делать все необходимое впоследствии (написать или читать из базы данных db).

Мои вопросы:

1. Так как это улучшит параллелизм и масштабируемость? из чего я знаю, так как рельсы обрабатывают запросы через контроллеры синхронно, а затем напишите в redis, запросы будут по-прежнему блокируется, хотя end.js end может забрать очередь асинхронно. (У меня есть ощущение, что это еще не асинхронный, если это не конец до конца без блокировки).

2. Будет ли node.js считаться здесь прокси или приложением, если redis это посредник?

3. Я новичок в Redis и изучаю его до сих пор. Если я использую 100% noSQL Решение для моей базы данных, такой как mongoDB или couchDB, полностью или частично заменяется redis или чаще рассматривается как инструмент очереди сообщений, как rabbitMQ?

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

Это весь мой вопрос. Я новичок в концепции очереди сообщений. Буду признателен за любую помощь и указатели на правильное направление и статьи, которые помогут мне узнать больше. спасибо.

Answer 1

Вы смешиваете некоторые вещи, которые здесь не сочетаются друг с другом.

Давайте сначала убедимся, что мы находимся на одной странице относительно сильных / слабых сторон задействованных технологий

Rails : используется для простоты веб-разработки и идеально подходит для обслуживания веб-приложений на основе базы данных.Не очень производительно, когда приходится обслуживать большое количество долго выполняющихся запросов, так как у вас не хватает потоков на ваших рабочих в Ruby - но хорошо подходит для всего, что может масштабироваться горизонтально с большим количеством веб-узлов (несколько веб-серверов - 1 дБ).

Node.js : отлично подходит для сценариев с высокой степенью параллелизма.Не так просто, как рельсы, написать в нем обычное веб-приложение.Но может эффективно обрабатывать почти безумное количество долгосрочных задач с низким процессором.

Redis : хранилище значений ключей, которое поддерживает операции с его структурами данных (значениями приращения / убывания,добавить / подготовить push / pop к спискам - все операции, которые заставляют эту БД работать согласованно с одновременной записью нескольких клиентов)

Теперь, как вы можете видеть, нет никакой выгоды в том, чтобы Rails AND Node обслуживали один и тот же запрос -общение через Redis.Прохождение стека Rails не даст никакой выгоды, если запросы будут обработаны сервером Node.И даже если вы только разгрузите некоторую обработку на сервер узла, все равно веб-сервер Rails обрабатывает запросы и должен ждать ответа от узла - убивая желаемую масштабируемость.Это просто не имеет смысла.

Где бы вы ни находились, если установка с Node и Rails вместе, находится в определенных областях вашего приложения, которые имеют совершенно разные требования к масштабированию.

Если вы, например, пишете веб-сайт, который отображает статистику в реальном времени для футбольных игр, вы легко можете заметить, что в вашем приложении есть две разные проблемы: «Нормальный» сайт, который включает в себя регистрацию, биллинг и профиль, который кричитдля быстрой реализации через рельсы.И «живая» часть сайта, где пользователи видят результаты в реальном времени, и вы ожидаете, что будете обрабатывать множество клиентов одновременно - все ожидают, что что-то произойдет (низкий процессор - высокий параллелизм).

В таком случаеможет быть полезно фактически разделить две части сайта на приложения Ruby и Node, а затем обмениваться данными о пользователе через такой магазин, как Redis (но на самом деле вам просто нужно некоторое общее состояние, которое можно просматривать и записывать вдля целей синхронизации).

Таким образом, вы могли бы использовать, например, Rails для частей Registration / Login - после регистрации напишите cookie сессии в redis вместе с разрешениями пользователя (за какой игрой он может следить) и передайте пользователюв приложение Node.js.Там приложение Node может читать информацию о сеансе из Redis и обслуживать пользователя.

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

Answer 2

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