"프로세스로 메시지"작업 큐에 대한 Erlang 디자인 패턴은 무엇입니까?

Question

나는 에얼랑 토크에서 언급 된 디자인 패턴을 알아 내려고하고있다. 기본적으로 연사는 작업을 프로세스로 사용하는 대신 "프로세스로 메시지 보내기"를 사용하여 작업 대기열을 사용한다고 언급합니다.

"프로세스로 메시지 보내기"를 사용하면 직렬화/직렬화 해제 오버 헤드를 줄일 수 있습니다.

감사

Answer 1

하자 우리가 시스템에 주위를 보내는 메시지 인 얼랑 용어를() 수 M. M을 처리하는 한 가지 분명한 방법은 프로세스와 큐의 파이프 라인을 구축하는 것입니다. M은 파이프 라인의 첫 번째 작업자에 의해 처리 된 후 다음 큐로 보내집니다. 그런 다음 다음 작업자 프로세스가 다시 처리하여 대기열에 넣습니다. 메시지가 완전히 처리 될 때까지 계속됩니다.

아마 그렇게 명백하지 않은 방법은 P 프로세스를 정의한 다음 M을 P으로 지정하는 것입니다. 우리는 이것을 P(M)으로 지정할 것입니다. 이제 메시지 자체는 프로세스이고 데이터는이 아닙니다. P은 작업자가 대기열 솔루션에서 수행 한 작업과 동일한 작업을 수행하지만 M을 다시 대기열에 집어 넣고 다시 가져 오는 오버 헤드를 지불 할 필요가 없습니다. 처리 P(M)이 완료되면 프로세스가 종료됩니다. M' 다른 메시지를 건네 주면 단순히 P(M')을 스폰하고 그 메시지를 동시에 처리하게합니다. 일련의 프로세스가 있으면 [P(M) || M <- Set] 등의 작업을 수행합니다.

P은 동기화 또는 메시징을 수행해야 할 경우 이 메시지 인이기 때문에 메시지를 "가장 할 필요없이"그렇게 할 수 있습니다. 작업자가 함께 오는 메시지에 대해 책임을 져야하는 작업자 대기열 접근 방식과 대조됩니다. P에 오류가있는 경우 오류의 영향을받는 P(M) 메시지 만 충돌합니다. 다시 말하지만, 파이프 라인의 충돌이 다른 메시지에 영향을 미칠 수있는 작업자 대기열 접근 방식과 대조됩니다 (주로 파이프 라인이 잘못 설계된 경우).

그래서 결론은 다음과 같습니다. 메시지가이되는 프로세스로 메시지를 넘깁니다.

이디엄은 '메시지 당 하나의 프로세스'이며 얼랭에서 흔히 볼 수 있습니다. 새로운 프로세스를 만드는 데 드는 비용과 오버 헤드는 충분히 낮습니다. 그러나 아이디어를 사용하면 과부하 보호가 필요할 수 있습니다. 그 이유는 동시 요청의 양에 제한을두기를 원할 것이므로 제어은 서버를 맹목적으로 파손시키지 않고 시스템의 부하를 제어하기 때문입니다. 하나는 이러한 구현은

https://github.com/esl/jobs

를 참조 얼랑 솔루션에 의해 생성 채용이고, 울프 Wiger는 그것을 제시 :

울프가 이야기에서 힌트로서 http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger

, 우리가 일반적으로 것입니다 P 외부에서 몇 가지 사전 처리를 수행하여 메시지를 분석하고이를 얼랑 시스템에 내재화하십시오.가능한 한 빨리 M 메시지를 작업으로 처리 할 것입니다 (P(M)). 따라서 Erlang Scheduler의 이점을 바로 얻을 수 있습니다.

이 선택의 또 다른 중요한 결과가 있습니다. 처리가 메시지에 오랜 시간이 걸리면 얼랭의 선점 스케줄러는 처리 요구가 적은 메시지가 여전히 신속하게 처리되도록합니다. 제한된 작업자 대기열이있는 경우 많은 작업이 막히면 시스템 처리량이 저하 될 수 있습니다.