Spring WeFlux
- Spring 5에 추가된 모듈
- 클라이언트, 서버에서 reactive 스타일의 어플리케이션 개발을 도와주는 모듈
- async + non-block + reactive stream 지원
- reactive Stream : Non-blocking backpressure를 통한 비동기 스트림 처리 표준을 제공하기 위한 명세
- 장점 : 고성능, netty 지원, 비동기 non-blocking 메시지 처리
Back Pressure
- 옵저버 패턴 : 발행자(publisher)가 구독자(subscriber)에게 데이터를 밀어넣는 방식
- 발행자의 데이터 전송이 더 빠를 경우, 큐를 사용해서 대기중인 이벤트를 저장해야 한다. -> 오버플로우(overflow)
- 고정 길이 버퍼 : 신규로 수신된 메시지 거절 -> 거절된 메시지를 재요청 하는 CPU 연산 비용 낭비
- 가변 길이 버퍼 : out of memory 에러로 서버 크래시(crash)
- 백 프레셔 기본 원리 : 풀 방식 사용
- 구독자가 처리할 수 있는 만큼의 데이터를 발행자에게 요청한다.
- Dynamic pool 방식의 데이터를 요청해서 구독자가 수용할 수 있는 만큼의 데이터를 요청하는 방식
Netty
- 프로토콜 서버 및 클라이언트와 같은 네트워크 응용 프로그램을 빠르고 쉽게 개발할 수 있는 NIO(Non-Blocking Input Output) 클라이언트 서버 프레임워크
Spring WebFlux vs Spring MVC
- MVC : Servlet stack 기반으로 요청 한 개에 대해 하나의 스레드가 처리하고 Sync + blocking
- WebFlux : Reative stack 기반으로 다수의 요청에 대해 1개의 스레드 처리 Async + non blocking
Spring WebFlux 사용이유
- 하나의 요청에 대해 여러 외부 시스템에 대한 요청이 필요한 시스템에서 가장 빠른 응답을 주기 위해
- 수 많은 요청을 처리하는 상황에서 스레드 지옥에서 벗어나기 위해
- MVC는 1:1 요청처리 방식이기 때문에 트래픽이 몰리면 많은 스레드가 발생하고, 이 때 스레드가 전환될 때도 context switching 비용이 발생해 스레드가 많을 수록 비용이 커지게 된다.
- WebFlux는 Event-Driven과 Async + Non-Blocking I/O를 통해 리소스를 효율적으로 사용한다.
- MVC도 servlet 버전이 올라가면서 비동기 / 논블로킹이 가능하다.
- MVC servlet 3.2 이후
- 1. reqeust를 받은 서블렛 스레드는 pool에게 반납
- 2. 특정 이벤트 발생 -> 서블릿 스레드 풀에 슬데ㅡ 요청
- 3. 서블렛 스레드를 할당받고 작업 수행 후 사용자에게 response
- 하지만 DB 접근, API call 등 모든 부분이 non blocking으로 구현하기에는 부족하다.