나는 capped_collections 및 tailable 커서를 사용하여 mongodb에 구현 된 스택을 통해 한 프로세스에서 다른 프로세스로 메시지를 전달하는 대기열 시스템을 구축 중입니다.mongodb에서 처리 된 콜렉션 + 사용 가능 커서에 관한 질문
수신 프로세스는 capped_collection에서 새로운 문서를 무한히 반복하여 루프하고, 발견하면 자동으로 작업을 수행합니다.
내 질문에, 만약 내가 여러 수신 프로세스를 구현하면 새로운 문서가 tailable 커서를 사용하는 프로세스 중 한 번만 읽히도록 보장 할 수있는 방법이 있다는 것입니다. 목표는 대기열에서 새 메시지를 찾는 두 개의 수신 프로세스가있는 경우 두 번 수행되는 작업을 피하는 것입니다. 나는 상대적으로 mongodb 프로그래밍에 익숙하지 않기 때문에 모든 기능을 계속 사용할 수 있습니다.
MongoDB documents에는 원자 적 업데이트를 수행하는 방법에 대한 철저한 설명이 포함되어 있습니다. 하나의 프로세스 만 새 문서를 받도록 보장 할 수는 없지만 하나의 프로세스가 처리되도록하려면 원자 업데이트를받은 후에이를 구현할 수 있습니다.
최근이 문제를 조사해 본 결과, 원자 적 업데이트에 의존하지 않고 여러 독자 (소비자)를 보유 할 수있는 다른 방법이 있는지 알고 싶습니다.
이것은 내가 생각해 낸 것입니다 : 논리를 두 개의 "모듈"로 나눕니다. 첫 번째 모듈은 사용 가능한 커서에서 새 문서를 가져 오는 작업을 담당합니다. 두 번째 모듈은 임의의 문서 작업을 담당합니다. 이 방법으로 한 소비자 (모듈 1) 만 문서를 가져 와서 나중에 여러 문서 작업자 (두 번째 모듈)로 보낼 수 있습니다.
두 모듈은 서로 다른 프로세스 및 다른 언어로 구현 될 수 있습니다. 예를 들어, Node.js 앱은 문서를 가져 와서 Python으로 작성된 스크립트 풀로 전송하여 동시에 문서를 처리 할 수 있습니다.
gearman에 관심이 있으실 것 같은데요. http://gearman.org/ –
질문은 두 개의 경쟁 가능한 커서가 동일한 메시지를받지 못하도록하는 것에 관한 것입니다. 원자 업데이트 또는 제공 한 설명서 링크와 관련이있는 것을 알지 못합니다 – mysomic
* 수락 된 * 대답을 이해할 수 없기 때문에 downvoted? 아마도 * 원자력 업데이트를 사용하여 "두 번 수행되는 작업을 피하는"방법을 이해하지 못했지만 질문을하는 사람이 분명히 한 것입니다. 좋은. –
질문과 대답을 이해합니다. 원자 적 업데이트는 "새로운 문서를 한 번만 읽을 수있는 커서를 사용하는 것으로 보장합니다."* 두 소비자 **가 동일한 문서를 받게됩니다. 중복 된 꼬리 문서를 수신 한 후에 그들이 어떻게 좌표를 잡을 수 있는지는 완전히 다른 문제이며 아마도 원자 적 업데이트가 어떻게 든 관련 될 수 있습니다. 받아 들여진 대답이라는 사실은 그것이 올바른 것이 중요하지 않습니다. – mysomic