Hız Sınırlama düzeni

Azure Service Bus

Azure Kuyruk Depolama

Azure Event Hubs

Birçok hizmet, kullandıkları kaynakları denetlemek için azaltma deseni kullanır ve diğer uygulama veya hizmetlerin bunlara erişim hızına sınırlamalar uygular. Bu azaltma sınırlarıyla ilgili azaltma hatalarını önlemenize veya en aza indirmenize yardımcı olmak ve aktarım hızını daha doğru tahmin etmenize yardımcı olmak için hız sınırlama deseni kullanabilirsiniz.

Hız sınırlama düzeni 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 hizmet kullanarak çok sayıda işlem gerçekleştirmek trafiğin ve aktarım hızının artmasına neden olabilir çünkü hem reddedilen istekleri izlemeniz hem de ardından bu işlemleri yeniden denemeniz gerekir. İşlem sayısı arttıkça, kısıtlama sınırı verilerin birden çok kez yeniden gönderilmesini gerektirebilir ve bu da performans üzerinde daha büyük bir etkide bulunabilir.

Örnek olarak, Azure Cosmos DB'ye veri almak için hata işleminde aşağıdaki basit yeniden denemeyi göz önünde bulundurun:

1. Uygulamanızın Azure Cosmos DB'ye 10.000 kayıt alması gerekiyor. Her kaydın alımı 10 İstek Birimine (RU) mal olur ve 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ılır.

Veri kümesinin tamamı yalnızca 10.000 kayıttan oluşsa bile alma işi başarıyla tamamlandı, ancak yalnızca Azure Cosmos DB'ye 30.000 kayıt gönderildikten sonra.

Yukarıdaki örnekte dikkate alınması gereken ek faktörler 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. Bu basit yaklaşım 20.000 hatayı işleyecek ve bu hataları günlüğe kaydetmek, işlem, bellek veya depolama kaynaklarında maliyete yol açabilir.
• Alım hizmetinin azaltma sınırlarını bilmemek, saf yaklaşımın veri işlemenin ne kadar süreceğine ilişkin beklentileri belirlemenin hiçbir yolu yoktur. Hız sınırlaması, alım için gereken süreyi hesaplamanıza olanak sağlayabilir.

Solution

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 zaman içinde farklı ölçümlere göre kısıtlama yapabilir, ö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).

Azaltma için kullanılan ölçümden bağımsız olarak hız sınırlama uygulamanız, belirli bir süre boyunca hizmete gönderilen işlemlerin sayısını ve/veya boyutunu denetlemeyi, azaltma kapasitesini aşmadan hizmet kullanımınızı iyileştirmeyi içerir.

API'lerinizin istekleri kısıtlanmış alım hizmetlerinden daha hızlı işleyebildiği senaryolarda, hizmeti ne kadar hızlı kullanabileceğinizi yönetmeniz gerekir. Ancak, azaltmayı yalnızca veri hızı uyuşmazlığı sorunu olarak ele almak ve kısıtlanan hizmet yetişene kadar alım isteklerinizi arabelleğe almak risklidir. Uygulamanız bu senaryoda kilitleniyorsa, arabelleğe alınan bu verilerden herhangi birini kaybetme riskiyle karşılaşırsınız.

Bu riski önlemek için, kayıtlarınızı tam alım oranınızı işleyebilen dayanıklı bir mesajlaşma sistemine göndermeyi göz önünde bulundurun. (Azure Event Hubs gibi hizmetler saniyede milyonlarca işlemi işleyebilir. Daha sonra bir veya daha fazla iş işlemcisi kullanarak, kısıtlanan hizmetin sınırları içinde bulunan 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
• Azure Event Hubs

Kayıtları gönderirken, kayıtları serbest bırakmak için kullandığınız zaman aralığı, hizmetin sınırlama süresinden daha ayrıntılı olabilir. Sistemler genellikle kolayca kavrayabileceğiniz ve çalışabileceğiniz zaman aralığına göre kısıtlama 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 başına veya dakika başına azaltma gerçekleştirebilir, ancak genellikle kod nanosaniye veya milisaniye sırasına göre işlenir.

Gerekli olmasa da, aktarım hızını artırmak için daha az miktarda kaydın daha sık gönderilmesi önerilir. Bu nedenle, bir yayın için işleri saniyede veya dakikada bir kez toplu hale getirmeye çalışmak yerine, kaynak tüketiminizin (bellek, CPU ve ağ) daha eşit bir hızda akmasını sağlamak ve ani istek artışlarından kaynaklanan olası performans sorunlarını önlemek için daha ayrıntılı olabilirsiniz. Ö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.

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 kilitlendiği her bölüm için belirli bir kapasite miktarı verilir.

Örneğin, azaltılan sistem saniyede 500 isteke izin veriyorsa, saniyede 25 istek değerinde 20 bölüm oluşturabilirsiniz. Bir işlemin 100 istek göndermesi gerekiyorsa, dağıtılmış karşılıklı dışlama sisteminden dört bölüm 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'yı 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 boyunca (örneğin, 15 saniye) doğrudan bu bloblara özel kiralar alabilir. Bir uygulamaya verilen her kiralama için söz konusu bölümün kapasite değerini kullanabilir. Daha sonra uygulamanın kira süresini izlemesi gerekir, böylece süresi dolduğunda verilen kapasiteyi kullanmayı durdurabilir. Bu düzeni uygularken 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ı gerekiyorsa paylaşılan kapasitede kiralama elde etmeye çalışır.

Azure Depolama'ya alternatif olarak Zookeeper, Konsolos vb. redis/Redsync gibi teknolojileri kullanarak da bu tür bir kira yönetim sistemi uygulayabilirsiniz.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacaklarına karar verirken aşağıdakileri göz önünde bulundurun:

• Hız sınırlama deseni 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.
• 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çişini sağlayarak 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 (ancak tümü değil) bu kullanımı koordine etmek mümkündür (yukarıda gösterildiği gibi). Beklenenden daha fazla sayıda kısıtlama hatası görmeye başlarsanız, bu bir hizmete erişen uygulamalar arasında bir çekişme işareti olabilir. Bu durumda, diğer uygulamalardan gelen kullanım azaltılana 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 düzenin kullanılacağı durumlar

Bu düzeni kullanarak:

• Kısıtlama sınırlı bir hizmet tarafından ortaya çıkarılan azaltma hatalarını azaltın.
• Hata yaklaşımında basit bir yeniden denemeyle karşılaştırıldığında trafiği azaltın.
• Yalnızca bunları işlemek için kapasite olduğunda kayıtların sorgularını kaldırarak bellek tüketimini azaltın.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için İş yükünün tasarımında Hız Sınırlama düzeninin nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Pillar	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya yardımcı olur.	Bu taktik, hizmet aşırı kullanımdan kaçınmak istediğinde bir hizmetle iletişim kurmanın sınırlamalarını ve maliyetlerini kabul ederek ve kabul ederek istemciyi korur. - RE:07 Kendini koruma

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

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ü için aşağıdaki adımları gerçekleştiren benzersiz bir iş işlemcisi vardır:

1. Validation
2. Enrichment
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.

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ğunda 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ı Kuyruk B'de sıralar.
5. İş İşlemcisi A, Kuyruk A'nın kayıtları olduğunu görür ve blob 2'de özel kira elde etmeye çalışır.
6. İş İşlemcisi B, Kuyruk B'nin kayıtları olduğunu görür ve blob 2'de özel kira kazanmaya çalışır.
7. İş İşlemcisi A kirayı alamaz.
8. İş İşlemcisi B, blob 2'de kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
9. İş İşlemcisi B, 100 kaydı Kuyruk B'den kaldırır ve yazar.
10. Bir saniye geçti.
11. İş İşlemcisi A, Kuyruk A'nın daha fazla kaydı olduğunu görür ve blob 6'da özel kira elde etmeye çalışır.
12. İş İşlemcisi B, Kuyruk B'nin daha fazla kaydı olduğunu görür ve blob 3'te özel kiralama elde etmeye çalışır.
13. İş İşlemcisi A, blob 6'da kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
14. İş İş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. (Blob 2 için kirayı da barındırıyor.)
15. İş İşlemcisi A, Kuyruk A'dan 100 kaydın sırasını kaldırır ve bunları yazar.
16. İş İşlemcisi B, 200 kaydı Kuyruk B'den kaldırır ve yazar.
17. Bir saniye geçti.
18. İş İşlemcisi A, Kuyruk A'nın daha fazla kaydı olduğunu görür ve blob 0'da özel kira elde etmeye çalışır.
19. İş İşlemcisi B, Kuyruk B'nin daha fazla kaydı olduğunu görür ve blob 1'de özel kiralama elde etmeye çalışır.
20. İş İş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 için kirayı da barındırıyor.)
21. İş İşlemcisi B, blob 1'de kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 300 oranında derecelendirebilir. (Ayrıca 2 ve 3 bloblarının kirasını da barındırıyor.)
22. İş İşlemcisi A, 200 kaydı Kuyruk A'dan kaldırır ve yazar.
23. İş İşlemcisi B, 300 kaydı Kuyruk B'den kaldırır ve yazar.
24. Ve benzeri...

15 saniye sonra, bir veya iki iş yine de tamamlanmaz. 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.

İlgili kaynaklar

Bu düzen uygulanırken aşağıdaki düzenler ve yönergeler de yararlı olabilir:

• Throttling. Burada açıklanan hız sınırlama düzeni genellikle kısıtlanmış bir hizmete yanıt olarak uygulanır.
• Retry. Azaltılan hizmete yönelik istekler azaltma hatalarına neden olduğunda, bunları uygun bir aralıkta yeniden denemek genellikle uygundur.

Kuyruk Tabanlı Yük Dengeleme benzerdir ancak Hız Sınırlama düzeninden birkaç temel yolla farklıdır:

1. 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 Azure Event Hubs gibi hizmetlerden yararlanabilir.
2. Hız sınırlama düzeni, bölümler üzerinde dağıtılmış bir karşılıklı dışlama sistemi kavramını ortaya çıkararak, aynı kısıtlanmış hizmetle iletişim kuran birden çok sıralanmamış işlem için kapasiteyi yönetmenize olanak tanır.
3. Kuyruk tabanlı yük dengeleme düzeni, hizmetler arasında performans uyuşmazlığı olduğunda veya dayanıklılığı artırmak için geçerlidir. Bu, özellikle kısıtlanmış bir hizmete verimli bir şekilde erişmeyle ilgili olan hız sınırlamasından daha geniş bir desen olmasını sağlar.

Birçok hizmet, kullandıkları kaynakları denetlemek için azaltma deseni kullanır ve diğer uygulama veya hizmetlerin bunlara erişim hızına sınırlamalar uygular. Bu azaltma sınırlarıyla ilgili azaltma hatalarını önlemenize veya en aza indirmenize yardımcı olmak ve aktarım hızını daha doğru tahmin etmenize yardımcı olmak için hız sınırlama deseni kullanabilirsiniz.

Hız sınırlama düzeni 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 hizmet kullanarak çok sayıda işlem gerçekleştirmek trafiğin ve aktarım hızının artmasına neden olabilir çünkü hem reddedilen istekleri izlemeniz hem de ardından bu işlemleri yeniden denemeniz gerekir. İşlem sayısı arttıkça, kısıtlama sınırı verilerin birden çok kez yeniden gönderilmesini gerektirebilir ve bu da performans üzerinde daha büyük bir etkide bulunabilir.

Örnek olarak, Azure Cosmos DB'ye veri almak için hata işleminde aşağıdaki basit yeniden denemeyi göz önünde bulundurun:

1. Uygulamanızın Azure Cosmos DB'ye 10.000 kayıt alması gerekiyor. Her kaydın alımı 10 İstek Birimine (RU) mal olur ve 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ılır.

Veri kümesinin tamamı yalnızca 10.000 kayıttan oluşsa bile alma işi başarıyla tamamlandı, ancak yalnızca Azure Cosmos DB'ye 30.000 kayıt gönderildikten sonra.

Yukarıdaki örnekte dikkate alınması gereken ek faktörler 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. Bu basit yaklaşım 20.000 hatayı işleyecek ve bu hataları günlüğe kaydetmek, işlem, bellek veya depolama kaynaklarında maliyete yol açabilir.
• Alım hizmetinin azaltma sınırlarını bilmemek, saf yaklaşımın veri işlemenin ne kadar süreceğine ilişkin beklentileri belirlemenin hiçbir yolu yoktur. Hız sınırlaması, alım için gereken süreyi hesaplamanıza olanak sağlayabilir.

Solution

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 zaman içinde farklı ölçümlere göre kısıtlama yapabilir, ö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).

Azaltma için kullanılan ölçümden bağımsız olarak hız sınırlama uygulamanız, belirli bir süre boyunca hizmete gönderilen işlemlerin sayısını ve/veya boyutunu denetlemeyi, azaltma kapasitesini aşmadan hizmet kullanımınızı iyileştirmeyi içerir.

API'lerinizin istekleri kısıtlanmış alım hizmetlerinden daha hızlı işleyebildiği senaryolarda, hizmeti ne kadar hızlı kullanabileceğinizi yönetmeniz gerekir. Ancak, azaltmayı yalnızca veri hızı uyuşmazlığı sorunu olarak ele almak ve kısıtlanan hizmet yetişene kadar alım isteklerinizi arabelleğe almak risklidir. Uygulamanız bu senaryoda kilitleniyorsa, arabelleğe alınan bu verilerden herhangi birini kaybetme riskiyle karşılaşırsınız.

Bu riski önlemek için, kayıtlarınızı tam alım oranınızı işleyebilen dayanıklı bir mesajlaşma sistemine göndermeyi göz önünde bulundurun. (Azure Event Hubs gibi hizmetler saniyede milyonlarca işlemi işleyebilir. Daha sonra bir veya daha fazla iş işlemcisi kullanarak, kısıtlanan hizmetin sınırları içinde bulunan 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
• Azure Event Hubs

Kayıtları gönderirken, kayıtları serbest bırakmak için kullandığınız zaman aralığı, hizmetin sınırlama süresinden daha ayrıntılı olabilir. Sistemler genellikle kolayca kavrayabileceğiniz ve çalışabileceğiniz zaman aralığına göre kısıtlama 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 başına veya dakika başına azaltma gerçekleştirebilir, ancak genellikle kod nanosaniye veya milisaniye sırasına göre işlenir.

Gerekli olmasa da, aktarım hızını artırmak için daha az miktarda kaydın daha sık gönderilmesi önerilir. Bu nedenle, bir yayın için işleri saniyede veya dakikada bir kez toplu hale getirmeye çalışmak yerine, kaynak tüketiminizin (bellek, CPU ve ağ) daha eşit bir hızda akmasını sağlamak ve ani istek artışlarından kaynaklanan olası performans sorunlarını önlemek için daha ayrıntılı olabilirsiniz. Ö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.

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 kilitlendiği her bölüm için belirli bir kapasite miktarı verilir.

Örneğin, azaltılan sistem saniyede 500 isteke izin veriyorsa, saniyede 25 istek değerinde 20 bölüm oluşturabilirsiniz. Bir işlemin 100 istek göndermesi gerekiyorsa, dağıtılmış karşılıklı dışlama sisteminden dört bölüm 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'yı 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 boyunca (örneğin, 15 saniye) doğrudan bu bloblara özel kiralar alabilir. Bir uygulamaya verilen her kiralama için söz konusu bölümün kapasite değerini kullanabilir. Daha sonra uygulamanın kira süresini izlemesi gerekir, böylece süresi dolduğunda verilen kapasiteyi kullanmayı durdurabilir. Bu düzeni uygularken 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ı gerekiyorsa paylaşılan kapasitede kiralama elde etmeye çalışır.

Azure Depolama'ya alternatif olarak Zookeeper, Konsolos vb. redis/Redsync gibi teknolojileri kullanarak da bu tür bir kira yönetim sistemi uygulayabilirsiniz.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacaklarına karar verirken aşağıdakileri göz önünde bulundurun:

• Hız sınırlama deseni 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.
• 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çişini sağlayarak 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 (ancak tümü değil) bu kullanımı koordine etmek mümkündür (yukarıda gösterildiği gibi). Beklenenden daha fazla sayıda kısıtlama hatası görmeye başlarsanız, bu bir hizmete erişen uygulamalar arasında bir çekişme işareti olabilir. Bu durumda, diğer uygulamalardan gelen kullanım azaltılana 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 düzenin kullanılacağı durumlar

Bu düzeni kullanarak:

• Kısıtlama sınırlı bir hizmet tarafından ortaya çıkarılan azaltma hatalarını azaltın.
• Hata yaklaşımında basit bir yeniden denemeyle karşılaştırıldığında trafiği azaltın.
• Yalnızca bunları işlemek için kapasite olduğunda kayıtların sorgularını kaldırarak bellek tüketimini azaltın.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için İş yükünün tasarımında Hız Sınırlama düzeninin nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Pillar	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya yardımcı olur.	Bu taktik, hizmet aşırı kullanımdan kaçınmak istediğinde bir hizmetle iletişim kurmanın sınırlamalarını ve maliyetlerini kabul ederek ve kabul ederek istemciyi korur. - RE:07 Kendini koruma

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

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ü için aşağıdaki adımları gerçekleştiren benzersiz bir iş işlemcisi vardır:

1. Validation
2. Enrichment
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.

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ğunda 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ı Kuyruk B'de sıralar.
5. İş İşlemcisi A, Kuyruk A'nın kayıtları olduğunu görür ve blob 2'de özel kira elde etmeye çalışır.
6. İş İşlemcisi B, Kuyruk B'nin kayıtları olduğunu görür ve blob 2'de özel kira kazanmaya çalışır.
7. İş İşlemcisi A kirayı alamaz.
8. İş İşlemcisi B, blob 2'de kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
9. İş İşlemcisi B, 100 kaydı Kuyruk B'den kaldırır ve yazar.
10. Bir saniye geçti.
11. İş İşlemcisi A, Kuyruk A'nın daha fazla kaydı olduğunu görür ve blob 6'da özel kira elde etmeye çalışır.
12. İş İşlemcisi B, Kuyruk B'nin daha fazla kaydı olduğunu görür ve blob 3'te özel kiralama elde etmeye çalışır.
13. İş İşlemcisi A, blob 6'da kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 100 oranında derecelendirebilir.
14. İş İş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. (Blob 2 için kirayı da barındırıyor.)
15. İş İşlemcisi A, Kuyruk A'dan 100 kaydın sırasını kaldırır ve bunları yazar.
16. İş İşlemcisi B, 200 kaydı Kuyruk B'den kaldırır ve yazar.
17. Bir saniye geçti.
18. İş İşlemcisi A, Kuyruk A'nın daha fazla kaydı olduğunu görür ve blob 0'da özel kira elde etmeye çalışır.
19. İş İşlemcisi B, Kuyruk B'nin daha fazla kaydı olduğunu görür ve blob 1'de özel kiralama elde etmeye çalışır.
20. İş İş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 için kirayı da barındırıyor.)
21. İş İşlemcisi B, blob 1'de kirayı 15 saniye boyunca alır. Artık veritabanına yönelik sınır isteklerini saniyede 300 oranında derecelendirebilir. (Ayrıca 2 ve 3 bloblarının kirasını da barındırıyor.)
22. İş İşlemcisi A, 200 kaydı Kuyruk A'dan kaldırır ve yazar.
23. İş İşlemcisi B, 300 kaydı Kuyruk B'den kaldırır ve yazar.
24. Ve benzeri...

15 saniye sonra, bir veya iki iş yine de tamamlanmaz. 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.

İlgili kaynaklar

Bu düzen uygulanırken aşağıdaki düzenler ve yönergeler de yararlı olabilir:

• Throttling. Burada açıklanan hız sınırlama düzeni genellikle kısıtlanmış bir hizmete yanıt olarak uygulanır.
• Retry. Azaltılan hizmete yönelik istekler azaltma hatalarına neden olduğunda, bunları uygun bir aralıkta yeniden denemek genellikle uygundur.

Kuyruk Tabanlı Yük Dengeleme benzerdir ancak Hız Sınırlama düzeninden birkaç temel yolla farklıdır:

1. 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 Azure Event Hubs gibi hizmetlerden yararlanabilir.
2. Hız sınırlama düzeni, bölümler üzerinde dağıtılmış bir karşılıklı dışlama sistemi kavramını ortaya çıkararak, aynı kısıtlanmış hizmetle iletişim kuran birden çok sıralanmamış işlem için kapasiteyi yönetmenize olanak tanır.
3. Kuyruk tabanlı yük dengeleme düzeni, hizmetler arasında performans uyuşmazlığı olduğunda veya dayanıklılığı artırmak için geçerlidir. Bu, özellikle kısıtlanmış bir hizmete verimli bir şekilde erişmeyle ilgili olan hız sınırlamasından daha geniş bir desen olmasını sağlar.