Java IO의 Reactor 네트워크 모델 개념은 무엇입니까?

1. 리액터 모델이란 무엇입니까?

리액터 설계 패턴은 하나 이상의 입력에 의해 서비스 핸들러에 동시에 전달된 서비스 요청을 처리하기 위한 이벤트 처리 패턴입니다. 리액터 디자인 패턴이라고도 하는 리액터 패턴은 하나 이상의 서비스 핸들러에 서비스 요청을 동시에 제출하는 이벤트 디자인 패턴입니다. 요청이 도착하면 이러한 요청은 역다중화되어 서비스 프로세서를 통해 해당 요청 프로세서로 배포됩니다. Reactor 모드는 아래 그림과 같이 크게 Reactor와 Handler 두 부분으로 구성됩니다.

Reactor: 이벤트 모니터링 및 배포를 담당합니다.

• Handler: 읽기 -> 비즈니스 로직(디코딩 + 계산 + 인코딩) -> 다음 단계 :
① 읽기: 소켓에서 데이터를 읽습니다.
• ②디코드: 디코딩, 네트워크의 데이터가 바이트 형태로 전송됩니다. 실제 요청을 얻으려면 디코딩이 필요합니다.

  3컴퓨팅: 계산, 즉 비즈니스 처리입니다.

  4인코드: 인코딩, 네트워크의 데이터는 바이트 형태로 전송됩니다. 즉, 소켓은 바이트만 수신하므로 인코딩이 필요합니다.
⑤ 보내기: 응답 데이터 보내기

Reactor 모드의 경우 이벤트가 서버에 입력될 때마다 서비스 핸들러는 이를 해당 핸들러로 전달(디스패치)하여 처리합니다. Reactor 모델에 정의된 세 가지 역할:


Reactor는 이벤트를 모니터링하고 배포하며 해당 핸들러에 이벤트를 전달하는 역할을 담당합니다. 새로운 이벤트에는 연결 설정 준비, 읽기 준비, 쓰기 준비 등이 포함됩니다.

Acceptor: 클라이언트의 새 연결을 처리하도록 커넥터를 요청합니다. Reactor는 클라이언트로부터 연결 이벤트를 수신한 후 이를 클라이언트의 연결을 수신하는 Acceptor로 전달하고 해당 Handler를 생성한 후 이 Handler를 Reactor에 등록합니다.

핸들러: 이벤트 처리를 담당하는 요청 프로세서, 이벤트에 바인딩, 비차단 읽기/쓰기 작업 수행, 채널 읽기 완료, 비즈니스 로직 처리 완료 후 채널에서 결과 쓰기 . 사용 가능한 자원 풀을 관리할 수 있습니다.

모델은 대략 아래 그림과 같습니다.

읽기/쓰기 요청의 경우 Reactor 모델은 다음 프로세스에 따라 처리됩니다.

(1) 애플리케이션은 읽기/쓰기 준비를 등록합니다. 이벤트 및 관련 이벤트 프로세서

(2) 이벤트 구분자는 이벤트 발생을 기다립니다

• (3) 읽기/쓰기 준비 이벤트가 발생하면 이벤트 구분자는 첫 번째 단계에서 등록한 이벤트 핸들러를 호출합니다

• II, Reactor 모델 분류:

Reactor 모델의 Reactor는 단일 또는 다중일 수 있으며 Handler도 단일 스레드 또는 다중 스레드일 수 있으므로 대략 세 가지 조합 모드가 있습니다.
Single Reactor 단일 스레드 모델

Single Reactor 멀티 스레드 모델

• Master-slave Reactor 단일 스레드 모델

• Master-slave Reactor 멀티 스레드 모델

• 제3의 마스터-슬레이브 Reactor 단일 스레드 모델은 실질적인 의미가 없으므로 다음은 다른 세 가지 모델에 중점을 둡니다

1. 단일 리액터 단일 스레드 모델:

• 1.1 처리 프로세스:

(1) 리액터 스레드는

(2) 연결 설정 이벤트인 경우 Acceptor는 accept() 메서드를 통해 연결을 획득하고 생성됩니다. 후속 응답 이벤트를 처리하기 위한 핸들러 객체

(3) IO 읽기 및 쓰기 이벤트인 경우 Reactor는 처리를 위해 이벤트를 현재 연결된 핸들러에 넘겨줍니다.

(4) 핸들러는 전체 비즈니스 프로세스를 완료합니다. 읽기 -> 비즈니스 처리 - > 보내기

1.2. 장점과 단점:

단일 Reactor 단일 스레드 모델의 장점은 모든 처리 로직이 하나의 스레드로 구현되며 멀티 스레딩에 문제가 없다는 것입니다. 프로세스 커뮤니케이션, 경쟁. 하지만 이 모델은 성능과 신뢰성 면에서 심각한 문제를 가지고 있습니다:

• ① 성능: 코드에서 구성 요소만 구별하고 전체 작업은 여전히 ​​단일 스레드이며 CPU 리소스를 완전히 활용할 수 없으며 Handler 비즈니스 처리 부분은 비동기적이지 않습니다. 연결 요청 처리 및 읽기를 담당해야 합니다. 일반적으로 연결 요청 처리는 매우 빠르지만 읽기 및 쓰기 요청 처리에는 비즈니스 논리 처리가 포함되므로 상대적으로 느립니다. Reactor는 읽기 및 쓰기 요청을 처리하므로 다른 요청은 차단되어 시스템 성능 병목 현상이 쉽게 발생할 수 있습니다

• ② 신뢰성: Reactor 스레드가 예기치 않게 중단되거나 무한 루프에 들어가면 전체 시스템 통신 모듈을 사용할 수 없습니다. 외부 메시지를 수신하고 처리할 수 없어 노드 오류가 발생합니다. 따라서 단일 Reactor 단일 프로세스 모델은 매우 빠른 비즈니스 처리 장면에만 적합한 밀집형 시나리오 계산에는 적합하지 않습니다. Redis의 스레딩 모델은 Single Reactor 단일 스레드 모델을 기반으로 구현되어 있습니다. Redis 업무 처리는 주로 메모리에서 이루어지기 때문에 작업 속도가 매우 빠르고 CPU에서 성능 병목 현상이 발생하지 않으므로 Redis는 명령을 단일 스레드로 처리합니다. 단일 프로세스.

2. Single Reactor 멀티 스레드 모델:

Single Reactor 단일 스레드 모델의 성능 문제를 해결하기 위해 단일 Reactor 멀티 스레드 모델이 진화했습니다. 이벤트 프로세서 부분

2.1. 처리 과정:

(1) Reactor 스레드는 select를 통해 이벤트를 수신하고, 이벤트를 수신한 후 Dispatch를 통해 배포합니다.

(2) 연결 설정 이벤트인 경우 이벤트는 Acceptor에 배포되고 Acceptor는 전달됩니다. accept() 메서드는 연결을 얻고 후속 응답 이벤트를 처리하기 위한 Handler 객체를 생성합니다

(3) IO 읽기 및 쓰기 이벤트인 경우 Reactor는 처리를 위해 현재 연결에 해당하는 Handler에 이벤트를 넘깁니다.

(4) 단일 Reactor 및 단일 스레드와 달리 Handler는 더 이상 특정 비즈니스 처리를 수행하지 않고 이벤트 수신 및 응답만 담당합니다. 읽기를 통해 데이터를 후속 Worker 스레드 풀로 전송하여 비즈니스 처리를 수행합니다.

(5) Worker 스레드 풀은 비즈니스 처리를 위해 스레드를 할당하고 완료 후 처리를 위해 응답 결과를 Handler로 보냅니다.

(6) 응답 결과를 받은 Handler는 send를 통해 응답 결과를 클라이언트에 반환합니다.

2.2. 장점 및 단점:

첫 번째 모델과 관련하여 비즈니스 로직을 처리한 후, 즉 IO 읽기 및 쓰기 이벤트를 얻은 후 처리를 위해 스레드 풀로 전달됩니다. 응답하면 클라이언트에 반환된 응답 결과를 보냅니다. 이를 통해 Reactor의 성능 오버헤드를 줄여 이벤트 배포에 더 집중하고 전체 애플리케이션의 처리량을 향상시킬 수 있습니다. 또한 핸들러는 멀티 스레딩 모드를 사용하여 CPU 성능을 최대한 활용합니다. 그러나 이 모델에는 다음과 같은 문제가 있습니다.

(1) 핸들러는 멀티 스레딩 모드를 사용하므로 자연스럽게 리소스에 대한 멀티 스레드 경쟁의 오버헤드가 발생합니다. 여기에는 공유 데이터에 대한 상호 배제 및 보호 메커니즘도 포함되므로 구현이 더 복잡해집니다. 복잡함

(2) 단일 리액터 모든 이벤트에 대한 모니터링, 배포 및 응답을 담당하므로 동시성이 높은 시나리오에서 성능 병목 현상이 쉽게 발생할 수 있습니다.

3. 마스터-슬레이브 Reactor 멀티 스레드 모델:

단일 Reactor 멀티 스레드 모델은 Handler의 단일 스레드 성능 문제를 해결하지만 Reactor는 여전히 단일 스레드이므로 높은 동시성을 위한 성능 병목 현상이 여전히 존재합니다. 따라서 Reactor를 멀티스레딩 모드로 조정해야 하는 것은 다음에 소개할 마스터-슬레이브 Reactor 멀티스레딩 모델입니다. 마스터-슬레이브 Reactor 멀티스레딩 모델에서 Reactor는 두 부분으로 나뉩니다

(1) MainReactor: 연결 설정 이벤트 처리, 선택을 통해 서버 소켓 수신, 설정된 소켓 채널을 subReactor에 등록하는 역할만 담당합니다. 보통 하나의 스레드이면 충분합니다.

(2) SubReactor: 이벤트 읽기 및 쓰기, 자체 선택기 유지 관리, MainReactor에 등록된 SocketChannel을 기반으로 다중 채널 분리된 IO 읽기 및 쓰기 이벤트 수행, 네트워크 데이터 읽기 및 쓰기 및 처리를 담당합니다. 완료를 위해 작업자 스레드 풀에 대한 비즈니스 처리를 완료합니다. SubReactor의 개수는 일반적으로 CPU의 개수와 같습니다

3.1 처리 흐름:

(1) 메인 스레드의 MainReactor 객체는 select를 통해 이벤트를 수신하고, 이벤트를 받은 후 Dispatch를 통해 배포합니다. .이벤트 유형이 연결인 경우 연결 설정을 위해 Acceptor에게 설정 이벤트가 배포됩니다

연결 설정:

① 메인 스레드 풀에서 Reactor 스레드를 Acceptor 스레드로 무작위로 선택하여 리스닝 포트를 바인딩하고 클라이언트 연결을 받습니다.
② Acceptor 스레드는 클라이언트 연결 요청을 받은 후 새로운 SocketChannel을 생성하고 이를 메인 스레드의 다른 스레드에 등록합니다. 스레드 풀 Reactor 스레드에서는 액세스 인증, IP 블랙 및 화이트 목록 필터링, 핸드셰이크 및 기타 작업을 담당합니다.
3 단계 ②가 완료되면 비즈니스 계층의 링크가 정식으로 생성됩니다. 메인 스레드 풀의 Reactor 스레드의 멀티플렉서에서 SocketChannel을 제거하고 이를 SubReactor 스레드 풀의 스레드에 다시 등록한 후 다양한 연결 이벤트 처리를 위한 핸들러

(2) 수신된 이벤트가 연결 수립 이벤트가 아닌 경우 SubReactor로 전달되고, SubReactor는 현재 연결에 해당하는 Handler를 호출하여 처리

(3) Handler가 읽은 후 데이터 읽기를 통해 Worker에 데이터를 배포합니다. Thread Pool은 비즈니스 처리를 수행하고 Worker 스레드 풀은 비즈니스 처리를 위해 스레드를 할당합니다. 완료 후 응답 결과가 Handler로 전송됩니다.

(4) Handler가 이를 수신한 후 응답 결과는 send를 통해 클라이언트에 응답 결과를 반환합니다

3.2. 장점과 단점:

   마스터-슬레이브 Reactor 멀티 스레딩 모델의 장점은 메인 스레드와 하위 스레드 간의 작업 분담입니다. 메인 스레드는 새로운 연결을 수신하는 역할만 담당하며, 하위 스레드는 후속 비즈니스 처리를 완료하는 역할도 담당합니다. 동시에, 하위 스레드와 하위 스레드 간의 상호 작용도 매우 간단합니다. - 스레드가 메인 스레드를 수신합니다. 스레드가 연결된 후에는 메인 스레드에 신경 쓰지 않고 비즈니스 처리에만 집중할 수 있습니다. 처리 결과를 하위 스레드에서 클라이언트에 직접 보낼 수 있습니다.

           이 Reactor 모델은 높은 동시성 시나리오에 적합하며 Netty 네트워크 통신 프레임워크도 이 구현을 채택합니다.

4. Reactor의 장점과 단점:

(1) 빠른 응답, 단일 동기화 시간으로 차단할 필요가 없습니다. Reactor 자체는 여전히 동기식이지만,

(2) 복잡한 멀티스레딩 및 동기화 문제를 최대한 피할 수 있고 멀티스레드/프로세스 전환 오버헤드를 피할 수 있습니다.

(3) 확장성을 높여 쉽게 늘릴 수 있습니다. Reactor 인스턴스 수 CPU 리소스를 최대한 활용합니다.

(4) 재사용성, Reactor 모델 자체는 특정 이벤트 처리 로직과 관련이 없으며 재사용성이 높습니다.

위 내용은 Java IO의 Reactor 네트워크 모델 개념은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!