Reactive系統怎么理解

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

Reactive 的系統就是通過實現回彈性、彈性能夠對客戶請求進行及時響應的系統。

正如 Reactive Manifesto 說的：

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

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

響應式流 = 觀察者 + 迭代器

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

以 RxJava 的 RxObserver 為例，感受下其接口語義上的改進：

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

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

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

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系統怎么理解”的內容了，經過本文的學習后，相信大家對Reactive系統怎么理解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！