Nginx----이벤트 처리 메커니즘 및 프로세스 모델

Nginx 이벤트 처리 메커니즘:
기본 웹 서버의 경우 일반적으로 세 가지 유형의 이벤트, 네트워크 이벤트, 신호 및 타이머가 있습니다.
먼저 요청의 기본 프로세스인 연결 설정---데이터 수신---데이터 보내기를 살펴보겠습니다.
시스템 하단의 작업을 다시 살펴보세요. 위 프로세스(연결 설정---데이터 수신---데이터 전송)는 시스템 하단의 읽기 및 쓰기 이벤트입니다.

1) 블로킹 호출 방식을 사용하는 경우 읽기, 쓰기 이벤트가 준비되지 않은 경우 읽기, 쓰기 이벤트는 수행할 수 없고 읽기, 쓰기 이벤트만 수행할 수 있습니다. 이벤트가 준비되기를 기다린 후 밖으로 나갑니다. 그러면 요청이 지연됩니다. 차단 호출은 커널에 들어가서 대기하며 다른 사람이 CPU를 사용하게 됩니다. 이는 단일 스레드 작업자에게는 분명히 적합하지 않으며, 네트워크 이벤트가 많아지면 아무도 CPU를 사용하지 않습니다. 유휴 상태입니다. CPU 사용률이 높으면 당연히 속도도 올라갈 수 없습니다.

2) 준비가 되어 있지 않으면 통화 차단이 불가능하므로 논 블로킹 방식을 사용하세요. 비차단이란 이벤트가 즉시 EAGAIN으로 돌아가서 이벤트가 아직 준비되지 않았음을 알리는 것을 의미합니다. 나중에 다시 오세요. 자, 잠시 후 이벤트가 준비될 때까지 다시 이벤트를 확인해 보세요. 이 기간 동안에는 다른 작업을 먼저 하신 후 이벤트가 준비되었는지 확인하시면 됩니다. 더 이상 차단되지 않지만 수시로 이벤트 상태를 확인해야 합니다. 더 많은 일을 할 수 있지만 오버헤드가 적지 않습니다.

요약: 이벤트를 지속적으로 확인하여 차단하지 않습니다. 읽기 및 쓰기 작업을 수행할지 여부를 결정하는 상태로, 오버헤드가 많이 발생합니다.

3) 따라서 비동기식 논블로킹 이벤트 처리 메커니즘이 있습니다. 시스템 호출과 관련된 것은 select/poll/epoll/kqueue와 같은 시스템 호출입니다. 여러 이벤트를 동시에 모니터링할 수 있는 메커니즘을 제공합니다. 호출하면 차단되지만 시간 제한 내에 이벤트가 준비되면 반환됩니다. 이 메커니즘은 위의 두 가지 문제를 해결합니다.

epoll을 예로 들어보겠습니다. 이벤트가 준비되지 않으면 epoll(큐)에 들어갑니다. 이벤트가 준비되면 이를 처리하고, 이벤트가 EAGAIN을 반환하면 계속해서 epoll에 넣습니다. 따라서 이벤트가 준비되면 처리하고, 항상 준비되지 않은 경우에만 epoll에서 기다리게 됩니다. 이런 식으로 많은 수의 동시 요청을 처리할 수 있습니다. 물론 여기서 동시 요청은 처리되지 않은 요청을 의미하므로 동시에 처리할 수 있는 요청은 하나뿐입니다. 단지 요청 사이를 계속 전환하는 것뿐입니다. 비동기 이벤트가 준비되지 않았기 때문에 자발적으로 전환이 이루어진 것뿐입니다. 여기서 전환하는 데는 비용이 들지 않습니다. 실제로는 루프에서 준비된 여러 이벤트를 처리하는 것으로 이해할 수 있습니다.

4) 멀티스레딩과의 비교:
멀티스레딩과 비교하여 이 이벤트 처리 방법은 스레드를 생성할 필요가 없고 각 요청이 매우 적은 메모리를 차지하며 컨텍스트 전환이 매우 가볍다는 장점이 있습니다. 핸들. 동시성이 아무리 많아도 불필요한 리소스 낭비(컨텍스트 전환)가 발생하지 않습니다.
요약: Nginx는 비동기식 비차단 이벤트 처리 메커니즘을 통해 준비된 여러 이벤트의 프로세스 루프 처리를 실현하여 높은 동시성과 경량성을 달성합니다.
Nginx 기능:
1. 크로스 플랫폼: Nginx는 OS와 같은 대부분의 Unix에서 컴파일하고 실행할 수 있으며 Windows용 포팅 버전도 있습니다.
2. 구성이 매우 간단하고 시작하기가 매우 쉽습니다. 구성 스타일은 프로그램 개발과 동일, 신과 같은 구성
3. Non-blocking, 높은 동시 연결: 데이터 복사 시 디스크 I/O의 첫 번째 단계는 Non-Blocking입니다. 공식 테스트에서는 50,000개의 동시 연결을 지원할 수 있으며 실제 프로덕션 환경에서는 동시 연결 수가 20,000~30,000에 이릅니다. (이는 최신 epoll 모델을 사용하는 Nginx 때문입니다.)
4. 이벤트 중심: 통신 메커니즘 epoll 모델을 채택하고 더 큰 동시 연결을 지원합니다.

5. nginx 프록시와 백엔드 웹 서버 사이에 긴 연결이 필요하지 않습니다.
6. 사용자 요청 수신은 비동기식입니다. 즉, 모든 사용자 요청이 먼저 수신된 다음 전송됩니다. 백엔드 웹서버에 한번에 전송하여 백엔드 웹서버의 부담을 대폭 줄여드립니다
7. 응답 메시지 전송시 백엔드 웹서버로부터 데이터를 받아 동시에 클라이언트에 전송합니다.
8. 낮은 네트워크 종속성. NGINX는 네트워크에 대한 의존도가 거의 없습니다. 이론적으로 ping이 가능하다면 로드 밸런싱을 구현할 수 있으며, 인트라넷과 외부 네트워크 트래픽을 효과적으로 구분할 수 있습니다.
9. 서버 감지를 지원합니다. NGINX는 애플리케이션 서버 처리 페이지에서 반환된 상태 코드 및 시간 초과 정보를 기반으로 서버 오류를 감지하고 잘못된 요청을 즉시 반환하여 다른 노드

마스터/작업자 구조에 다시 제출할 수 있습니다. 마스터 프로세스는 하나 이상의 작업자 프로세스를 생성합니다.
낮은 메모리 소비: 대규모 동시 요청을 처리하면 메모리가 거의 소비되지 않습니다. 30,000개의 동시 연결 미만에서 시작된 10개의 Nginx 프로세스는 150M의 메모리(15M*10=150M)만 소비합니다. 저렴한 비용: Nginx는 오픈 소스 소프트웨어이며 무료로 사용할 수 있습니다. F5 BIG-IP, NetScaler 등 하드웨어 부하 분산 스위치를 구입하려면 10만 위안 이상에서 수십만 위안의 비용이 듭니다.
내장 상태 확인 기능: Nginx Proxy 백엔드의 웹 서버가 다운되면 프런트 엔드 액세스에는 영향이 없습니다.
대역폭 절약: GZIP 압축을 지원하고 브라우저에서 로컬로 캐시된 헤더를 추가할 수 있습니다.
높은 안정성: 역방향 프록시에 사용되며 다운타임 가능성이 매우 적습니다.
nginx는 다중 프로세스 방식으로 작동합니다. 물론 nginx도 다중 스레딩을 지원하지만 우리의 주류 방식은 여전히 ​​다중 프로세스입니다. 이 방법은 nginx의 기본 방법이기도 합니다. 다중 프로세스 접근 방식을 사용하면 nginx에 많은 이점이 있습니다.
(1) nginx가 시작된 후에는 마스터 프로세스와 여러 작업자 프로세스가 있습니다. 마스터 프로세스는 외부 세계로부터 신호 수신, 각 작업자 프로세스에 신호 보내기, 작업자 프로세스의 실행 상태 모니터링, 작업자 프로세스 종료 시 자동으로 새 작업자 프로세스 다시 시작 등 작업자 프로세스를 관리하는 데 사용됩니다. 비정상적인 상황). 기본 네트워크 이벤트는 작업자 프로세스에서 처리됩니다. 여러 작업자 프로세스는 P2P 방식으로 클라이언트의 요청을 놓고 동등하게 경쟁하며 각 프로세스는 서로 독립적입니다. 요청은 하나의 작업자 프로세스에서만 처리할 수 있으며 작업자 프로세스는 다른 프로세스의 요청을 처리할 수 없습니다. 작업자 프로세스 수는 설정할 수 있으며 일반적으로 머신의 CPU 코어 수와 일치하도록 설정합니다. 그 이유는 nginx의 프로세스 모델 및 이벤트 처리 모델과 불가분의 관계입니다.
(2)마스터는 신호를 받은 후 어떻게 신호를 처리합니까(./nginx -s reload)?
먼저 신호를 받은 후 마스터 프로세스는 구성 파일을 먼저 다시 로드한 다음 새 작업을 시작합니다. 모든 이전 프로세스에 명예롭게 은퇴할 수 있다는 신호를 보냅니다. 새 프로세스가 시작된 후 새 요청을 받기 시작하는 반면, 이전 프로세스는 마스터로부터 신호를 받은 후 새 요청 수신을 중지하고 현재 프로세스에서 처리되지 않은 모든 요청이 처리된 후 종료됩니다.
(3) 작업자 프로세스는 요청을 어떻게 처리합니까?
앞서 작업자 프로세스는 동일하며 각 프로세스에는 요청을 처리할 수 있는 기회가 동일하다고 언급했습니다. 포트 80에서 http 서비스를 제공하고 연결 요청이 오면 각 프로세스가 연결을 처리할 수 있습니다. 먼저, 각 작업자 프로세스는 마스터 프로세스에서 분기됩니다. 마스터 프로세스에서는 먼저 수신해야 하는 소켓을 설정한 다음 여러 작업자 프로세스를 분기하여 각 작업자 프로세스가 소켓을 수락할 수 있도록 합니다. 동일한 소켓이지만 각 프로세스의 소켓은 동일한 IP 주소 및 포트에서 모니터링됩니다. 이는 네트워크 프로토콜에서 허용됩니다. 일반적으로 연결이 들어오면 소켓을 수락하는 모든 프로세스가 알림을 받게 되며, 한 프로세스만 연결을 수락할 수 있고 다른 프로세스는 수락하지 못하는 소위 Thundering Herd 현상이 발생합니다.물론 nginx는 눈을 돌리지 않을 것이므로 nginx는 accept_mutex를 제공합니다. 이름에서 이것이 accept에 추가된 공유 잠금임을 알 수 있습니다. 이 잠금을 사용하면 동시에 Accpet에 연결되는 프로세스가 하나만 있으므로 Thundering Herd 문제가 발생하지 않습니다. accept_mutex는 명시적으로 끌 수 있는 제어 가능한 옵션입니다. 기본적으로 켜져 있습니다. 작업자 프로세스가 연결을 수락하면 요청을 읽고, 요청을 구문 분석하고, 요청을 처리하고, 데이터를 생성한 다음 이를 클라이언트에 반환하고, 마지막으로 연결을 끊습니다. 이것이 완전한 요청의 모습입니다. 요청이 작업자 프로세스에 의해 완전히 처리되고 하나의 작업자 프로세스에서만 처리되는 것을 볼 수 있습니다.
(4) 이 프로세스 모델을 채택한 nginx의 이점은 무엇입니까?
독립적인 프로세스를 사용해도 서로 영향을 미치지 않습니다. 한 프로세스가 종료된 후에도 다른 프로세스는 계속 작동하며 서비스는 중단되지 않습니다. 마스터 프로세스는 새 작업자 프로세스를 빠르게 다시 시작합니다. 물론 작업자 프로세스가 비정상적으로 종료되면 프로그램에 버그가 있는 것이 틀림없으며 비정상적으로 종료하면 현재 작업자에 대한 모든 요청이 실패하게 되지만 모든 요청에 ​​영향을 미치지는 않으므로 위험이 줄어듭니다. 물론 장점도 많고, 누구나 천천히 경험할 수 있습니다.
(5) nginx는 다중 작업자 방식을 사용하여 요청을 처리합니다. 각 작업자에는 하나의 기본 스레드만 있으므로 처리할 수 있는 동시 작업 수는 매우 제한되어 있습니다. 그렇다면 어떻게 높은 동시성을 달성할 수 있을까요? 아니요, 이것이 nginx의 장점입니다. nginx는 요청을 처리하기 위해 비동기식 및 비차단 방식을 사용합니다. 즉, nginx는

모든 IIS 서버에 대해 동시에 처리할 수 있습니다. 작업 스레드를 독점적으로 점유합니다. 동시성 수가 수천 개에 도달하면 수천 개의 스레드가 동시에 요청을 처리하게 됩니다. 이는 운영 체제에 있어서 큰 과제입니다. 스레드가 차지하는 메모리는 매우 크고 스레드 컨텍스트 전환으로 인한 CPU 오버헤드도 매우 큽니다. 당연히 성능을 향상시킬 수 없으며 이러한 오버헤드는 전혀 의미가 없습니다. 이전에 작업자 수를 CPU 코어 수로 설정하는 것이 좋습니다. 여기서는 이해하기 쉽습니다. 작업자가 많아지면 프로세스가 CPU 리소스를 두고 경쟁하게 되어 불필요한 컨텍스트 전환이 발생하게 됩니다. 게다가, 멀티 코어 기능을 더 잘 활용하기 위해 nginx는 CPU 선호도 바인딩 옵션을 제공합니다. 특정 프로세스를 특정 코어에 바인딩하여 프로세스 전환으로 인해 캐시가 실패하는 일이 없습니다.

로드밸런싱

로드밸런싱 기술은 이제 저렴하고, 네트워크 장치 및 서버의 대역폭을 확장하고 처리량을 늘리며 네트워크 데이터 처리 기능을 강화하고 네트워크 유연성과 가용성을 향상시키기 위해 네트워크 구조를 기반으로 하는 효과적이고 투명한 방법입니다. 두 가지 의미가 있습니다. 첫째, 별도의 처리를 위해 대량의 동시 액세스 또는 데이터 트래픽이 여러 노드 장치에 공유되어 사용자가 응답을 기다리는 시간이 줄어듭니다. 둘째, 단일 과부하 작업이 병렬을 위해 여러 노드 장치에 공유됩니다. 처리, 각 노드 장치의 처리가 완료된 후 결과가 요약되어 사용자에게 반환되며 시스템 처리 능력이 크게 향상됩니다

위 내용은 내용의 측면을 포함하여 Nginx---이벤트 처리 메커니즘 및 프로세스 모델을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.