Webflux 란?

1. WebFlux

기존 방식
- 서버에서 다른 요청을 못받는다.
- 이를 스레드를 늘려 시간을 쪼개서 일을 진행하는데 이 경우 context switching 문제가 생긴다.
문제점
1. A와 B에 멍때리는 시간이 존재한다. 그 시간에 다른일을 못한다. : 비동기 처리로 해결
2. 물어봐야만 알고싶은 정보를 알 수 있다. : 응답을 유지하여 해결

비동기 처리
- DB가 서버에게, 서버가 클라이언트에게 즉각적인 응답을 해준다.
- 서버는 이 이후 다른 일을 진행할 수 있다.
- 서버는 미처 처리하지 못한 이벤트를 기억해야 하고 이를 이벤트 루프에 저장하여 기억한다.
- 이벤트 루프덕분에 서버는 여러가지 요청을 동시에 받고 기억할 수 있어 비동기 처리가 가능해진다.
응답 유지
- Stream을 만들어 놓는다. (물길을 유지한다.)
- 요청과 응답의 선을 만들어놓고 계속 통신 : webSocket
- 요청이 필요없어 요청을 끊고 응답만 지속적으로 유지 : SSE 프로토콜

- - -

Reactive-Stream 라이브러리를 기반으로 만들어진 구현체
Spring 5 (Springboot 2) 에서 새롭게 추가된 모듈
client / server 에서 reactive 스타일의 어플리케이션 개발을 도와주는 모듈
non-blocking에 reactive stream을 지원
Spring Web MVC 와 Spring Web Flux를 동시에 사용할 수 있다.
- MVC가 기본으로 적용되며 MVC controller에 reactive WebClient를 함께 사용 가능
- 현재 회원통합 프로젝트가 그러하다?
웹 어플리케이션이 각 Layer들이 Reactive 하게 개발됐더라도 DB가 Reactive를 지원하지 않는다면 결국 DB에서 blocking 되기 때문에 사실 의미가 없다.
RDBMS는 비동기 처리가 불가능하다.
- MongoDB, Redis 등은 지원
- R2DBC 라이브러리를 통해 DB에서 비동기 처리가 가능 (MySQL, Postgres, H2, mssql)

netty 지원
- NIO(Non-Blocking Input Ouput) 클라이언트 서버 프레임 워크
- 그 외에도 Servlet 3.1+ Container 를 포함한 다양한 reactive runtime 지원 (tomcat, reactor etc.)
비동기 non-blocking 메세지 처리
Back Pressure
- 빠른 Publisher - 느린 Subscriber 문제를 해결하는 원리
- Publisher의 일방적 데이터 Push 가 아니라, Subscriber가 처리할 수 있을 만큼의 데이터만 Subscriber의 요청에 의해서 전달

일반적으로 많은 트래픽을 소화하는 시스템은 리소스 최적화가 필요하다.
- 하나의 사용자 요청을 처리하기 위해 수십개의 외부 시스테에 대한 요청이 필요한 시스템에서 빠른 응답을 줘야 한다.
Spring MVC는 1:1 로 요청을 처리하기에 트래픽이 몰리면 많은 스레드가 생긴다. 스레드 전환의 context switching 비용이 발생하는데, 이는 스레드가 많을 수록 비용이 커지므로 스레드 수를 유지하는 것이 중요하다.
이에 반해 WebFlux는 적은 양의 스레드와 최소한의 하드웨어 자원으로 효율적인 동시성 핸들링이 가능하다.
- request를 Event-Driven 방식으로 처리
- 비동기 / non-blocking I/O 사용

동기 / 비동기 / 블록킹 / 논블록킹 (0)	2022.05.15