이 항목에서는 WCF(Windows Communication Foundation)에서 대기 중인 통신에 대한 권장 사례를 제공합니다. 다음 섹션에서는 시나리오 관점에서 권장되는 사례를 설명합니다.
빠르고 Best-Effort 대기 중인 메시징
분리가 필요하고 빠르고 고성능이며 최선의 보장을 제공하는 메시징 시나리오에 대해서는 비 트랜잭션 큐를 사용하고 속성을 ExactlyOnce에서 false로 설정합니다.
또한 속성을 Durable.로 설정 false 하여 디스크 쓰기 비용을 발생시키지 않도록 선택할 수 있습니다.
보안은 성능에 영향을 줍니다. 자세한 내용은 성능 고려 사항을 참조하세요.
신뢰할 수 있는 종단 간 메시지 큐잉
다음 섹션에서는 종단 간 신뢰할 수 있는 메시징이 필요한 시나리오에 권장되는 사례를 설명합니다.
기본 신뢰할 수 있는 전송
엔드 투 엔드 신뢰성을 위해 ExactlyOnce 속성을 true로 설정하여 전송을 보장합니다. 속성은 Durable 요구 사항(기본값true)에 따라 설정할 falsetrue 수 있습니다. 일반적으로 Durable 속성은 엔드 투 엔드 신뢰성의 일부로 true로 설정됩니다. 손상은 성능 비용이지만 큐 관리자가 충돌하는 경우 메시지가 손실되지 않도록 메시지를 지속성 있게 만듭니다.
트랜잭션 사용
엔드 투 엔드 안정성을 보장하려면 트랜잭션을 사용해야 합니다.
ExactlyOnce 보증은 메시지가 대상 큐에 전달되도록 합니다. 메시지가 수신되도록 하려면 트랜잭션을 사용합니다. 트랜잭션 없이 서비스가 충돌하면, 애플리케이션에 전달되기 위해 배달 중이었던 메시지가 손실될 수 있습니다.
배달 못 한 편지 큐 사용
메시지가 대상 큐에 배달되지 않을 경우, 미전송 메시지 큐를 통해 알림을 받을 수 있습니다. 시스템에서 제공한 데드레터 큐 또는 사용자 지정 데드레터 큐를 사용할 수 있습니다. 일반적으로 사용자 정의 죽은 편지 큐를 사용하면 한 애플리케이션에서 죽은 편지 메시지를 단일 죽은 편지 큐로 보낼 수 있기 때문에 가장 좋습니다. 그렇지 않으면, 시스템에서 실행되는 모든 애플리케이션에 대한 배달 실패 메시지가 모두 단일 큐에 전달됩니다. 그런 다음 각 애플리케이션은 배달 못한 편지 큐를 검색하여 해당 애플리케이션과 관련된 배달 못한 편지 메시지를 찾아야 합니다. MSMQ 3.0을 사용하는 경우와 같이 사용자 지정 배달 못 한 편지 큐를 사용할 수 없는 경우가 있습니다.
종단 간 신뢰할 수 있는 통신을 위해 '데드 레터 큐'를 비활성화하는 것은 권장되지 않습니다.
자세한 내용은 Dead-Letter 큐를 사용하여 메시지 전송 실패 처리를 참조하세요.
Poison-Message 처리 사용
포이즌 메시지 처리는 메시지 처리 실패에서 복구하는 기능을 제공합니다.
포이즌 메시지 처리 기능을 사용하는 경우 속성이 ReceiveErrorHandling 적절한 값으로 설정되어 있는지 확인합니다. 데이터가 손실됨을 의미하도록 Drop 설정합니다. 반면에, Fault 설정하면 포이즌 메시지를 감지했을 때 서비스 호스트가 오류를 일으킵니다. MSMQ 3.0 Fault을 사용하는 것이 데이터 손실을 방지하고 포이즌 메시지를 다른 곳으로 이동시키는 가장 좋은 옵션입니다. MSMQ 4.0 Move 을 사용하는 것이 좋습니다. Move 는 서비스에서 새 메시지를 계속 처리할 수 있도록 포이즌 메시지를 큐 밖으로 이동합니다. 포이즌 메시지 서비스는 포이즌 메시지를 별도로 처리할 수 있습니다.
자세한 내용은 포이즌 메시지 처리를 참조하세요.
높은 처리량 달성
단일 엔드포인트에서 높은 처리량을 달성하려면 다음을 사용합니다.
트랜잭션 처리된 일괄 작업입니다. 트랜잭션 일괄 처리는 단일 트랜잭션에서 많은 메시지를 읽을 수 있도록 합니다. 이렇게 하면 트랜잭션 커밋이 최적화되고 전반적인 성능이 향상됩니다. 일괄 처리 비용은 일괄 처리 내의 단일 메시지에서 오류가 발생하는 경우 전체 일괄 처리가 롤백되고 메시지를 다시 일괄 처리할 수 있을 때까지 한 번에 하나씩 처리해야 한다는 것입니다. 대부분의 경우 포이즌 메시지는 드물기 때문에 일괄 처리는 특히 트랜잭션에 참여하는 다른 리소스 관리자가 있는 경우 시스템 성능을 향상시키는 기본 방법입니다. 자세한 내용은 트랜잭션에서 메시지 일괄 처리를 참조하세요.
동시성. 동시성은 처리량을 증가하지만 동시성은 공유 리소스에 대한 경합에도 영향을 줍니다. 자세한 내용은 동시성을 참조하세요.
속도 제한 최적의 성능을 위해 디스패처 파이프라인의 메시지 수를 제한합니다. 이 작업을 수행하는 방법의 예는 제한을 참조하세요.
일괄 처리를 사용하는 경우 동시성과 제한 조정은 동시 일괄 처리로 이어진다는 점에 유의하세요.
처리량 및 가용성을 높이려면 큐에서 데이터를 읽는 WCF 서비스 팜을 사용하십시오. 이렇게 하려면 이러한 모든 서비스가 동일한 엔드포인트에 동일한 계약을 노출해야 합니다. 메시지의 생성 속도가 높은 애플리케이션에는 팜 접근 방식이 가장 적합합니다. 이것은 여러 서비스가 동일한 큐에서 메시지를 읽을 수 있게 해주기 때문입니다.
팜을 사용할 때 MSMQ 3.0은 원격 트랜잭션 읽기를 지원하지 않는다는 점에 유의하세요. MSMQ 4.0은 원격 트랜잭션 읽기를 지원합니다.
자세한 내용은 트랜잭션에서 메시지 일괄 처리를 참조하세요.
작업 단위 의미 체계를 사용하여 대기열 처리하기
일부 시나리오에서는 큐의 메시지 그룹이 관련될 수 있으므로 이러한 메시지의 순서가 중요합니다. 이러한 시나리오에서는 관련 메시지 그룹을 단일 단위로 함께 처리합니다. 모든 메시지가 성공적으로 처리되거나 아무 메시지도 처리되지 않습니다. 이러한 동작을 구현하려면 큐가 있는 세션을 사용합니다.
자세한 내용은 세션에서 대기 중인 메시지 그룹화(Grouping Queued Messages)를 참조하세요.
Request-Reply 메시지 상관 관계 지정
큐는 일반적으로 단방향이지만 일부 시나리오에서는 이전에 보낸 요청에 수신된 회신의 상관 관계를 지정할 수 있습니다. 이러한 상관 관계가 필요한 경우 메시지와의 상관 관계 정보를 포함하는 사용자 고유의 SOAP 메시지 헤더를 적용하는 것이 좋습니다. 일반적으로 발신자는 메시지를 처리하고 회신 큐에서 새 메시지로 다시 회신할 때 메시지와 함께 이 헤더를 첨부하고, 발신자가 요청 메시지로 회신 메시지를 식별할 수 있도록 상관 관계 정보가 포함된 보낸 사람의 메시지 헤더를 첨부합니다.
비 WCF 애플리케이션과 통합
WCF 서비스 또는 클라이언트를 비 WCF 서비스 또는 클라이언트와 통합할 때 사용합니다 MsmqIntegrationBinding . 비 WCF 애플리케이션은 System.Messaging, COM+, Visual Basic 또는 C++를 사용하여 작성된 MSMQ 애플리케이션일 수 있습니다.
사용하는 MsmqIntegrationBinding경우 다음 사항에 유의하세요.
WCF 메시지 본문은 MSMQ 메시지 본문과 동일하지 않습니다. 큐에 대기 중인 바인딩을 사용하여 WCF 메시지를 보낼 때 WCF 메시지 본문은 MSMQ 메시지 내부에 배치됩니다. MSMQ 인프라는 이 추가 정보를 알지 못합니다. MSMQ 메시지만 표시됩니다.
MsmqIntegrationBinding는 인기 있는 serialization 형식을 지원합니다. serialization 형식에 따라 제네릭 메시지 MsmqMessage<T>의 본문 형식은 다른 형식 매개 변수를 사용합니다. 예를 들어 ByteArray는MsmqMessage\<byte[]>이 필요하고, Stream는MsmqMessage<Stream>이 필요합니다.XML serialization을 사용하면
KnownTypes지정한 다음 XML 메시지를 역직렬화하는 방법을 결정할 수 있습니다.<