RX против очередей сообщений, таких как rabbitmq или zeromq?

Я новичок в этих парадигмах высокого уровня concurrency, и я начал использовать привязки scala RX. Итак, я пытаюсь понять, как RX отличается от очередей сообщений, таких как RabbitMQ или ZeroMQ?

Они оба, похоже, используют парадигму подписки/публикации. Где-то я увидел твит о том, что RX запускается на RabbitMQ.

Может ли кто-нибудь объяснить различия между RX и очередями обмена сообщениями? Почему я должен выбирать один за другим? Можно ли заменить другого, или они являются взаимоисключающими? В каких областях они перекрываются?

Ответ 1

Стоит щелкнуть ссылку узнать больше на теге [system.reactive], мы разместим там немного информации!

Из введения вы можете видеть, что Rx не является технологией очередности сообщений:

Reactive Extensions (Rx) - это библиотека для создания асинхронных и основанных на событиях программ с использованием наблюдаемых последовательностей и операторов запросов типа LINQ. System.Reactive - это корневое пространство имен, используемое в библиотеке. Используя Rx, разработчики представляют асинхронные потоки данных с использованием операторов LINQ и параметризуют concurrency в асинхронных потоках данных с использованием планировщиков. Проще говоря, Rx = Observables + LINQ + Schedulers.

Итак, Rx и очередность сообщений - действительно отличные технологии, которые могут хорошо дополнять друг друга. Классическим примером является услуга тикета цен на акции - это может быть доставлено через очередь сообщений, но затем преобразовано Rx для группировки, агрегации и фильтрации цен.

Вы можете пойти дальше: так как Entity Framework превращает запросы IQueryable<T> в SQL, запущенные непосредственно в базе данных, вы можете создавать поставщиков, которые обращают запросы Rx IQbservable<T> в собственные запросы, например, фильтр Where может использовать встроенная фильтрация, которая существует во многих технологиях очередей сообщений для непосредственного применения фильтров. Это довольно много работы, хотя и трудно.

Это намного проще и нередко видеть сообщения очереди сообщений, поданные в Rx Subject, чтобы входящие сообщения из очереди были преобразованы в поток Rx для легкого потребления на клиенте. Rx также широко используется в графических интерфейсах для работы с событиями на стороне клиента, такими как нажатия кнопок и изменения текстового поля, что значительно упрощает традиционно сложные сценарии, такие как drag-n-drop и автозаполнение текста через асинхронные серверные запросы. Там хорошие руки в лаборатории, охватывающие более поздний сценарий здесь. Это было написано против раннего выпуска Rx, но все же очень актуально.

Я рекомендую посмотреть эту видео-презентацию Барта де Смета за фантастическое введение: Лечение обработки событий с помощью реактивных расширений (Rx) - включая классическую демонстрационную версию Rx, которая пишет запрос через живой канал от Kinect, чтобы интерпретировать размахивание руками!

Ответ 2

Может ли кто-нибудь объяснить различия между RX и этими другими очередями обмена сообщениями?

Rx - это просто абстракция над событиями (любое событие!). Получение сообщения из распределенной очереди является событием, и часто решения ZeroMQ/RabbitMQ часто вынуждены использовать и комбинировать разные события совсем немного, что очень удобно для Rx.

Так часто Rx делает приложения ZeroMQ/RabbitMQ намного проще, чем в противном случае:)