Webflux를 사용하는 이유?
- Event-Driven 과 Asynchronous Non-blocking I/O를 통해 리소스를 효율적으로 사용하기 위해
Synchronous (동기) Vs Asynchronous (비동기)
- Synchronous
요청과 그 결과가 동시에 일어난다
호출한 함수가 호출된 함수의 작업이 끝나서 결과값을 반환하기를 기다리거나, 지속적으로 호출된 함수에게 확인 요청을 하는 경우가 있다. - Asynchronous
요청과 그 결과가 동시에 일어나지 않는다.
호출하는 함수가 호출되는 함수에게 작업을 맡겨놓고 신경을 쓰지 않는다.
Callback
Blocking VS Non-Blocking
- Blocking
자신의 수행결과가 끝날 때까지 제어권을 갖고 있는 것을 의미한다. - Non-Blocking
직접 제어할 수 없는 대상의 작업처리 여부와 상관없이 바로 제어권을 넘겨주어 자신의 작업을 할 수 있다.
Spring MVC VS Spring WebFlux
- Spring MVC
- 1요청 1쓰레드
- Sync + Blocking
- Spring WebFlux
- 다요청 1쓰레드
- Async + NonBlocking
- Blocking I/O가 발생하면 Spring MVC에 비해 성능이 떨어질 수 있다.
Reactive Programming
가장 다른 점이라고 할 수 있는 Reactive API는 Spring WebFlux에서 선택한 reactive라이브러리인 Reactor를 기반으로 한다.
Reactive API는 Mono와 Flux API타입을 제공한다.
- Mono: 0~1개의 아이템을 가지고 있는 publisher
- Flux: 0~N개의 아이템을 가지고 있는 publisher
- 동작 순서
1. Subscriber가 subscribe() 메서드를 통해 Publisher에게 구독 요청
2. Publisher는 onSubscribe() 메서드로 Subscription을 Subscriber에게 전달
3. Subscriber는 Subscription.request()를 통해, 자신에게 데이터를 흘려줄 것을 요청
4. Publisher는 Subscription 을 통해 Subscriber.onNext()로 데이터를 전달
5. 전달이 성공적으로 끝났으면 onComplete() 시그널, 오류가 발생했다면 onError() 시그널 발생 - 핵심
- Observer pattern 기반에 backpressure(배합-압력조절) 개념을 적용
=> publisher 가 subscriber에게 push하는 방식이 아니라, 반대로 pull 하는 방식
=> subscriber가 감당할 수 있는 만큼의 데이터를 수신
- backpressure 개념
: 데이터를 받는 쪽에서 pull하여 적정 데이터양만 수신하여 오류를 방지하는 로직
reference
https://velog.io/@neity16/WebFlux-1-%EA%B0%9C%EB%85%90-%EC%9E%A1%EA%B8%B0
배고파