메시지 큐 솔루션 구현 방법

Question

약 10 개의 다른 메시지를 대기열에 넣고 대기열에 넣고 처리해야하는 시나리오가 있습니다. 가입자 한 명당 10 개의 메시지가 모두 필요하지만 다른 가입자는 10 개의 메시지 중 8 개만 필요합니다. 이 아키텍처 유형을 설치하는 것이 가장 좋은 방법인지 이해하려고합니다. 구독자가 관련 큐를 구독 할 수 있도록하거나 각 큐를 동일한 큐에 덤프하고 해당 구독자와 관련이없는 메시지는 무시하도록 각 메시지 유형에 대한 큐를 만드십니까? 나는 등,이 솔루션은 확장 성/유연성을 확보 할

프로세스 :

1. 10 가지 XML 메시지가는 IBM WebSphere MQ 서버에 대기열에 포함됩니다.
2. .Net (WebSphere MQ 7.1이 WCF 지원으로 추가 된 이후 가능성이 가장 높은 WCF)
3. 메시지를 대기열에서 빼내어 다른 백엔드 DB (대부분의 SQL Server)에로드합니다.
4. 매우 많은 수의 메시지를 처리 ​​할 것이고 증가 할 수 있으므로 솔루션의 확장이 필요합니다 (시간당 40-50,000). 최소한 우리 한테는 많은 돈.

언제나 정보를 높이 평가합니다. 큐 만들기

--S

Answer 1

댓글을 기반으로하면 좋으며 크기를 조정하고 앱을 많이 변경하지 않아도됩니다.

생산자 측에서 메시지 선택 기준을 메시지 속성에 복사 한 다음 해당 메시지를 주제에 게시합니다. 이 앱에 필요한 유일한 변경 사항은 message 속성뿐입니다. 어떤 이유로 네이티브 기능을 사용하여 게시하지 않으려는 경우 주제에 대한 별칭을 정의 할 수 있습니다. 응용 프로그램은 메시지를 보내는 것으로 생각하지만 실제로는 간행물입니다.

소비자 측면에서 몇 가지 선택 사항이 있습니다. 하나는 각 앱에 대한 관리 구독을 만들고 구독자에 선택자를 사용하는 것입니다. 그런 다음 메시지는 선택 기준에 따라 소비자 당 전용 대기열로 유입됩니다. 앱은 단순히 메시지를 소비하고 있다고 생각합니다.

또는 앱은 단순히 주제에 가입 할 수 있습니다. 이렇게하면 응용 프로그램의 연결이 끊어 지거나 (실제로 원하는 경우) 메시지 또는 관리 구독과 기능적으로 동일한 영구 구독을 수신하지 않는 동적 구독 옵션이 제공됩니다.

이 솔루션은 사용자가 인용 한 볼륨으로 쉽게 확장됩니다. 또 다른 옵션은 제작자가 속성을 사용하지 않는다는 것입니다.여기에서 소비자 응용 프로그램은 모든 메시지를 사용하고 각 메시지에서 메시지 페이로드를 열고 메시지 처리 또는 무시 여부를 결정합니다. 이 솔루션에서 제작자는 여전히 주제에 게시하고 있습니다. 직선 대기열을 포함하는 모든 솔루션은 생산자에게 모든 목적지를 알리도록 강요합니다. 다른 소비자를 추가하고 제작자를 변경하십시오. 또한 각 목적지마다 PUT이 있습니다.

최악의 경우는 제작자가 여러 메시지를 넣고 소비자가 메시지를 읽지 않고 무시할지 결정해야한다는 것입니다. 이 옵션은 페이로드에서 선택 기준 필드의 깊이가 얼마나 깊은 지에 따라 문제를 스케일링 할 수 있습니다. 정말 긴 XPath 표현 = 성능이 좋지 않으며 대기 시간이 그 시점에서 모든 응용 프로그램에 있기 때문에 WMQ를 조정할 방법이 없습니다.

최상의 경우, 제작자는 메시지 속성을 설정하고 게시합니다. 소비자가 구독에서 속성을 선택하거나 관리 구독에서 해당 콘텐츠를 선택합니다. 이 솔루션이 응용 프로그램 구독 또는 관리 구독을 사용하는지 여부는 확장 성과 관련하여 아무런 차이가 없습니다.

Answer 2

은 자원 관점에서 상대적으로 '저렴'입니다 플러스는 대상 클라이언트로 구분이 경우 아마도 더 나은 그래서 예, 그것은 각각의 특정 목적을 위해 큐를 사용하는 것이 좋습니다 가능하다면. 대기열을 사용하여 일부 기준 (상관 ID 또는 다른 것)에 따라 선택적으로 메시지를 가져 오는 것은 대개 잘못된 생각입니다. 메시징에서 가장 성능이 우수한 시나리오는 가장 직접적인 시나리오입니다. 단순히 메시지를 선별하여 수신하지 않고 대기열에서 메시지를 가져옵니다.

스케일링에 관해서는 Websphere MQ 또는 다른 IBM 제품을 말할 수는 없지만 시간당 40-50K 메시지는 Windows 서버의 MSMQ가 처리하기가 특히 어렵지 않으므로 IBM이이를 수행 할 수 있다고 가정합니다. 게다가. 일반적으로 병목 현상은 큐 플랫폼 자체가 아니라 개별 메시지를 큐에서 제거하고 처리하는 프로세스입니다.