2017-11-21 3 views
0

애그리 게이터 전후에 AMQP (RabbitMQ) 큐의 지속성을 활용하여 MessageStore가 지원하지 않는 애그리 게이터를 사용할 때 스프링 통합 설정에서 지속성을 유지할 수 있는지 알고 싶습니다. 나는 이것이 ack 's를 사용할 것이라고 상상한다. aggregator는 모든 부분을 모으고 결과 메시지를 보내기 전에 메시지를 확인하지 않을 것이다. 또한 이것이 좋은 생각인지 알고 싶습니다.AMQP를 사용하여 MessageStore가없는 Spring 통합 애그리 게이터의 메시지 지속성?

저는 큐에 익숙하며 패턴을 사용할 때 좋은 느낌을 얻으 려합니다.

  • 내가 한 큐에 메시지가 나타납니다 다음과 같이 대한

    내 비즈니스 로직이다.

  • 각 메시지는 서로 관련되지 않은 두 개의 웹 서비스 호출 (바람직하게는 병렬로)을 가져와야합니다.
  • 이 두 호출의 결과는 원본 메시지의 세부 정보와 결합해야합니다.
  • 그런 다음 조합을 큐의 새 메시지로 보내야합니다.

메시지는 중요하므로 손실되지 않아야합니다.

나는 '영구적 인'시스템, 즉 RabbitMQ만을 사용하고 데이터베이스를 추가 할 필요가 없기를 바랬다.

나는 특정 질문을 유지하기 위해 노력했지만이 접근하는 방법에 대한 다른 제안이 크게 감사합니다 :) 당신이 할 싶은 것은 Scatter-Gather EI Pattern이 날을 회상

답변

1

.

따라서 AMQP에서 메시지를 가져 와서 ScatterGather 끝점으로 보내고 집계 된 응답을 기다립니다. 기본 승인을 고수하기에 충분합니다.

오른쪽, 실행자가 웹 서비스를 병렬로 호출하는 은 PublishSubscribeChannel 일 수 있습니다. 어쨌든 수집기 프로세스는 릴리스 전략에 따라 응답을 기다리고 원래 AMQP 수신기가 메시지를 조기에 확인하지 못하도록 차단합니다.

+0

인바운드 채널의 프리 페치는 최소한 그룹의 예상 메시지와 같아야합니다. 브로커는 unack'd 메시지를 미리 가져 오지 않습니다. –

+0

@GaryRussell 만약 내가 당신의 의견을 정확하게 이해한다면, 여러 개의 원본 메시지에 대한 아웃 바운드 요청 (병렬로 여러 개 처리하려고 시도)을 사용하면 프리 페치가 적절하게 확장되어야합니까? – cranphin

+0

정확 하 게, 예; container'concurrency * prefetch'는 중개인이 허용하는 미해결 메시지의 수를 결정합니다. 이것은 조금 부서지기 쉽습니다. 잘못하면 오류가 발생합니다. 나는 그 디자인에별로 관심이 없다. –