Socket.io vs RethinkDB changefeed

В настоящее время я использую socket.io без RethinkDB следующим образом:

Клиенты выделяют события в socket.io, который получает события, испускает разные клиенты и сохраняет db для сохранения. Новое соединение с клиентом будет получать существующие данные из db, а затем прослушивать новые события через socket.io.

Как бы мне переключиться на RethinkDB и changefeed?

Как я вижу то же самое, что работает с RethinkDB, клиент может сделать POST (который вставляет в RethinkDB) вместо того, чтобы выходить на socket.io, а затем socket.io наблюдает за изменением RethinkDB и испусканием для всех клиентов, когда он получает новые данные.

Как этот метод использует RethinkDB и changefeed лучше, чем мой текущий метод? Для меня они оба чувствуют, что они выполняют одно и то же, но я не вижу никаких очевидных преимуществ в методе RethinkDB, и потому, что я собираюсь перейти к db, а не сразу же из socket.io на сервере, это будет наверняка будет немного медленнее.

Ответ 1

Во-первых, давайте проясним взаимосвязь между сокетными и RethinkDB changefeeds. Socket.io предназначен для обмена в реальном времени между клиентом (браузером) и сервером (Node.js). RethinkDB changfeeds - путь для вашего сервера (Node.js) для прослушивания изменений в базе данных. Клиент не может напрямую связываться с RethinkDB.

Очень типичной архитектурой для приложения реального времени является изменение подписей RethinkDB на изменения в базе данных, а затем использование socket.io для передачи этих изменений клиенту. Клиент обычно также отправляет сообщения, которые могут быть записаны в вашу базу данных, в зависимости от вашей логики приложения.

Да, вы можете просто выпустить все сообщения через socket.io, затем передать все сообщения всем клиентам, а затем просто написать эти сообщения в базу данных для сохранения. Также верно, что это происходит быстрее, но для этого подхода есть ряд недостатков.

1. База данных как единственный источник истины

Простейшая проблема заключается в следующем:

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

Это лишь некоторые быстрые примеры, в которых из-за вашей архитектуры вы потеряете или получите данные из синхронизации. И чтобы повторить это, вы потеряете данные, потому что ваш основной источник истины находится в памяти. У вас могут также быть расхождения между данными в вашем приложении Node.js и вашей БД.

Дело в том, что база данных всегда должна быть вашим единственным источником правды, и вы должны только подтверждать данные, когда они записываются на диск. Я не знаю, как кто-то сможет спать по ночам.

2. Расширенные запросы

Если вы просто передаете все новые сообщения от всех клиентов ко всем клиентам через socket.io, теперь у вас должна быть довольно сложная логика для вашего клиента, чтобы отфильтровать все важные данные. Примите во внимание, что вы передаете много бесполезных данных по сети, которые клиент фактически не использует.

Альтернативой является создание паб/подсистемы, в которой вы подписываетесь на определенные каналы (или что-то в этом роде), чтобы отфильтровывать данные, которые действительно важны для клиента.

RethinkDB решает это, предоставляя ему очень собственный язык запросов, который вы можете подключить к файлам changefeeds. Если клиенту, например, нужны все пользователи в моей таблице users в возрасте от 20 до 30 лет, которые живут в штате Калифорния, в 10 милях от Сан-Франциско, и которые купили книгу за последние 6 месяцев, это может быть выражено в ReQL (язык запросов RethinkDB), и для этого запроса может быть настроен changefeed, так что клиент получает уведомление только при соответствующих изменениях. Это гораздо сложнее сделать с помощью Socket.io и Node.js.

3. Масштабируемость

Последняя проблема, которую решает RethinkDB, заключается в том, что это гораздо более масштабируемое решение для простого хранения всего в памяти (через Socket.io и Node.js). Поскольку RethinkDB построен с нуля для распространения, у вас может быть кластер из 20 + RethinkDB узлов с осколками и репликами. Каждый запрос RethinkDB, который вы пишете, распространяется по умолчанию. Теперь у вас может быть 20 + других Node.js узлов, которые не имеют состояния и все слушают changfeeds. Поскольку база данных является основным источником правды, это не проблема.

Альтернативой было бы ограничить себя одним сервером, например, какая-то другая система pub/sub (построенная на чем-то вроде Reddis), есть только одна база данных, которую вы опросили... Там, вероятно, больше примеров, но вы может видеть, где я собираюсь с этим.

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