분할 큐 및 항목Partitioned queues and topics

Azure Service Bus에서는 여러 메시지 broker가 메시지를 처리하고 여러 메시징 저장소가 메시지를 저장하도록 합니다.Azure Service Bus employs multiple message brokers to process messages and multiple messaging stores to store messages. 일반적인 큐 또는 항목은 단일 메시지 broker에서 처리되며 하나의 메시징 저장소에 저장됩니다.A conventional queue or topic is handled by a single message broker and stored in one messaging store. Service Bus 파티션 을 사용하면 큐 및 항목 또는 메시징 엔터티 가 여러 메시지 broker 및 메시징 저장소에 분할될 수 있습니다.Service Bus partitions enable queues and topics, or messaging entities, to be partitioned across multiple message brokers and messaging stores. 분할은 분할된 엔터티의 전체 처리량이 단일 메시지 broker 또는 메시징 저장소의 성능으로 제한되지 않는다는 의미입니다.Partitioning means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker or messaging store. 또한 메시징 스토어가 일시적으로 중단된 경우에도 분할된 큐 또는 항목을 계속 렌더링할 수 없습니다.In addition, a temporary outage of a messaging store does not render a partitioned queue or topic unavailable. 분할된 큐 및 항목은 트랜잭션 및 세션에 대한 지원 같은 모든 고급 Service Bus 기능을 포함할 수 있습니다.Partitioned queues and topics can contain all advanced Service Bus features, such as support for transactions and sessions.

참고

분할은 기본 또는 표준 SKU의 모든 큐와 항목에서 엔터티 생성에 지원됩니다.Partitioning is available at entity creation for all queues and topics in Basic or Standard SKUs. 프리미엄 메시지 SKU에 지원되지 않지만 프리미엄 네임스페이스에서 기존에 분할된 엔터티는 정상적으로 계속 작동합니다.It is not available for the Premium messaging SKU, but any previously existing partitioned entities in Premium namespaces continue to work as expected.

기존 큐 또는 토픽에 대해 분할 옵션을 변경할 수 없으며 엔터티를 만들 때만 이 옵션을 설정할 수 있습니다.It is not possible to change the partitioning option on any existing queue or topic; you can only set the option when you create the entity.

작동 방식How it works

각 분할 된 큐 또는 토픽은 여러 파티션으로 구성 됩니다.Each partitioned queue or topic consists of multiple partitions. 각 파티션은 다른 메시징 저장소에 저장 되 고 다른 메시지 브로커에 의해 처리 됩니다.Each partition is stored in a different messaging store and handled by a different message broker. 분할 된 큐 또는 토픽으로 메시지를 보내면 Service Bus는 파티션 중 하나에 메시지를 할당 합니다.When a message is sent to a partitioned queue or topic, Service Bus assigns the message to one of the partitions. 선택은 발신자가 지정할 수 있는 Service Bus 또는 파티션 키에서 임의로 수행됩니다.The selection is done randomly by Service Bus or by using a partition key that the sender can specify.

클라이언트가 분할 된 큐 또는 분할 된 항목에 대 한 구독에서 메시지를 받으려는 경우 Service Bus는 모든 파티션을 메시지에 대해 쿼리 한 다음 메시징 저장소 중 하나에서 받은 첫 번째 메시지를 받는 사람에 게 반환 합니다.When a client wants to receive a message from a partitioned queue, or from a subscription to a partitioned topic, Service Bus queries all partitions for messages, then returns the first message that is obtained from any of the messaging stores to the receiver. Service Bus는 추가 수신 요청을 받을 때 다른 메시지를 캐시하고 반환합니다.Service Bus caches the other messages and returns them when it receives additional receive requests. 수신하는 클라이언트는 분할을 인식하지 못합니다. 분할된 큐 또는 항목의 클라이언트 연결 동작(예, 읽기, 완료, 연기, 효력 상실, 프리페치)은 일반적인 엔터티 동작과 동일합니다.A receiving client is not aware of the partitioning; the client-facing behavior of a partitioned queue or topic (for example, read, complete, defer, deadletter, prefetching) is identical to the behavior of a regular entity.

분할 되지 않은 엔터티의 피킹 (peeking) 작업은 항상 가장 오래 된 메시지를 반환 하지만 분할 된 엔터티는 반환 하지 않습니다.The peek operation on a non-partitioned entity always returns the oldest message, but not on a partitioned entity. 대신, 메시지 브로커가 먼저 응답 한 파티션 중 하나에서 가장 오래 된 메시지를 반환 합니다.Instead, it returns the oldest message in one of the partitions whose message broker responded first. 반환 된 메시지가 모든 파티션에서 가장 오래 된 메시지 임을 보장 하지는 않습니다.There is no guarantee that the returned message is the oldest one across all partitions.

분할된 큐 또는 항목에 메시지를 보내거나 메시지를 받을 때 추가 비용이 없습니다.There is no additional cost when sending a message to, or receiving a message from, a partitioned queue or topic.

참고

피킹 (peeking) 작업은 시퀀스 번호를 기준으로 파티션에서 가장 오래 된 메시지를 반환 합니다.The peek operation returns the oldest message from the partition based on its sequence number. 분할된 엔터티의 경우 시퀀스 번호는 파티션에 상대적으로 발생됩니다.For partitioned entities, the sequence number is issued relative to the partition. 자세한 내용은 메시지 시퀀싱 및 타임 스탬프를 참조 하세요.For more information, see Message sequencing and timestamps.

분할 사용Enable partitioning

Azure Service Bus로 분할된 큐 및 항목을 사용하려면 Azure SDK 버전 2.2 이상을 사용하거나 HTTP 요청에서 api-version=2013-10 이상을 지정합니다.To use partitioned queues and topics with Azure Service Bus, use the Azure SDK version 2.2 or later, or specify api-version=2013-10 or later in your HTTP requests.

표준Standard

표준 메시징 계층에서 Service Bus 큐 및 토픽은 1, 2, 3, 4 또는 5GB 크기로 만들 수 있습니다(기본값은 1GB).In the Standard messaging tier, you can create Service Bus queues and topics in 1, 2, 3, 4, or 5-GB sizes (the default is 1 GB). 분할을 사용 하도록 설정 하면 Service Bus는 엔터티의 16 개 복사본 (16 개 파티션)을 만듭니다. 이때 각각 동일한 크기가 지정 됩니다.With partitioning enabled, Service Bus creates 16 copies (16 partitions) of the entity, each of the same size specified. 따라서 크기가 5GB인 큐를 만들 경우 16개의 파티션에서 최대 큐 크기는 (5 * 16) = 80GB가 됩니다.As such, if you create a queue that's 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. Azure Portal의 해당 엔터티에 대한 개요 블레이드에서 해당 항목을 보면 분할된 큐 또는 토픽의 최대 크기를 확인할 수 있습니다.You can see the maximum size of your partitioned queue or topic by looking at its entry on the Azure portal, in the Overview blade for that entity.

PremiumPremium

프리미엄 계층 네임 스페이스에서 분할 엔터티는 지원 되지 않습니다.In a Premium tier namespace, partitioning entities are not supported. 그러나 Service Bus 큐 및 항목은 1, 2, 3, 4, 5, 10, 20, 40 또는 80GB 크기로 만들 수 있습니다(기본값은 1GB).However, you can still create Service Bus queues and topics in 1, 2, 3, 4, 5, 10, 20, 40, or 80-GB sizes (the default is 1 GB). Azure Portal의 해당 엔터티에 대한 개요 블레이드에서 해당 항목을 보면 큐 또는 토픽의 크기를 확인할 수 있습니다.You can see the size of your queue or topic by looking at its entry on the Azure portal, in the Overview blade for that entity.

분할된 엔터티 만들기Create a partitioned entity

분할된 큐 또는 항목을 만들 수 있는 여러 방법이 있습니다.There are several ways to create a partitioned queue or topic. 애플리케이션에서 큐 또는 항목을 만들 때 QueueDescription.EnablePartitioning 또는 TopicDescription.EnablePartitioning 속성을 각각 true 로 설정하여 큐 또는 항목에 분할을 설정할 수 있습니다.When you create the queue or topic from your application, you can enable partitioning for the queue or topic by respectively setting the QueueDescription.EnablePartitioning or TopicDescription.EnablePartitioning property to true. 이러한 속성은 큐 또는 항목을 만든 시간에 설정해야 하며, 이전 WindowsAzure.ServiceBus 라이브러리에서만 사용할 수 있습니다.These properties must be set at the time the queue or topic is created, and are available only in the older WindowsAzure.ServiceBus library. 앞서 설명한 것처럼 기존 큐 또는 토픽에서 이러한 속성을 변경하는 것은 불가능합니다.As stated previously, it is not possible to change these properties on an existing queue or topic. 예를 들면 다음과 같습니다.For example:

// Create partitioned topic
NamespaceManager ns = NamespaceManager.CreateFromConnectionString(myConnectionString);
TopicDescription td = new TopicDescription(TopicName);
td.EnablePartitioning = true;
ns.CreateTopic(td);

또는 Azure Portal에서 분할된 큐나 토픽을 만들 수 있습니다.Alternatively, you can create a partitioned queue or topic in the Azure portal. 포털에서 큐 또는 토픽을 만들 때 큐 또는 토픽 만들기 대화 상자에 있는 분할 사용 옵션이 기본적으로 선택되어 있습니다.When you create a queue or topic in the portal, the Enable partitioning option in the queue or topic Create dialog box is checked by default. 이 옵션은 표준 계층 엔터티에서만 사용하지 않도록 설정할 수 있습니다. 프리미엄 계층에서 분할은 지원되지 않고, 확인란은 적용되지 않습니다.You can only disable this option in a Standard tier entity; in the Premium tier partitioning is not supported, and the checkbox has no effect.

파티션 키의 사용Use of partition keys

메시지가 분할된 큐 또는 항목에 큐를 넣으면 Service Bus는 파티션 키의 존재를 확인합니다.When a message is enqueued into a partitioned queue or topic, Service Bus checks for the presence of a partition key. 찾은 경우 해당 키에 따라 파티션을 선택 합니다.If it finds one, it selects the partition based on that key. 파티션 키를 찾지 못하면 내부 알고리즘을 기반으로 파티션을 선택 합니다.If it does not find a partition key, it selects the partition based on an internal algorithm.

파티션 키 사용Using a partition key

세션 또는 트랜잭션과 같은 일부 시나리오에서는 메시지를 특정 파티션에 저장 해야 합니다.Some scenarios, such as sessions or transactions, require messages to be stored in a specific partition. 이러한 모든 시나리오에서는 파티션 키를 사용해야 합니다.All these scenarios require the use of a partition key. 동일한 파티션 키를 사용 하는 모든 메시지는 동일한 파티션에 할당 됩니다.All messages that use the same partition key are assigned to the same partition. 파티션을 일시적으로 사용할 수 없는 경우 Service Bus에서 오류를 반환 합니다.If the partition is temporarily unavailable, Service Bus returns an error.

시나리오에 따라 다양한 메시지 속성이 파티션 키로 사용됩니다.Depending on the scenario, different message properties are used as a partition key:

SessionId: 메시지에 SessionId 속성 집합이 있으면 Service Bus는 SessionID 를 파티션 키로 사용합니다.SessionId: If a message has the SessionId property set, then Service Bus uses SessionID as the partition key. 이러한 방식으로 동일한 세션에 속한 모든 메시지가 동일한 메시지 broker에서 처리됩니다.This way, all messages that belong to the same session are handled by the same message broker. 세션을 사용하면 Service Bus가 세션 상태의 일관성 뿐만 아니라 메시지 순서를 보장할 수 있습니다.Sessions enable Service Bus to guarantee message ordering as well as the consistency of session states.

PartitionKey: 메시지에 PartitionKey 속성이 있지만 SessionId 속성 집합이 없으면 Service Bus는 PartitionKey 속성 값을 파티션 키로 사용합니다.PartitionKey: If a message has the PartitionKey property but not the SessionId property set, then Service Bus uses the PartitionKey property value as the partition key. 메시지에 SessionIdPartitionKey 속성 집합이 모두 있으면 속성이 모두 동일해야 합니다.If the message has both the SessionId and the PartitionKey properties set, both properties must be identical. PartitionKey 속성이 SessionId 속성이 아닌 다른 값으로 설정되면 Service Bus는 잘못된 작업 예외를 반환합니다.If the PartitionKey property is set to a different value than the SessionId property, Service Bus returns an invalid operation exception. 발신자가 비 세션 인식 트랜잭션 메시지를 보내는 경우 PartitionKey 속성을 사용해야 합니다.The PartitionKey property should be used if a sender sends non-session aware transactional messages. 파티션 키는 트랜잭션 내에서 전송되는 모든 메시지가 동일한 메시징 broker에서 처리되도록 합니다.The partition key ensures that all messages that are sent within a transaction are handled by the same messaging broker.

MessageId: 큐 또는 항목에 RequiresDuplicateDetection 속성이 true 로 설정되고 SessionId 또는 PartitionKey 속성이 설정되지 않은 경우 MessageId 속성 값이 파티션 키로 제공됩니다.MessageId: If the queue or topic has the RequiresDuplicateDetection property set to true and the SessionId or PartitionKey properties are not set, then the MessageId property value serves as the partition key. (보내는 응용 프로그램에서 자동으로 메시지 ID를 할당 하지 않는 경우 Microsoft .NET 및 AMQP 라이브러리에서 자동으로 메시지 ID를 할당 합니다.) 이 경우 동일한 메시지의 모든 복사본이 동일한 메시지 브로커에 의해 처리 됩니다.(The Microsoft .NET and AMQP libraries automatically assign a message ID if the sending application does not.) In this case, all copies of the same message are handled by the same message broker. 이 ID를 사용하면 Service Bus가 중복 메시지를 감지하고 제거할 수 있습니다.This ID enables Service Bus to detect and eliminate duplicate messages. RequiresDuplicateDetection 속성이 true 로 설정되지 않으면 Service Bus는 MessageId 속성을 파티션 키로 고려하지 않습니다.If the RequiresDuplicateDetection property is not set to true, Service Bus does not consider the MessageId property as a partition key.

파티션 키 사용하지 않음Not using a partition key

파티션 키가 없으면 Service Bus 분할 된 큐 또는 항목의 모든 파티션에 라운드 로빈 방식으로 메시지를 배포 합니다.In the absence of a partition key, Service Bus distributes messages in a round-robin fashion to all the partitions of the partitioned queue or topic. 선택한 파티션을 사용할 수 없는 경우 Service Bus는 메시지를 다른 파티션에 할당 합니다.If the chosen partition is not available, Service Bus assigns the message to a different partition. 이러한 방식으로 메시징 저장소를 일시적으로 사용할 수 없음에도 불구하고 보내기 작업은 성공합니다.This way, the send operation succeeds despite the temporary unavailability of a messaging store. 그러나 파티션 키가 제공하는 순서가 보장되지는 않습니다.However, you will not achieve the guaranteed ordering that a partition key provides.

가용성(파티션 키 없음) 및 일관성(파티션 키 사용) 간 상쇄 관계에 대한 보다 자세한 설명을 보려면 이 문서를 참조하세요.For a more in-depth discussion of the tradeoff between availability (no partition key) and consistency (using a partition key), see this article. 이 정보는 분할된 Service Bus 엔터티에 동일하게 적용됩니다.This information applies equally to partitioned Service Bus entities.

다른 파티션에 메시지를 큐에 넣을 수 있는 충분 한 시간 Service Bus 제공 하기 위해 메시지를 전송 하는 클라이언트에서 지정한 Operationtimeout 값은 15 초 보다 커야 합니다.To give Service Bus enough time to enqueue the message into a different partition, the OperationTimeout value specified by the client that sends the message must be greater than 15 seconds. OperationTimeout 속성을 기본값인 60초로 설정하는 것이 좋습니다.It is recommended that you set the OperationTimeout property to the default value of 60 seconds.

파티션 키는 특정 파티션에 메시지를 "고정" 합니다.A partition key "pins" a message to a specific partition. 이 파티션을 보유 하 고 있는 메시징 저장소를 사용할 수 없는 경우 Service Bus에서 오류를 반환 합니다.If the messaging store that holds this partition is unavailable, Service Bus returns an error. 파티션 키가 없으면 다른 파티션을 선택할 수 Service Bus 작업이 성공 합니다.In the absence of a partition key, Service Bus can choose a different partition and the operation succeeds. 그러므로 필요한 경우가 아니면 파티션 키를 제공하지 않는 것이 좋습니다.Therefore, it is recommended that you do not supply a partition key unless it is required.

고급 항목: 분할된 엔터티로 트랜잭션 사용Advanced topics: use transactions with partitioned entities

트랜잭션의 일부로 전송되는 메시지는 파티션 키를 지정해야 합니다.Messages that are sent as part of a transaction must specify a partition key. 키는 다음 속성 중 하나일 수 있습니다. SessionId, PartitionKey 또는 MessageId.The key can be one of the following properties: SessionId, PartitionKey, or MessageId. 동일한 트랜잭션의 일부로 전송되는 모든 메시지는 동일한 파티션 키를 지정해야 합니다.All messages that are sent as part of the same transaction must specify the same partition key. 트랜잭션 내에서 파티션 키 없이 메시지를 보내려면 Service Bus는 잘못된 작업 예외를 반환합니다.If you attempt to send a message without a partition key within a transaction, Service Bus returns an invalid operation exception. 다른 파티션 키를 가진 동일한 트랜잭션 내에서 여러 메시지를 보내려면 Service Bus는 잘못된 작업 예외를 반환합니다.If you attempt to send multiple messages within the same transaction that have different partition keys, Service Bus returns an invalid operation exception. 예를 들면 다음과 같습니다.For example:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    Message msg = new Message("This is a message");
    msg.PartitionKey = "myPartitionKey";
    await messageSender.SendAsync(msg); 
    await ts.CompleteAsync();
}
committableTransaction.Commit();

파티션 키로 사용 되는 속성이 설정 된 경우 Service Bus는 메시지를 특정 파티션에 고정 합니다.If any of the properties that serve as a partition key are set, Service Bus pins the message to a specific partition. 이 동작은 트랜잭션이 사용되는지 여부와 상관 없이 발생합니다.This behavior occurs whether or not a transaction is used. 필요하지 않은 경우 파티션 키를 지정하지 않는 것이 좋습니다.It is recommended that you do not specify a partition key if it is not necessary.

분할된 엔터티로 세션 사용Using sessions with partitioned entities

세션 인식 토픽 또는 큐에 트랜잭션 메시지를 보내려면 메시지에 SessionId 속성 집합이 있어야 합니다.To send a transactional message to a session-aware topic or queue, the message must have the SessionId property set. PartitionKey 속성도 지정될 경우 SessionId 속성과 동일해야 합니다.If the PartitionKey property is specified as well, it must be identical to the SessionId property. 다른 경우 Service Bus가 잘못된 작업 예외를 반환합니다.If they differ, Service Bus returns an invalid operation exception.

일반(분할되지 않은) 큐 또는 항목과 달리 단일 트랜잭션을 사용하여 다른 세션에 여러 메시지를 보낼 수 없습니다.Unlike regular (non-partitioned) queues or topics, it is not possible to use a single transaction to send multiple messages to different sessions. 시도할 경우 Service Bus가 잘못된 작업 예외를 반환합니다.If attempted, Service Bus returns an invalid operation exception. 예를 들면 다음과 같습니다.For example:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    Message msg = new Message("This is a message");
    msg.SessionId = "mySession";
    await messageSender.SendAsync(msg); 
    await ts.CompleteAsync();
}
committableTransaction.Commit();

분할된 엔터티로 자동 메시지 전달Automatic message forwarding with partitioned entities

Service Bus는 분할된 엔터티 간에 자동 메시지 전달을 지원합니다.Service Bus supports automatic message forwarding from, to, or between partitioned entities. 자동 메시지 전달을 사용하려면 원본 큐 또는 구독에 QueueDescription.ForwardTo 속성을 설정합니다.To enable automatic message forwarding, set the QueueDescription.ForwardTo property on the source queue or subscription. 메시지가 파티션 키(SessionId, PartitionKey 또는 MessageId)를 지정하는 경우 해당 파티션 키를 대상 엔터티에 사용합니다.If the message specifies a partition key (SessionId, PartitionKey, or MessageId), that partition key is used for the destination entity.

고려 사항 및 지침Considerations and guidelines

  • 높은 일관성 기능: 엔터티에서 세션, 중복 검색 또는 분할 키의 명시적 제어와 같은 기능을 사용 하는 경우 메시징 작업은 항상 특정 파티션으로 라우팅됩니다.High consistency features: If an entity uses features such as sessions, duplicate detection, or explicit control of partitioning key, then the messaging operations are always routed to specific partition. 파티션이 높은 트래픽을 경험 하거나 기본 저장소가 비정상 상태 이면 해당 작업이 실패 하 고 가용성이 줄어듭니다.If any of the partitions experience high traffic or the underlying store is unhealthy, those operations fail and availability is reduced. 결과적으로 분할되지 않은 엔터티보다 일관성은 훨씬 높아집니다. 모든 트래픽이 아닌 트래픽 일부에서만 문제가 나타나기 때문입니다.Overall, the consistency is still much higher than non-partitioned entities; only a subset of traffic is experiencing issues, as opposed to all the traffic. 자세한 내용은 이 가용성 및 일관성 논의를 참조하세요.For more information, see this discussion of availability and consistency.
  • 관리: 만들기, 업데이트 및 삭제와 같은 작업은 엔터티의 모든 파티션에서 수행 되어야 합니다.Management: Operations such as Create, Update, and Delete must be performed on all the partitions of the entity. 파티션이 비정상 이면 이러한 작업에 오류가 발생할 수 있습니다.If any partition is unhealthy, it could result in failures for these operations. 가져오기 작업의 경우 메시지 개수와 같은 정보는 모든 파티션에서 집계 되어야 합니다.For the Get operation, information such as message counts must be aggregated from all partitions. 파티션이 비정상 이면 엔터티 가용성 상태가 제한 됨으로 보고 됩니다.If any partition is unhealthy, the entity availability status is reported as limited.
  • 저용량 메시지 시나리오: 이런 시나리오에서, 특히 HTTP 프로토콜을 사용하는 경우 모든 메시지를 가져오기 위해 여러 수신 작업을 수행해야 할 수 있습니다.Low volume message scenarios: For such scenarios, especially when using the HTTP protocol, you may have to perform multiple receive operations in order to obtain all the messages. 수신 요청의 경우 프런트 엔드는 모든 파티션에서 수신을 수행 하 고 수신 된 모든 응답을 캐시 합니다.For receive requests, the front end performs a receive on all the partitions and caches all the responses received. 동일한 연결에 대한 후속 수신 요청은 이러한 캐싱 덕분에 수신 대기 시간이 감소합니다.A subsequent receive request on the same connection would benefit from this caching and receive latencies will be lower. 그러나 연결이 여러 개 있거나 HTTP를 사용하는 경우 각 요청에 대해 새 연결이 설정됩니다.However, if you have multiple connections or use HTTP, that establishes a new connection for each request. 따라서 동일한 노드에 요청이 들어온다고 보장할 수 없습니다.As such, there is no guarantee that it would land on the same node. 모든 기존 메시지가 잠기고 다른 프런트 엔드에 캐시될 경우 수신 작업은 null 을 반환합니다.If all existing messages are locked and cached in another front end, the receive operation returns null. 결과적으로 메시지가 만료되고 다시 받을 수 있습니다.Messages eventually expire and you can receive them again. HTTP 연결 유지를 사용하는 것이 좋습니다.HTTP keep-alive is recommended. 볼륨이 낮은 시나리오에서 분할을 사용 하는 경우 수신 작업이 예상 보다 오래 걸릴 수 있습니다.When using partitioning in low-volume scenarios, receive operations may take longer than expected. 따라서 이러한 시나리오에서는 분할을 사용 하지 않는 것이 좋습니다.Hence, we recommend that you don't use partitioning in these scenarios. 기존 분할 된 엔터티를 삭제 하 고 분할을 사용 하지 않도록 설정 하 여 다시 만들어 성능을 향상 시킵니다.Delete any existing partitioned entities and recreate them with partitioning disabled to improve performance.
  • 메시지 찾아보기/보기: 이전 WindowsAzure.ServiceBus 라이브러리에서만 사용할 수 있습니다.Browse/Peek messages: Available only in the older WindowsAzure.ServiceBus library. PeekBatchMessageCount 속성에 지정된 메시지 수를 항상 반환하지는 않습니다.PeekBatch does not always return the number of messages specified in the MessageCount property. 이 동작에는 일반적으로 다음 두 가지 이유가 있습니다.There are two common reasons for this behavior. 하나는 메시지 컬렉션의 집계 크기가 최대 크기인 256KB를 초과하기 때문입니다.One reason is that the aggregated size of the collection of messages exceeds the maximum size of 256 KB. 또 다른 이유는 큐 또는 토픽이 EnablePartitioning 속성true 로 설정하면 파티션에 요청된 메시지 수를 완료하기 위한 충분한 메시지에 없을 수 있기 때문입니다.Another reason is that if the queue or topic has the EnablePartitioning property set to true, a partition may not have enough messages to complete the requested number of messages. 일반적으로 애플리케이션이 특정 개수의 메시지를 받으려는 경우 해당 메시지 수에 도달할 때까지 또는 엿볼 수 있는 추가 메시지가 없게 될 때까지 PeekBatch를 반복적으로 호출해야 합니다.In general, if an application wants to receive a specific number of messages, it should call PeekBatch repeatedly until it gets that number of messages, or there are no more messages to peek. 코드 샘플을 비롯한 자세한 내용은 QueueClient.PeekBatch 또는 SubscriptionClient.PeekBatch API 설명서를 참조하세요.For more information, including code samples, see the QueueClient.PeekBatch or SubscriptionClient.PeekBatch API documentation.

최근에 추가된 기능Latest added features

분할된 엔터티 제한 사항Partitioned entities limitations

현재 Service Bus에서는 분할된 큐 및 항목에 다음과 같은 제한 사항이 적용됩니다.Currently Service Bus imposes the following limitations on partitioned queues and topics:

  • 프리미엄 메시징 계층에서 분할된 큐 및 항목이 지원되지 않습니다.Partitioned queues and topics are not supported in the Premium messaging tier. 세션은 SessionId를 사용하는 방식을 통해 프리미어 계층에서 지원됩니다.Sessions are supported in the premier tier by using SessionId.
  • 분할된 큐 및 항목은 단일 트랜잭션에서 다른 세션에 속한 보내는 메시지를 지원하지 않습니다.Partitioned queues and topics do not support sending messages that belong to different sessions in a single transaction.
  • Service Bus는 현재 네임스페이스당 최대 100개의 분할된 큐 또는 항목을 허용합니다.Service Bus currently allows up to 100 partitioned queues or topics per namespace. 각 분할된 큐 또는 항목은 네임스페이스 당 10,000개의 엔터티를 할당량으로 계산합니다(프리미엄 계층에는 적용되지 않음).Each partitioned queue or topic counts towards the quota of 10,000 entities per namespace (does not apply to Premium tier).

다음 단계Next steps

AMQP 1.0 프로토콜 가이드에서 AMQP 1.0 메시징 사양의 핵심 개념을 읽어보세요.Read about the core concepts of the AMQP 1.0 messaging specification in the AMQP 1.0 protocol guide.