스프링부트 웹플럭스 반응기 동시성 모델

스프링부트 웹플럭스 반응기 동시성 모델

springboot webflux의 기본 동시성 모델에 대해 자세히 알고 싶습니다.

CPU 집약적인 웹 서비스의 경우 기존의 Blocking Multithread 모델이 더 적합합니까?아니면 일반적으로 기존 스레드 풀 모델이 이 문서 https://people.eecs.berkeley.edu/ ~hotos/hotos-2003.pdf에 따라 더 적합합니까?

Reactor chain에 blocking step이 있는 경우 publishOn을 사용하여 다른 threadpool로 스케줄링합니다.그러면 원래 스레드가 자유로워지고 체인 전체가 여전히 차단되지 않습니까?

WebFlux가 잘 맞는 곳 및 후드 아래에서 작동하는 방법

제 입장에서는 Spring WebFlux에 가장 적합한 것은 네트워크 집약적인 애플리케이션입니다.Spring WebFlux는 Netty 주변에 배압 지원 래퍼인 Reactor-Netty를 사용합니다.Reactor-Netty는 거의 동일한 Netty Threading 전략을 사용하고 생성합니다.Runtime.getRuntime().availableProcessors() * 2부에 대한 EventLoopThreadPool은 각각. Thread는 자체 코어/프로세서에 바인딩되며 CPU 리소스에 대한 경합을 최소화하면서 작동합니다.이러한 모델은 엔드 투 엔드 비 차단 통신과 매우 잘 작동합니다.따라서 수신 요청이 원격 네트워크 호출로 끝날 경우, 동일한 스레드가 짝수 루프 대기열의 나머지 작업으로 돌아갈 수 있도록 해당 호출을 비차단 방식으로 실행해야 합니다.이러한 기술을 사용하면 많은 수의 관련 스레드와의 통신을 차단하는 일반적인 특성인 컨텍스트 전환 및 높은 경합에 거의 소요되지 않고 하드웨어를 효율적으로 활용할 수 있습니다.

프로젝트 원자로의 역할

Spring WebFlux에서 Project Reactor의 중심 역할은 복잡한 비차단, 비동기 실행의 명확성을 유지하는 프로그래밍 모델을 제공하는 것입니다.데이터 처리의 연속성에 대한 복잡성을 숨기고 기능적이고 선언적인 요소 처리 파이프를 쉽게 구축할 수 있습니다.또한 Reactor의 스레드 모델은 두통 없이 전용 스레드 풀에서 정교하고 효율적인 요소 처리 일정 조정을 가능하게 하는 몇 가지 연산자에 불과합니다.후드 아래에서는 Java Core 라이브러리에서 가져온 동일한 ThreadPools 및 ExecutorServices를 사용합니다.

CPU 집약적인 작업을 처리하는 방법, Project Reactor가 거기에 잘 맞습니까?

Reactor Netty는 CPU 집약적인 작업에도 적합합니다.그러나 이 경우에는 Project Reactor를 적절하게 사용해야 합니다.복잡한 알고리즘 처리나 유사한 작업의 경우 Reactor가 성능에 대한 오버헤드를 100~150% 정도 추가하기 때문에 순수 Java를 사용하는 것이 좋습니다.

Project Reactor 및 Reactor-Netty(WebFlux)를 이용한 효율적인 CPU 집중 작업 처리 구축 방법

이전 작업이 완료되면 각 스레드가 새로운 작업을 수행할 수 있도록 "작업 대기열" 패턴을 따르는 것을 권장합니다.

CPU 사용량이 많은 작업의 경우 전용 쓰레드 풀에서 예약하는 것이 좋습니다.약간의 오버헤드가 발생하더라도 네트워크 앱의 필수 요소인 읽기 쓰기 I/O 지연 시간이 증가할 것입니다.Netty의 경우, Netty의 EventLoop은 네트워크에 읽기 및 쓰기만 수행하고 그 이상은 수행하지 않습니다.

전용 스레드 풀에서 작업을 예약하려면 아래 코드 샘플에 나와 있는 기술을 따를 수 있습니다.

@PostMapping
public Mono<CpuIntensiveResult> cpuIntensiveProcessingHandler(
    Mono<CpuIntensiveInput> monoInput
) {
    return monoInput
        .publishOn(Schedulers.fromExecutorService(myOwnDedicatedExecutor))
        .map(i -> doCpuIntensiveInImperativeStyle(i));
}

위의 코드에서 알 수 있듯이 Project Reactor 무기고의 한 연산자를 사용하면 전용 Threadpool에서 작업 처리를 쉽게 예약할 수 있습니다.이를 통해 기존 Executor Service를 스케줄러로 신속하게 랩핑하고 Whit-in Reactor 에코시스템을 사용할 수 있습니다.

멀티스레드 기술을 통한 차단은 어떻습니까?

일반적으로 코어보다 스레드 수가 많은 멀티 스레드 기술을 사용하면 아무런 이점도 얻을 수 없습니다.여기서 단점은 상황 전환과 경합이라는 점입니다.작업이 동시에 진행되는 것 같습니다.그러나 시스템 스케줄러는 동시 스레드 간에 CPU 시간 할당이라는 동일한 하드 작업을 수행합니다.몇 가지 집중적인 작업 간에 동일한 CPU를 공유하므로 각 작업의 지연 시간이 길어집니다.평균적으로 시스템의 CPU/코어와 동일한 수의 스레드에서 동일한 작업을 수행하는 것보다 처리 시간이 더 높습니다.

스레드 모델을 "진정한" 처리 모델로 간주하는 몇 가지 참고 사항.

언급된 백서에 따르면, 스레드 모델은 진정한 프로그래밍 모델입니다.아마도 이 논문의 저자들은 그린 스레드에 대해 이야기하고 있는 것 같습니다.Green Threads가 더 나은 프로그래밍 모델이 될 수 있지만, 결국 Reactor 프로그래밍 모델에 대해서는 위에서 언급한 것과 같은 규칙을 따라야 합니다.스레드 및 그에 따른 필수 프로그래밍 모델의 단점은 리액터 프로그래밍 모델이 매우 잘 맞는 데이터 스트림을 사용할 수 없다는 것입니다.

또한 Universal Scalability Law를 재검토하여 현재 Java Threading 실행과 관련된 경합 및 일관성의 문제를 검토할 것을 권장합니다.또한 확장성에 대한 좋은 개요는 다음 논문에서 설명합니다.

비동기식 + 비차단 요청 처리를 효율적으로 사용하는 또 다른 예는 Facebook 아키텍처로, 선택 로드 시 작업 대기열을 작업 스택으로 변환하여 지연 시간을 최소화합니다.

언급URL : https://stackoverflow.com/questions/53675791/springboot-webflux-reactor-concurrency-model