Geçici hata işleme

  • Makale

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ı 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 anlık ağ bağlantısı kaybı, hizmetin geçici olarak kullanılamadığı 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 tekrarlanırsa başarılı olma olasılığı yüksektir.

Bu makalede geçici hata işlemeye yönelik genel yönergeler sağlanmaktadır. Azure hizmetlerini kullanırken geçici hataları işleme hakkında bilgi için bkz . Azure hizmetleri için yeniden deneme kılavuzu.

Neden bulutta geçici hatalar oluşur?

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 yoluyla korunur ve bileşenler ve kaynaklar birbirine yakın bir yerde bulunur. Bu yaklaşım hata olasılığını düşürür, ancak geçici hatalar oluşmaya devam edebilir; dış güç kaynağı, ağ sorunları veya diğer olağanüstü durum senaryoları gibi öngörülemeyen olayları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, yedeklilik, otomatik yük devretme ve dinamik kaynak ayırma kullanarak daha yüksek genel kullanılabilirlik sunabilir. Ancak bulut ortamlarının doğası gereği geçici hataların 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 için 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ında çok sayıda ticari donanım birimi kullanılı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 özellik 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ı dahil olmak üzere 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.

  • özellikle iletişim İnternet üzerinden geçtiğinde istemci ile sunucu arasındaki ağ koşulları 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 bir uygulamanın algılanan kullanılabilirliği üzerinde büyük 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 verebilmesini sağlamanız gerekir:

  • Uygulama, oluştuğunda hataları algılayabilmeli ve hataların geçici olma olasılığını, uzun ömürlü olup olmadığını veya terminal hataları olup olmadığını saptayabilmelidir. Hata oluştuğunda farklı kaynaklar farklı yanıtlar döndürebilir ve bu yanıtlar işlemin bağlamlarına bağlı olarak da değişebilir. Örneğin, uygulama depolama alanından okurken bir hatanın yanıtı, depolama alanına yazarken bir hatanın yanıtından farklı olabilir. Birçok kaynak ve hizmetin 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 olup olmadığı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 kaç kez yeniden denemesi gerektiğini, 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, yeniden denemenin uygun olup olmadığını ve bir sonraki yeniden deneme denemesi öncesinde 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 yoksa, 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ından bir miktar olduğunda gerçekleştirin. Mevcut 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şlem deneyen işlemleri yeniden denemenin bir anlamı yoktur.

  • Genel olarak, yeniden denemeleri yalnızca bunu yapmanın tam etkisini belirleyebildiğinizde ve koşullar iyi anlaşıldığında ve doğrulanabildiğinde uygulayın. Aksi takdirde, çağıran kodun yeniden denemeler uygulamasına izin verin. Denetiminizin 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.

  • Hizmetler veya bileşenler 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 denemesi gerekip gerekmediğini (belki de bir isTransient değeri döndürerek) belirtin ve bir sonraki yeniden deneme girişiminden önce uygun bir gecikme önerin. 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 iptal edilmesi 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 üstel olarak 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 ardından 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, hata uygulamanın bir sonraki isteği derlemesi ve göndermesi için gereken sürede 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çim. 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 4 saniye, 12 saniye, 26 saniye vb. sonra işlemi yeniden deneyebilir. Rastgele seçim, diğer stratejilerle birleştirilebilen kullanışlı bir tekniktir.

  • Genel bir kılavuz olarak, arka plan işlemleri için üstel bir geri alma stratejisi kullanın ve etkileşimli işlemler için hemen 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 birleşimini dikkate alın. Bu faktörler arasında başarısız bir bağlantının yanıt üretmesi için geçen süre (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, genel işlem sürelerinin uzun sürmesine neden olabilir. Bir işlemin belirli bir hizmet düzeyi sözleşmesine (SLA) uyması 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 kurtarılmasını engelleyebilir ve istekleri engellemeye veya reddetmeye devam eder. Bu senaryo, kaynağa veya hizmete her gün 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 beklemeniz ve işlemi yeniden deneme sıklıkları 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 Yeniden DenemeDen Sonra üst bilgisi bulunur) hatanın ne kadar sürebileceğini veya hizmetin başarısız olduğunu ve sonraki hiçbir denemeye yanıt vermeyeceğini gösterebilir.

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 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 bulunduğu ve ardından hedef hizmete eriştiği varsayalım. 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. Bunun yapılması, kaynağın veya hizmetin aşırı yükleme durumlarından kurtulmasını ve azaltma ve reddedilen bağlantıların daha uzun süre devam etmesini engelleme olasılığı yüksektir. Sonlu 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 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 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 seçim sağlayın.

Yeniden deneme stratejinizi ve uygulamanızı test edin

  • Yeniden deneme stratejinizi, özellikle 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. TestApi kullanan örnekler için bkz . TestApi ile Hata Ekleme Testi ve TestApi'ye Giriş – Bölüm 5: Yönetilen Kod Hata Ekleme API'leri.

    • Gerçek hizmetin döndürebileceği bir dizi hata döndüren kaynak 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ı zorlayabilirsiniz. (Azure'da paylaşılan kaynakları veya paylaşılan hizmetleri aşırı yüklemeyi denemeyin.)

    • HTTP tabanlı API'ler için, fazladan gidiş dönüş süreleri ekleyerek veya yanıtı değiştirerek (HTTP durum kodu, üst bilgiler, gövde veya diğer faktörler gibi) HTTP isteklerinin sonucunu değiştirmek için otomatikleştirilmiş testlerinizde bir kitaplık kullanmayı göz önünde bulundurun. Bunun yapılması, geçici hatalar ve diğer hata türleri için hata koşullarının bir alt kümesinin belirlenimci testini etkinleştirir.

    • 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, yeniden denemenin istemcinin çalışmasını olumsuz etkilemediğinden veya istekler arasında çapraz kirlenmeye neden olmadığından da 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 olma olasılığını, kullanılacak aralığın türünü (normal, üstel geri alma ve rastgeleleştirme 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 yeniden deneme ilkelerini program aracılığıyla 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 hassas ayarlamayı kolaylaştırır. Ancak, her seferinde bir yapılandırma dosyasını yeniden okumak yerine değerleri depolamak için sistemi tasarlayın ve değerler yapılandırmadan alınamıyorsa uygun varsayılan değerleri kullanın.

  • Azure Cloud Services uygulamasında, yeniden deneme ilkelerini çalışma zamanında oluşturmak için kullanılan değerleri, uygulamayı yeniden başlatmanıza gerek kalmadan değiştirebilmeniz için hizmet yapılandırma dosyasında depolayabilirsiniz.

  • Kullandığınız istemci API'lerinde kullanılabilen ancak yalnızca senaryonuza uygun olan yerleşik veya varsayılan yeniden deneme stratejilerinden yararlanın. 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 sorunu göstermez. Ancak normal ve artan sayıda yeniden deneme 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 verileri analiz etme sırasında bunları 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ı günlüğe kaydeder.

  • Hata sayısı ve oranı, ortalama yeniden deneme sayısı veya işlemler başarılı olmadan önce geçen genel 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 denemede başarısız olan işlemleri nasıl işleneceğini düşünün. Böyle durumlar kaçınılmazdır.

    • Yeniden deneme stratejisi, bir işlemin yeniden denenmesi gereken en fazla sayıda işlemi tanımlasa da, uygulamanın işlemi aynı sayıda yeniden denemeyle tekrarlamasını engellemez. Örneğin, bir sipariş işleme hizmeti kalıcı olarak işlem dışı bırakılacak ö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 dener 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şlemlerin sürekli yeniden denenmesini önlemek için Devre Kesici düzenini uygulamayı göz önünde bulundurmanız gerekir. Bu düzeni kullandığınızda, belirtilen zaman penceresindeki hata sayısı eşiği aşarsa, istekler çağırana hemen hata olarak geri döner ve başarısız kaynağa veya hizmete erişme girişimi olmaz.

    • Uygulama, hizmetin ne zaman kullanılabilir olduğunu 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 de 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 bir kuyrukta veya veri deposunda depolamak ve daha sonra yeniden denemek uygun olabilir. Veya 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.

Dikkat edilecek diğer noktalar

  • Bir ilkenin yeniden deneme sayısı ve yeniden deneme aralıkları değerlerine 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 yinelenirse 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ç verir. Bir 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 . Idempotency 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 hatalarla ilgili uyarılar oluşturmadan önce bunları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 kullanırken nasıl etkileyebileceğini göz önünde bulundurun. 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 uygulamalar için paylaşılmayan premium hizmetleri kullanmak isteyebilirsiniz. Bunu yapmak, bu kaynakların ve hizmetlerin yükü ve sonuç olarak azaltması üzerinde daha fazla denetim sağlar ve bu da ek maliyeti haklı çıkarmanıza yardımcı olabilir.