Windows에서 MSMQ에 대한 대기열 대안은 무엇입니까?[닫은]

https://stackoverflow.com/questions/37579

09-06-2019
|

문제

.NET 2.0 이상을 실행하는 Windows에서 내구성 있는 메시징을 위해 큐 제품을 사용하려는 경우 현재 MSMQ에 대한 대안은 무엇입니까?저는 ActiveMQ에 대해 알고 있습니다(http://activemq.apache.org/) 그리고 WSMQ에 대한 참조를 본 적이 있습니다( http://wsmq.net) 그런데 사이트가 다운된 것 같습니다.

다른 대안이 있나요?

해결책

Java JMS 메시징 사양의 구현인 Tibco EMS에 대해 충분히 좋은 점을 말할 수 없습니다.Tibco EMS는 WinCE의 Compact Framework .NET을 포함하여 .NET 클라이언트에 대한 탁월한 지원을 제공합니다.(C 클라이언트 라이브러리도 있습니다.)

따라서 Windows, Unix(AIX/Solaris), Linux 또는 Mac OS X에서 실행되는 메시징 코드와 관련된 이기종 분산 애플리케이션을 구축하는 경우 Tibco EMS가 적합합니다.

여기에서 내 기사를 확인하세요.

분산 소프트웨어 개발에 JMS 사용

저는 Microsoft에서 근무하면서 MSMQ를 일부 구현했습니다.하지만 아시다시피 Microsoft는 Windows에만 관심이 있습니다.그들은 MSMQ 클라이언트를 다른 플랫폼에 제공하기 위해 제3자에 의존했습니다.Tibco EMS와의 만남은 훨씬 더 나은 경험이었습니다.Tibco가 Microsoft보다 메시징을 훨씬 더 잘 이해하고 있다는 것은 매우 분명했습니다.그리고 Tibco는 다양한 클라이언트 바인딩을 자체적으로 지원하기 위해 노력했습니다.이것이 결국 제품 이름을 Tibco JMS에서 Tibco EMS(Enterprise Messaging Service)로 변경한 이유입니다.

그리고 Tibco EMS를 중심으로 이기종 소프트웨어 시스템을 구축했습니다.Tibco EMS 메시징을 통해 Java/JBoss 중간 계층과 상호 작용하는 Rolled C# .NET Winform 클라이언트입니다.(그리고 Compact Framework .NET Tibco 클라이언트를 사용하는 WinCE 산업용 임베디드 컴퓨터도 있습니다.)

내 JMS 저작 링크

다른 팁

여기서는 "모범 사례" 조언이 아닐 수도 있습니다...그러나 실제 생활의 필요와 경험을 바탕으로:우리는 분산 시스템을 가지고 있으며, 각각 10개의 클라이언트를 실행하는 60개의 상자가 모두 작업 X를 수행하고 대기열에서 다음 작업을 가져와야 합니다.대기열이 다른 "클라이언트"로부터 공급되고 있습니다...

우리는 프로세스 간 통신을 사용했고 MSMQ도 사용했으며 서비스 브로커도 사용해 보았습니다...응용 프로그램에 대한 제어권을 Microsoft에 넘겨주기 때문에 장기적으로는 작동하지 않습니다.귀하의 요구 사항이 충족되는 한 훌륭하게 작동합니다.지원되지 않는 것이 필요할 때 그것은 지옥이 됩니다.

우리에게 가장 좋은 솔루션은 다음과 같습니다.SQL Database 테이블을 큐로 사용합니다.실수(잠금)가 발생할 수 있으므로 거기서 바퀴를 재발명하지 마십시오.이를 수행하는 방법에 대한 정보가 있으며 매우 쉽고 24시간당 200,000개 이상의 메시지를 처리했습니다(60x10 = 600개의 동시 읽기 및 대기열 쓰기).이는 나머지 애플리케이션 작업을 처리하는 동일한 SQL 서버에 추가됩니다.

MSMQ가 작동하지 않는 몇 가지 이유는 다음과 같습니다.

대기열의 논리를 FIFO가 아닌 "가장 오래된 RED 메시지" 또는 "가장 오래된 BLUE 메시지"와 같은 것으로 변경해야 하는 경우에는 그렇게 할 수 없습니다.(사람들이 뭐라고 말할지 알아요. 빨간 줄 그리고 파란색 대기열...그러나 대기열의 수/유형이 애플리케이션 관리 방식에 따라 동적이고 매일 변경된다면 어떻게 될까요?)
이는 실패 지점과 배포 악몽을 추가합니다(큐는 실패 지점이며 이러한 유형의 일에 대해 피를 지불하는 엔터프라이즈 소프트웨어에서 메시지 읽기/쓰기 등을 위해 모든 상자에 대한 올바른 권한 설정을 처리해야 합니다). .SQL 서버...모든 클라이언트가 이미 DB에서 쓰고/읽고 있으며 테이블이 하나 더 있습니다.

RabbitMQ 프레임워크 여기서는 간과된 것 같습니다.여전히 관심이 있다면 .NET 2.0 코드 기반이 있고 netMsmqBinding과 유사한 WCF 바인딩이 함께 제공됩니다.바인딩에는 기본적으로 .NET 3.0 이상이 필요하며 기본 제공 netMsmqBinding보다 더 많은 기능이 있습니다.무엇보다도 Mono 친화적입니다.볼만한 가치가 있습니다.

SQL 2005는 어떻습니까? 서비스 브로커?

ActiveMQ를 사용하지 않는 이유는 무엇입니까?:)

비용이 문제가 되지 않는 경우(Express SKU도 있습니다) 그런 다음 800,000파운드의 고릴라를 살펴보세요.WebSphere MQ(MQ 시리즈).이는 거의 모든 플랫폼에서 실행되며 매우 다양한 큐 관리자와 메시징 패턴을 지원하므로 여기에 나열하는 것은 실제로 적절하지 않습니다.

IBM의 WebSphere MQ 사이트: http://www.ibm.com/software/integration/wmq/
그만큼 MQ 지원 포럼: http://www.mqseries.net/phpBB2/index.php

고가용성이 중요하다면 Amazon SQS를 살펴볼 가치가 있습니다.메시지가 다른 물리적 위치에서 오는 경우 추가 오버헤드가 많지 않습니다.저렴하고 확장 가능합니다!

Redis는 이 플랫폼의 또 다른 인기 품종입니다.세트 기반 대기열 구현과 Pub/Sub 패턴을 확인하세요.홍보하는거같아

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow