Можно ли использовать Node-Redis таким образом или я буду придерживаться веб-сокетов? - PullRequest
Новая
       27

Можно ли использовать Node-Redis таким образом или я буду придерживаться веб-сокетов?

0 голосов
/ 26 марта 2020

Я размышлял над проектом, который включает:

  1. Клиент, делающий запрос POST к конечной точке
  2. Затем публикуется маршрут (из конструктора, который возвращает запрос) объект, который я преобразую) в канал Redis. например, 
( {request: String, transid: String, data: Object } )
Другой сервер, прослушивающий этот канал, анализирует JSON -> переключает ключ запроса с объекта Имеет ли функции, такие как проверка учетных данных и т. Д .; Вызывает класс, который возвращает предварительно созданный объект ответа, который преобразуется в str и отправляется обратно по тому же (или другому каналу) обработчику маршрута (который отправил исходный запрос по каналу), который ожидает в асинхронном режиме ожидания (в данном случае fastify.), например,
( { "transid": "1234-Abcd-5678-abcde", "state": Boolean, data: <data> } )

Временная шкала

Обработчик маршрута отправляет запрос Pub в Redis Listener:

  1. ( {request: "auth", transid: "1234-Abcd-5678-abcde", data: { email: "test@test.com", "password": "pass" } )

  2. Подписанный прослушиватель на другом сервере выполняет внутреннюю проверку учетных данных

Публикует обратно на канал Redis

( {transid: "1234-Abcd-5678-abcde", state: false, data: { error: "Incorrect" } } )

Обработчик маршрута отвечает клиенту, используя методы библиотеки c, то есть request.send (200)

Моя проблема в том, что я не совсем понимаю, как мне достичь результата шага 4 в приведенной выше временной шкале; т. е. возможно ли даже ожидать сообщения в обработчике маршрута? Я подошел очень близко, но я задаюсь вопросом, является ли это практичным способом go о вещах, когда я проектирую что-то, что может масштабироваться. (Пользователь отправляет сведения в / конечную точку, обработчик маршрута / конечной точки публикует сообщение json на канал, внешний сервер прослушивает сообщение и отправляет его в оператор switch, т.е. [switch (data.request)], который вызывает функцию, которая выполняет операция БД, а затем использует конструктор класса, чтобы сгенерировать объект для отправки обратно по каналу redis в обработчик маршрута, который будет ожидать ответа, на который затем ответит клиент.)

Могу я спросить если у кого-нибудь есть мнения по этому поводу?

1 Ответ

1 голос
/ 30 марта 2020

Концепция pub / sub заключается в разделении и выполнении асин c задач, но вы заставляете систему использовать стиль syn c, и это пропускает все его плюсы.

Например: если вы publi sh сообщение a никто из подписчиков не получает его .. что вы делаете? Retry? - тайм-аут клиента тикает, ошибка? - но пользователь хочет только войти в систему, а база данных работает и работает

Более того, когда трафик c возрастает, ответы замедляются, потому что у вас будет только один подписчик на все эти сообщения, так как pub / sub транслируется, и вы не хотите обрабатывать логин c дважды! (Я предполагаю)

Таким образом, чтобы решить эту проблему, вы должны реализовать peer2peer logi c, где: - все подписчики получают сообщение - каждый подписчик знает друг друга - один подписчик говорит: «Я сделаю работу» - один «основной» подписчик говорит, что все в порядке - другие подписчики отклоняют сообщение - основной подписчик cra sh, и вам нужны выборы, чтобы получить новый основной .. - et c ...

Но это то, что делает брокер сообщений или API Redis Stream , поэтому вам не нужно реализовывать это самостоятельно. Я делал это в прошлом, но Redis 5 еще не существовало.

По этим причинам, я думаю, вы должны выполнить работу syn c способом syn c. Паб / саб не соответствует вашему примеру использования.

...