여러 푸른 작업자 역할 폴링 같은 큐가 죽은 잠금이 발생하거나하지 포이즌 메시지

Question

시나리오 :

내가 여러 작업자 역할 또는 다중 스레드, 푸른 대기열에서 폴링 새 메시지와 ONE 작업자 역할을 분사 한 경우.

누군가 올바른 설계 접근 방식을 사용했는지 확인할 수 있습니까? 많은 작업자 역할을하고 싶다면 PROCESSJOB의 속도를 높이는 것이 좋습니다. 우리의 응용 프로그램은 실시간에 가까워 야합니다. 즉, 우리가 알아야 할 메시지가있는 즉시 복잡한 비즈니스 규칙을 적용하고 AZURE DB에 커밋해야합니다. 우리는 3 분당 11,000 메시지를 기대하고 있습니다.

감사합니다.

Answer 1

원하는만큼 많은 큐 판독기가있을 수 있습니다. 작업 대기열 인스턴스를 모두 동일한 대기열에서 읽을 수 있기 때문에 작업자 인스턴스를 확장하는 것이 매우 일반적이어서 작업 처리량이 훨씬 더 높아집니다.

큐 메시지를 읽으면 다른 사람이 읽고 작업하지 못하도록 일정 기간 동안 "보이지 않음"으로 표시됩니다. 메시지 소유자는 기간이 만료되기 전에 메시지를 삭제해야합니다. 그렇지 않으면 메시지가 다시 표시되고 원본 판독기가 메시지를 삭제하려고 시도하면 예외가 throw됩니다. 즉, 귀하의 작업은 멱등수가되어야합니다.

직접 포이즌 메시지 처리는 없지만 구현하기가 쉽습니다. 각 메시지에는 대기열에 포함되지 않은 수가 있습니다. 그냥 그것을 확인하고 3-4 번 읽은 후 독이 메시지를 제거하십시오. 또한 너무 짧은 시간 창으로 인해 처리가 실패 할 수 있으므로 대기열 해제 수에 따라 동적으로 시간 초과 기간을 조정할 수 있습니다.

여기에 DequeueCount에 대한 MSDN documentation입니다.

EDIT : 3 분 안에 11,000 개의 메시지 처리까지 : 큐의 확장 성 대상은 2,000 TPS 또는 3 분 안에 최대 360,000 트랜잭션 (메시지 요구 사항 11,000 개를 훨씬 능가 함)입니다. 한 번에 여러 메시지를 읽는 것뿐만 아니라 메시지를 단일 대기열 메시지로 결합하여 트랜잭션 수를 줄일 수도 있습니다. 대기열의 ApproximateMessageCount 속성을보고 대기열이 백업 중인지 확인한 다음 대기열 항목을 사용하는 데 도움이되는 추가 입력으로 확장 할 수도 있습니다.