RxJava Backpressure - Geri tepme

Giriş

Açıklaması şöyle. Yani hızlı bir Producer ve yavaş bir Consumer varsa, Producer bu durum karşısında ezilmez.

... considering a fast data producer and a slow data consumer, backpressure is the mechanism that 'pushes back' on the producer not to be overwhelmed by data.

Şeklen şöyle

Açıklaması şöyle. Producer'ın ezilmemesinin sebebi, tüketen tarafın Subscription.request() metodu ile veriyi çekmesi.

A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.

The intent of this rule is to establish that it is the responsibility of the Subscriber to decide when and how many elements it is able and willing to receive. To avoid signal reordering caused by reentrant Subscription methods, it is strongly RECOMMENDED for synchronous Subscriber implementations to invoke Subscription methods at the very end of any signal processing. It is RECOMMENDED that Subscribers request the upper limit of what they are able to process, as requesting only one element at a time results in an inherently inefficient "stop-and-wait" protocol.

-- Reactive Streams specifications for the JVM

Açıklaması şöyle

To cope with that, RxJava offers two main strategies to handle 'overproduced' items:

1. Store items in a buffer

2. Drop items

RxJava 3 Sınıfları

Sınıflar şöyle

Flowable

Açıklaması şöyle

A flow of 0..N items. It supports Reactive-Streams and backpressure.

Observable

Açıklaması şöyle

A flow of 0..N items. It doesn't support backpressure.

Single

Açıklaması şöyle

A flow of exactly: 1 item, or an error.

Maybe

Açıklaması şöyle

A flow with either: no items, exactly one item, or an error.

Completable

Açıklaması şöyle

A flow with no item but either: a completion, or an error signal.