【Reactor学习-三——从命令式编程到反应式编程】

From Imperative to Reactive Programming

反应式库（如Reactor）旨在解决JVM上“经典”异步方法的这些缺点，同时还关注几个其他方面：

• 可组合性和可读性
• 数据作为一个流，使用丰富的运算符词汇表进行操作
• 在你订阅之前什么都不会发生
• 背压或消费者向生产者发出排放率过高信号的能力
• 高级别但高价值的抽象，与并发无关

组合性，可读性

类似流水线

您可以将被动应用程序处理的数据视为在装配线中移动。反应器既是传送带又是工作站。原材料从一个来源（原始出版商）倾泻而出，最终成为成品，准备推送到消费者（或订阅者）手中。
原材料可以经过各种转换和其他中间步骤，也可以是将中间零件聚合在一起的大型装配线的一部分。如果某一点出现故障或堵塞（可能包装产品需要的时间过长），受影响的工作站可以向上游发出信号，以限制原材料的流动。

操作性

在反应堆中，操作员是组装模拟中的工作站。每个操作员向发布者添加行为，并将上一步的发布者包装到新实例中。因此，整个链是链接的，因此数据源于第一个发布者，并沿着链向下移动，通过每个链接进行转换。最终，订阅者完成了这个过程。请记住，在订阅者订阅发布者之前，一切都不会发生，我们很快就会看到这一点。
了解运营商创建新实例可以帮助您避免一个常见错误，该错误会导致您认为您在链中使用的运营商没有被应用。请参见常见问题解答中的此项。
虽然Reactive Streams规范根本没有指定运算符，但Reactor等Reactive库的最佳附加值之一是它们提供的运算符的丰富词汇表。这些涉及很多方面，从简单的转换和过滤到复杂的编排和错误处理。

订阅（ subscribe()）之前一切都不会发生

在Reactor中，当您编写发布者链时，默认情况下，数据不会开始注入其中。相反，您可以创建异步过程的抽象描述（这有助于重用性和组合）。
通过订阅，您可以将发布者与订阅者绑定，从而触发整个链中的数据流。这是通过来自订阅者的单个请求信号在内部实现的，该信号向上游传播，一直传回源发布者。

回压(Backpressure)

大多数地方都是根据翻译网站或机器人翻译成背压,少数地方翻译为回压，我也认为翻译为回压更契合场景的意思。

向上游传播信号也用于实现回压，我们在流水线类比中将其描述为当下游工作站的处理速度比上游工作站慢时，向上发送的反馈信号。
Reactive Streams规范定义的真正机制与类比非常接近：订阅者可以在无边界模式下工作，让源以其最快的可实现速率推送所有数据，或者可以使用请求机制向源发出信号，表示它准备处理最多n个元素。
中间操作员也可以在传输过程中更改请求。想象一下，一个缓冲区操作符将元素分成10个批次。如果订阅者请求一次缓冲区，则生产者可以生成十个元素。一些操作还实现了预取策略，这可以避免一个请求多次往返，如果在请求之前生成元素的成本不太高的话，这是有益的。
这将推模式转换为推拉混合模式，这样下游可以从上游拉n个元素（在它们随时可用的情况下）。但如果这些元素还没有准备好，它们就会在上游推送时运行困难。

冷/热反应序列

Rx系列反应式库分成了两大类反应序列：热序列和冷序列。这种区别主要与反应流对订阅者的反应有关：

• 对于每个订阅者，一个冷序列重新开始，包括在数据源。例如，如果源包装了一个HTTP调用，则会为每个订阅发出一个新的HTTP请求。

• 对于每个订阅者，热序列并不是从头开始的。相反，迟到的订阅者会收到他们订阅后发出的信号。然而，请注意，一些热反应流可以完全或部分缓存或重放排放历史。从一般的角度来看，热序列甚至可以在没有订阅者在监听时发出（这是“订阅之前什么都不会发生”规则的例外）。

有关反应堆中热态与冷态的更多信息，请参阅本反应堆特定章节。