Node.js 이벤트 루프(Event Loop) 및 스레드 pool_node.js에 대한 자세한 설명

Node의 '이벤트 루프'는 대규모 동시성과 높은 처리량을 처리하는 능력의 핵심입니다. 이것은 Node.js가 기본적으로 "단일 스레드"로 이해될 수 있는 동시에 백그라운드에서 임의의 작업을 처리할 수 있는 가장 마법 같은 부분입니다. 이 글에서는 이벤트 루프가 어떻게 작동하는지 설명하여 여러분이 그 마법을 느낄 수 있도록 하겠습니다.

이벤트 중심 프로그래밍

이벤트 루프를 이해하려면 먼저 이벤트 중심 프로그래밍을 이해해야 합니다. 1960년에 등장했습니다. 요즘에는 이벤트 중심 프로그래밍이 UI 프로그래밍에 많이 사용됩니다. JavaScript의 주요 용도 중 하나는 DOM과 상호작용하는 것이므로 이벤트 기반 API를 사용하는 것은 자연스러운 일입니다.

간단히 정의하면 이벤트 중심 프로그래밍은 이벤트나 상태 변경을 통해 애플리케이션의 흐름을 제어합니다. 일반적으로 이벤트 모니터링을 통해 구현되며, 이벤트가 감지되면(즉, 상태가 변경되면) 해당 콜백 함수가 호출됩니다. 익숙한 것 같나요? 실제로 이것이 Node.js 이벤트 루프의 기본 작동 원리입니다.

클라이언트 측 JavaScript 개발에 익숙하다면 DOM 요소와 결합하여 사용자 상호 작용을 전달하는 데 사용되는 element.onclick()과 같은 .on*() 메서드를 생각해 보세요. 이 작업 모드를 사용하면 단일 인스턴스에서 여러 이벤트를 트리거할 수 있습니다. Node.js는 서버측 소켓 및 "http" 모듈과 같은 EventEmitters(이벤트 생성기)를 통해 이 패턴을 트리거합니다. 단일 인스턴스에서 하나 이상의 상태 변경이 트리거될 수 있습니다.

또 다른 일반적인 패턴은 성공과 실패를 표현하는 것입니다. 일반적으로 두 가지 일반적인 구현 방법이 있습니다. 첫 번째는 "오류 예외"를 콜백에 전달하는 것입니다. 일반적으로 콜백 함수의 첫 번째 매개변수로 사용됩니다. 두 번째는 Promises 디자인 패턴을 사용하고 ES6를 추가했습니다. 참고* Promise 모드는 jQuery와 유사한 함수 체인 작성 방법을 사용하여 다음과 같은 콜백 함수의 깊은 중첩을 방지합니다.

코드 복사 코드는 다음과 같습니다.

$.getJSON('/getUser').done(successHandler).fail(failHandler)

"fs"(파일 시스템) 모듈은 대부분 콜백에 예외를 전달하는 스타일을 채택합니다. fs.readFile() 연결된 이벤트와 같은 특정 호출을 기술적으로 트리거하지만 API는 단지 사용자에게 경고하고 작업의 성공 또는 실패를 표현하는 것입니다. 이러한 API의 선택은 기술적 제한보다는 아키텍처 고려 사항을 기반으로 합니다.

일반적인 오해는 이벤트 발생기가 이벤트를 실행할 때 본질적으로 비동기적이라는 것인데 이는 잘못된 것입니다. 다음은 이를 보여주는 간단한 코드 조각입니다.

코드 복사 코드는 다음과 같습니다.

함수 MyEmitter() {
EventEmitter.call(this);
}
util.inherits(MyEmitter, EventEmitter);

MyEmitter.prototype.doStuff = 함수 doStuff() {
console.log('이전')
Emitter.emit('불')
console.log('이후')}
};

var me = new MyEmitter();
me.on('fire', function() {
console.log('방출 실행');
});

me.doStuff();
// 출력:
//전
// 발사됨
//후

참고* Emitter.emit이 비동기인 경우 출력은
이어야 합니다. //전
//후
// 발사됨

EventEmitter는 비동기적으로 완료되어야 하는 작업을 알리는 데 자주 사용되기 때문에 비동기적으로 동작하는 경우가 많지만 EventEmitter API 자체는 완전히 동기적입니다. Listening 함수는 내부적으로 비동기적으로 실행될 수 있지만, 모든 Listening 함수는 추가된 순서대로 동기적으로 실행된다는 점에 유의하세요.

메커니즘 개요 및 스레드 풀

노드 자체는 여러 라이브러리에 의존합니다. 그 중 하나는 비동기 이벤트 큐 및 실행을 처리하는 놀라운 라이브러리인 libuv입니다.

노드는 기존 기능을 구현하기 위해 운영 체제 커널을 최대한 활용합니다. 응답 요청 생성, 연결 전달 및 처리를 위해 시스템에 위임하는 것과 같습니다. 예를 들어, 들어오는 연결은 Node.js에서 처리할 수 있을 때까지 운영 체제를 통해 대기열에 추가됩니다.

Node에 스레드 풀이 있다는 말을 듣고 "Node가 작업을 순서대로 처리한다면 왜 스레드 풀이 필요한가요?"라고 궁금해하실 수도 있습니다. 비동기적으로 실행됩니다. 이 경우 Node.JS가 차단되지 않고 이벤트 루프를 계속 실행할 수 있도록 작동하는 동안 일정 시간 동안 스레드를 잠글 수 있어야 합니다.

다음은 내부 작동 메커니즘을 보여주는 간단한 예시 다이어그램입니다.

┌──────────────────────┐
╭──►│ 타이머 타이머 │        └───────────┬───────────┘
│       ┌───────────┴───────────┐
│                                                                                                          +                               │          └───────────┬───────────┘                                                                    ~ | │ │ │ 설문조사 ││── 연결, │
│                                                                                                          ~       이후 │           ┌────────────┴───────────┐                                                                                                                            ╰─── ┤ 즉시 설정 └───────────────────────┘

이벤트 루프의 내부 작동에 대해 이해하기 어려운 몇 가지 사항이 있습니다.

모든 콜백은 이벤트 루프의 한 단계(예: 타이머)가 끝나고 다음 단계로 전환되기 전에 process.nextTick()을 통해 사전 설정됩니다. 이렇게 하면 process.nextTick()에 대한 잠재적인 재귀 호출을 방지하여 무한 루프가 발생합니다.
"보류 중인 콜백"은 다른 이벤트 루프 주기(예: fs.write에 전달됨)에 의해 처리되지 않는 콜백 대기열의 콜백입니다.

이벤트 이미터 및 이벤트 루프

EventEmitter를 생성하여 이벤트 루프와의 상호 작용을 단순화합니다. 이벤트 기반 API를 보다 쉽게 ​​생성할 수 있는 일반 래퍼입니다. 두 가지가 상호 작용하는 방식은 종종 개발자를 혼란스럽게 만듭니다.

다음 예는 이벤트가 동기적으로 트리거된다는 사실을 잊어버리면 이벤트가 누락될 수 있음을 보여줍니다.

코드 복사 코드는 다음과 같습니다.

// v0.10 이후에는 require('events').EventEmitter가 더 이상 필요하지 않습니다.
var EventEmitter = require('events');
var util = require('util');

MyThing() 함수 {
EventEmitter.call(this);

doFirstThing();
this.emit('thing1');
}
util.inherits(MyThing, EventEmitter);

var mt = new MyThing();

mt.on('thing1', 함수 onThing1() {
// 죄송합니다. 이 이벤트는 절대 발생하지 않습니다.
});

위의 'thing1' 이벤트는 MyThing()에 의해 캡처되지 않습니다. 왜냐하면 MyThing()이 이벤트를 수신하기 전에 인스턴스화되어야 하기 때문입니다. 추가 클로저를 추가하지 않고 간단한 해결 방법은 다음과 같습니다.

코드 복사 코드는 다음과 같습니다.

var EventEmitter = require('events');
var util = require('util');

MyThing() 함수 {
EventEmitter.call(this);

doFirstThing();
setImmediate(emitThing1, this);
}
util.inherits(MyThing, EventEmitter);

emitThing1(self) 함수 {
self.emit('thing1');
}

var mt = new MyThing();

mt.on('thing1', 함수 onThing1() {
// 실행
});

다음 솔루션도 작동하지만 일부 성능이 저하됩니다.

코드 복사 코드는 다음과 같습니다.

함수 MyThing() {
EventEmitter.call(this);

doFirstThing();
// Function#bind()를 사용하면 성능이 저하됩니다
setImmediate(this.emit.bind(this, 'thing1'));
}
util.inherits(MyThing, EventEmitter);

또 다른 문제는 오류를 유발하는 것입니다. 애플리케이션에서 문제를 찾는 것은 충분히 어렵지만 호출 스택(*e.stack 참고)이 없으면 디버깅이 거의 불가능합니다. 원격 비동기 요청에서 오류가 수신되면 호출 스택이 손실됩니다. 두 가지 가능한 해결 방법이 있습니다. 동기적으로 트리거하거나 오류가 다른 중요한 정보와 함께 전달되도록 하는 것입니다. 아래 예에서는 두 가지 솔루션을 모두 보여줍니다.

코드 복사 코드는 다음과 같습니다.

MyThing.prototype.foo = 함수 foo() {
// 이 오류는 비동기적으로 발생합니다
var er = doFirstThing();
만약 (어) {
//트리거되면 현장 호출 스택 정보를 유지하기 위해 새로운 오류를 생성해야 합니다
setImmediate(emitError, this, new Error('나쁜 물건'));
반품;
}

// 오류를 발생시키고 즉시(동기적으로) 처리
var er = doSecondThing();
만약 (어) {
This.emit('error', '더 나쁜 내용');
반품;
}
}

상황을 평가하십시오. 오류가 발생하면 즉시 처리될 수 있습니다. 또는 쉽게 처리하거나 나중에 처리할 수 있는 사소한 예외일 수도 있습니다. 또한 생성자를 통해 Error를 전달하는 것은 좋은 생각이 아닙니다. 생성된 개체 인스턴스가 불완전할 가능성이 높기 때문입니다. 방금 Error가 직접 발생한 경우는 예외입니다.

결론

이 기사에서는 이벤트 루프의 내부 작동 방식과 기술적 세부 사항을 간략하게 설명합니다. 모두 잘 생각되었습니다. 또 다른 기사에서는 이벤트 루프와 시스템 커널의 상호 작용에 대해 논의하고 NodeJS 비동기 작업의 마법을 보여줄 것입니다.