1. Publisher와 Subscriber 간의 프로세스
- subscribe : Subscriber에서 subscribe 를 호출하여 구독
- onSubscribe : Publisher에서 구독이 정상적으로 이루어졌음을 알리는 onSubscribe 시그널 발생
- request : Subscriber는 Publisher에게 request 시그널로 데이터 요청
- onNext : Publisher는 전달받은 request 시그널에 해당하는 onNext 시그널을 Subscriber에게 전송하면서 데이터를 emit
- onComplete : Publisher측에서 emit 할 데이터가 없으면 Subscriber에게 onComplete 시그널을 발생
- onError : 데이터를 emit하는 과정중에서 에러가 발생하게 되면 onError 시그널을 보내게 되면서 Publisher와 Subscriber간 프로세스가 종료
2. Backpressure란?
- Publisher에서 emit되는 데이터를 Subscriber 쪽에서 안정적으로 처리하기 위한 제어 기능
- Subscriber 측에서 데이터를 처리하지 못한 경우, Publisher 에서 emit한 데이터가 계속 누적
- 최악의 경우 데이터가 쌓이면서 시스템이 다운될 수 있으며, 이를 방지하기 위해서 리액티브 프로그래밍에서 Backpressure 기능은 반드시 필요
3. 1 Reactor에서 Backpressure 처리 방법
- 요청 데이터의 개수를 제어하는 방법
- Subscriber가 적절히 처리할 수 있는 수준의 데이터 개수를 Publisher에게 요청. (가장 기본적인 Backpressure 처리 방법)
- Reactor에서 제공하는 Backpressure 전략
3.2 Reactor Backpressure 전략
- IGNORE 전략 : Backpressure를 적용하지 않음
- ERROR 전략 : Downstream으로 전달할 데이터가 버퍼에 가득 찰 경우, Exception을 바생시키는 전략
- DROP 전략 : Downstream으로 전달할 데이터가 버퍼에 가득 찰 경우, 버퍼 밖에서 대기하는 먼저 emit 된 데이터부터 Drop 시키는 전략
- LATEST 전략 : Downstream으로 전달할 데이터가 버퍼에 가득 찰 경우, 버퍼 밖에서 대기하는 최근에(나중에) emit 된 데이터 부터 버퍼에 채우는 전략
- BUFFER 전략 : Downstream으로 전달할 데이터가 버퍼에 가득 찰 경우, 버퍼 안에 있는 데이터를 Drop 시키는 전략
3.3 Reactor Backpressure DROP 전략
3.3 Reactor Backpressure LATEST 전략
3.3 Reactor Backpressure BUFFER DROP-LATEST 전략
3.4 Reactor Backpressure BUFFER DROP-OLDEST 전략
출처
'Spring > Webflux' 카테고리의 다른 글
Reactive Programming (0) | 2024.03.01 |
---|---|
Context (0) | 2024.03.01 |
Scheduler의 종류 (0) | 2024.02.29 |
Scheduler (0) | 2024.02.29 |
Sinks (0) | 2024.02.29 |