reactive stream: 響應式編程

 

既然 Reactive Stream 和 Java 8 引入的 Stream 都叫作流，它們之間有什麼關係呢？有一點關係，Java 8 的 Stream 主要關注在流的過濾，映射，合併，而  Reactive Stream 更進一層，側重的是流的產生與消費，即流在生產與消費者之間的協調。

在進行異步消息處理時，Reactive Streams 和  Actor 是兩種不一樣的編程模式選擇。Reactive Streams 規範相比 Actor 更簡單，只是說收發消息異步，有流量控制。而 Actor 編程模式涉及到 Actor 容錯管理，消息路由，集羣，並支持遠程消息等。

還有共同之處是: 它們定義的 API 都很簡單，編碼時都基本不須要關注線程自己，而實際消息的傳遞都是背後的線程池。因此線程的配置可延遲到部署階段來進行優化處理。

 

1. 由推變拉，數據可屢次消費

Asynchronous processing decouples I/O or computation from the thread that invoked the operation. A handle to the result is given back, usually a java.util.concurrent.Future or similar, that returns either a single object, a collection or an exception. Retrieving a result, that was fetched asynchronously is usually not the end of processing one flow. Once data is obtained, further requests can be issued, either always or conditionally. With Java 8 or the Promise pattern, linear chaining of futures can be set up so that subsequent asynchronous requests are issued. Once conditional processing is needed, the asynchronous flow has to be interrupted and synchronized. While this approach is possible, it does not fully utilize the advantage of asynchronous processing.

 

In contrast to the preceding examples, Publisher<T> objects answer the multiplicity and asynchronous questions in a different fashion: By inverting the Pull pattern into a Push pattern.

A Publisher is the asynchronous/push 「dual」 to the synchronous/pull Iterable

event	Iterable (pull)	Publisher (push)
retrieve data	T next()	onNext(T)
discover error	throws Exception	onError(Exception)
complete	!hasNext()	onCompleted()

2. 不單單是發送一個值，能夠多個值

An Publisher<T> supports emission sequences of values or even infinite streams, not just the emission of single scalar values (as Futures do). You will very much appreciate this fact once you start to work on streams instead of single values. Project Reactor uses two types in its vocabulary: Mono and Flux that are both publishers.

A Mono can emit 0 to 1 events while a Flux can emit 0 to N events.

 

3. 做爲Publisher<T>的消費者，沒必要關心生產者的實現，無論生產者是同步仍是異步，消費者沒必要跟着修改代碼

A Publisher<T> is not biased toward some particular source of concurrency or asynchronicity and how the underlying code is executed - synchronous or asynchronous, running within a ThreadPool. As a consumer of a Publisher<T>, you leave the actual implementation to the supplier, who can change it later on without you having to adapt your code.

 

4. 有訂閱Publisher<T>時，生產者才執行，這是和java.util.concurrent.Future的最大區別

The last key point of a Publisher<T> is that the underlying processing is not started at the time the Publisher<T> is obtained, rather its started at the moment an observer subscribes or signals demand to the Publisher<T>. This is a crucial difference to a java.util.concurrent.Future, which is started somewhere at the time it is created/obtained. So if no observer ever subscribes to the Publisher<T>, nothing ever will happen.

 

 

出處：

Lettuce : Reactive API