Kuyruk Tabanlı Yük Dengeleme düzeniQueue-Based Load Leveling pattern

Görevle hizmet arasında tampon görevi görecek ve hizmetin başarısız olmasına veya görevin zaman aşımına uğramasına neden olabilecek aralıklı olarak ağırlaşan yükleri hafifletmek için çağrılacak bir kuyruk kullanın. Bu, hem görev hem de hizmet için kullanılabilirlik ve yanıt vermeye yönelik isteğe bağlı artışların etkisini azaltmaya yardımcı olabilir.Use a queue that acts as a buffer between a task and a service it invokes in order to smooth intermittent heavy loads that can cause the service to fail or the task to time out. This can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.

Bağlam ve sorunContext and problem

Buluttaki birçok çözüm, hizmetleri çağıran görevler çalıştırmayı içerir.Many solutions in the cloud involve running tasks that invoke services. Bu ortamda, bir hizmet aralıklı olarak ağır yükler ile karşılaşıyorsa, bu performans veya güvenilirlik sorunlarına neden olabilir.In this environment, if a service is subjected to intermittent heavy loads, it can cause performance or reliability issues.

Bir hizmet hizmeti kullanan görevler ile aynı çözümün parçası veya bir önbellek ya da depolama hizmeti gibi sık kullanılan kaynaklara erişin sağlayan üçüncü taraf bir hizmet olabilir.A service could be part of the same solution as the tasks that use it, or it could be a third-party service providing access to frequently used resources such as a cache or a storage service. Aynı hizmet eşzamanlı olarak çalışan çok sayıda görev tarafından kullanılıyorsa, herhangi bir zamanda hizmetteki istek sayısını tahmin etmek zor olabilir.If the same service is used by a number of tasks running concurrently, it can be difficult to predict the volume of requests to the service at any time.

Hizmet istek sayısındaki artış nedeniyle aşırı yüklenebilir ve isteklere zamanında yanıt veremeyebilir.A service might experience peaks in demand that cause it to overload and be unable to respond to requests in a timely manner. Bir hizmete çok fazla sayıda istek göndermek de hizmet bu isteklerin neden olduğu çekişmeyi işleyemezse hizmetin başarısız olmasına neden olabilir.Flooding a service with a large number of concurrent requests can also result in the service failing if it's unable to handle the contention these requests cause.

ÇözümSolution

Çözümü yeniden düzenleyin ve görev ile hizmet arasında bir kuyruk ekleyin.Refactor the solution and introduce a queue between the task and the service. Görev ve hizmet zaman uyumsuz olarak çalışır.The task and the service run asynchronously. Görev, hizmet için gereken verileri içeren bir iletiyi bir kuyruğa gönderir.The task posts a message containing the data required by the service to a queue. Kuyruk bir arabellek görevi görerek ileti hizmet tarafından alınana kadar iletiyi depolar.The queue acts as a buffer, storing the message until it's retrieved by the service. Hizmet iletileri kuyruktan alır ve işler.The service retrieves the messages from the queue and processes them. Yüksek oranda değişken bir hızla birden çok sayıda görev tarafından oluşturulan istekler aynı ileti kuyruğu üzerinden hizmete geçirilebilir.Requests from a number of tasks, which can be generated at a highly variable rate, can be passed to the service through the same message queue. Bu şekilde bir hizmet üzerindeki yükü dengelemek için bir kuyruk kullanma gösterilmektedir.This figure shows using a queue to level the load on a service.

Şekil 1 - Bir hizmet üzerindeki yükü dengelemek için bir kuyruk kullanma

Kuyruk görevleri hizmetten ayırır ve hizmet eş zamanlı görevlerden gelen istek hacminden bağımsız olarak iletileri kendi hızında işleyebilir.The queue decouples the tasks from the service, and the service can handle the messages at its own pace regardless of the volume of requests from concurrent tasks. Ayrıca, bir hizmet kuyruğa bir ileti gönderdiğinde hizmet kullanılamıyorsa görevde gecikme yaşanmaz.Additionally, there's no delay to a task if the service isn't available at the time it posts a message to the queue.

Bu düzen aşağıdaki faydaları sağlar:This pattern provides the following benefits:

  • Uygulama hizmet kullanılabilir olmadığında veya iletileri işlemiyor olduğunda bile kuyruğa ileti göndermeye devam edebileceğinden, hizmetlerde oluşan gecikmeler uygulama üzerinde doğrudan bir etkiye sahip olmadığından kullanılabilirliği en üst düzeye çıkarmaya yardımcı olur.It can help to maximize availability because delays arising in services won't have an immediate and direct impact on the application, which can continue to post messages to the queue even when the service isn't available or isn't currently processing messages.

  • Hem kuyruk sayısı hem de hizmet sayısı isteği karşılamak için değiştirilebileceğinden, ölçeklenebilirliği en üst düzeye çıkarmaya yardımcı olur.It can help to maximize scalability because both the number of queues and the number of services can be varied to meet demand.

  • Dağıtılan hizmet örneklerinin en fazla yükü değil ortalama yükü karşılaması gerektiğinden maliyetleri denetlemeye yardımcı olabilir.It can help to control costs because the number of service instances deployed only have to be adequate to meet average load rather than the peak load.

    Bazı hizmetler, istek sistemin başarısız olmasına neden olabilecek bir eşiğe ulaştığında azaltma uygular.Some services implement throttling when demand reaches a threshold beyond which the system could fail. Azaltma mevcut işlevsellik düzeyini düşürebilir.Throttling can reduce the functionality available. Bu eşiğin aşılmadığından emin olmak için bu hizmetlerde yük dengeleme uygulayabilirsiniz.You can implement load leveling with these services to ensure that this threshold isn't reached.

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:

  • Kaynak hedefin aşırı yüklenmesini önlemek için, hizmetin iletileri işleme hızını denetleyen bir uygulama mantığı kullanmak gereklidir.It's necessary to implement application logic that controls the rate at which services handle messages to avoid overwhelming the target resource. İstek artışlarını sistemin sonraki aşamasına geçirmekten kaçının.Avoid passing spikes in demand to the next stage of the system. Sistemin gereken dengelemeyi sağladığından emin olmak için sistemi yük altında test edin ve bunu gerçekleştirmek için gereken kuyruk sayısını ve iletileri işleyen hizmet örneği sayısını ayarlayın.Test the system under load to ensure that it provides the required leveling, and adjust the number of queues and the number of service instances that handle messages to achieve this.
  • İleti kuyrukları tek yönlü bir iletişim mekanizmasıdır.Message queues are a one-way communication mechanism. Bir görev bir hizmetten yanıt bekliyorsa, hizmetin yanıt göndermek için kullanabileceği bir mekanizma uygulamak gerekli olabilir.If a task expects a reply from a service, it might be necessary to implement a mechanism that the service can use to send a response. Daha fazla bilgi için bkz. Zaman Uyumsuz Mesajlaşma Temel Bilgileri.For more information, see the Asynchronous Messaging Primer.
  • Kuyruktaki istekler için dinleyen hizmetlere otomatik ölçeklendirme uyguluyorsanız dikkatli olun.Be careful if you apply autoscaling to services that are listening for requests on the queue. Bu, bu hizmetlerin paylaştığı kaynaklar için çekişmenin artması ve yük dengeleme için kuyruğu kullanma verimliliğinin azalmasıyla sonuçlanabilir.This can result in increased contention for any resources that these services share and diminish the effectiveness of using the queue to level the load.

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

Bu düzen aşırı yüklenen hizmetleri kullanan uygulamalar için yararlıdır.This pattern is useful to any application that uses services that are subject to overloading.

Bu düzen uygulama hizmetten en düşük gecikme süresiyle yanıt bekliyorsa yararlı değildir.This pattern isn't useful if the application expects a response from the service with minimal latency.

ÖrnekExample

Bir web uygulaması bir dış veri deposuna verileri yazar.A web app writes data to an external data store. Örnek web uygulaması, çok sayıda eş zamanlı olarak çalıştırılırsa, veri deposu isteklere yeterince hızlı yanıt, istekleri neden zaman aşımına kısıtlanabilir veya aksi halde hata ver bağlanamayabilirsiniz.If a large number of instances of the web app run concurrently, the data store might be unable to respond to requests quickly enough, causing requests to time out, be throttled, or otherwise fail. Aşağıdaki diyagramda, bir veri deposuna çok sayıda eş zamanlı isteklerin uygulama örnekleri tarafından dolmasını gösterilmektedir.The following diagram shows a data store being overwhelmed by a large number of concurrent requests from instances of an application.

Şekil 2 - bir hizmet tarafından çok sayıda eş zamanlı istekleri web uygulamasının örneklerinden dolmasını

Bu sorunu gidermek için uygulama örnekleri ile veri deposu arasında yük dengelemek için bir kuyruk kullanabilirsiniz.To resolve this, you can use a queue to level the load between the application instances and the data store. Bir Azure işlev uygulaması, kuyruktan iletileri okuyan ve veri deposu okuma/yazma isteklerine gerçekleştirir.An Azure Functions app reads the messages from the queue and performs the read/write requests to the data store. İşlev uygulaması uygulama mantığı, istekleri engeller kısası deposu önlemek için veri deposuna geçirir Geçirme hızını denetleyebilir.The application logic in the function app can control the rate at which it passes requests to the data store, to prevent the store from being overwhelmed. (Aksi takdirde işlev uygulaması yalnızca arka uçta aynı sorunu yeniden başlatacaktır.)(Otherwise the function app will just re-introduce the same problem at the back end.)

Şekil 3 - yük dengelemek için bir kuyruk ve bir işlev uygulaması'nı kullanma

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:

  • Zaman Uyumsuz Mesajlaşma Temel Bilgileri.Asynchronous Messaging Primer. İleti kuyrukları kendiliğinden zaman uyumsuzdur.Message queues are inherently asynchronous. Bir görevdeki uygulama mantığı bir hizmetle doğrudan iletişim kurmaktan bir ileti kuyruğu kullanmaya uyarlandıysa, mantığın yeniden tasarlanması gerekebilir.It might be necessary to redesign the application logic in a task if it's adapted from communicating directly with a service to using a message queue. Benzer şekilde, bir hizmetin bir ileti kuyruğundan istekleri kabul etmek için yeniden düzenlenmesi gerekebilir.Similarly, it might be necessary to refactor a service to accept requests from a message queue. Alternatif olarak, örnekte açıklandığı gibi bir proxy hizmeti uygulamak mümkün olabilir.Alternatively, it might be possible to implement a proxy service, as described in the example.

  • Rakip Tüketiciler düzeni.Competing Consumers pattern. Bir hizmetin her biri yük dengeleme kuyruğundan bir ileti tüketicisi olarak davranan birden çok örneğini çalıştırmak mümkün olabilir.It might be possible to run multiple instances of a service, each acting as a message consumer from the load-leveling queue. İletilen alınma ve bir hizmete geçirilme hızını ayarlamak için bu yaklaşımı kullanabilirsiniz.You can use this approach to adjust the rate at which messages are received and passed to a service.

  • Azaltma düzeni.Throttling pattern. Bir hizmet ile azaltma kullanmanın basit bir yolu, kuyruk tabanlı yük dengeleme kullanmak ve bir hizmete tüm istekleri bir ileti kuyruğu üzerinden yönlendirmektir.A simple way to implement throttling with a service is to use queue-based load leveling and route all requests to a service through a message queue. Hizmet istekleri hizmet tarafından gerektirilen kaynakların bitmemesini sağlayan ve oluşabilecek çekişme miktarını azaltan bir hızda işleyebilir.The service can process requests at a rate that ensures that resources required by the service aren't exhausted, and to reduce the amount of contention that could occur.

  • Azure Mesajlaşma hizmetleri arasında seçim.Choose between Azure messaging services. Azure uygulamalarında bir mesajlaşma ve kuyruğa alma mekanizması seçme hakkında bilgiler.Information about choosing a messaging and queuing mechanism in Azure applications.

  • Bir Azure web uygulamasında ölçeklenebilirliği geliştirme.Improve scalability in an Azure web application. Bu başvuru mimarisi, mimariyi bir parçası olarak kuyruk tabanlı Yük Dengeleme içerir.This reference architecture includes queue-based load leveling as part of the architecture.