共计 6787 个字符，预计需要花费 17 分钟才能阅读完成。
导读：前端开发的实质是什么？响应式编程绝对于 MVVM 或者 Redux 有什么长处？响应式编程的思维是否能够利用到后端开发中？本文以一个新闻网站为例，论述在前端开发中如何应用响应式编程思维；再以计算电商平台双 11 每小时成交额为例，分享同样的思维在实时计算中的雷同与不同之处。
一、前端开发在开发什么
大家在前端开发的过程中，可能会想过这样一个问题：前端开发到底是在开发什么？在我看来，前端开发的实质是让网页视图可能正确地响应相干事件。在这句话中有三个关键字：” 网页视图 ”，” 正确地响应 ” 和 ” 相干事件 ”。
“ 相干事件 ” 可能包含页面点击，鼠标滑动，定时器，服务端申请等等，” 正确地响应 ” 意味着咱们要依据相干的事件来批改一些状态，而 ” 网页视图 ” 就是咱们前端开发中最相熟的局部了。
依照这样的观点咱们能够给出这样 视图 = 响应函数(事件) 的公式：
View = reactionFn(Event)
在前端开发中，须要被处理事件能够归类为以下三种：
● 用户执行页面动作，例如 click, mousemove 等事件。
● 近程服务端与本地的数据交互，例如 fetch, websocket。
● 本地的异步事件，例如 setTimeout, setInterval async_event。
这样咱们的公式就能够进一步推导为：
View = reactionFn(UserEvent | Timer | Remote API)
二、利用中的逻辑解决
为了可能更进一步了解这个公式与前端开发的关系，咱们以新闻网站举例，该网站有以下三个要求：
● 单击刷新：单击 Button 刷新数据。
● 勾选刷新：勾选 Checkbox 时主动刷新，否则进行主动刷新。
● 下拉刷新：当用户从屏幕顶端下拉时刷新数据。
如果从前端的角度剖析，这三种需要别离对应着：
● 单击刷新：click -> fetch
● 勾选刷新：change -> (setInterval + clearInterval) -> fetch
● 下拉刷新：(touchstart + touchmove + touchend) -> fetch news_app
1.MVVM
在 MVVM 的模式下，对应上文的响应函数（reactionFn）会在 Model 与 ViewModel 或者 View 与 ViewModel 之间进行被执行，而事件 (Event) 会在 View 与 ViewModel 之间进行解决。
MVVM 能够很好的形象视图层与数据层，然而响应函数（reactionFn）会散落在不同的转换过程中，这会导致数据的赋值与收集过程难以进行准确追踪。另外因为事件 (Event) 的解决在该模型中与视图局部严密相干，导致 View 与 ViewModel 之间对事件处理的逻辑复用艰难。
2.Redux
在 Redux 最简略的模型下，若干个事件 (Event) 的组合会对应到一个 Action 上，而 reducer 函数能够被间接认为与上文提到的响应函数 (reactionFn) 对应。
然而在 Redux 中：
● State 只能用于形容中间状态，而不能形容两头过程。
● Action 与 Event 的关系并非一一对应导致 State 难以追踪理论变动起源。
3. 响应式编程与 RxJS
维基百科中是这样定义响应式编程：
在计算中，响应式编程或反应式编程（英语：Reactive programming）是一种面向数据流和变动流传的申明式编程范式。这意味着能够在编程语言中很不便地表白动态或动静的数据流，而相干的计算模型会主动将变动的值通过数据流进行流传。
以数据流维度重新考虑用户应用该利用的流程：
● 点击按钮 -> 触发刷新事件 -> 发送申请 -> 更新视图
● 勾选主动刷新
● 手指触摸屏幕
● 主动刷新距离 -> 触发刷新事件 -> 发送申请 -> 更新视图
● 手指在屏幕上下滑
● 主动刷新距离 -> 触发刷新事件 -> 发送申请 -> 更新视图
● 手指在屏幕上进行滑动 -> 触发下拉刷新事件 -> 发送申请 -> 更新视图
● 主动刷新距离 -> 触发刷新事件 -> 发送申请 -> 更新视图
● 敞开主动刷新
以 Marbles 图示意：
拆分上图逻辑，就会失去应用响应式编程开发以后新闻利用时的三个步骤：
● 定义源数据流
● 组合 / 转换数据流
● 生产数据流并更新视图
咱们别离来进行详细描述。
定义源数据流
应用 RxJS，咱们能够很不便的定义出各种 Event 数据流。
1）单击操作
波及 click 数据流。
click$ = fromEvent<MouseEvent>(document.querySelector('button'), 'click');2）勾选操作
波及 change 数据流。
change$ = fromEvent(document.querySelector('input'), 'change');3）下拉操作
波及 touchstart, touchmove 与 touchend 三个数据流。
touchstart$ = fromEvent<TouchEvent>(document, 'touchstart');
touchend$ = fromEvent<TouchEvent>(document, 'touchend');
touchmove$ = fromEvent<TouchEvent>(document, 'touchmove');4）定时刷新
interval$ = interval(5000);5）服务端申请
fetch$ = fromFetch('https://randomapi.azurewebsites.net/api/users');组合 / 转换数据流
1）点击刷新事件流
在点击刷新时，咱们心愿短时间内屡次点击只触发最初一次，这通过 RxJS 的 debounceTime operator 就能够实现。
clickRefresh$ = this.click$.pipe(debounceTime(300));2）主动刷新流
应用 RxJS 的 switchMap 与之前定义好的 interval$ 数据流配合。
autoRefresh$ = change$.pipe(switchMap(enabled => (enabled ? interval$ : EMPTY))
);3）下拉刷新流
联合之前定义好的 touchstart$touchmove$ 与 touchend$ 数据流。
pullRefresh$ = touchstart$.pipe(
switchMap(touchStartEvent =>
touchmove$.pipe(map(touchMoveEvent => touchMoveEvent.touches[0].pageY - touchStartEvent.touches[0].pageY),
takeUntil(touchend$)
)
),
filter(position => position >= 300),
take(1),
repeat());最初，咱们通过 merge 函数将定义好的 clickRefresh$autoRefresh$ 与 pullRefresh$ 合并，就失去了刷新数据流。
refresh$ = merge(clickRefresh$, autoRefresh$, pullRefresh$));生产数据流并更新视图
将刷新数据流间接通过 switchMap 打平到在第一步到定义好的 fetch$，咱们就取得了视图数据流。
能够通过在 Angular 框架中能够间接 async pipe 将视图流间接映射为视图：
<div *ngFor="let user of view$ | async">
</div>在其余框架中能够通过 subscribe 取得数据流中的实在数据，再更新视图。
至此，咱们就应用响应式编程残缺的开发实现了以后新闻利用，示例代码 [1] 由 Angular 开发，行数不超过 160 行。
咱们总结一下，应用响应式编程思维开发前端利用时经验的三个过程与第一节中公式的对应关系：
View = reactionFn(UserEvent | Timer | Remote API)
1）形容源数据流
与事件 UserEvent | Timer | Remote API 对应，在 RxJS 中对应函数别离是：
● UserEvent: fromEvent
● Timer: interval, timer
● Remote API: fromFetch, webSocket
2）组合转换数据流
与响应函数 (reactionFn) 对应，在 RxJS 中对应的局部办法是：
● COMBINING: merge, combineLatest, zip
● MAPPING: map
● FILTERING: filter
● REDUCING: reduce, max, count, scan
● TAKING: take, takeWhile
● SKIPPING: skip, skipWhile, takeLast, last
● TIME: delay, debounceTime, throttleTime
3）生产数据流更新视图
与 View 对应，在 RxJS 及 Angular 中能够应用：
● subscribe
● async pipe
响应式编程绝对于 MVVM 或者 Redux 有什么长处呢？
● 形容事件产生的自身，而非计算过程或者中间状态。
● 提供了组合和转换数据流的办法，这也意味着咱们取得了复用继续变动数据的办法。
● 因为所有数据流均由层层组合与转换取得，这也就意味着咱们能够准确追踪事件及数据变动的起源。
如果咱们将 RxJS 的 Marbles 图的时间轴含糊，并在每次视图更新时减少纵切面，咱们就会发现这样两件乏味的事件：
● Action 是 EventStream 的简化。
● State 是 Stream 在某个时刻的对应。
难怪咱们能够在 Redux 官网中有这样一句话：如果你曾经应用了 RxJS，很可能你不再须要 Redux 了。
The question is: do you really need Redux if you already use Rx? Maybe not. It’s not hard to re-implement Redux in Rx. Some say it’s a two-liner using Rx.scan() method. It may very well be!
写到这里，咱们对网页视图可能正确地响应相干事件这句话是否能够进行进一步的形象呢？
所有事件 — 找到 –> 相干事件 — 做出 –> 响应
而按工夫程序产生的事件，实质上就是数据流，进一步拓展就可变成：
源数据流 — 转换 –> 两头数据流 — 订阅 –> 生产数据流
这正是响应式编程在前端可能完满工作的根底思维。然而该思维是否只在前端开发中有所利用呢？
答案是否定的，该思维不仅能够利用于前端开发，在后端开发乃至实时计算中都有着宽泛的利用。
三、突破信息之墙
在前后端开发者之间，通常由一面叫 REST API 的信息之墙隔开，REST API 隔离了前后端开发者的职责，晋升了开发效率。但它同样让前后端开发者的眼界被这面墙隔开，让咱们试着来推倒这面信息之墙，一窥同样的思维在实时计算中的利用。
1. 实时计算 与 Apache Flink
在开始下一部分之前，让咱们先介绍一下 Flink。Apache Flink 是由 Apache 软件基金会开发的开源流解决框架，用于在无边界和有边界数据流上进行有状态的计算。它的数据流编程模型在无限和有限数据集上提供单次事件（event-at-a-time）解决能力。
在理论的利用中，Flink 通常用于开发以下三种利用：
● 事件驱动型利用 事件驱动型利用从一个或多个事件流提取数据，并依据到来的事件触发计算、状态更新或其余内部动作。场景包含基于规定的报警，异样检测，反欺诈等等。
● 数据分析利用 数据分析工作须要从原始数据中提取有价值的信息和指标。例如双十一成交额计算，网络品质监测等等。
● 数据管道 (ETL) 利用 提取 - 转换 - 加载（ETL）是一种在存储系统之间进行数据转换和迁徙的罕用办法。ETL 作业通常会周期性地触发，将数据从事务型数据库拷贝到剖析型数据库或数据仓库。
咱们这里以计算电商平台双十一每小时成交额为例，看下咱们在之前章节失去计划是否依然能够持续应用。
在这个场景中咱们首先要获取用户购物下单数据，随后计算每小时成交数据，而后将每小时的成交数据转存到数据库并被 Redis 缓存，最终通过接口获取后展现在页面中。
在这个链路中的数据流解决逻辑为：
用户下单数据流 — 转换 –> 每小时成交数据流 — 订阅 –> 写入数据库
与之前章节中介绍的：
源数据流 — 转换 –> 两头数据流 — 订阅 –> 生产数据流
思维完全一致。
如果咱们用 Marbles 形容这个过程，就会失去这样的后果，看起来很简略，仿佛应用 RxJS 的 window operator 也能够实现同样的性能，然而事实真的如此吗？
2. 被暗藏的复杂度
实在的实时计算比前端中响应式编程的复杂度要高很多，咱们在这里举几个例子：
事件乱序
在前端开发过程中，咱们也会碰到事件乱序的状况，最经典的状况先发动的申请后收到响应，能够用如下的 Marbles 图示意。这种状况在前端有很多种方法进行解决，咱们在这里就略过不讲。
咱们明天想介绍的是数据处理时面临的工夫乱序状况。在前端开发中，咱们有一个很重要的前提，这个前提大幅度降低了开发前端利用的复杂度，那就是：前端事件的产生工夫和解决工夫雷同。
设想一下，如果用户执行页面动作，例如 click, mousemove 等事件都变成了异步事件，并且响应工夫未知，那整个前端的开发复杂度会如何。
然而事件的产生工夫与解决工夫不同，在实时计算畛域是一个重要的前提。咱们仍以每小时成交额计算为例，当原始数据流通过层层传输之后，在计算节点的数据的先后顺很可能曾经乱序了。
如果咱们依然以数据的到来工夫来进行窗口划分，最初的计算结果就会产生谬误：
为了让 window2 的窗口的计算结果正确，咱们须要期待 late event 到来之后进行计算，然而这样咱们就面临了一个两难问题：
● 有限等上来：late event 可能在传输过程中失落，window2 窗口永远没有数据产出。
● 等待时间太短：late event 还没有到来，计算结果谬误。
Flink 引入了 Watermark 机制来解决这个问题，Watermark 定义了什么时候不再期待 late event，实质上提供了实时计算的准确性和实时性的折中计划。
对于 Watermark 有个形象的比喻：上学的时候，老师会将班级的门关上，而后说：“从这个点之后来的同学都算早退了，通通罚站“。在 Flink 中，Watermark 充当了老师关门的这个动作。
数据反压
在浏览器中应用 RxJS 时，不晓得大家有没有思考这样一种状况：observable 产生的速度快于 operator 或者 observer 生产的速度时，会产生大量的未生产的数据被缓存在内存中。这种状况被称为反压，侥幸的是，在前端产生数据反压只会导致浏览器内存被大量占用，除此之外不会有更重大的结果。
然而在实时计算中，当数据产生的速度高于两头节点解决能力，或者超过了上游数据的生产能力时，该当如何解决？
对于许多流应用程序来说，数据失落是不可承受的，为了保障这一点，Flink 设计了这样一种机制：
● 在现实状况，在一个长久通道中缓冲数据。
● 当数据产生的速度高于两头节点解决能力，或者超过了上游数据的生产能力时，速度较慢的接收器会在队列的缓冲作用耗尽后立刻升高发送器的速度。更形象的比喻是，在数据流流速变慢时，将整个管道从水槽“回压”到水源，并对水源进行节流，以便将速度调整到最慢的局部，从而达到稳固状态。
Checkpoint
实时计算畛域，每秒钟解决的数据可能有数十亿条，这些数据的解决不可能由单台机器独立实现。事实上，在 Flink 中，operator 运算逻辑会由不同的 subtask 在 不同的 taskmanager 上执行，这时咱们就面临了另外一个问题，当某台机器产生问题时，整体的运算逻辑与状态该如何解决能力保障最初运算后果的正确性？
Flink 中引入了 checkpoint 机制用于保障能够对作业的状态和计算地位进行复原，checkpoint 使 Flink 的状态具备良好的容错性。Flink 应用了 Chandy-Lamport algorithm 算法的一种变体，称为异步 barrier 快照（asynchronous barrier snapshotting）。
当开始 checkpoint 时，它会让所有 sources 记录它们的偏移量，并将编号的 checkpoint barriers 插入到它们的流中。这些 barriers 会通过每个 operator 时标注每个 checkpoint 前后的流局部。
当产生谬误时，Flink 能够依据 checkpoint 存储的 state 进行状态复原，保障最终后果的正确性。
冰山一角
因为篇幅的关系，明天介绍的局部只能是冰山一角，不过：
源数据流 — 转换 –> 两头数据流 — 订阅 –> 生产数据流
的模型无论在响应式编程还是实时计算都是通用的，心愿这篇文章可能让大家对数据流的思维有更多的思考。
相干链接：
[1]https://github.com/vthinkxie/…
