乐趣区

响应式编程以及反应式编程框架Reactor3的简单介绍

福利

现在关注微信公众号:码农小胖哥,发送关键字【抽奖】进行抽奖,可有机会获取实体编程书籍。【本次抽奖截止到周末,如果错过以后还有很多机会】

前言

Reactor 3 是一个围绕 Reactive Streams 规范构建的库,它在 JVM 上引入了响应式编程的一个范例。目前 Spring5 引入的 Webflux 就是 reactor 3 实现的一个响应式 web 框架。Spring Cloud Gateway 是 Webflux 的一个网关场景实践。想学好上面这两项技术必须搞明白响应式编程以及 Reactor 3。本篇文章中,小胖哥将带你来简单了解响应式编程和 Reactor 3。

为什么要搞响应式

有这么一个场景,产品提了一个这么需求:商品打折,根据商品的原价来计算商品的折扣价。这个需求不是很简单嘛,按照我们通常的做法,搞一个如下的方法就搞定了。

但是如果我折扣改了呢,这时有人该说重新计算啊。这样是不是重新走了一次流程呢,我们需要花精力来维护这种流程逻辑。那么能不能我下游能直接响应上游的变化?就像 excel 表格计算一样,下游始终监听上游,有点风吹草动,结果就会变化。这种潜在的需求就是响应式。响应式编程正是用某种操作符帮助你构建这种关系,而不是执行某种赋值命令。这种思想其实在前端的一些框架中已经风靡很久了。

响应式的特点

基于以上的一个简单事例。我们可以看出如果是响应式一定要有一个触发点。就像我们点击了计算机桌面的 QQ 图标一只企鹅跳啊跳。我们点击了迅雷图标有一只飞鸟在扑腾着翅膀。计算机只维护一个点击图标的事件。也就是说响应式编程一定是一个事件触发机制。并且是以异步和非阻塞的方式发送和接收的。不是我们平常请求 - 响应的同步模型。事件驱动的系统通过 push 而不是 pull 来处理,生产者在有消息时才推送消息给消费者,而不是通过一种浪费资源方式:让 消费者不断地轮询或等待数据。基于这个机制相对高的吞吐量和实时响应也是响应式的特点。事件驱动由于 Publisher 只用关心数据源,Consumer 只用关心
对处理结果的消费。完全是松耦合的。这就给我们很大的操作空间来定制化我们的逻辑组合,从而使异步代码更一睹和可维护。

Reactor 简介

Reactor 3 框架是 Pivotal(Spring 母公司)基于 Reactive Programming 思想实现的。它实现了 Reactive Streams(该规范由 Netflix、TypeSafe、Pivotal 等公司发起的响应式规范)。其他诸如 RxJava 2, Akka Streams, Vert.x 和 Ratpack 也都实现了该规范。
Reactor 有一个很重要概念的就是 backpressure。由于生产者消费者处理数据的能力不对等,很容易产生下游消费能力过载的问题。这就需要一个 backpressure 处理,来告诉上游生产者避免过载。打个比方,一个人负责放水,一个人负责接水,如果放水的速度太快,水桶势必会溅出来,接水的人会根据情况来告诉放水的人什么速度最合适,并且在快满的时候告知放水人关闭开关。
Reactor 还添加了运算符的概念,这些运算符被链接在一起以描述在每个阶段对数据应用的处理。应用运算符返回一个中间 Publisher(实际上,它可以被认为是上游运算符的订阅者和下游的发布者)。数据的最终归纳点是在最终 Subscriber 中(这里还定义了用户角度的业务逻辑)。还拿放水举例,如果我们放水不是为了单纯放水而是造肥宅快乐水。这样就不是一个人接水了,中间加入了原浆,下一个接的人接到了原浆勾兑水,那么这个人充当了最开始的消费者,但是注意他不是最终的消费者。他的下游还有加气儿的。他下游的下游还有罐装操作。到这里整个工艺才算告一段落。这里你也更能看清 backpressure(背压)操作的作用,可能开始是大桶,到罐装流程开始小瓶子了。通过背压来控制出水的速率。

最上面揭示了一个最小单元的 Reactor 流程,源 Publisher 产生数据。但默认情况下,它只有 Subscriber 在注册(订阅)之后才会把数据推送给 Subscriber 执行运算符操作,中间可能伴随者背压处理。其实这些概念更重要的是理解它们。理解了 Reactor 的特性才能为后面更好的学习 java 响应式编程打好基础。
关注公众号:码农小胖哥 获取更多资讯

退出移动版