2011-09-01 5 views
0

나는 잠시 동안이 개념에 어려움을 겪고 있습니다. 큐와 큐를 사용하여 항목을 큐에서 제거하고 처리하는 작업자 역할을 사용하여 완전히 확장 가능한 느슨하게 결합 된 Azure 구성 요소 디자인을 제안하려고합니다. 원하는대로 작업자 역할을 확장 할 수 있으며 큐에 게시하는 것이 결코 문제가되지 않습니다. 지금까지는 그렇게 좋았지 만, 실제로 작동 할 수있는 유일한 실제 모델은 화재와 잊기입니다. 로깅과 다른 단방향 작업에서는 환상적으로 작동하지만 대기열/작업자 역할을 사용하여 파일을로드하고 BLOB에 저장 한 다음 완료되면 다시 응답을 받겠습니다. 또는이 유형의 모델을 온라인 앱에 사용하지 않아야합니까? 작업이 완료되면 알림을 다시 보내는 가장 좋은 방법은 무엇입니까? 응답 Q를 작성한 다음 (어쨌든) 연관된 응답을 검색합니까? 어떤 도움이라도 대단히 감사합니다 !!!!!하늘빛 느슨하게 결합/확장 가능

답변

4

보통 폴링 모델을 사용합니다.

  1. 클라이언트 (대개 브라우저)가 작업을 요청합니다.
  2. 프런트 엔드 (웹 역할)는 작업을 대기열에 추가하고 ID로 응답합니다.
  3. 백엔드 (작업자 역할)는 대기열을 처리하고 이름이 지정된 BLOB 또는 테이블 엔티티에 결과를 저장합니다.
  4. 클라이언트 폴링 ("아직 완료되지 않았습니까?")이 약간의 간격으로 나타납니다.
  5. 프런트 엔드는 BLOB 또는 테이블 엔티티가 있는지 확인하고 그에 따라 응답합니다.

이 패턴의 한 예는 http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure을 참조하십시오.

+0

너 야 !! !!!! 냉담한 반응. 처음에는 응답 대기 중을 생각하고 있었지만, 그렇게 잘못되었을 수 있습니다. 나는 id/blob 솔루션을 좋아한다. 대단히 감사합니다 !!! 추신 : 구름 커버 록! –

+0

도움이 된 것을 기쁘게 생각합니다. :-) – smarx

1

대기열을 사용하는 대신 servicebus 응용 프로그램을 조사 할 수도 있습니다. servicebus를 사용하면 servicebus 응용 프로그램에서 메시지, 사용 대기열 등을 모두 보낼 수 있습니다. 폴링 대신 게시하고 구독 할 수 있습니다!

+0

+1 이벤트 알림을 위해 서비스 버스를 사용했으며 훌륭하게 작동합니다. 잘 가치가있어. 항상 일을하는 가장 싼 방법은 아니지만 매우 똑같습니다. –

관련 문제