Öncelikli Kuyruk düzeniPriority Queue pattern

Yüksek öncelikli isteklerin düşük öncelikli olanlardan daha önce alınması ve işlenmesini sağlamak için hizmete gönderilen isteklerin önceliklerini belirleyin.Prioritize requests sent to services so that requests with a higher priority are received and processed more quickly than those with a lower priority. Bu düzen, ayrı ayrı istemcilere farklı hizmet düzeyi garantileri sunan uygulamalarda kullanışlıdır.This pattern is useful in applications that offer different service level guarantees to individual clients.

Bağlam ve SorunContext and Problem

Uygulamalar, arka plan işlemleri gerçekleştirme ya da diğer uygulama veya hizmetler ile tümleştirme gibi amaçlarla belirli görevler için diğer hizmetleri temsilci seçebilir.Applications can delegate specific tasks to other services, for example, to perform background processing or to integrate with other applications or services. Bulutta arka planda işleme amacıyla göreve temsilci atamak için genelde bir ileti kuyruğu kullanılır.In the cloud, a message queue is typically used to delegate tasks to background processing. Çoğu durumda hizmetin istekleri alma sırası önemli değildir.In many cases the order requests are received in by a service isn't important. Ancak, bazı durumlarda belirli isteklere öncelik tanımak gerekir.In some cases, though, it's necessary to prioritize specific requests. Bu istekler, uygulama tarafından daha önce gönderilen daha düşük öncelikli isteklerden daha önce işlenmelidir.These requests should be processed earlier than lower priority requests that were sent previously by the application.

ÇözümSolution

Kuyruklar, çoğunlukla ilk giren ilk çıkar (FIFO) yapısındadır ve tüketiciler genelde iletileri kuyruğa gönderildiği sırada alır.A queue is usually a first-in, first-out (FIFO) structure, and consumers typically receive messages in the same order that they were posted to the queue. Ancak, bazı ileti kuyrukları öncelikli mesajlaşmayı destekler.However, some message queues support priority messaging. İleti gönderen uygulama bu iletiye bir öncelik atayabilir. Bu durumda, kuyruktaki iletiler otomatik olarak yeniden sıralanır. Böylece yüksek öncelikli iletilerin daha düşük öncelikli olanlardan daha önce alınması sağlanır.The application posting a message can assign a priority and the messages in the queue are automatically reordered so that those with a higher priority will be received before those with a lower priority. Şekilde öncelikli mesajlaşma içeren bir kuyruk gösterilmektedir.The figure illustrates a queue with priority messaging.

Şekil 1 - İletilerin önceliğinin belirlenmesini destekleyen bir kuyruğa alma mekanizması kullanma

İleti kuyruğu uygulamalarının çoğu birden fazla tüketiciyi destekler (Rakip Tüketiciler düzenini izleyerek) ve tüketici işlemlerinin sayısında talebe bağlı olarak ölçek artırılıp azaltılabilir.Most message queue implementations support multiple consumers (following the Competing Consumers pattern), and the number of consumer processes can be scaled up or down depending on demand.

Öncelik tabanlı ileti kuyruklarını desteklemeyen sistemler için alternatif bir çözüm her bir öncelik için ayrı bir kuyruk sürdürmektir.In systems that don't support priority-based message queues, an alternative solution is to maintain a separate queue for each priority. Uygulama, iletilerin uygun kuyruğa gönderilmesinden sorumludur.The application is responsible for posting messages to the appropriate queue. Her bir kuyruğun ayrı bir tüketici havuzu olabilir.Each queue can have a separate pool of consumers. Yüksek öncelik kuyrukların, düşük öncelikli kuyruklara göre daha hızlı donanımlar üzerinde çalışan daha büyük bir tüketici havuzu olabilir.Higher priority queues can have a larger pool of consumers running on faster hardware than lower priority queues. Aşağıdaki şekilde her bir öncelik için ayrı ileti kuyrukları kullanılması gösterilmektedir.The next figure illustrates using separate message queues for each priority.

Şekil 2 - Her bir öncelik için ayrı ileti kuyrukları kullanma

Bu stratejinin farklı bir versiyonu, tek bir tüketici havuzu kullanılıp önce yüksek öncelikli kuyruklarda ileti olup olmadığının denetlenmesi, ancak bundan sonra düşük öncelikli kuyruklardaki iletilerin getirilmesidir.A variation on this strategy is to have a single pool of consumers that check for messages on high priority queues first, and only then start to fetch messages from lower priority queues. Tek bir tüketici işlemleri havuzunu kullanan (farklı önceliklere sahip iletileri destekleyen tek bir kuyruk veya her biri tek bir önceliğe sahip iletileri işleyen birden fazla kuyruk aracılığıyla) bir çözüm ile her bir kuyruk için ayrı bir havuzun olduğu birden fazla kuyruk kullanan bir çözüm arasında anlamsal bazı farklar vardır.There are some semantic differences between a solution that uses a single pool of consumer processes (either with a single queue that supports messages with different priorities or with multiple queues that each handle messages of a single priority), and a solution that uses multiple queues with a separate pool for each queue.

Tek havuzlu yaklaşımda yüksek öncelikli iletiler her zaman düşük öncelikli iletilerden daha önce alınıp işlenir.In the single pool approach, higher priority messages are always received and processed before lower priority messages. Teorik olarak, çok düşük öncelikli iletiler sürekli geriye düşüp hiçbir zaman işlenmeyebilir.In theory, messages that have a very low priority could be continually superseded and might never be processed. Birden fazla havuzlu yaklaşımda düşük öncelikli iletiler her zaman işlenir. Sadece bu işleme, yüksek öncelikli iletiler için olduğu kadar hızlı olmaz (havuzların birbirlerine göre boyutlarına ve kullanabilecekleri kaynaklara bağlı olarak).In the multiple pool approach, lower priority messages will always be processed, just not as quickly as those of a higher priority (depending on the relative size of the pools and the resources that they have available).

Öncelikli bir kuyruğa alma mekanizmasının kullanılması aşağıdaki avantajları sağlayabilir:Using a priority queuing mechanism can provide the following advantages:

  • Uygulamaların kullanılabilirlik veya performans için öncelik belirlenmesini gerektiren iş gereksinimlerini karşılamasına olanak sağlar. Örneğin, belirli müşteri gruplarına farklı düzeylerde hizmet sunulabilir.It allows applications to meet business requirements that require prioritization of availability or performance, such as offering different levels of service to specific groups of customers.

  • İşletim maliyetlerinin en aza indirilmesine yardımcı olabilir.It can help to minimize operational costs. Tek kuyruklu yaklaşımda gerekirse tüketici sayısının ölçeğini küçültebilirsiniz.In the single queue approach, you can scale back the number of consumers if necessary. Yüksek öncelikli iletiler yine ilk olarak işlenir (ancak büyük olasılıkla daha yavaş bir şekilde) ve düşük öncelikli iletiler daha uzun bir süre için ertelenebilir.High priority messages will still be processed first (although possibly more slowly), and lower priority messages might be delayed for longer. Her bir kuyruk için ayrı bir tüketici havuzu içeren birden fazla ileti kuyruğu yaklaşımını uyguladıysanız düşük öncelikli kuyruklar için tüketici havuzunu küçültebilir hatta çok düşük öncelik kuyruklarda ileti olup olmadığını dinleyen tüm tüketicileri durdurarak bu kuyrukların işlemlerini askıya alabilirsiniz.If you've implemented the multiple message queue approach with separate pools of consumers for each queue, you can reduce the pool of consumers for lower priority queues, or even suspend processing for some very low priority queues by stopping all the consumers that listen for messages on those queues.

  • Birden fazla ileti kuyruğu yaklaşımı, iletileri işleme gereksinimlerine bağlı olarak bölümleyerek uygulama performansı ve ölçeklenebilirliğinin en üst düzeye çıkarılmasına yardımcı olabilir.The multiple message queue approach can help maximize application performance and scalability by partitioning messages based on processing requirements. Örneğin, çok önemli görevler hemen çalıştırılan alıcılar tarafından işlenecek şekilde önceliklendirilebilir. Önemi daha düşük arka plan görevleri de daha az meşgul zamanlarda çalıştırılması zamanlanan alıcılar tarafından işlenebilir.For example, vital tasks can be prioritized to be handled by receivers that run immediately while less important background tasks can be handled by receivers that are scheduled to run at less busy periods.

Sorunlar ve Dikkat Edilmesi GerekenlerIssues and Considerations

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when deciding how to implement this pattern:

Öncelikleri, çözümün bağlamında tanımlayın.Define the priorities in the context of the solution. Örneğin, yüksek öncelik iletilerin on saniye içinde işlenmesi gerektiği anlamına gelebilir.For example, high priority could mean that messages should be processed within ten seconds. Yüksek öncelikli öğeleri işleme gereksinimlerini ve bu ölçütlere uymak için ayrılacak olan diğer kaynakları belirleyin.Identify the requirements for handling high priority items, and the other resources that should be allocated to meet these criteria.

Düşük öncelikli öğelere geçmeden önce tüm yüksek öncelikli öğelerin işlenmesinin gerekip gerekmediğine karar verin.Decide if all high priority items must be processed before any lower priority items. İletiler tek bir tüketici havuzu tarafından işleniyorsa daha yüksek öncelikli bir ileti kullanılabilir hale geldiğinde düşük öncelikli bir iletiyi işlemekte olan bir görevi etkisiz hale getirip askıya alacak bir mekanizma sağlamanız gerekir.If the messages are being processed by a single pool of consumers, you have to provide a mechanism that can preempt and suspend a task that's handling a low priority message if a higher priority message becomes available.

Birden fazla kuyruklu yaklaşımda her kuyruk için adanmış bir tüketici havuzu yerine tüm kuyrukları dinleyen tek bir tüketici işlemleri havuzu kullanıyorsanız tüketici, düşük öncelikli kuyruklardaki iletilere geçmeden önce her zaman yüksek öncelikli kuyruklardaki iletilere hizmet sunmasını sağlayan bir algoritma uygulamalıdır.In the multiple queue approach, when using a single pool of consumer processes that listen on all queues rather than a dedicated consumer pool for each queue, the consumer must apply an algorithm that ensures it always services messages from higher priority queues before those from lower priority queues.

Yüksek ve düşük öncelikli kuyruklardaki işleme hızını izleyerek bu kuyruklardaki iletilerin beklenen hızlarda işlendiğinden emin olun.Monitor the processing speed on high and low priority queues to ensure that messages in these queues are processed at the expected rates.

Düşük öncelikli iletilerin işleneceğini garantilemeye ihtiyacınız varsa birden fazla tüketici havuzu içeren birden fazla ileti kuyruğu yaklaşımını uygulamak gereklidir.If you need to guarantee that low priority messages will be processed, it's necessary to implement the multiple message queue approach with multiple pools of consumers. Alternatif olarak, ileti önceliği belirlemeyi destekleyen bir kuyrukta kuyruğa alınmış bir ileti eskidikçe iletinin önceliğini dinamik olarak artırmak mümkündür.Alternatively, in a queue that supports message prioritization, it's possible to dynamically increase the priority of a queued message as it ages. Ancak, bu yaklaşım için ileti kuyruğunun bu özelliği sağlaması gereklidir.However, this approach depends on the message queue providing this feature.

Her bir ileti önceliği için ayrı bir kuyruk kullanılması, en çok az sayıda iyi tanımlanmış önceliğe sahip sistemler için uygundur.Using a separate queue for each message priority works best for systems that have a small number of well-defined priorities.

İleti öncelikleri sistem tarafından mantıksal olarak belirlenebilir.Message priorities can be determined logically by the system. Örneğin, açıkça yüksek veya düşük öncelikli iletiler yerine bu öncelikler "ücret ödeyen müşteri" ve "ücret ödemeyen müşteri" olarak belirlenebilir.For example, rather than having explicit high and low priority messages, they could be designated as “fee paying customer,” or “non-fee paying customer.” Sisteminiz, iş modelinize bağlı olarak ücret ödeyen müşterilerden gelen iletileri işlemek için ücret ödemeyen müşterilere göre daha fazla kaynak ayırabilir.Depending on your business model, your system can allocate more resources to processing messages from fee paying customers than non-fee paying ones.

Bir kuyrukta ileti olup olmadığını denetlemeye ait bir finansal ve işleme maliyeti olabilir (bazı ticari mesajlaşma sistemleri her ileti gönderildiğinde veya alındığında ve bir kuyrukta ileti olup olmadığı her sorgulandığında küçük bir ücret alır).There might be a financial and processing cost associated with checking a queue for a message (some commercial messaging systems charge a small fee each time a message is posted or retrieved, and each time a queue is queried for messages). Birden fazla kuyruk denetlendiğinde bu maliyet artar.This cost increases when checking multiple queues.

Bir tüketici havuzunun boyutunu, hizmet verdiği kuyruğun uzunluğuna göre dinamik olarak ayarlamak mümkündür.It's possible to dynamically adjust the size of a pool of consumers based on the length of the queue that the pool is servicing. Daha fazla bilgi için bkz. Otomatik Ölçeklendirme Kılavuzu.For more information, see the Autoscaling Guidance.

Bu düzenin kullanılacağı durumlarWhen to use this pattern

Bu düzen, aşağıdakilerin geçerli olduğu senaryolarda kullanışlıdır:This pattern is useful in scenarios where:

  • Sistem farklı önceliklere sahip birden çok görevi işlemelidir.The system must handle multiple tasks that have different priorities.

  • Farklı kullanıcı veya kiracılara farklı önceliklerle hizmet sunulması gereklidir.Different users or tenants should be served with different priority.

ÖrnekExample

Microsoft Azure, sıralama aracılığıyla iletilerin önceliklerinin otomatik belirlenmesini yerel olarak destekleyen bir kuyruğa alma mekanizması sağlamaz.Microsoft Azure doesn't provide a queuing mechanism that natively supports automatic prioritization of messages through sorting. Ancak, bir kuyruğa alma mekanizmasını destekleyen Azure Service Bus konuları ve abonelikleri sağlar. Bu mekanizma, ileti filtrelemenin yanı sıra kendisini birçok öncelikli kuyruk uygulamasında kullanım için ideal kılan çok sayıda esnek özellik sunar.However, it does provide Azure Service Bus topics and subscriptions that support a queuing mechanism that provides message filtering, together with a wide range of flexible capabilities that make it ideal for use in most priority queue implementations.

Azure çözümleri, uygulamaların aynen bir kuyruğa gönderir gibi ileti gönderebilecekleri bir Service Bus konusu uygulayabilir.An Azure solution can implement a Service Bus topic an application can post messages to, in the same way as a queue. İletiler, uygulama tanımlı özel özellikler biçiminde meta veriler içerebilir.Messages can contain metadata in the form of application-defined custom properties. Service Bus abonelikleri konu ile ilişkilendirilebilir ve bu abonelikler iletileri özelliklerine göre filtreleyebilir.Service Bus subscriptions can be associated with the topic, and these subscriptions can filter messages based on their properties. Bir uygulama bir konuya ileti gönderdiğinde ileti tüketiciler tarafından okunabileceği uygun aboneliğe yönlendirilir.When an application sends a message to a topic, the message is directed to the appropriate subscription where it can be read by a consumer. Tüketici işlemleri, bir ileti kuyruğuyla aynı semantiği kullanarak bir abonelikten ileti alabilir (abonelik, mantıksal bir kuyruktur).Consumer processes can retrieve messages from a subscription using the same semantics as a message queue (a subscription is a logical queue). Aşağıdaki şekilde, Azure Service Bus konuları ve abonelikleri aracılığıyla öncelikli bir kuyruk uygulanması gösterilmektedir.The following figure illustrates implementing a priority queue with Azure Service Bus topics and subscriptions.

Şekil 3 - Azure Service Bus konuları ve abonelikleri aracılığıyla öncelikli bir kuyruk uygulama

Yukarıdaki şekilde, uygulama çeşitli iletiler oluşturur ve her iletiye High veya Low değerine sahip Priority adlı bir özel özellik atar.In the figure above, the application creates several messages and assigns a custom property called Priority in each message with a value, either High or Low. Uygulama bu iletileri bir konuya gönderir.The application posts these messages to a topic. Konuyla ilişkili iki abonelik de Priority özelliğini inceleyerek iletileri filtreler.The topic has two associated subscriptions that both filter messages by examining the Priority property. Bir abonelik Priority özelliğinin High olarak ayarlanmış olduğu iletileri ve diğer abonelik de Priority özelliğinin Low olarak ayarlanmış olduğu iletileri kabul eder.One subscription accepts messages where the Priority property is set to High, and the other accepts messages where the Priority property is set to Low. Her iki abonelikten gelen iletileri bir tüketici havuzu okur.A pool of consumers reads messages from each subscription. Yüksek öncelikli aboneliğin havuzu daha büyüktür ve bu tüketiciler düşük öncelikli havuzdaki tüketicilere göre daha fazla kaynağa sahip, daha güçlü bilgisayarlarda çalıştırılıyor olabilir.The high priority subscription has a larger pool, and these consumers might be running on more powerful computers with more resources available than the consumers in the low priority pool.

Bu örnekte yüksek ve düşük öncelikli iletilerin atanması hakkında özel bir şey olmadığına dikkat edin.Note that there's nothing special about the designation of high and low priority messages in this example. Bunlar, yalnızca her iletide özellik olarak belirtilen etiketlerdir ve iletileri belirli bir aboneliğe yönlendirmek için kullanılmaktadır.They're simply labels specified as properties in each message, and are used to direct messages to a specific subscription. Ek öncelikler gerekirse bu öncelikleri işlemek için kolayca başka abonelikler ve tüketici işlemi havuzları oluşturulabilir.If additional priorities are required, it's relatively easy to create further subscriptions and pools of consumer processes to handle these priorities.

GitHub’dan edinilebilecek PriorityQueue çözümü bu yaklaşımın bir uygulamasını içerir.The PriorityQueue solution available on GitHub contains an implementation of this approach. Bu çözüm, PriorityQueue.High ve PriorityQueue.Low adlı iki çalışan rolü projesi içerir.This solution contains two worker role projects named PriorityQueue.High and PriorityQueue.Low. Bu çalışan rolleri, OnStart yöntemindeki belirtilen bir aboneliğe bağlanma işlevini içeren PriorityWorkerRole sınıfından devralır.These worker roles inherit from the PriorityWorkerRole class that contains the functionality for connecting to a specified subscription in the OnStart method.

PriorityQueue.High ve PriorityQueue.Low çalışan rolleri, yapılandırma ayarları tarafından tanımlanan farklı aboneliklere bağlanır.The PriorityQueue.High and PriorityQueue.Low worker roles connect to different subscriptions, defined by their configuration settings. Bir yönetici, her rolün çalıştırılacağı farklı bir sayı yapılandırabilir.An administrator can configure different numbers of each role to be run. Genellikle PriorityQueue.High çalışan rolünün PriorityQueue.Low çalışan rolüne göre daha fazla örneği olacaktır.Typically there'll be more instances of the PriorityQueue.High worker role than the PriorityQueue.Low worker role.

PriorityWorkerRole sınıfındaki Run yöntemi, kuyrukta alınan her ileti için sanal ProcessMessage yönteminin (yine PriorityWorkerRole sınıfında tanımlanan) çalıştırılmasını düzenler.The Run method in the PriorityWorkerRole class arranges for the virtual ProcessMessage method (also defined in the PriorityWorkerRole class) to be run for each message received on the queue. Aşağıdaki kod, Run ve ProcessMessage yöntemlerini göstermektedir.The following code shows the Run and ProcessMessage methods. PriorityQueue.Shared projesinde tanımlanan QueueManager sınıfı, Azure Service Bus kuyruklarını kullanmaya yönelik yardımcı yöntemler sağlar.The QueueManager class, defined in the PriorityQueue.Shared project, provides helper methods for using Azure Service Bus queues.

public class PriorityWorkerRole : RoleEntryPoint
{
  private QueueManager queueManager;
  ...

  public override void Run()
  {
    // Start listening for messages on the subscription.
    var subscriptionName = CloudConfigurationManager.GetSetting("SubscriptionName");
    this.queueManager.ReceiveMessages(subscriptionName, this.ProcessMessage);
    ...;
  }
  ...

  protected virtual async Task ProcessMessage(BrokeredMessage message)
  {
    // Simulating processing.
    await Task.Delay(TimeSpan.FromSeconds(2));
  }
}

PriorityQueue.High ve PriorityQueue.Low çalışan rollerinin her ikisi de ProcessMessage yönteminin varsayılan işlevlerini geçersiz kılar.The PriorityQueue.High and PriorityQueue.Low worker roles both override the default functionality of the ProcessMessage method. Aşağıdaki kod, PriorityQueue.High çalışan rolüne ilişkin ProcessMessage yöntemini göstermektedir.The code below shows the ProcessMessage method for the PriorityQueue.High worker role.

protected override async Task ProcessMessage(BrokeredMessage message)
{
  // Simulate message processing for High priority messages.
  await base.ProcessMessage(message);
  Trace.TraceInformation("High priority message processed by " +
    RoleEnvironment.CurrentRoleInstance.Id + " MessageId: " + message.MessageId);
}

Bir uygulama, PriorityQueue.High ve PriorityQueue.Low çalışan rolleri tarafından kullanılan abonelikler ile ilişkili konuya ileti gönderirken aşağıdaki kod örneğinde gösterildiği gibi Priority özel özelliğini kullanarak önceliği belirtir.When an application posts messages to the topic associated with the subscriptions used by the PriorityQueue.High and PriorityQueue.Low worker roles, it specifies the priority by using the Priority custom property, as shown in the following code example. Bu kod (PriorityQueue.Sender projesindeki WorkerRole sınıfında uygulanır) bir konuya toplu olarak ileti göndermek için QueueManager sınıfının SendBatchAsync yardımcı yöntemini kullanır.This code (implemented in the WorkerRole class in the PriorityQueue.Sender project), uses the SendBatchAsync helper method of the QueueManager class to post messages to a topic in batches.

// Send a low priority batch.
var lowMessages = new List<BrokeredMessage>();

for (int i = 0; i < 10; i++)
{
  var message = new BrokeredMessage() { MessageId = Guid.NewGuid().ToString() };
  message.Properties["Priority"] = Priority.Low;
  lowMessages.Add(message);
}

this.queueManager.SendBatchAsync(lowMessages).Wait();
...

// Send a high priority batch.
var highMessages = new List<BrokeredMessage>();

for (int i = 0; i < 10; i++)
{
  var message = new BrokeredMessage() { MessageId = Guid.NewGuid().ToString() };
  message.Properties["Priority"] = Priority.High;
  highMessages.Add(message);
}

this.queueManager.SendBatchAsync(highMessages).Wait();

Bu düzen uygulanırken aşağıdaki düzenler ve yönergeler de yararlı olabilir:The following patterns and guidance might also be relevant when implementing this pattern:

  • Bu düzeni gösteren bir örnek GitHub’dan edinilebilir.A sample that demonstrates this pattern is available on GitHub.

  • Zaman Uyumsuz Mesajlaşma Temel Bilgileri.Asynchronous Messaging Primer. Bir isteği işleyen bir tüketici hizmetinin isteği gönderen uygulama örneğine bir yanıt göndermesi gerekebilir.A consumer service that processes a request might need to send a reply to the instance of the application that posted the request. İstek/yanıt iletilerini uygulamak için kullanabileceğiniz stratejiler hakkında bilgiler sunulmaktadır.Provides information on the strategies that you can use to implement request/response messaging.

  • Rakip Tüketiciler düzeni.Competing Consumers pattern. Kuyrukların işleme miktarını artırmak için, aynı kuyrukta dinleme yapan ve görevleri paralel olarak işleyen birden fazla tüketici kullanılması mümkündür.To increase the throughput of the queues, it’s possible to have multiple consumers that listen on the same queue, and process the tasks in parallel. Bu tüketiciler iletiler için rekabete girer, ancak her bir iletiyi yalnızca tek bir tüketici işleyebilmelidir.These consumers will compete for messages, but only one should be able to process each message. Bu yaklaşımı uygulamanın avantajları ve dezavantajları hakkında daha fazla bilgi sağlanmaktadır.Provides more information on the benefits and tradeoffs of implementing this approach.

  • Azaltma düzeni.Throttling pattern. Kuyrukları kullanarak azaltma uygulayabilirsiniz.You can implement throttling by using queues. Öncelikli mesajlaşma kullanılarak kritik uygulamalardan veya yüksek değerli müşteriler tarafından çalıştırılan uygulamalardan gelen isteklere daha az önemli uygulamalardan gelen isteklere göre öncelik verilmesi sağlanabilir.Priority messaging can be used to ensure that requests from critical applications, or applications being run by high-value customers, are given priority over requests from less important applications.

  • Otomatik Ölçeklendirme Kılavuzu.Autoscaling Guidance. Bir kuyruğu işleyen tüketici işlemleri havuzunun boyutunu kuyruğun uzunluğuna bağlı olarak ölçeklendirmek mümkün olabilir.It might be possible to scale the size of the pool of consumer processes handling a queue depending on the length of the queue. Bu strateji, özellikle yüksek öncelikli iletileri işleyen havuzların performansını artırmak için yardımcı olabilir.This strategy can help to improve performance, especially for pools handling high priority messages.

  • Service Bus ile Kurumsal Tümleştirme Düzenleri yazısı Abhishek Lal'ın blogundadır.Enterprise Integration Patterns with Service Bus on Abhishek Lal’s blog.