나는 rpc 호출을 듣고 어딘가에 쌓아서 처리하고 응답해야한다. 것은 그들이 올 자마자 달리지 않는다는 것입니다. 응답은 수신 된 각 rpc 호출에 대한 ACK입니다. 문제는 내가 많은 청취 서버를 같은 스택의 스택에 작성할 수있는 방식으로 디자인하고 싶다는 것입니다.확장 가능한 rpc 호출 수신기를 설계하는 방법은 무엇입니까?
내 목표는 가능한 한 많은 전화를 수신하는 것입니다. 어떻게해야합니까?
내 주요 기술은 Perl과 node.js이지만이 작업에는 오픈 소스 소프트웨어를 사용합니다.
그것은 당신이 그것을 필요로하는 어떤 종류의 작업 대기열처럼 들린다. 저는 개인적으로 이런 종류의 것을 을 사용하는 것을 좋아합니다. Redis 목록은 삽입 순서를 유지하기 때문에 RPC 호출을 수신하는 임의의 수의 웹 서버에서 목록의 끝에있는 RPC 호출 정보를 LPUSH으로 간단하게 지정할 수 있습니다 (다른 프로세스/다른 컴퓨터에서 가정 함) RPOP (또는 BRPOP) 그들을 처리하고 처리하십시오.
Node.js가 완전히 비동기 IO를 사용하기 때문에 RPC 리스너에서 많은 처리를 수행하지 않는다고 가정하면 (즉, 요청을 수신하고 ACK를 보내고 Redis로 푸시), my node가 일 것입니다.이 경우에는이 매우 효율적입니다.
대기열에 Redis를 사용하는 것을 제외하고는 : 치명적인 오류가 발생해도 작업이 손실되지 않도록하려면 좀 더 많은 논리를 구현해야합니다.
패턴 : 다음 RPOPLPUSH 문서에서 신뢰할 수있는 큐
레디 스 종종 백그라운드 작업 또는 메시징 작업의 다른 종류의 처리를 구현하는 메시징 서버로 사용됩니다. 큐의 간단한 형태는 자주 (폴링 사용) 생산자 측에서 목록에 값을 밀어 및 RPOP을 사용하여 소비자 측이 값을 기다리고 획득, 또는 클라이언트가 차단 작업에 의해 제공 더 나은 경우 BRPOP된다. 메시지는 경우 예를 들면, 손실 될 수
그러나 이러한 맥락에서 얻어진 큐가 네트워크 문제가 있거나 신뢰할 수 없습니다 소비자 충돌 그냥 메시지가 수신 된 후하지만 여전히 처리 할 수있는 경우 .
RPOPLPUSH (또는 차단 변이체 BRPOPLPUSH)이 문제를 방지하는 방법을 제공한다 : 소비자는 메시지를 가져 오는 동시에 처리리스트에 에게 넘겨 준다. 메시지가 처리되면 처리 목록에서 메시지를 제거하기 위해 LREM 명령을 사용합니다.
추가 클라이언트가 너무 많은 시간 동안 남아있는 항목에 대한 처리 목록을 모니터링 할 수 있으며 필요하면 시간 초과 된 항목을 다시 보낼 수 있습니다.
그래서 패턴은 메시지의 실제 처리를 수행하는 서버에서 RPOPLPUSH를 요청하는 것이지만 다른 목록은 어떻게됩니까? 그것이 완료되면 파괴 되나요? – AlfredoVR
RPOPLPUSH는 작업자가 충돌 할 경우 나중에 찾을 수 있고 실패한 작업을 다시 처리 할 수있는 방법입니다. 작업이 성공하고 임시 목록에서 항목을 제거하면 자동으로 사라집니다 (Redis의 모든 목록처럼). 따라서 대기열의 모든 항목이 소비되면 목록이 사라지고 BRPOP은 새 항목이 목록에 푸시되고 목록이 다시 만들어 질 때까지 차단됩니다. –
다음은 패턴의 SO에 대한 훌륭한 글입니다. http://stackoverflow.com/a/8555671/62082 –