node.js의 높은 동시성과 분산 클러스터링에 대한 간략한 토론-JS 튜토리얼-php.cn

이 글은 node.js의 높은 동시성과 분산 클러스터에 대한 간략한 논의를 소개합니다. 필요한 친구들이 참고할 수 있기를 바랍니다.

노드 기능: 높은 동시성

노드가 높은 동시성을 달성할 수 있는 이유를 설명하기 전에 노드의 다른 여러 기능을 이해하는 것이 좋습니다.

단일 스레드

먼저 개념을 명확히 합시다. 즉, 노드는 싱글 스레드는 브라우저의 JavaScript 특성과 동일하며, 노드에서는 JavaScript 메인 스레드가 다른 스레드(예: I/O 스레드)와 상태를 공유할 수 없습니다. 单线程的，这一点与JavaScript在浏览器中的特性相同，并且在node中JavaScript主线程与其他线程（例如I/O线程）是无法共享状态的。

单线程的好处就是：

无需像多线程那样去关注线程之间的状态同步问题
没有线程切换所带来的开销
没有死锁存在

当然单线程也有许多坏处：

无法充分利用多核CPU
大量计算占用CPU会导致应用阻塞(即不适用CPU密集型)
错误会引起整个应用的退出

不过在今天看来，这些坏处都已经不再是问题或者得到了适当的解决：

(1) 创建进程 or 细分实例

关于第一个问题，最直白解决方案就是使用child_process核心模块或者cluster：child_process 和 net 组合应用。我们可以通过在一台多核服务器上创建多个进程（通常使用fork操作）来充分利用每个核心，不过要处理好进程间通信问题。

另一个方案是，我们可以将物理机器划分为多台单核的虚拟机，并通过pm2等工具，管理多台虚拟机形成一个集群架构，高效运行所需服务，至于每台机器间的通信（状态同步）我这里先按下不表，在下文的Node分布式架构中再做详细说明。

(2) 时间片轮转

关于第二点，我跟小伙伴讨论过后认为可以通过时间片轮转方式，在单线程上模拟多线程，适当减少应用阻塞的感觉（虽然这种方法不会真的像多线程那样节约时间）

(3) 负载均衡、坏点监控/隔离

至于第三点，我跟小伙伴们也讨论过，认为主要的痛点就在于node不同于JAVA，它所实现的逻辑是以异步为主的。

这就导致了node无法像JAVA一样方便地使用 try/catch 来来捕获并绕过错误，因为无法确定异步任务会何时传回异常。而在单线程环境下，绕不过错误就意味着导致应用退出，重启恢复的间隙会导致服务中断，这是我们不愿意看到的。

当然，在服务器资源丰富的当下，我们可以通过 pm2 或 nginx 这些工具，动态的判断服务状态。在服务出错时隔离坏点服务器，将请求转发到正常服务器上，并重启坏点服务器以继续提供服务。这也是Node分布式架构的一部分。

异步I/O

你可能会问，既然node是单线程的，事件全部在一个线程上处理，那不是应该效率很低、与高并发相悖吗？

恰恰相反，node的性能很高。原因之一就是node具有异步I/O特性，每当有I/O请求发生时，node会提供给该请求一个I/O线程。然后node就不管这个I/O的操作过程了，而是继续执行主线程上的事件，只需要在该请求返回回调时在处理即可。也就是node省去了许多等待请求的时间。

这也是node支持高并发的重要原因之一

实际上不光是I/O操作，node的绝大多数操作都是以这种异步的方式进行的。它就像是一个组织者，无需事必躬亲，只需要告诉成员们如何正确的进行操作并接受反馈、处理关键步骤，就能使得整个团队高效运行。

事务驱动

你可能又要问了，node怎么知道请求返回了回调，又应该何时去处理这些回调呢？

答案就是node的另一特性：事务驱动

싱글 쓰레드의 장점은

멀티 쓰레드처럼 쓰레드 간 상태 동기화 문제에 신경 쓸 필요가 없습니다.

스레드 전환으로 인한 오버헤드가 없습니다.

없습니다. 교착 상태

물론 단일 스레딩에도 많은 단점이 있습니다.

멀티 코어 CPU를 완전히 활용할 수 없습니다.

CPU를 차지하는 많은 계산으로 인해 응용 프로그램이 차단됩니다(예: CPU에 적합하지 않음) -집중)
오류로 인해 전체 애플리케이션이 종료됩니다
🎜 🎜그러나 오늘날 이러한 단점은 더 이상 문제가 되지 않거나 적절하게 해결된 것 같습니다. 🎜🎜(1) 프로세스 생성 또는 인스턴스 세분화 🎜🎜 첫 번째 문제와 관련하여 가장 간단한 해결책은 child_process 코어 모듈 또는 클러스터인 child_process와 net 결합 애플리케이션을 사용하는 것입니다. 멀티 코어 서버에서 여러 프로세스를 생성(보통 포크 작업 사용)하여 각 코어를 최대한 활용할 수 있지만 프로세스 간 통신 문제를 처리해야 합니다. 🎜🎜또 다른 솔루션은 물리적 머신을 여러 개의 단일 코어 가상 머신으로 나누고 pm2와 같은 도구를 사용하여 여러 가상 머신을 관리하여 클러스터 아키텍처를 형성하여 필요한 서비스를 효율적으로 실행할 수 있다는 것입니다. 통신(상태 동기화) 지금은 여기에 나열하지 않고 아래 Node 분산 아키텍처에서 자세히 설명하겠습니다. 🎜🎜(2) 타임 슬라이스 회전🎜🎜 두 번째 점에 관해서는 친구들과 논의한 후 타임 슬라이스 회전을 사용하여 단일 스레드에서 멀티스레딩을 시뮬레이션하여 애플리케이션 차단 느낌을 적절하게 줄일 수 있다고 믿습니다. 방법은 그렇지 않습니다. 멀티스레딩처럼 정말 시간이 절약됩니다)🎜🎜(3) 로드 밸런싱, 불량 픽셀 모니터링/격리🎜🎜세 번째로, 저도 친구들과 의논한 적이 있는데 가장 큰 문제점은 다음과 같습니다. 노드는 JAVA와 다릅니다. 구현된 로직은 주로 비동기식입니다. 🎜🎜이로 인해 노드는 try/catch를 사용하여 JAVA만큼 편리하게 오류를 포착하고 우회할 수 없게 됩니다. 비동기 작업이 언제 예외를 반환할지 결정할 수 없기 때문입니다. 단일 스레드 환경에서 오류 우회에 실패하면 애플리케이션이 종료되고 다시 시작과 복구 사이의 간격으로 인해 서비스 중단이 발생하므로 우리는 이를 보고 싶지 않습니다. 🎜🎜물론, 이제 서버 리소스가 풍부하므로 pm2 또는 nginx와 같은 도구를 사용하여 서비스 상태를 동적으로 확인할 수 있습니다. 서비스 오류 발생 시 불량 픽셀 서버를 격리하고, 정상 서버로 요청을 전달한 후 불량 픽셀 서버를 재시작하여 서비스를 계속 제공합니다. 이는 Node의 분산 아키텍처의 일부이기도 합니다. 🎜🎜비동기 I/O🎜🎜노드가 단일 스레드이고 모든 이벤트가 하나의 스레드에서 처리되기 때문에 매우 비효율적이고 높은 동시성에 반하는 것이 아닌가? 🎜🎜반대로 노드의 성능은 매우 높습니다. 그 이유 중 하나는 노드에 비동기 I/O 기능이 있기 때문입니다. I/O 요청이 발생할 때마다 노드는 요청에 대한 I/O 스레드를 제공합니다. 그러면 노드는 I/O 작업 프로세스에 신경 쓰지 않고 기본 스레드에서 이벤트를 계속 실행합니다. 요청이 콜백을 반환할 때만 처리하면 됩니다. 즉, 노드는 요청을 기다리는 데 많은 시간을 절약합니다. 🎜🎜🎜이것은 노드가 높은 동시성을 지원하는 중요한 이유 중 하나이기도 합니다🎜🎜🎜실제로 I/O 작업뿐만 아니라 노드의 대부분의 작업이 이러한 비동기 방식으로 수행됩니다. 모든 일을 개인적으로 할 필요는 없고 구성원들에게 올바르게 작동하는 방법, 피드백을 수용하고 주요 단계를 처리하는 방법만 알려주면 팀 전체가 효율적으로 운영될 수 있습니다. 🎜🎜Transaction-driven🎜🎜다시 물어보고 싶을 수도 있습니다. 노드는 요청이 콜백을 반환했다는 것을 어떻게 알 수 있으며 언제 이러한 콜백을 처리해야 합니까? 🎜🎜답은 노드의 또 다른 기능인 트랜잭션 드라이버입니다. 즉, 메인 스레드가 이벤트 루프 트리거를 통해 프로그램을 실행합니다. 🎜🎜🎜이것이 노드가 높은 동시성을 지원하는 또 다른 중요한 이유입니다🎜🎜 🎜 노드 환경의 이벤트 루프 그림: 🎜
```
   ┌───────────────────────┐
┌─>│        timers         │🎜🎜poll 단계: 🎜🎜🎜poll 단계에 들어가고 타이머가 호출되지 않으면 다음 상황이 발생합니다. 🎜🎜 (1) poll 대기열이 비어 있지 않은 경우 ： 🎜🎜🎜🎜이벤트 루프는 대기열이 비어 있거나 실행된 콜백이 온라인 상태가 될 때까지 폴 대기열에서 콜백(새 I/O 이벤트)을 동기적으로 실행합니다. 🎜🎜🎜🎜(2) 폴링 대기열이 비어 있는 경우: 🎜🎜🎜🎜스크립트가 setImmediate()를 호출하면 이벤트 루프는 폴링 단계를 종료하고 확인 단계로 들어가 setImmediate() 콜백을 실행합니다. 🎜🎜🎜🎜setImmediate()에 의해 스크립트가 호출되지 않으면 이벤트 루프는 콜백(새 I/O 이벤트)이 대기열에 추가될 때까지 기다린 다음 이를 즉시 실행합니다. 🎜
```
로그인 후 복사

폴링 단계에 들어가고 타이머가 호출되면 다음이 발생합니다.

폴링 대기열이 비어 있으면 이벤트 루프는 타이머가 있는지 확인하고 하나 이상의 타이머가 도착하면 이벤트 루프가 다음으로 돌아갑니다. 타이머 단계를 완료하고 해당 타이머 콜백을 실행합니다(즉, 다음 틱 입력).

우선순위:

Next Tick Queue > MicroTask Queue

setTimeout, setInterval > setImmediate

타이머는 시간이 도달했는지 확인하기 위해 레드-블랙 트리에서 타이머를 꺼내야 하기 때문에, 시간 복잡도는 O(lg(n))이므로 이벤트를 즉시 비동기식으로 실행하려면 setTimeout(func, 0)을 사용하지 않는 것이 가장 좋습니다. 대신 process.nextTick()을 사용하여 이를 수행하세요.

분산 노드 아키텍처

제가 배운 노드 클러스터 아키텍처는 크게 다음과 같은 모듈로 나뉩니다.

Nginx(로드 밸런싱, 스케줄링) ->노드 클러스터-> Redis(동기화 상태)

압축 내 이해를 바탕으로 한 그림:

node.js의 높은 동시성과 분산 클러스터링에 대한 간략한 토론

물론 이것이 이상적인 아키텍처여야 합니다. Redis의 읽기/쓰기 속도가 꽤 빠르긴 하지만, 메모리 풀에 데이터를 저장하고 메모리에서 관련 작업을 수행하기 때문이다.

이것은 서버의 메모리 부하에 비해 상당히 높기 때문에 일반적으로 아래와 같이 아키텍처에 MySQL을 추가합니다.

node.js의 높은 동시성과 분산 클러스터링에 대한 간략한 토론

먼저 이 그림을 설명합니다.
사용자 데이터가 도착하면 데이터 쓰기 대상 먼저 Mysql로 가서 Node에 필요한 데이터가 없으면 Mysql로 가서 원하는 데이터를 쿼리하고, 다음번에 Redis로 직접 가서 쓰면 됩니다. 질문.

Redis에서 읽기/쓰기만 하는 것에 비해 Mysql을 추가하면 다음과 같은 장점이 있습니다.

(1) Redis에 불필요한 데이터를 단기적으로 쓰는 것을 피하고, 메모리를 점유하며, Redis에 대한 부담을 줄입니다.

(2) 수정 필요 이후 단계의 데이터 특정 쿼리 및 분석(예: 운영 활동 사용자 증가 분석 등)을 수행할 때 SQL 관계형 쿼리가 큰 도움이 될 수 있습니다

물론 단기적인 대규모 트래픽 쓰기를 처리할 때는 다음과 같은 작업을 수행할 수 있습니다. 또한 Redis에 직접 데이터를 쓰기도 합니다. 데이터를 빠르게 저장하고 서버의 트래픽 대처 능력을 높이기 위한 목적을 달성하기 위해 트래픽이 가라앉을 때 데이터를 Mysql에 별도로 쓸 수도 있습니다.

일반 아키텍처를 간략하게 소개한 후 각 부분의 세부 사항을 자세히 살펴보겠습니다.