Geçici hataları işlemeye yönelik öneriler

  • Makale

Bu Azure Well-Architected Framework Güvenilirlik denetim listesi önerisi için geçerlidir:

RE:07 Kendini koruma ve kendini iyileştirici önlemler uygulayarak iş yükünüzün dayanıklılığını ve kurtarılabilirliğini güçlendirin. Bileşen hatalarını ve geçici hataları işlemek için altyapı tabanlı güvenilirlik desenlerini ve yazılım tabanlı tasarım desenlerini kullanarak çözümde özellikler oluşturun. İş yükü tam veya azaltılmış işlevsellikle çalışmaya devam ederken çözüm bileşeni hatalarını algılamak ve otomatik olarak düzeltici eylem başlatmak için sistemde özellikler oluşturun.

İlgili kılavuzlar:Arka plan işleri | Kendini koruma

Bu kılavuzda, bulut uygulamalarınızdaki geçici hataları işlemeye yönelik öneriler açıklanmaktadır. Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara karşı duyarlı olması gerekir. Bu durum özellikle bulutta çalışan uygulamalar için geçerlidir. Ortamın doğası gereği ve İnternet üzerinden bağlantı nedeniyle bu tür hatalarla daha sık karşılaşılabilir. Geçici hatalar arasında bileşenlere ve hizmetlere ağ bağlantısının anlık kaybı, bir hizmetin geçici olarak kullanılamama durumu ve bir hizmet meşgul olduğunda oluşan zaman aşımları yer alır. Bu hatalar genellikle kendi kendine düzeltilir, bu nedenle eylem uygun bir gecikmeden sonra yinelenirse başarılı olma olasılığı yüksektir.

Bu makalede geçici hata işlemeye yönelik genel yönergeler sağlanmaktadır. Geçici hataları işleme hakkında bilgi için yeniden deneme düzenine bakın ve Azure hizmetlerini kullanırken Bkz. Azure hizmetleri için yeniden deneme kılavuzu.

Temel tasarım stratejileri

Geçici hatalar her türlü ortamda, herhangi bir platformda veya işletim sisteminde ve herhangi bir uygulama türünde gerçekleşebilir. Yerel şirket içi altyapıda çalışan çözümler için, uygulamanın ve bileşenlerinin performansı ve kullanılabilirliği genellikle pahalı ve genellikle az kullanılan donanım yedekliliği ile korunur ve bileşenler ve kaynaklar birbirine yakın bir konumda bulunur. Bu yaklaşım hata olasılığını düşürür, ancak geçici hatalar oluşmaya devam edebilir çünkü dış güç kaynağı veya ağ sorunları gibi öngörülemeyen olayların veya olağanüstü durum senaryolarının neden olduğu kesintiler olabilir.

Özel bulut sistemleri de dahil olmak üzere bulut barındırma, birçok ticari işlem düğümünde paylaşılan kaynakları, yedekliliği, otomatik yük devretmeyi ve dinamik kaynak ayırmayı kullanarak daha yüksek genel kullanılabilirlik sunabilir. Ancak bulut ortamlarının doğası gereği geçici hatalar oluşma olasılığı daha yüksektir. Bunun birkaç nedeni vardır:

  • Bulut ortamındaki birçok kaynak paylaşılır ve kaynakları korumak için bu kaynaklara erişim azaltmaya tabidir. Bazı hizmetler, mevcut isteklerin işlenmesine izin vermek ve tüm kullanıcılar için hizmetin performansını korumak amacıyla yük belirli bir düzeye yükseldiğinde veya maksimum aktarım hızına ulaşıldığında bağlantıları reddeder. Azaltma, komşular ve paylaşılan kaynağı kullanan diğer kiracılar için hizmet kalitesinin korunmasına yardımcı olur.

  • Bulut ortamları çok sayıda ticari donanım birimi kullanır. Yükü birden çok bilgi işlem birimine ve altyapı bileşenine dinamik olarak dağıtarak performans sunar. Başarısız birimleri otomatik olarak geri dönüştürerek veya değiştirerek güvenilirlik sağlar. Bu dinamik yapı nedeniyle geçici hatalar ve geçici bağlantı hataları zaman zaman oluşabilir.

  • Genellikle, uygulama ile kullandığı kaynaklar ve hizmetler arasında yönlendiriciler ve yük dengeleyiciler gibi ağ altyapısı gibi daha fazla donanım bileşeni vardır. Bu ek altyapı zaman zaman ek bağlantı gecikme süresi ve geçici bağlantı hataları oluşturabilir.

  • İstemci ile sunucu arasındaki ağ koşulları, özellikle de iletişim İnternet üzerinden geçtiğinde değişken olabilir. Şirket içi konumlarda bile yoğun trafik yükleri iletişimi yavaşlatabilir ve aralıklı bağlantı hatalarına neden olabilir.

Zorluklar

Geçici hatalar, tüm öngörülebilir koşullarda kapsamlı bir şekilde test edilmiş olsa bile uygulamanın algılanan kullanılabilirliği üzerinde önemli bir etkiye sahip olabilir. Bulutta barındırılan uygulamaların güvenilir bir şekilde çalıştığından emin olmak için aşağıdaki zorluklara yanıt vereceklerinden emin olmanız gerekir:

  • Uygulama, oluşan hataları algılayabilmeli ve hataların geçici olma olasılığının yüksek olup olmadığını, uzun süreli mi yoksa terminal hatası mı olduğunu saptayabilmelidir. Bir hata oluştuğunda farklı kaynakların farklı yanıtlar döndürmesi olasıdır ve bu yanıtlar işlemin bağlamlarına bağlı olarak da farklılık gösterebilir. Örneğin, uygulama depolama alanından okurken bir hatanın yanıtı, depolamaya yazarken bir hatanın yanıtından farklı olabilir. Birçok kaynak ve hizmette iyi belgelenmiş geçici hata sözleşmeleri vardır. Ancak, bu tür bilgiler mevcut olmadığında, hatanın doğasını ve geçici olma olasılığını keşfetmek zor olabilir.

  • Hatanın geçici olma olasılığını belirlerse uygulamanın işlemi yeniden deneyebilmesi gerekir. Ayrıca işlemin yeniden denenmesi sayısını da izlemesi gerekir.

  • Uygulamanın yeniden denemeler için uygun bir strateji kullanması gerekir. Strateji, uygulamanın yeniden deneme sayısını, her deneme arasındaki gecikmeyi ve başarısız bir girişimden sonra gerçekleştirilecek eylemleri belirtir. Uygun sayıda deneme ve her biri arasındaki gecikmeyi belirlemek genellikle zordur. Strateji, kaynağın türüne ve kaynağın ve uygulamanın geçerli çalışma koşullarına bağlı olarak değişir.

Genel yönergeler

Aşağıdaki yönergeler, uygulamalarınız için uygun geçici hata işleme mekanizmaları tasarlamanıza yardımcı olabilir.

Yerleşik bir yeniden deneme mekanizması olup olmadığını belirleme

  • Birçok hizmet, geçici hata işleme mekanizması içeren bir SDK ya da istemci kitaplığı sağlar. Kullandığı yeniden deneme ilkesi genellikle hedef hizmetin niteliğine ve gereksinimlerine uygun hale getirilir. Alternatif olarak, hizmetler için REST arabirimleri bir yeniden denemenin uygun olup olmadığını ve bir sonraki yeniden deneme girişiminden önce ne kadar bekleneceğini belirlemenize yardımcı olabilecek bilgiler döndürebilir.

  • Farklı bir yeniden deneme davranışını daha uygun hale getiren belirli ve iyi anlaşılmış gereksinimleriniz olmadığı sürece, kullanılabilir olduğunda yerleşik yeniden deneme mekanizmasını kullanmanız gerekir.

İşlemin yeniden deneme için uygun olup olmadığını belirleme

  • Yeniden deneme işlemlerini yalnızca hatalar geçici olduğunda (genellikle hatanın doğasıyla belirtilir) ve yeniden denendiğinde işlemin başarılı olma olasılığı en az bir miktar olduğunda gerçekleştirin. Var olmayan bir öğeye veritabanı güncelleştirmesi veya önemli bir hatayla karşı karşıya olan bir hizmet veya kaynağa yönelik istek gibi geçersiz bir işlemi deneyen işlemleri yeniden denemenin bir anlamı yoktur.

  • Genel olarak, yeniden denemeleri yalnızca bunu yapmanın tam etkisini belirleyebildiğinizde ve koşulların iyi anlaşıldığı ve doğrulanabildiği durumlarda uygulayın. Aksi takdirde, çağıran kodun yeniden denemeler uygulamasına izin verin. Denetiminiz dışındaki kaynaklardan ve hizmetlerden döndürülen hataların zaman içinde gelişebileceğini ve geçici hata algılama mantığınızı yeniden ziyaret etmeniz gerekebileceğini unutmayın.

  • Hizmetleri veya bileşenleri oluştururken, istemcilerin başarısız işlemleri yeniden denemeleri gerekip gerekmediğini belirlemelerine yardımcı olan hata kodları ve iletiler uygulamayı göz önünde bulundurun. Özellikle, istemcinin işlemi yeniden deneyip denemeyeceği (belki de bir isTransient değeri döndürerek) ve bir sonraki yeniden deneme girişiminden önce uygun bir gecikme önerip önermediğini belirtin. Bir web hizmeti oluşturuyorsanız, hizmet sözleşmelerinizde tanımlanan özel hataları döndürmeyi göz önünde bulundurun. Genel istemciler bu hataları okuyamasa da, özel istemcilerin oluşturulmasında yararlıdır.

Uygun yeniden deneme sayısını ve aralığını belirleme

  • Yeniden deneme sayısını ve aralığı kullanım örneği türüne göre iyileştirin. Yeterli süre yeniden denemezseniz uygulama işlemi tamamlayamaz ve büyük olasılıkla başarısız olur. Çok fazla kez yeniden denerseniz veya denemeler arasında çok kısa bir aralıkla uygulama iş parçacıkları, bağlantılar ve bellek gibi kaynakları uzun süre tutabilir ve bu da uygulamanın durumunu olumsuz yönde etkileyebilir.

  • Zaman aralığı için değerleri ve yeniden deneme denemelerinin sayısını işlem türüne uyarlar. Örneğin, işlem bir kullanıcı etkileşiminin parçasıysa, aralık kısa olmalı ve yalnızca birkaç yeniden deneme denenmelidir. Bu yaklaşımı kullanarak, açık bağlantıları tutan ve diğer kullanıcıların kullanılabilirliğini azaltabilen bir yanıt için kullanıcıları bekletmekten kaçınabilirsiniz. İşlem uzun süre çalışan veya kritik bir iş akışının parçasıysa ve işlemin iptali ve yeniden başlatılması pahalı veya zaman alıcıysa, denemeler arasında daha uzun süre beklemek ve daha fazla kez yeniden denemek uygundur.

  • Yeniden denemeler arasındaki uygun aralıkları belirlemenin başarılı bir strateji tasarlamanın en zor kısmı olduğunu unutmayın. Tipik stratejiler aşağıdaki yeniden deneme aralığı türlerini kullanır:

    • Üstel geri alma. Uygulama ilk yeniden denemeden önce kısa bir süre bekler ve ardından sonraki her yeniden deneme arasındaki süreyi katlanarak artırır. Örneğin, işlemi 3 saniye, 12 saniye, 30 saniye vb. sonra yeniden deneyebilir.

    • Artımlı aralıklar. Uygulama ilk yeniden denemeden önce kısa bir süre bekler ve sonraki her yeniden deneme arasındaki süreyi artımlı olarak artırır. Örneğin, işlemi 3 saniye, 7 saniye, 13 saniye vb. sonra yeniden deneyebilir.

    • Düzenli aralıklar. Uygulama her girişimden önce aynı süre boyunca bekler. Örneğin, işlemi 3 saniyede bir yeniden deneyebilir.

    • Hemen yeniden deneme. Bazen geçici bir hata kısadır ve bunun nedeni büyük olasılıkla ağ paketi çakışması veya donanım bileşenindeki ani artış gibi bir olaydır. Bu durumda, uygulamanın bir sonraki isteği derlemesi ve göndermesi için gereken sürede hata temizlenirse başarılı olabileceğinden, işlemi hemen yeniden denemek uygundur. Ancak, hiçbir zaman birden fazla anında yeniden deneme girişimi olmamalıdır. Hemen yeniden deneme başarısız olursa üstel geri alma veya geri dönüş eylemleri gibi alternatif stratejilere geçmeniz gerekir.

    • Rastgele seçme. Daha önce listelenen yeniden deneme stratejilerinden herhangi biri, istemcinin birden çok örneğinin aynı anda sonraki yeniden deneme girişimlerini göndermesini önlemek için rastgele bir seçim içerebilir. Örneğin, bir örnek işlemi 3 saniye, 11 saniye, 28 saniye vb. sonra yeniden denerken, başka bir örnek işlemi 4 saniye, 12 saniye, 26 saniye vb. sonra yeniden deneyebilir. Rastgelelik, diğer stratejilerle birleştirilebilen kullanışlı bir tekniktir.

  • Genel bir kılavuz olarak, arka plan işlemleri için üstel geri alma stratejisini ve etkileşimli işlemler için anında veya düzenli aralıklı yeniden deneme stratejilerini kullanın. Her iki durumda da gecikmeyi ve yeniden deneme sayısını, tüm yeniden deneme girişimleri için en uzun gecikme süresi gerekli uçtan uca gecikme gereksinimleri dahilinde olacak şekilde seçmeniz gerekir.

  • Yeniden denenen bir işlem için genel maksimum zaman aşımına katkıda bulunan tüm faktörlerin bileşimini dikkate alın. Bu faktörler arasında başarısız bir bağlantının yanıt oluşturma süresi (genellikle istemcideki bir zaman aşımı değeri tarafından ayarlanır), yeniden deneme girişimleri arasındaki gecikme ve en fazla yeniden deneme sayısı bulunur. Tüm bu sürelerin toplamı, özellikle her hatadan sonra yeniden denemeler arasındaki aralığın hızla arttığı üstel bir gecikme stratejisi kullandığınızda uzun genel işlem sürelerine neden olabilir. Bir işlemin belirli bir hizmet düzeyi sözleşmesini (SLA) karşılaması gerekiyorsa, tüm zaman aşımları ve gecikmeler dahil olmak üzere genel işlem süresi SLA'da tanımlanan sınırlar içinde olmalıdır.

  • Aşırı agresif yeniden deneme stratejileri uygulamayın. Bunlar, çok kısa aralıklara veya çok sık yapılan yeniden denemelere sahip stratejilerdir. Hedef kaynak veya hizmet üzerinde olumsuz bir etkiye sahip olabilirler. Bu stratejiler, kaynağın veya hizmetin aşırı yüklenmiş durumundan kurtarmasını engelleyebilir ve istekleri engellemeye veya reddetmeye devam eder. Bu senaryo, kaynağa veya hizmete giderek daha fazla isteğin gönderildiği bir kısır döngüyle sonuçlanıyor. Sonuç olarak, kurtarma yeteneği daha da azalır.

  • Sonraki bir denemenin hemen başlatılmasını önlemek için yeniden deneme aralıklarını seçtiğinizde işlemlerin zaman aşımını dikkate alın (örneğin, zaman aşımı süresi yeniden deneme aralığına benzerse). Ayrıca, toplam olası süreyi (zaman aşımı artı yeniden deneme aralıkları) belirli bir toplam sürenin altında tutmanız gerekip gerekmediğini de göz önünde bulundurun. Bir işlemin olağan dışı bir şekilde kısa veya uzun bir zaman aşımı varsa, zaman aşımı ne kadar süre beklendiğini ve işlemi yeniden deneme sıklıklarını etkileyebilir.

  • Yeniden deneme sayısını ve aralarındaki aralığı iyileştirmek için özel durumun türünü ve içerdiği tüm verileri veya hizmetten döndürülen hata kodlarını ve iletileri kullanın. Örneğin, bazı özel durumlar veya hata kodları (HTTP kodu 503, Hizmet Kullanılamıyor, yanıtta Retry-After üst bilgisi olan) hatanın ne kadar sürebileceğini veya hizmetin başarısız olduğunu ve sonraki hiçbir girişime yanıt vermeyeceğini gösterebilir.

  • Tüm yeniden deneme girişimleri tükendikten sonra gelen çağrıdaki tüm bilgilerin kaybolmadığından emin olmak için teslim edilemeyen bir kuyruk yaklaşımı kullanmayı göz önünde bulundurun.

Anti-desenlerden kaçının

  • Çoğu durumda, yinelenen yeniden deneme kodu katmanları içeren uygulamalardan kaçının. Bunu gerektiren belirli gereksinimleriniz olmadığı sürece, basamaklı yeniden deneme mekanizmaları içeren veya bir istek hiyerarşisi içeren bir işlemin her aşamasında yeniden deneme uygulayan tasarımlardan kaçının. Bu olağanüstü durumlarda, aşırı sayıda yeniden deneme ve gecikme sürelerini önleyen ilkeler kullanın ve sonuçları anladığınızdan emin olun. Örneğin, bir bileşenin başka bir bileşene istekte bulunarak hedef hizmete eriştiğine dikkat edin. Her iki çağrıda da üç sayıyla yeniden deneme uygularsanız, hizmete karşı toplamda dokuz yeniden deneme denemesi olur. Birçok hizmet ve kaynak yerleşik bir yeniden deneme mekanizması uygular. Yeniden denemeleri daha yüksek bir düzeyde uygulamanız gerekiyorsa bu mekanizmaları nasıl devre dışı bırakabileceğinizi veya değiştirebileceğinizi araştırmanız gerekir.

  • Hiçbir zaman sonsuz bir yeniden deneme mekanizması uygulamayın. Bunu yapmak, kaynağın veya hizmetin aşırı yükleme durumlarından kurtarılmasını ve azaltmanın ve reddedilen bağlantıların daha uzun süre devam etmesini engelleme olasılığı yüksektir. Sınırlı sayıda yeniden deneme kullanın veya hizmetin kurtarılması için Devre Kesici gibi bir desen uygulayın.

  • Hemen yeniden denemeyi hiçbir zaman birden çok kez gerçekleştirmeyin.

  • Azure'da hizmetlere ve kaynaklara erişirken, özellikle de çok fazla sayıda yeniden deneme denemeniz olduğunda düzenli bir yeniden deneme aralığı kullanmaktan kaçının. Bu senaryoda en iyi yaklaşım, devre kesme özelliğine sahip üstel bir geri alma stratejisidir.

  • Aynı istemcinin birden çok örneğinin veya farklı istemcilerin birden çok örneğinin aynı anda yeniden deneme göndermesini önleyin. Bu senaryonun gerçekleşme olasılığı varsa, yeniden deneme aralıklarına rastgele dönüştürmeyi girin.

Yeniden deneme stratejinizi ve uygulamanızı test etme

  • Yeniden deneme stratejinizi, özellikle de hem uygulama hem de kullandığı hedef kaynaklar veya hizmetler aşırı yük altında olduğunda, mümkün olduğunca geniş bir koşullar altında tam olarak test edin. Test sırasında davranışı denetlemek için şunları yapabilirsiniz:

    • Hizmete geçici ve geçici olmayan hatalar ekleme. Örneğin, geçersiz istekler gönderin veya test isteklerini algılayıp farklı hata türleri ile yanıt veren kodlar ekleyin.

    • Gerçek hizmetin döndürebileceği bir dizi hata döndüren kaynağın veya hizmetin bir kopyasını oluşturun. Yeniden deneme stratejinizin algılamak üzere tasarlandığı tüm hata türlerini kapsar.

    • Oluşturup dağıttığınız özel hizmetler için hizmeti geçici olarak devre dışı bırakarak veya aşırı yükleyerek geçici hataların oluşmasını zorlayın. (Azure'da paylaşılan kaynakları veya paylaşılan hizmetleri aşırı yüklemeyi denemeyin.)

    • Otomatikleştirilmiş testlerinizin olumsuz senaryolarını çoğaltmak için ağ trafiğini kesen ve değiştiren kitaplıkları veya çözümleri kullanın. Örneğin testler fazladan gidiş dönüş süreleri ekleyebilir, paketleri bırakabilir, üst bilgileri değiştirebilir ve hatta isteğin gövdesini değiştirebilir. Bunu yapmak, geçici hatalar ve diğer hata türleri için hata koşullarının bir alt kümesinin belirlenimci testini etkinleştirir.

    • İstemci web uygulamasının geçici hatalara karşı dayanıklılığını test ederken tarayıcının geliştirici araçlarını veya test çerçevenizin ağ isteklerini taklit etme veya engelleme yeteneğini kullanın.

    • Yeniden deneme mekanizmasının ve stratejisinin bu koşullar altında düzgün çalıştığından emin olmak için yüksek yük faktörü ve eşzamanlı testler gerçekleştirin. Bu testler ayrıca yeniden denemenin istemcinin çalışması üzerinde olumsuz bir etkisi olmadığından veya istekler arasında çapraz kontaminasyona neden olmadığından emin olmanıza yardımcı olur.

Yeniden deneme ilkesi yapılandırmalarını yönetme

  • Yeniden deneme ilkesi, yeniden deneme stratejinizin tüm öğelerinin birleşimidir. Bir hatanın geçici olup olmayacağını, kullanılacak aralığın türünü (normal, üstel geri alma ve rastgele seçme gibi), gerçek aralık değerlerini ve yeniden deneme sayısını belirleyen algılama mekanizmasını tanımlar.

  • En basit uygulamada ve daha karmaşık uygulamaların her katmanında bile birçok yerde yeniden denemeler uygulayın. Her ilkenin öğelerini birden çok konumda sabit kodlamak yerine, tüm ilkeleri depolamak için merkezi bir nokta kullanmayı göz önünde bulundurun. Örneğin, aralık ve yeniden deneme sayısı gibi değerleri uygulama yapılandırma dosyalarında depolayın, çalışma zamanında okuyun ve program aracılığıyla yeniden deneme ilkelerini oluşturun. Bunu yapmak, ayarları yönetmeyi ve değişen gereksinimlere ve senaryolara yanıt vermek için değerleri değiştirmeyi ve ince ayarlamayı kolaylaştırır. Ancak, sistemi her seferinde bir yapılandırma dosyasını yeniden okumak yerine değerleri depolamak için tasarlayın ve değerler yapılandırmadan alınamıyorsa uygun varsayılanları kullanın.

  • Yeniden deneme ilkelerini çalışma zamanında oluşturmak için kullanılan değerleri uygulamanın yapılandırma sisteminde depolayın; böylece uygulamayı yeniden başlatmanıza gerek kalmadan bunları değiştirebilirsiniz.

  • Kullandığınız istemci API'lerinde kullanılabilen yerleşik veya varsayılan yeniden deneme stratejilerinden yararlanın, ancak yalnızca senaryonuz için uygun olduğunda. Bu stratejiler genellikle geneldir. Bazı senaryolarda ihtiyacınız olan tek şey bunlar olabilir, ancak diğer senaryolarda gereksinimlerinize uygun tüm seçenekleri sunmaz. En uygun değerleri belirlemek için, ayarların uygulamanızı nasıl etkilediğini anlamak için test gerçekleştirmeniz gerekir.

Geçici ve geçici olmayan hataları günlüğe kaydetme ve izleme

  • Yeniden deneme stratejinizin bir parçası olarak, özel durum işlemeyi ve yeniden deneme girişimlerini günlüğe kaydeden diğer izlemeleri ekleyin. Ara sıra geçici bir hata ve yeniden deneme beklenir ve bir sorun olduğunu göstermez. Ancak normal ve artan yeniden deneme sayısı genellikle hataya neden olabilecek veya uygulama performansını ve kullanılabilirliğini düşüren bir sorunun göstergesidir.

  • İzleme sistemlerinin bunları hatalı uyarıları tetikleyebilecek uygulama hataları olarak algılamaması için geçici hataları hata girdileri olarak değil uyarı girdileri olarak günlüğe kaydeder.

  • Yeniden denemelerin hizmetteki azaltmadan mı yoksa bağlantı hataları gibi diğer hata türlerinden mi kaynaklandığını gösteren bir değeri günlük girdilerinizde depolamayı göz önünde bulundurun; böylece bunları verilerin analizi sırasında ayırt edebilirsiniz. Kapasite azaltma hatalarının sayısındaki artış genellikle uygulamadaki bir tasarım kusurunun ya da ayrılmış donanım sunan bir premium hizmete geçiş gereksiniminin göstergesidir.

  • Yeniden deneme mekanizması içeren işlemler için geçen genel süreleri ölçmeyi ve günlüğe kaydetmeyi göz önünde bulundurun. Bu ölçüm, geçici hataların kullanıcı yanıt süreleri, işlem gecikme süresi ve uygulama kullanım örneklerinin verimliliği üzerindeki genel etkisinin iyi bir göstergesidir. Ayrıca, yanıt süresine katkıda bulunan faktörleri anlayabilmek için gerçekleşen yeniden deneme sayısını da günlüğe kaydedebilirsiniz.

  • Hata sayısı ve oranı, ortalama yeniden deneme sayısı veya işlemler başarılı olmadan önce geçen toplam süreler arttığında uyarı oluşturabilen bir telemetri ve izleme sistemi uygulamayı göz önünde bulundurun.

Sürekli başarısız olan işlemleri yönetme

  • Her girişimde başarısız olan işlemlerin nasıl işlendiğini düşünün. Böyle durumlar kaçınılmazdır.

    • Yeniden deneme stratejisi, bir işlemin en fazla kaç kez yeniden denenmesi gerektiğini tanımlasa da, uygulamanın işlemi aynı sayıda yeniden deneme ile tekrarlamasını engellemez. Örneğin, bir sipariş işleme hizmeti onu kalıcı olarak kullanım dışı tutan önemli bir hatayla başarısız olursa, yeniden deneme stratejisi bir bağlantı zaman aşımı algılayabilir ve geçici bir hata olarak kabul edebilir. Kod işlemi belirtilen sayıda yeniden denenir ve sonra vazgeçer. Ancak, başka bir müşteri sipariş verdiyse, her seferinde başarısız olsa bile işlem yeniden denenecektir.

    • Sürekli başarısız olan işlemler için sürekli yeniden denemeleri önlemek için Devre Kesici düzenini uygulamayı göz önünde bulundurmalısınız. Bu düzeni kullandığınızda, belirtilen zaman penceresindeki hata sayısı eşiği aşarsa istekler çağırana hata olarak hemen geri döner ve başarısız kaynağa veya hizmete erişme girişimi olmaz.

    • Uygulama, ne zaman kullanılabilir hale geldiğini algılamak için hizmeti aralıklı olarak ve istekler arasında uzun aralıklarla düzenli aralıklarla test edebilir. Uygun bir aralık, işlemin kritikliği ve hizmetin doğası gibi faktörlere bağlıdır. Birkaç dakika ile birkaç saat arasında bir şey olabilir. Test başarılı olduğunda, uygulama normal işlemleri sürdürebilir ve istekleri yeni kurtarılan hizmete geçirebilir.

    • Bu arada, hizmetin başka bir örneğine (belki farklı bir veri merkezinde veya uygulamada) geri dönebilir, uyumlu (belki daha basit) işlevler sunan benzer bir hizmet kullanabilir veya hizmetin yakında kullanıma sunulacağı umuduyla bazı alternatif işlemler gerçekleştirebilirsiniz. Örneğin, hizmet isteklerini kuyrukta veya veri deposunda depolamak ve daha sonra yeniden denemek uygun olabilir. Ya da kullanıcıyı uygulamanın alternatif bir örneğine yönlendirebilir, uygulamanın performansını düşürebilir, ancak yine de kabul edilebilir işlevler sunabilir veya uygulamanın şu anda kullanılabilir olmadığını belirtmek için kullanıcıya bir ileti döndürebilirsiniz.

Diğer önemli noktalar

  • Yeniden deneme sayısı için değerlere ve ilkenin yeniden deneme aralıklarına karar verirken, hizmet veya kaynak üzerindeki işlemin uzun süre çalışan veya çok adımlı bir işlemin parçası olup olmadığını göz önünde bulundurun. Başarısız olduğunda zaten başarılı olan diğer tüm işlem adımlarını telafi etmek zor veya pahalı olabilir. Bu durumda, bu strateji kıt kaynakları tutarak veya kilitleyerek diğer işlemleri engellemediği sürece çok uzun bir aralık ve çok sayıda yeniden deneme kabul edilebilir.

  • Aynı işlemi yeniden denemenin verilerde tutarsızlıklara neden olup olmadığını göz önünde bulundurun. Çok adımlı işlemin bazı bölümleri yineleniyorsa ve işlemler bir kez etkili değilse tutarsızlıklar oluşabilir. Örneğin, bir değeri artıran bir işlem yinelenirse geçersiz bir sonuç üretir. Kuyruğa ileti gönderen bir işlemin yinelenmesi, tüketici yinelenen iletileri algılayamazsa ileti tüketicisinde tutarsızlığa neden olabilir. Bu senaryoları önlemek için her adımı bir kez etkili bir işlem olarak tasarlar. Daha fazla bilgi için bkz. Tek etkililik desenleri.

  • Yeniden denenen işlemlerin kapsamını göz önünde bulundurun. Örneğin, yeniden deneme kodunu birkaç işlemi kapsayan bir düzeyde uygulamak ve biri başarısız olursa hepsini yeniden denemek daha kolay olabilir. Ancak bunu yapmak, bir kez etkililik sorunlarına veya gereksiz geri alma işlemlerine neden olabilir.

  • Birkaç işlemi kapsayan bir yeniden deneme kapsamı seçerseniz, yeniden deneme aralıklarını belirlerken, işlemin geçen sürelerini izlerken ve hata uyarıları oluşturmadan önce bunların tümünün toplam gecikme süresini dikkate alın.

  • Yeniden deneme stratejinizin paylaşılan bir uygulamadaki komşuları ve diğer kiracıları nasıl etkileyebileceğini ve paylaşılan kaynakları ve hizmetleri ne zaman kullandığınızı düşünün. Agresif yeniden deneme ilkeleri bu diğer kullanıcılar ve kaynaklar ile hizmetleri paylaşan uygulamalar için oluşan geçici hata sayısının artmasına neden olabilir. Benzer şekilde, uygulamanız diğer kaynak ve hizmet kullanıcıları tarafından uygulanan yeniden deneme ilkelerinden etkilenebilir. İş açısından kritik uygulamalarda, paylaşılmayan premium hizmetleri kullanmak isteyebilirsiniz. Bunu yaptığınızda, bu kaynakların ve hizmetlerin yükü ve sonuç olarak azaltılma durumu üzerinde daha fazla denetime sahip olursunuz ve bu da ek maliyeti haklı çıkarmanıza yardımcı olabilir.

Not

Dezavantajlar ve riskler hakkında daha fazla rehberlik için Yeniden deneme düzeni makalesindeki sorunlar ve dikkat edilmesi gerekenler bölümüne bakın.

Azure kolaylaştırma

Çoğu Azure hizmeti ve istemci SDK'sı bir yeniden deneme mekanizması sağlar. Ancak, her hizmetin farklı özellikleri ve gereksinimleri olduğundan ve her yeniden deneme mekanizması belirli bir hizmete ayarlandığı için bu mekanizmalar farklılık gösterir. Bu bölümde, yaygın olarak kullanılan bazı Azure hizmetleri için yeniden deneme mekanizması özellikleri özetlenmektedir.

Hizmet Yeniden deneme özellikleri İlke yapılandırması Kapsam Telemetri özellikleri
Microsoft Entra Kimlik Microsoft Kimlik Doğrulama Kitaplığı'nda (MSAL) yerel MSAL kitaplığına katıştırılmış İç Hiçbiri
Azure Cosmos DB Hizmette yerel Yapılandırılamaz Genel TraceSource
Azure Data Lake Storage İstemcide yerel Yapılandırılamaz Tek tek işlemler Hiçbiri
Azure Event Hubs İstemcide yerel Programlı İstemci Hiçbiri
Azure IoT Hub İstemci SDK'sında yerel Programlı İstemci Hiçbiri
Redis için Azure Önbelleği İstemcide yerel Programlı İstemci TextWriter
Azure Bilişsel Arama İstemcide yerel Programlı İstemci ETW veya özel
Azure Service Bus İstemcide yerel Programlı NamespaceManager, MessagingFactory ve client ETW
Azure Service Fabric İstemcide yerel Programlı İstemci Hiçbiri
ADO.NET ile Azure SQL Veritabanı Polly Bildirim temelli ve programlı Tek deyimler veya kod blokları Özel
Entity Framework ile SQL Veritabanı İstemcide yerel Programlı Uygulama Etki Alanı başına genel Hiçbiri
Entity Framework Core ile SQL Veritabanı İstemcide yerel Programlı Uygulama Etki Alanı başına genel Hiçbiri
Azure Depolama İstemcide yerel Programlı İstemci ve tek işlemler TraceSource

Not

Azure'daki yerleşik yeniden deneme mekanizmalarının çoğunda, şu anda farklı hata veya özel durum türleri için farklı bir yeniden deneme ilkesi uygulamanın hiçbir yolu yoktur. En iyi ortalama performansı ve kullanılabilirliği sağlayan bir ilke yapılandırmanız gerekir. İlkenizde ince ayar yapma yollarından biri, oluşan geçici hataların türünü belirlemek için günlük dosyalarını analiz etmektir.

Örnek

Bu makalede açıklanan desenlerin birçoğunun kullanıldığı bir örnek için bkz. .NET için güvenilir web uygulaması deseni . GitHub'da bir başvuru uygulaması da vardır.

Güvenilirlik denetim listesi

Önerilerin tamamına bakın.

Güvenilirlik denetim listesi