反应式编程和消息队列的区别

Question

这些天我忙于 Reactive 概念。我已经理解了两个独立的概念，即 Reactive System 和 Reactive Programming。另外，我知道 Reactive System 是一个更大的概念，它包含四个属性：

1. 响应式
2. 有弹性
3. 可扩展
4. 事件驱动

图片参考：medium.com

我的问题是关于反应式编程，我知道它的目标是通过 Observable/Subscriber 模型进行异步编程。

图片参考：https://hub.packtpub.com/introduction-reactive-programming/

现在我对响应式编程和消息队列之间的区别感到困惑。我在 Message Oriented Middleware 和 JMS 等相关标准方面有一些经验，我认为 Reactive Programming 与在侦听器模式下使用消息队列相同非阻塞模式。

我想明确反应式编程真正的概念。

Answer 1

响应式编程是旧概念的新名称。这意味着更喜欢事件驱动的计算而不是请求-回复计算。或“推”与“拉”。因此，您无需编写等待某事到达的代码，而是定义在某事发生时执行的回调。 观察者模式是反应式编程的一个很好的例子，好莱坞原则（“不要打电话给我们，我们会打电话给你”）也是如此。

在 JMS 术语中，如果你在你的消费者上定义了一个 MessageListener，你就是在做响应式编程：MessageConsumer.setMessageListener(MessageListener listener)

然后，您的 API 或其他代码可以决定同时处理什么，如果有东西从队列或主题到达，则调用该回调。

使用MessageConsumer.receive(long timeout) 的替代方法不是反应式编程。在下一条消息到达之前，您正在阻止当前线程。

以事件驱动或反应式的方式思考有时需要一点飞跃，但值得付出努力。

在查看系统本身时，我认为使用主题构建的基础架构是一个反应式系统。使用队列构建的基础设施不是。

Answer 2

在同步编程中，blocking queues被广泛使用。如果消费者没有及时处理消息，blocking queue 会暂停生产者线程，以避免消息过多消耗内存。

在同步世界中，必须避免线程阻塞，所以blocking queues 是不可接受的。相反，reactive streams 被使用，它通知生产者允许发送多少消息。

从技术上讲，reactive stream 是通常的消息流加上permissions 的反向流。 Permissions 就像无法区分的消息，不需要存储，只需要计数。在同步世界中，permissions 由java.lang.Semaphore 和java.lang.CountdownLatch 存储（计数）。不幸的是，大多数异步库没有为开发人员提供单独的构造来处理permissions。我知道的唯一例外是我自己的库 df4j（可以在 Github 上找到）。

除了（隐式）异步信号量的概念，我在reactive programming 炒作中找不到任何其他意义。