Reactive系統(tǒng)怎么理解

這篇文章主要講解了“Reactive系統(tǒng)怎么理解”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Reactive系統(tǒng)怎么理解”吧！

Reactive 的系統(tǒng)就是通過實現(xiàn)回彈性、彈性能夠?qū)蛻粽埱筮M(jìn)行及時響應(yīng)的系統(tǒng)。

正如 Reactive Manifesto 說的：

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable.

說到松耦合，最基本的模式之一就算是“觀察者模式”了。從觀察者模式更進(jìn)一步，可以衍生出“發(fā)布訂閱模式”。較之前者，發(fā)布訂閱模式多了一個‘事件通道’的角色。通過這個通道，使得訂閱者不必知道發(fā)布者——兩者解耦。

響應(yīng)式流 = 觀察者 + 迭代器

從 Iterator 定義看，Iterator是一個“拉”模型，當(dāng)我們需要數(shù)據(jù)時通過調(diào)用 next()拉取，hasNext()是查詢是否還有數(shù)據(jù)可用。如果上游數(shù)據(jù)有什么異常情況，只能是通過 next()拋出的異常感知甚至感知不到。public interface Iterator { E next(); boolean hasNext(); }

以 RxJava 的 RxObserver 為例，感受下其接口語義上的改進(jìn)：

public interface RxObserver<T> {
  void onNext(T next);
  void onComplete();
  void onError();
}

以 on 形式的前綴開頭的方法名讓我很明顯的感受到一種“通知”的味道。上游組件告訴我們有新數(shù)據(jù)了、結(jié)束了、出錯了！一種“推”的味道。

演進(jìn)到這一步是不是就完美了呢？不。
如果 RxObserver 與上游組件是跨網(wǎng)絡(luò)通信，那么我們可以想象每次的 onNext 通過網(wǎng)絡(luò)一次處理一個數(shù)據(jù)的這種模式并不高效。而且 RxObserver 不能想上游表達(dá)自己的需求(比如需要幾個數(shù)據(jù)？不再需要數(shù)據(jù)等)，這就很容易延伸到 RxObserver 作為消費(fèi)者的處理速度與上游不匹配時如何與上游協(xié)調(diào)工作這樣的問題。
Reactive Stream 規(guī)范對以上需求進(jìn)行了標(biāo)準(zhǔn)化，如下。其中 Subscription 就可用于向上游 Publisher 表達(dá)是否還需要、需要多少數(shù)據(jù)這樣的請求。如果每次 request(1)，整個模式就相當(dāng)于“拉”模型；request(Integer.MAX_VALUE)就相當(dāng)于“推”模型了。

public interface Publisher<T> {
    public void subscribe(Subscriber<? super T> s);
}

public interface Subscriber<T> {
    public void onSubscribe(Subscription s);
    public void onNext(T t);
    public void onError(Throwable t);
    public void onComplete();
}

public interface Subscription {
    public void request(long n);
    public void cancel();
}

public interface Processor<T, R> extends Subscriber<T>, Publisher<R> {
}

感謝各位的閱讀，以上就是“Reactive系統(tǒng)怎么理解”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Reactive系統(tǒng)怎么理解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！