Thread driven(쓰레드 기반), Event driven(이벤트 기반) : 정의, 분석

Nginx, Redis 및 노드는 모두 이벤트 기반입니다. 비동기식 작업(IO)이 완료되었다는 이벤트를 수신한 다음 비동기식 작업이 시작되었을 때 등록된 콜백을 실행하는 이벤트 루프가 있습니다. 이 루프는 어떤 것도 기다리지 않습니다. 즉, 단일 스레드가 이 코드를 실행하기만 하면 작업이 완전히 중단될 수 있습니다.

우리가 마이크로소프트의 노예였을 때, 작업을 나누는 방법으로 멀티스레딩과 씨름하곤 했습니다. 웹 앱에서 모든 요청이 새 스레드로 시작했습니다. 또한 쉬운 추상화가 아닌 TPML(Task Parallel Library)을 사용합니다. 그리고 이를 Rx(Reactive Extensions)와 같은 일부 이벤트 처리 라이브러리와 결합합니다. C#의 새로운 Wait 키워드는 많은 도움이 되지만, 어느 쪽이든 항상 스레드 안전성에 대해 생각해야 합니다. 그리고 동일한 데이터에 동시에 액세스하는 모든 종류의 잠금 전략도 있습니다. 그 모든 것에도 불구하고, 그렇게 빠르지 않습니다.

두 작동 방식의 차이점은 프로그램이 조정되는 방식에 있습니다.

이벤트 기반

이벤트 기반 애플리케이션은 콜백, 이벤트 루프 및 대기열을 사용하여 작업을 나눕니다. 작업의 단위 또는 태스크는 콜백을 뜻합니다. 한 번에 한 번의 콜백만이 실행됩니다. 유일한 블록처럼 코드를 쓸 수 있습니다. 언제 다 끝났는지 결정하고 나서 다른 함수에게 효과적으로 통제권을 넘겨줍니다. 다들 정말 예의바른 함수라서 잘 작동합니다.

스레드 기반

스레드 기반 애플리케이션은 기본적으로 하드웨어에서 작업을 분할합니다. 각 작업에는 자체 스레드가 있으며 필요한 경우 차단되므로 CPU는 해당 스레드를 일시 중단하고 대기 중인 다른 스레드를 실행합니다. 그럴 때마다 약 2MB의 데이터를 이동하는 등 상당히 큰 컨텍스트 스위치가 사용됩니다. 실제로 하드웨어가 언제 제어권을 넘겨야 할지 결정하는데도 별다른 권한이 없습니다.

모든 것을 처리하는 하나의 프로세서가 여러 프로세서보다 더 빠를 수 있을까요? 하나의 핵심에서, 사실일지도 모릅니다. 여러 코어에서 실제로 그럴 수도 있습니다. 그 이유는 Nginx와 Node, Redis가 모두 동일한 머신에서 실행되고 있기 때문입니다. 단순하게, 4중 코어에서 각각 하나의 코어만 사용하고 나머지 하나는 여전히 남아 있습니다.

하지만 멀티스레드 환경의 동기식 코드를 쓰는 것이 단일 스레드 환경의 비동기식 코드를 쓰는 것보다 훨씬 쉽습니다. 하지만 노드 커뮤니티에 도움이 되는 몇 가지 훌륭한 패턴이 등장했습니다.  

CPS(Continuous-Passing Style)는 콜백입니다. 익숙해지면 어렵지 않습니다. 그리고 캡슐화 하는 좋은 방법이자 모듈화가 매우 쉽습니다. 비동기 함수의 패턴은 마지막 인수가 항상 콜백이고 콜백 패턴은 오류가 항상 첫 번째 인수(이후 결과)라는 것입니다. 이 표준화는 코딩을 정말 쉽게 만들어 줍니다.

복잡성을 줄이는 데 도움이 될 수 있는 NPM 모듈이 많이 있습니다. 그 중 최고는 여전히 비동기입니다. 가장 인기 있고 노드 규칙을 따릅니다. 또한 보다 동기적인 스타일로 코드를 입력할 수 있는 CPS 컴파일러도 몇 개 있습니다. 과거에는 추천하지 않았겠지만, TameJs나 Iceed CoffeeScript와 같이 꽤 괜찮은 "aait, late" 패턴을 사용하는 몇 가지가 있습니다. 요즘 점점 더 CoffeeScript를 사용하고 있는데, 매우 매력적이지만 저는 아직 사용하지 않습니다.

노드에서 앱을 개발하고 있으며 문제를 분리하고 코드를 모듈화하는 방법에 대해 많은 것을 알 수 있습니다. 익숙했던 개체 지향의 클래스 기반의 분리와는 많이 다릅니다. 하지만 기능적인 스타일을 사용하기 위해 재프로그래밍한 후에 실제로 구조화하기가 훨씬 더 쉽습니다. 노드가 대형 프로젝트에 좋지 않을 수 있습니다. 하지만, 몇 가지 간단한 규칙을 따른 후에 완벽해질 것입니다.