Hız Sınırlama düzeni

Uygulamanızın bir hizmete istek gönderme hızını denetlediğinizden, hizmetin azaltma sınırları ve genel kapasitenin içinde kalırsınız. Bu yaklaşım, kısıtlama hatalarını önlemenize veya en aza indirmenize ve iş hacmini daha doğru tahmin etmenize yardımcı olur.

Hız sınırlama birçok senaryoda uygundur, ancak toplu işlem gibi büyük ölçekli, yinelenen otomatik görevler için özellikle yararlıdır.

Bağlam ve sorun

Kısıtlanmış bir hizmete karşı çok sayıda işlem gerçekleştirmek, reddedilen istekleri izlemeniz ve ardından işlemleri yeniden denemeniz gerektiğinden trafiğin artmasına ve aktarım hızının azalmasına neden olabilir. İşlem sayısı arttıkça, hız sınırlama limiti verilerin birden fazla kez yeniden gönderilmesini gerektirebilir; bu da performans üzerinde daha büyük bir etkiye yol açabilir.

Örneğin, verileri Azure Cosmos DB’ye almak için kullanılan aşağıdaki sorunlu hata durumunda yeniden deneme işlemini ele alın:

1. Uygulamanızın Azure Cosmos DB'ye 10.000 kayıt alması gerekiyor. Her kaydın alınması 10 istek birimine (RU) mal olur, bu nedenle işi tamamlamak için toplam 100.000 RU gerekir.

2. Azure Cosmos DB örneğinizde sağlanan 20.000 RU kapasitesi vardır.

3. 10.000 kaydın tümünü Azure Cosmos DB'ye gönderirsiniz. 2.000 kayıt başarıyla yazılır ve 8.000 kayıt reddedilir.

4. Kalan 8.000 kaydı Azure Cosmos DB'ye gönderirsiniz. 2.000 kayıt başarıyla yazılır ve 6.000 kayıt reddedilir.

5. Kalan 6.000 kaydı Azure Cosmos DB'ye gönderirsiniz. 2.000 kayıt başarıyla yazılır ve 4.000 kayıt reddedilir.

6. Kalan 4.000 kaydı Azure Cosmos DB'ye gönderirsiniz. 2.000 kayıt başarıyla yazılır ve 2.000 kayıt reddedilir.

7. Kalan 2.000 kaydı Azure Cosmos DB'ye gönderirsiniz. Hepsi başarıyla yazıldı.

Alma görevi başarıyla tamamlanır, ancak bu ancak Azure Cosmos DB'ye 30.000 kayıt gönderildikten sonra gerçekleşir. Veri kümesinin tamamı yalnızca 10.000 kayıttır.

Bu örnekte dikkate alınması gereken başka faktörler de vardır:

• Çok sayıda hata, bu hataları günlüğe kaydetmek ve sonuçta elde edilen günlük verilerini işlemek için ek çalışmalara neden olabilir. Yukarıdaki yaklaşım 20.000 hatayı işler ve bu hataları günlüğe kaydetmek işlem, bellek veya depolama kaynağı maliyetine neden olabilir.

• Veri alma hizmetinin hız sınırlama limitlerini bilmediğiniz için, veri işlemenin ne kadar süreceği konusunda bir beklenti oluşturamazsınız. Hız sınırlaması, alım için gereken süreyi hesaplamanıza olanak sağlayabilir.

Çözüm

Hız sınırlaması, belirli bir süre boyunca hizmete gönderilen kayıt sayısını azaltarak trafiğinizi azaltabilir ve potansiyel olarak aktarım hızını artırabilir.

Bir hizmet, istekleri zaman içinde farklı ölçümlere göre kısıtlayabilir, örneğin:

• İşlem sayısı (örneğin, saniyede 20 istek).
• Veri miktarı (örneğin, dakikada 2 GiB).
• İşlemlerin göreli maliyeti (örneğin, saniyede 20.000 RU).

Daraltma için kullandığınız metrik ne olursa olsun, oran sınırlama uygulamanız, belirli bir süre içinde hizmete gönderilen işlemlerin sayısını ve/veya boyutunu kontrol etmeyi içerir. İstek hızı sınırlaması, hizmetin kısıtlama kapasitesini aşmadan hizmeti kullanımınızı optimize eder.

API'lerinizin, katmanlı alım hizmetlerinin izin verdiğinden daha hızlı istek işleyebildiği senaryolarda, hizmeti ne hızda kullanmanız gerektiğini yönetmeniz gerekir. Azaltmayı yalnızca veri hızı uyumsuzluğu olarak ele almak ve hizmet kurtarana kadar alma isteklerini geçici olarak arabelleğe almak risk taşır. Uygulamanız bu senaryoda yanıt vermeyi durdurursa arabelleğe alınan veriler kaybolabilir.

Bu riski önlemek için, kayıtlarınızı tam veri alım hızınızı işleyebilen dayanıklı bir mesajlaşma sistemine göndermeyi değerlendirin. (Azure Event Hubs gibi hizmetler saniyede milyonlarca işlemi işleyebilir.) Daha sonra bir veya daha fazla iş işlemcisi kullanarak, azaltılan hizmetin sınırları dahilindeki denetimli bir hızda mesajlaşma sisteminden kayıtları okuyabilirsiniz. Kayıtları mesajlaşma sistemine göndermek, yalnızca belirli bir zaman aralığında işlenebilen kayıtların sırasını kaldırmanıza olanak tanıyarak dahili bellek tasarrufu sağlayabilir.

Azure, aşağıdakiler dahil olmak üzere bu desenle kullanabileceğiniz çeşitli dayanıklı mesajlaşma hizmetleri sağlar:

• Azure Service Bus
• Azure Kuyruk Depolama
• Etkinlik Merkezleri

Akış, kullanıcının bir API bileşenine 10.000 iletiden oluşan bir toplu iş göndermesiyle başlar. API tüm iletileri dayanıklı bir mesajlaşma hizmeti bileşenine iletir. Dayanıklı mesajlaşma hizmetinden üç ayrı akış, üç iş işlemcisi bileşenine yol açar. Her akış x100 / sn olarak etiketlenir ve bu, her iş işlemcisinin iletileri saniyede 100 denetimli bir hızda sıraladığını gösterir. Üç işleyici bileşeninin tümü, hızı sınırlandırılmış bir hizmet bileşenine bağlanır. "Hızı saniyede 300 kayıtla sınırlandırıldı" olarak etiketlenen hizmet, üç işlemcinin toplam çıktısına eşittir.

Kayıtları gönderdiğinizde, kayıtları yayımlamak için kullandığınız zaman aralığı, hizmetin kısıtlamayı uyguladığı zaman aralığından daha ayrıntılı olabilir. Sistemler genellikle kolayca kavrayabileceğiniz ve çalışabileceğiniz zaman aralığına göre kısıtlar ayarlar. Ancak, bir hizmeti çalıştıran bilgisayar için bu zaman çerçeveleri, bilgileri ne kadar hızlı işleyebileceğinden çok uzun olabilir. Örneğin, bir sistem saniye veya dakika başına hız sınırlaması uygulayabilir, ancak genellikle kod nanosaniye ya da milisaniye mertebesinde çalışır.

Gerekli olmasa da, aktarım hızını artırmak için daha az sayıda kaydın daha sık gönderilmesi önerilir. Bu nedenle, bir yayının kayıtlarını saniyede veya dakikada bir kez toplu işlemeye çalışmak yerine, kaynak tüketiminizin (bellek, CPU ve ağ) daha eşit bir hızda akmasını sağlamak için bundan daha ayrıntılı olabilirsiniz. Bu yaklaşım, ani istek artışlarından kaynaklanan olası performans sorunlarını önler. Örneğin, bir hizmet saniyede 100 işlem yapılmasına izin veriyorsa, hız sınırlayıcının uygulanması, aşağıdaki grafikte gösterildiği gibi, her 200 milisaniyede 20 işlem gerçekleştirilmesiyle istekleri dengeleyebilir.

Grafiğin başlığı Hız Sınırlamalı Akış. X ekseninde 0,0 ile 4,0 arası bir zaman damgasına karşı 0 ile 25 arası y eksenindeki işlem sayısını çizer. Zaman damgası 0,0 ile 0,2 arasındaki işlem sayısı 0'dır ve bu da hiçbir işlem gönderilmediğini gösterir. 0,2 ile 0,4 arasında eğri, hız sınırlayıcının yapılandırılmış üst sınırına ulaştığını gösteren 20 değerine dik bir şekilde yükselir. Zaman damgası 3.0 olduğunda, çizgi keskin bir şekilde 0'a geri düşer ve bu da işin tamamlandığını veya hız sınırlayıcının kayıtları yayımlamayı durdurduğunu gösterir. 3.2 ile 3.8 arasında değer 0'da kalır. 0,4 ile 3,0 arasındaki düz plato grafiğin temel özelliğidir. Hız sınırlamanın, sorunlu bir hatada yeniden deneme yaklaşımıyla ilişkili ani artışlar ve düşüşler yerine tutarlı, öngörülebilir bir aktarım hızı ürettiğini gösterir.

Ayrıca, bazen birden çok koordine edilmemiş işlemin kısıtlanmış bir hizmeti paylaşması gerekir. Bu senaryoda hız sınırlaması uygulamak için hizmetin kapasitesini mantıksal olarak bölümleyebilir ve ardından dağıtılmış bir karşılıklı dışlama sistemi kullanarak bu bölümlerdeki özel kullanım kilitlerini yönetebilirsiniz. Daha sonra koordine edilmemiş işlemler, kapasiteye ihtiyaç duyduklarında bu bölümlerdeki kilitler için rekabet edebilir. Bir işlemin kilit tuttuğu her bölüm için belirli bir kapasite tahsis edilir.

Örneğin, hızı sınırlanmış sistem saniyede 500 isteğe izin veriyorsa, her biri saniyede 25 istek olacak şekilde 20 bölüm oluşturabilirsiniz. Bir işlemin 100 istekte bulunması gerekiyorsa, dağıtılmış karşılıklı dışlama sisteminden dört bölme isteyebilir. Sistem 10 saniye boyunca iki bölüm verebilir. İşlem daha sonra sınırı saniyede 50 istekle derecelendirecek, görevi iki saniye içinde tamamlayacak ve ardından kilidi serbest bırakacaktı.

Bu düzeni uygulamanın bir yolu Azure Depolama kullanmaktır. Bu senaryoda, bir kapsayıcıda mantıksal bölüm başına bir 0 baytlık blob oluşturursunuz. Uygulamalarınız daha sonra kısa bir süre için (örneğin 15 saniye) bu bloblar üzerinde doğrudan özel kiralama alabilir. Bir uygulamaya verilen her kiralama için söz konusu bölümün kapasite miktarını kullanabilir. Daha sonra uygulamanın kira süresini izlemesi gerekir, böylece süre dolduğunda uygulama kendisine verilen kapasiteyi kullanmayı durdurabilir. Bu düzeni uyguladığınızda, genellikle her işlemin kapasiteye ihtiyaç duyduğunda rastgele bir bölüm kiralamayı denemesini istersiniz.

Gecikme süresini daha da azaltmak için her işlem için az miktarda özel kapasite ayırabilirsiniz. Bu durumda bir işlem, yalnızca ayrılmış kapasitesini aşması gerektiğinde paylaşılan kapasite için kiralama almaya çalışır.

Diyagram, Blob Depolama'da depolanan numaralandırılmış altı blob bölümü üzerinde münhasır kiralamalar için yarışan dört işlemi göstermektedir. Dört işlem A, B, C ve D olarak etiketlenir. Blob Depolama 0 ile 5 arasında numaralandırılmış altı blob bölümü içerir. A işleminden çıkan yeşil bir ok, bölüm 0'ı işaret eder ve kiralamanın başarıyla alındığını gösterir. Kırmızı ok, A işleminden bölüm 1'e işaret ederek başarısız bir kiralama girişimi olduğunu gösterir, çünkü başka bir işlem zaten bu bölümü barındırır. D işleminden çıkan bir yeşil ok, bölüm 1'i işaret eder; bu da D işleminin o bölümün lease'ine sahip olduğunu gösterir. Bu nedenle, A işleminin 1 numaralı partisyona yönelik denemesi başarısız oldu. D işleminden 4. bölüme uzanan ikinci bir yeşil ok, D işleminin elinde bulunan ikinci kiralamaya işaret eder. B ve C işlemleriyle ilişkili hiçbir ok yoktur, çünkü kiralamaya sahip değildirler. 2, 3 ve 5 numaralı bölüntüler de kiralanmamış durumda.

Azure Depolama’a alternatif olarak, ZooKeeper, etcd ve Redis/Redsync gibi teknolojileri kullanarak bu tür bir kiralama yönetimi sistemini de uygulayabilirsiniz.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Hız Sınırlama düzeni azaltma hatalarının sayısını azaltabilir ancak uygulamanızın yine de oluşabilecek azaltma hatalarını düzgün bir şekilde işlemesi gerekir.

• Yeniden denemelerin hız sınırlama ile eşgüdümlü olduğundan emin olun. Bilinçsizce veya aşırı agresif yeniden denemeler yükü artırabilir ve yeniden deneme fırtınalarına yol açabilir; bu nedenle geri basınç sinyallerini (örneğin, HTTP 429 ve Retry-After gibi) iletin ve denemeler arasında küçük rastgele gecikmeler bırakarak sınırlı sayıda yeniden deneme kullanın.

• Uygulamanızın aynı kısıtlanmış hizmete erişen birden çok iş akışı varsa, bunların tümünü hız sınırlama stratejinizle tümleştirmeniz gerekir. Örneğin, kayıtların bir veritabanına toplu yüklenmesini destekleyerek aynı veritabanındaki kayıtları sorgulamayı da destekleyebilirsiniz. Tüm iş akışlarının aynı hız sınırlama mekanizması üzerinden geçitli olduğundan emin olarak kapasiteyi yönetebilirsiniz. Alternatif olarak, her iş akışı için ayrı kapasite havuzları ayırabilirsiniz.

• Kısıtlanan hizmet birden çok uygulamada kullanılabilir. Bazı durumlarda, bu kullanımı koordine etmek mümkündür (bu makalenin önceki bölümlerinde gösterildiği gibi). Beklenenden daha fazla sayıda kısıtlama hatası görmeye başlarsanız, bu artış hizmete erişen uygulamalar arasında kaynak çekişmesi olduğunu gösterebilir. Bu durumda, diğer uygulamalardan gelen kullanım azalıncaya kadar hız sınırlama mekanizmanız tarafından uygulanan aktarım hızını geçici olarak azaltmayı göz önünde bulundurmanız gerekebilir.

Bu desen ne zaman kullanılır?

Bu düzeni aşağıdaki durumlarda kullanın:

• İstek hızı sınırlandırılmış bir hizmetin oluşturduğu kısıtlama hatalarını azaltmanız gerekir.

• Basit hata durumunda yeniden deneme yaklaşımlarıyla karşılaştırıldığında, trafiği en aza indirmek istersiniz.

• Yalnızca bunları işlemek için yeterli kapasite olduğunda kayıtların sorgularını kaldırarak bellek tüketimini azaltmanız gerekir.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

• İşlem, çok düşük gecikme süresiyle anında, zaman uyumlu tamamlama gerektirir ve kuyruğa alma veya ertelenmiş işlemeyi tolere edemez.

• Birincil performans sorunu istek oranı değildir, ancak bunun yerine eşzamanlılık veya kaynak çekişmesidir (örneğin, CPU doygunluğu veya uzun süre çalışan uçuş içi çalışma). Bu gibi durumlarda ölçeklendirme veya eşzamanlılık denetimleri daha uygundur.

İş yükü tasarımı

Azure Well-Architected Framework yapılarında ele alınan hedefleri ve ilkeleri ele almak için iş yükünün tasarımında Hız Sınırlama deseninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Temel	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur.	Bu taktik, hizmet aşırı kullanımdan kaçınmayı tercih ettiğinde, bir hizmetle iletişim kurmanın sınırlamalarını ve maliyetlerini gözetip bunlara saygı duyarak istemciyi korur. - RE:07 Kendini koruma

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

Aşağıdaki örnek uygulama, kullanıcıların bir API'ye çeşitli türlerdeki kayıtları göndermesine olanak tanır. Her kayıt türünün aşağıdaki adımları gerçekleştiren benzersiz bir iş işlemcisi vardır:

1. Doğrulama
2. Zenginleşme
3. Kaydın veritabanına eklenmesi

Uygulamanın tüm bileşenleri (API, iş işlemcisi A ve iş işlemcisi B), bağımsız olarak ölçeklendirilebilen ayrı işlemlerdir. İşlemler birbiriyle doğrudan iletişim kurmaz.

Diyagramda, paylaşılan API aracılığıyla kayıt gönderen iki kullanıcı gösterilmektedir. Her kayıt türü ayrı bir kuyruğa yönlendirilir, ayrılmış bir iş işlemcisi tarafından işlenir ve Azure Depolama blob bölüm kiralamaları tarafından yönetilen denetimli bir hızda kısıtlanmış bir veritabanına yazılır. İki kullanıcının her biri API bileşenine bir toplu ileti gönderir. Bir kullanıcı 10.000 ileti gönderirken diğeri 5.000 ileti gönderir. API, 10.000 iletiyi A kuyruğuna, 5.000 iletiyi de B kuyruğuna yönlendirir. A Kuyruğu A iş işlemcisine, B kuyruğu ise iş işlemcisi B'ye bağlanır. İş işlemcisi A veritabanına saniyede 300 kayıt hızında yazar. İş işlemcisi B, veritabanına saniyede 500 kayıt yazar. Her iki işlem işleyicisi de "saniyede 800 kayıtla sınırlandırılmış" olarak etiketlenmiş bir veritabanı bileşenine bağlanır. İki iş işlemcisinin altında, Azure Depolama 0 ile 7 arasında etiketlenmiş sekiz blob bölümü içerir. Bir notta, her bölümün saniyede 100 kayıtlık bir kapasiteye sahip olduğu belirtilir. Birden çok ok, iş işlemcilerini blob bölümlerine bağlar. Yeşil oklar, A işlemcisinden 0, 4 ve 6 bölümlerine uzanır; bu da işlemcinin bu üç bölümün kiralamalarını elinde bulundurduğunu gösterir. Bu kiralamalar, saniye başına 300 kayıt oranını hesaba ekler. Yeşil oklar B iş işlemcisinden 1, 2, 3, 5 ve 7 bölümlerine işaret eder. Bu oklar, bu işlemcinin beş bölüm üzerinde lease'lere sahip olduğunu gösterir. Bu kiralamalar, saniye başına 500 kayıt oranını hesaba ekler. Başarısız kiralama girişimleri, diğer işlemci tarafından zaten tutulan bölümlerin üzerine uzanan kırmızı oklar olarak gösterilir. Bu oklar çekişme çözümlemesini temsil eder. Diyagram, her iki işlemcide tutulan tüm bölümlerin toplamının saniyede 800 kayda eşit olduğunu gösterir ve bu da veritabanı kısıtlama sınırıyla eşleşir.

Bu örnekte, her blob kiralaması izin verilen veritabanı aktarım hızının sabit bir paylaşımını temsil eder. Bir işlemci yalnızca şu anda sahip olduğu kiralamaların toplam hızıyla kuyruktan çıkarabilir ve yazabilir. İşlemciler zaman içinde kiralama hakları kazandıkça veya kaybettikçe, izin verilen yazma hızları değişir; bu da toplam veritabanı trafiğini yapılandırılmış sınır içinde tutarken kuyruktaki tüm işlerin ilerlemesini sağlar.

Bu diyagram aşağıdaki iş akışını içerir:

1. Kullanıcı API'ye A türünde 10.000 kayıt gönderir.
2. API, A kuyruğundaki bu 10.000 kaydı sıralar.
3. Kullanıcı API'ye B türünde 5.000 kayıt gönderir.
4. API bu 5.000 kaydı B kuyruğunda sıralar.
5. Görev işlemcisi A, A kuyruğunda kayıtlar olduğunu görür ve blob 2 üzerinde özel bir kiralama almaya çalışır.
6. İş işlemcisi B, B kuyruğunda kayıtların olduğunu görür ve blob 2'de özel kiralama elde etmeye çalışır.
7. A iş işlemcisi kirayı alamaz.
8. İş işlemcisi B, blob 2 için kiralamayı 15 saniyeliğine alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
9. İş işlemcisi B, B kuyruğundan 100 kaydı sıralar ve yazar.
10. Bir saniye geçti.
11. Görev işlemcisi A, A kuyruğunda daha fazla kayıt olduğunu görür ve 6 numaralı blob üzerinde münhasır bir kiralama almaya çalışır.
12. Görev işlemcisi B, B kuyruğunda daha fazla kayıt bulunduğunu görür ve blob 3 üzerinde özel bir kiralama almaya çalışır.
13. Görev işlemcisi A, blob 6’nın kiralamasını 15 saniyeliğine alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
14. İş işlemcisi B, blob 3'te kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 200 oranında derecelendirebilir. (Ayrıca blob 2’nin kiralama sözleşmesini de elinde tutar.)
15. İş işlemcisi A, A kuyruğundan 100 kaydı sıralar ve bunları yazar.
16. İş işlemcisi B, B kuyruğundan 200 kaydı sıralar ve yazar.
17. Bir saniye geçti.
18. Görev işlemcisi A, A kuyruğunda daha fazla kayıt bulunduğunu görür ve blob 0 üzerinde münhasır bir kiralama almaya çalışır.
19. İş işlemcisi B, B kuyruğunda daha fazla kayıt olduğunu görür ve blob 1'de özel kiralama elde etmeye çalışır.
20. İş işlemcisi A, blob 0 üzerindeki kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 200 oranında derecelendirebilir. (Blob 6’nın lease’ini de elinde tutuyor.)
21. İşlem işleyicisi B, blob 1 üzerinde 15 saniyelik kiralamayı edinir. Artık veritabanına yönelik sınır isteklerini saniyede 300 oranında derecelendirebilir. (Ayrıca 2 ve 3 numaralı blobların kiralama hakkını da elinde bulunduruyor.)
22. İş işlemcisi A, A kuyruğundan 200 kaydı alır ve yazar.
23. İş işlemcisi B, B kuyruğundan 300 kaydı sıralar ve yazar.
24. Ve böyle devam edin.

15 saniye sonra bir veya her iki iş de tamamlanamaz. Kiralamaların süresi doldukça, işlemcinin de sıralayıp yazdığı istek sayısını azaltması gerekir.

Bu desenin uygulamaları farklı programlama dillerinde kullanılabilir:

• GitHub'da Go uygulaması kullanılabilir.
• Java uygulaması GitHub'da kullanılabilir.

Sonraki Adımlar

Bu düzeni uyguladığınızda aşağıdaki yönergeler de uygun olabilir:

• Azure API Management ile gelişmiş istek azaltma. Anahtar başına çağrı hızı sınırlarını ve kotalarını zorunlu kılmak ve istemcilere tutarlı geri basınç sinyalleri döndürmek için bunu tamamlayıcı uç erişim denetimi olarak kullanın.

• Azure mesajlaşma hizmetleri arasında seçim yapın. Tamponlama ve kontrollü veri alımı için en iyi dayanıklı mesajlaşma omurgasını seçin.

• Azure uygulamalarında geçici hataları işleme. Sınırlara ulaşıldığında istemcilerin doğru şekilde geri dönmesi için yeniden deneme davranışını tasarlayın.

İlgili kaynaklar

Bu deseni uyguladığınızda aşağıdaki desenler ve yönergeler de uygun olabilir:

• Throttling. Hız Sınırlama düzeni genellikle kısıtlanmış bir hizmete yanıt olarak uygulanır.

• Retry. İstek hızı sınırlandırılmış bir hizmete yönelik istekler hız sınırlama hatalarıyla sonuçlandığında, genellikle bu istekleri uygun bir süre geçtikten sonra yeniden denemek gerekir.

• Queue-Based Yük Dengeleme , Hız Sınırlama düzenine benzer ancak çeşitli temel yollarla farklılık gösterir:

  • Hız sınırlamanın yükü yönetmek için kuyrukları kullanması gerekmez, ancak dayanıklı bir mesajlaşma hizmetinden yararlanması gerekir. Örneğin, Hız Sınırlama düzeni Apache Kafka veya Event Hubs gibi hizmetleri kullanabilir.

  • Hız Sınırlama deseni, bölümler arasında dağıtık bir karşılıklı dışlama sistemi kavramını ortaya koyar; bu da hız sınırlaması uygulanan aynı hizmetle iletişim kuran, birbiriyle koordine olmayan birden çok sürecin kapasitesini yönetmenize olanak tanır.

  • Hizmetler arasında performans uyuşmazlığı olduğunda veya dayanıklılığı geliştirmek istediğinizde Queue-Based Yük Dengeleme düzeni uygulanabilir. Bu nedenle, özellikle kısıtlanmış bir hizmete verimli bir şekilde erişmeyle ilgili olan Hız Sınırlama'dan daha geniş bir desendir.