출처 : https://www.youtube.com/watch?v=fYfNd6hqxu8&list=PL93mKxaRDidFH5gRwkDX5pQxtp0iv3guf&index=3
Reactive Programing 탄생 배경
Client -> Server -> DB
순서로 요청이 일어날 때
기존의 비동기 요청 / 응답 방식의 경우,
요청을 보낸 Client 와 Server는 응답이 올 때 까지 멍 때리며 대기하는 시간이 존재했다.
기존의 Spring Web MVC 방식은 이러한 멍 때리는 시간의 비효율을 줄이기 위해 요청마다 쓰레드를 할당해 부여 했었다.
- 요청이 들어오면 새로운 쓰레드를 생성하여 Time 슬라이싱 방식으로 작업을 조금씩 나눠 리소스를 사용하게끔 처리하였는데, 이러한 방식은 요청이 무수히 많아 쓰레드의 갯수가 많을 경우 컨텍스트 스위칭 과정에서 발생하는 자원 낭비가 커졌다.
이를 효율적으로 수행하기 위한 비동기 방식의 프로그래밍에 대한 고민으로 탄생하게 된 것이 Spring WebFlux 이다.
WebFlux 탄생
비동기로 응답을 받으려면 해결해야 하는 문제가 2가지가 있었다.
- 멍 때리는 시간을 어떻게 없애지?
- stateless 연결이기 때문에 요청을 보낸 후, 응답값을 받으려면 다시 요청을 보내야 하는데..?
- 멍 때리는 시간을 없애기 위해
Server는 DB에 요청을 보낸 뒤 작업 예상 시간을 리턴받아
이벤트 루프에 Client의 요청에 대한 정보와 예상 작업 완료 시간을 저장해둔다.
요청을 DB로 넘긴 뒤 다른 작업들을 열심히 수행하다가..
요청이 아무 것도 들어오지 않는 빈 시간을 활용해 이벤트 루프를 확인한다.
DB에서 10초 후에 작업이 완료될 것 같다는 정보를 받아 시간을 저장해두었는데
이벤트 루프를 확인한 시간이 13초 후라면, 해당 요청에 대한 응답값이 들어 있을 것이다.
이제 Server 는 요청을 보낸 Client에게 이 응답값을 보낸다.
그런데 Stateless 상태로 연결이 끊겼다면 응답을 보낼 수 없을 것이다.
여기서 다시 요청하는 작업을 없애고 응답을 보내기 위해 탄생한 것이 SSE 프로토콜 이다.
SSE 프로토콜은 Push 기술의 일종이다.
- SSE 프로토콜은 요청 연결은 더 이상 필요없으니, 요청을 받은 시점에서 연결을 끊고 응답 연결만을 유지시킨다.
지속적인 응답이 가능 하도록 Stream 을 열어두어 통로를 만들어 둔다.
WebFlux 의 Flux = Stream 동일한 의미이다.
Subscribe -> Response 선이 유지되고 있다. (Client가 Subscribe를 하면 해당 Client는 Response 선이 유지되는 것)
Publishing -> 유지되고 있는 Response 선으로 데이터를 지속적으로 보내주는 것
Mono -> 0번 혹은 1번 응답하고 끝내는 것. Response Stream이 끊긴다.
Flux -> 1번 이상을 응답하는 것. Response Stream이 계속 유지된다.
