36 lines
2.2 KiB
Markdown
36 lines
2.2 KiB
Markdown
# Spring Webflux
|
||
## Concept
|
||
### 核心机制
|
||
#### reactive
|
||
reactive代表基于“事件响应”的编程模型，
|
||
#### back pressure
|
||
在spring webflux中，`back pressure`为反应式编程的核心机制，用于协调生产者和消费者之间的速率差异，令系统在高负载或资源受限的情况下仍能稳定运行。
|
||
|
||
- 同步场景：在同步场景下，阻塞式调用是一种天然的back pressure形式，调用方会阻塞并等待，直到被调用方执行完成
|
||
- 非阻塞场景：在非阻塞的代码中，需要关注事件速率，生产者产生事件的速率不能压过消费者消费的速率
|
||
|
||
##### reactive stream
|
||
reactive stream为一个小型规范，定义了异步组件和back pressure交互的规范。reactive stream的主要用途是让Subscriber控制publisher产生数据的速率。
|
||
|
||
### 编程模型
|
||
`spring-web` module包含Spring webflux的响应式基础，包括若夏内容：
|
||
- http抽象
|
||
- 对支持server的reactive stream adapters
|
||
- codecs
|
||
- 核心WebHandler API，其与servlet api兼容
|
||
|
||
Spring webflux提供了如下两种编程模型：
|
||
- `Annotated Controllers`: 和spring mvc一致，基于相同的注解。`spring mvc`和`webflux controllers`都支持`reactive return type`，因此，很难区分`spring mvc`和`webflux controllers`
|
||
- `Functional Endpoint`：基于lambda的、轻量的函数编程模型。其可以被看做是一个`支持对请求进行route和handle`的工具集合。
|
||
|
||
### 并发模型
|
||
#### spring mvc
|
||
在`spring mvc`（通常为servlet应用）中，其假设当前线程可能会被阻塞（例如，远程调用等会阻塞当前线程）。为了减少处理请求时阻塞所带来的影响，servlet容器会使用包含大量线程的线程池。
|
||
|
||
#### webflux
|
||
对于`webflux`（通常为non-blocking server），其会假设应用并不会阻塞，故而，非阻塞的server可以使用一个线程数较少且固定的线程池（event loop workers）来处理请求。
|
||
|
||
#### 调用阻塞api
|
||
当想要在webflux中使用阻塞api时，可以按如下方式进行使用。`RxJava`和`Reactive`都支持`publushOn`操作，其支持在另一个线程中`继续执行`。
|
||
|