读Java实战（第二版）笔记17_反应式编程

1. 再次出现在聚光灯下的原因

1.1. 基本思想已经有二三十年的历史

1.2. 大数据

1.2.1. 以PB计量的大数据

1.2.2. 当前互联网中流量最大的部分是移动流量

1.2.3. 物联网（Internet of things, IoT）流量取代移动流量成为互联网流量的主流，这种情况还会进一步加剧

1.3. 异构环境

1.3.1. 移动设备

1.3.2. 运行着数千个多核处理器的云端集群

1.4. 使用模式

1.4.1. 用户期望毫秒级的响应时间

1.4.2. 希望应用百分之百时时刻刻都在线

2. 反应式编程

2.1. 一种利用反应式流的编程技术

2.1.1. 以异步方式处理潜在无边界数据流的标准技术

2.2. 以异步的方式处理、整合来自不同系统和源头的数据流

2.2.1. 比线程更轻量级

2.2.2. 提升了创建并发以及异步应用的抽象层次

2.2.3. 任务能以异步的方式运行

2.3. 可以构建单一组件或者应用

2.4. 协调多个组件，将它们搭建成一个反应式系统

2.5. 主线程池中运行的线程执行的都为无阻塞的操作

2.5.1. 确保所有的CPU核都能得到最充分的利用

2.6. 不要在主事件循环中添加可能阻塞的操作

2.6.1. 所有I/O密集型的操作

2.6.1.1. 访问数据库或文件系统

2.6.1.2. 调用远程服务

2.6.2. 无法预测何时能够结束

2.6.3. 可能消耗比较长时间的事件

2.7. 开辟独立的线程池用于执行阻塞式操作

2.7.1. 为CPU密集型和I/O密集型的操作分别创建单独的线程池

2.7.2. 更精细地监控不同类型任务的性能

2.7.3. 更好地配置和调整线程池的规模

2.7.4. 更好地适应业务的需求

2.8. 背压

2.8.1. 发表-订阅模式下的一种常见的流量控制机制

2.8.2. 提供了一种协议，可以在不阻塞线程的情况下，避免数据接收方被压垮

2.8.3. 避免流中事件处理的消费者由于处理速度较慢，被一个或多个快速的生产者压垮

2.8.4. 组件需要一种方式来向上游生产者反馈，让它们减缓生产速度

2.8.5. 告诉生产者它在接收更多数据之前，在给定的时间内能够接受和处理多少事件

3. Flow类

3.1. java.util.concurrent.Flow

3.1.1. Java 9

3.2. 所有实现该接口的库需要遵守的合约

3.2.1. 使构建于不同的反应式库之上的应用间能相互协调、相互理解沟通的通用语言

3.2.2. 接口可以帮助你更好地构建你的程序思维

3.2.3. 并不能帮你更快地完成程序设计

3.3. 标准化使得不同库之间互通和调用成为可能

3.3.1. Akka

3.3.2. RxJava

3.4. 发布-订阅”模型

3.4.1. 发布者（Publisher）

3.4.1.1. 顺序事件的提供者

3.4.1.2. 事件的数量可能没有上限

3.4.1.3. 受背压机制的制约

3.4.1.4. 按照Subscriber的反馈进行元素的生产

3.4.1.5. Java函数式接口

3.4.2. 订阅者（Subscriber）

3.4.2.1. 把自己注册为该事件的监听方从而完成对Publisher事件的注册

3.4.3. 订阅（Subscription）

3.4.3.1. 流量控制，包括Publisher与Subscriber之间的背压都是由Subscription管理的

3.4.3.2. cancel()方法的实现必须是幂等和线程安全的

3.4.3.2.1. 调用它一次与重复调用多次的效果是同样的

3.4.3.2.2. 任何对Subscription的额外调用都不会有副作用

3.4.4. 处理者（Processor）

3.4.4.1. 反应式流中事件的转化阶段

3.4.4.2. 转换数据

3.4.5. 所有方法都返回void，从而确保它们能以完全异步的方式实现

4. RxJava

4.1. 应用最广泛的反应式库

4.1.1. 诞生于Netflix

4.1.2. 对微软．Net环境中反应式扩展（reactive extension, Rx）项目的迁移

4.1.3. 比Java 9的Flow API更方便

4.1.3.1. 更加丰富的函数集

4.1.3.2. 更灵活地对流进行整合、创建以及过滤操作

4.2. io.reactivex.Observable

4.2.1. 不支持背压

4.2.2. 适用于

4.2.2.1. 用户接口事件（譬如鼠标移动）

4.2.2.2. 流元素不超过一千个

4.2.2.3. 基于图形用户界面的事件流

4.2.2.4. 无法背压或不常发生的事件时

4.2.3. onSubscribe方法需要一个Disposable参数

4.2.4. 只在需要Observable的额外结构时使用Observable，否则就应该继续使用它的Publisher接口

4.3. Subscriber可以通过request(Long.MAX_VALUE)调用关闭背压功能

4.4. just()工厂方法

4.4.1. 将一个或多个元素转换为Observable

4.5. interval工厂方法

4.5.1. 按照固定的时间间隔发出事件

4.6. blockingSubscribe方法

4.6.1. 调用当前线程（在这个例子中就是main函数所在的线程）的回调函数

4.7. 弹珠图

5. 反应式宣言

5.1. 2013年至2014年间发起

5.2. 开发反应式应用和系统的规范

5.3. Jonas Bonér、Dave Farley、Roland Kuhn和Martin Thompson

5.4. 响应性

5.4.1. 反应式系统的响应时间很快

5.4.2. 响应时间应该是稳定且可预测的

5.4.2.1. 用户才能明确地设定他的预期

5.4.2.2. 增强用户的信心

5.5. 韧性

5.5.1. 系统在出现失败时依然能继续响应服务

5.5.1.1. 组件运行时复制

5.5.1.2. 从时间（发送方和接受方都拥有相互独立的生命周期）和空间（发送方和接收方运行于不同的进程）维度对组件进行解耦

5.5.1.3. 任何一个组件都能以异步的方式向其他组件分发任务

5.6. 弹性

5.6.1. 应用的工作负载

5.6.2. 有能力自动地适配和服务更大的负荷

5.7. 消息驱动

5.7.1. 组件间的松耦合

5.7.2. 组件隔离

5.7.3. 位置透明性

5.7.3.1. 实现韧性的决定性要素

5.7.3.2. 使得系统能够依据当前的负荷情况，对应用进行复制或者自动地水平扩展

5.7.3.3. 位置无关的扩展也是反应式应用（异步、并发、即时松耦合）与反应式系统（凭借位置透明性从空间角度解耦）之间的另一个区别

6. 反应式应用

6.1. 主要对临时数据流进行处理

6.2. 事件驱动型

6.2.1. 事件会被所有注册了该事件的组件接收

6.3. 异步、并发、即时松耦合

7. 反应式系统

7.1. 多个独立应用可以像一个单一系统那样步调一致地工作，同时其又具备良好的扩展性

7.2. 各个应用也是充分解耦的

7.2.1. 即使其中某一个应用发生失效，也不会拖垮整个系统

7.3. 用于构造应用以及协调组件间的通信

7.3.1. 以异步的方式发送和接收的，这种方式有效地解耦了发送方与接收方

7.4. 消息驱动系统

7.4.1. 消息往往是直接发送给某个单一目标的

7.5. 组件间完全的解耦合既是实现有效隔离的必要前提，也是保障系统在遭遇失效（韧性）和超大负荷（弹性）时仍能保持响应的基础

7.6. 韧性更偏向于容错

7.6.1. 系统不只要能优雅地降级，更重要的是能通过隔离失效组件，将系统重新拉回健康状

7.6.2. 失效节点的管理可以不受失效组件自身的影响，在一个安全的上下文中进行

7.7. 凭借位置透明性从空间角度解耦

7.7.1. 反应式系统的所有组件都可以和其他任何服务通信，无须顾忌接收方在什么位置