푸른 대기열 - 기능 - 메시지 가시성 - 근로자?

Question

Azure Queues, Functions 및 Workers에 관한 몇 가지 질문이 있습니다. 나는 이것이 어떻게 작동하는지 잘 모른다.

시나리오 :

• Q-알림 푸른 저장소 계정의 큐입니다.
• f-process-notification은 q-notifications에 바인딩 된 Azure의 함수입니다. 큐의 첫 번째 메시지를 가져 와서 처리하는 것이 그 업무입니다.

이론적으로 메시지가 q-notifications에 추가되면 함수 f-process-notification이 호출되어야합니다.

질문 :

1. 가 트리거 기능은 노동자의 필요성을 대체합니까? 즉, 메시지가 대기열에 배치 될 때마다 f-process-notification이 호출됩니다.

2. 표시 시간 제한이 5 분인 메시지를 큐에 넣는다고 가정 해보십시오. 기본적으로 나는 메시지를 대기시키고 있지만 5 분이 지날 때까지는 행동해서는 안됩니다. 큐가 메시지를 큐에 넣었을 때 즉시 큐가 f-process-notification을 트리거합니까? 또는 메시지가 표시 될 때, 즉 큐에 배치 된 후 5 분 만에 f-process-notification을 트리거합니까?

Answer 1

Azure 함수에서 대기열 트리거 함수를 실행하는 각 함수 App 인스턴스에는 대상 대기열에 대한 자체 수신기가 있습니다. 지수 대기 백 오프 전략을 사용하여 대기열을 모니터링하여 새로운 작업을 찾습니다. 새 항목이 대기열에 추가되면 청취자는 대기열에서 여러 항목을 가져오고 (배치 동작은 구성 가능) 을 병렬로에 전달합니다. 함수가 성공적이면 메시지가 삭제되고, 그렇지 않으면 다시 처리 할 대기열에 남아 있습니다. 귀하의 질문에 대답 - 예 우리는 시정 시간 제한을 지정합니다. 메시지가 5 분의 시간 초과로 추가되면 메시지는 그 이후에만 처리됩니다.

스케일 아웃에 관해서 - 기능 App의 N 개의 인스턴스가 실행 중일 때 그들은 모두 큐 처리에 협조 할 것입니다. 각 대기열 수신기는 처리 할 대기열에서 개별적으로 일괄 처리 메시지를 가져옵니다. 결과적으로 작업은 N 개의 인스턴스에서로드 균형 조정됩니다. 정확히 원하는 것 :) Azure 함수는 여러 소비자/작업자 패턴의 모든 복잡성을 배경으로 구현합니다.

Answer 2

일반적으로 트리거와는 달리 수신기 논리를 사용합니다. 소비자는 메시지 대기열을 지속적으로 모니터링합니다. 같은 버스/대기열을 처리하는 다른 Azure 작업자 역할의 소비 코드 인스턴스 5 개와 같이 여러 소비자가있는 경우 첫 번째 소비자가 메시지를 얻습니다 (경쟁하고 있음). SOA 아키텍처에서 일반적인 확장 시나리오를 제공합니다.

이 기사에서는 처리를 지연하는 몇 가지 방법에 대해 설명합니다. 행운

http://markheath.net/post/defer-processing-azure-service-bus-message

좋은!