지금 당장 프로세스를 진행 중입니다! 메시지,하지만 내가 좀 봤 거든, 메시지 대기열 크기는 메모리로만 제한됩니다. 나는 잎이 메시지를 생성하고 루트까지 피드하는 프로세스의 트리를 가지고 있으며 큐를 제한하거나 같은 것을 수행하는 다른 방법으로 전환해야한다.erlang - 메시지 큐를 제한하거나 에뮬레이트하는 방법은 무엇입니까?
개 이상의 경우 가끔 프로세스가 한 잎과 때로는 두 잎에서 메시지를 가져옵니다. 두 번째 경우에는 처마 잎을위한 다른 유한 대기열이 필요합니다.
프로세스의 메시지 대기열 크기를 제한하는 기본 제공 메커니즘이 없습니다.
erlang의이 문제에 대한 일반적인 해결책은 생산자와 소비자간에 흐름 제어 프로토콜을 도입하는 것입니다. 다음 메시지를 보내기 전에 발신자가 continue 답장을 기다리는 것처럼 간단 할 수 있습니다. 좀 더 복잡한 흐름 제어 프로토콜 (windowing, ...)을 만들 수 있지만 종종 send/wait-reply가 수행합니다. gen_server:call/2 프로토콜은 좋은 요청 - 응답 프로토콜이며 gen_server 및 gen:call 코드를보고 다시 사용할 수 있습니다. 가능한 많은 엣지 케이스를 처리합니다.
또 다른 접근법은 푸시하는 대신 시스템을 통해 메시지를 가져 오는 것입니다.이 경우 수신자는 송신자에게 준비가되었을 때 메시지를 요청합니다. 속도를 제한하거나 충분히 버퍼링 할 수없는 외부 제작자가있는 경우이 옵션을 사용할 수 없습니다.
두 번째 사례를 처리하는 일반적인 방법은 메시지에 전송 프로세스 Pid을 포함시키는 것입니다. 이것은 보통 {SendingPid,Data}과 비슷한 구조를 갖는 erlang 메시지에 대해 매우 일반적입니다. 이렇게하면 수신자가 메시지를 보낸 사람을 확인하고 receive 내의 패턴 일치를 사용하여 메시지를 수신 할 프로세스를 선택할 수 있습니다.
이것은 erlang이 여러 메시지 보낸 사람의 메시지를 하나의 메시지 큐에 다중화하고 모든 가능한 메시지를 모든 곳에서 처리 할 수있는 방법입니다.
RabbitMQ는 Credit Flow의 형태로 이것을 구현합니다. 이 블로그 게시물에 대한 추가 정보 : http://videlalvaro.github.io/2013/09/rabbitmq-internals-credit-flow-for-erlang-processes.html