Azure 서비스 버스에 100 개 이상의 메시지를 전송합니다.

거래 내에서 Azure 서비스 버스에 100 개 이상의 중개 메시지를 보내는 방법은 무엇입니까?Azure 서비스 버스에 100 개 이상의 메시지를 전송합니다.

나는 TransactionScope이 트릭을하지만 100 개의 메시지로 제한된다는 것을 알고 있습니다. 그리고 메시지를 일괄 작업으로 보내면 메시지의 전체 크기가 제한되어 일괄 처리가 다른 일괄 처리로 분할되고 트랜잭션이 보장되지 않는다는 것을 알고 있습니다. 그리고 나는 100 개의 메시지가있는 문제는 심지어 일괄 전송으로 남아 있다고 생각합니다.

해결책을 찾은 사람이 있습니까?

출처

2015-01-17 Diogo Bento

당신은 메시지가 나타 사항에 대한 자세한 정보를 제공 할 수 있습니까?단일 트랜잭션 내에서 수천 개의 메시지를 보내는 것은 꽤 좁은 유스 케이스입니다. – Mitch

@Mitch Azure 서비스 버스는 트랜잭션 내에서 100 개가 넘는 메시지 전송을 지원하지 않으며 예외를 반환합니다. 문서에 지정되어 있습니다. –

예, 이해합니다. 왜 내가 100 개 이상의 메시지를 보내려하는지 이해할 수 없다. 100 개가 넘는 메시지를 보내려는 이유를 설명하면 많은 메시지를 보내지 않아도되는 다른 솔루션을 제공 할 수 있습니다. – Mitch

하나의 중개 메시지에 여러 개의 "논리적"메시지를 넣으십시오. 구독자가 중개 된 메시지를 받으면 각 논리 메시지를 한 번에 하나씩 처리 할 수 있습니다.

출처

2015-01-17 20:49:34 hugoterelle

메시지 크기의 문제가 남아 있습니다. –

여러 개체가 포함 된 1 개의 목록이 1 개의 중개 메시지에 들어갈 수 있습니다. 그런 다음 1 개의 트랜잭션에서 100 개의 중개 메시지로 범위를 제한하기 위해 중개 메시지에 넣어야 할 오브젝트의 수를 계산합니다. – hugoterelle

동일한 중개 메시지에 10 개의 메시지를 넣어도 100 개의 중개 메시지 제한이 남아 있습니다 .. 얼마나 많은 메시지를 보내야하는지 kown하지 않고 보낼 메시지가 10,000 개가 넘을 수 있습니다. 그리고 "논리적 메시지"의 솔루션을 사용할 수 없습니다. –

서비스 버스를 사용하여 필요한 모든 정보를 전송할 수 없기 때문에 다른 방법으로 전송해야합니다.

트랜잭션에 관련된 모든 데이터를 다른 위치 (Azure Storage?)에 저장 한 다음 하나를 보내십시오. 데이터 파일의 위치를 포함하는 메시지 - 수행해야 할 10,000 작업에 대한 정보가 들어있는 파일 하나의 거래.

귀하의 서비스는 거래 내에서 데이터 파일을 읽고 작업을 수행합니다.

출처

2015-01-25 23:11:14 zmbq

클라이언트가 TCP 프로토콜을 통해 서비스 버스 큐와 통신 할 때 단일 서비스 버스 큐에 대한 최대 동시 연결 수는 100 개로 제한됩니다.이 번호는 보낸 사람과받는 사람간에 공유됩니다. 이 할당량에 도달하면 추가 연결에 대한 후속 요청이 거부되고 호출 코드에서 예외가 수신됩니다.

Service Bus is a multi-protocol service: you can send and receive messages to or from the service using REST or .NET managed API, mixing and matching clients using different protocols in a given scenario.

단일 서비스 버스 서비스 네임 스페이스에 10,000 개 이상의 대기열이 필요한 경우

A client application can access a REST-style service by using the WebHttpRelayBinding or by directly sending HTTP requests to the service endpoint.

This limit is not imposed on clients connecting to the queues using REST-based API.

, 당신은 푸른 지원팀에 문의 및 증가를 요청할 수 있습니다. 서비스 버스를 통해 10,000 개의 대기열을 확장하려면 Microsoft Azure 관리 포털을 사용하여 추가 서비스 네임 스페이스를 만들 수도 있습니다.

Because they offer support for sessions, 트랜잭션 및 pub/sub 모델, 서비스 버스 대기열은보다 복잡한 메시징 시나리오에서 선호되는 선택입니다. 그러나 Azure 대기열은 각기 다른 구성 요소의 기본 분리를 위해 고속 및 고용량 처리량을 필요로하는 아키텍처를 지원하기위한 훌륭한 옵션입니다.

From a developer’s point of view의 경우 서비스 버스 대기열과 Azure 대기열의 가장 큰 차이점은 서로 다른 네임 스페이스를 사용하고 복제되거나 중독 된 메시지가 처리되는 방식입니다. 또한 서비스 버스 대기열은 ACS를 사용하여보다 유연한 보안 메커니즘을 제공합니다. 고급 필터링, 지연된 메시지 및 배달 못 한 편지 대기열과 같은 고급 시나리오는 향후 기사에서 다루게 될 것입니다.

Auxiliary link to Setting up the Service Bus in Azure