这篇文章主要讲解了“Reactive系统怎么理解”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Reactive系统怎么理解”吧！
成都创新互联公司主要从事成都网站设计、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务德安,十余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220
Reactive 的系统就是通过实现回弹性、弹性能够对客户请求进行及时响应的系统。
正如 Reactive Manifesto 说的：
Systems built as Reactive Systems are more flexible, loosely-coupled and scalable.
说到松耦合，最基本的模式之一就算是“观察者模式”了。从观察者模式更进一步，可以衍生出“发布订阅模式”。较之前者，发布订阅模式多了一个‘事件通道’的角色。通过这个通道，使得订阅者不必知道发布者——两者解耦。
响应式流 = 观察者 + 迭代器
从 Iterator 定义看，Iterator是一个“拉”模型，当我们需要数据时通过调用 next()拉取，hasNext()是查询是否还有数据可用。如果上游数据有什么异常情况，只能是通过 next()抛出的异常感知甚至感知不到。public interface Iterator
以 RxJava 的 RxObserver 为例，感受下其接口语义上的改进：
public interface RxObserver {
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 {
public void subscribe(Subscriber s);
}
public interface Subscriber {
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 extends Subscriber, Publisher {
}
感谢各位的阅读，以上就是“Reactive系统怎么理解”的内容了，经过本文的学习后，相信大家对Reactive系统怎么理解这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
