Geçici hataları ele alma önerileri

Bu kılavuz, bulut uygulamalarınızdaki geçici hataları ele alma önerilerini açıklar. Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara duyarlı olması gerekir. Bu, özellikle bulutta çalışan uygulamalar için geçerlidir. Burada, ortamın yapısı ve internet bağlantısı nedeniyle, bu tür bir hatayla daha sık karşılaşılabilir. Geçici hatalar arasında bileşenlere ve hizmetlere olan ağ bağlantısının anlık kaybı, bir servisin geçici olarak kullanılmaması ve bir servis meşgul olduğunda oluşan zaman aşımı yer alır. Bu hatalar genellikle kendi kendine düzeltilir, bu nedenle, eylem uygun bir gecikmeden sonra tekrar edilirse, başarma olasılığı yüksektir.

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

Terminoloji

Geçici hata işlemeyi uygulamaya başlamadan önce bu önemli terimleri tanıyın.

Süre	Tanım
Circuit Breaker tasarımı	Başarısız olma olasılığı olan bir işleme yönelik yinelenen girişimleri önleyen tasarım deseni. Bir hata eşiğinden sonra devre açılır ve istekler işlemi denemeden hemen başarısız olur ve bu da hizmet süresinin kurtarılmasına olanak tanır.
Teslim edilemeyen ileti kuyruğu	Birden çok denemeden sonra başarıyla işlenemeyen iletileri depolayan özel kuyruk. Sorunlu iletileri araştırma ve çözüm için koruyarak ana işleme kuyruğunda blokaj oluşmasını önler.
Üstel gecikmeli geri çekilme	Yeniden deneme girişimleri arasındaki bekleme süresinin 3 saniye, 12 saniye, 30 saniye gibi katlanarak arttığı yeniden deneme stratejisi. Yinelenen isteklerle kendini toparlayan bir hizmetin fazla yüklenmesini önlemeye yardımcı olur.
İdempotent	Kaç kez çalıştırıldığından bağımsız olarak aynı sonucu veren bir işlemin özelliği. İşlemler tekrarlandığında istenmeyen yan etkileri önlemek için yeniden deneme mantığı için temel öneme sahiptir.
Salınım	Birden çok istemcinin aynı anda yeniden denemesini önlemek için yeniden deneme aralıklarına rastgele gecikme eklendi. Kurtarma hizmetini bunaltabilecek senkronize yeniden deneme saldırılarını önlemeye yardımcı olur.
Yeniden Deneme Politikası	Algılama mekanizması, aralık türü, gerçek aralık değerleri ve yeniden deneme denemesi sayısı gibi tüm yeniden deneme stratejisi öğelerinin birleşimi. Bir uygulamanın geçici hatalara nasıl yanıt verdiğini tanımlar.
Kısıtlama	Aşırı yüklemeden korumak amacıyla bir hizmet veya kaynağa yönelik istek oranını sınırlama uygulaması. Genellikle sınırlar aşıldığında geçici hataları tetikler ve bu da uygun yeniden deneme stratejileri gerektirir.
Timeout	Başarısız olduğunu düşünmeden önce işlemin tamamlanmasını bekleme süresi üst sınırı. İşlemlerin izin verilen toplam süreyi aşmasını önlemek için yeniden deneme stratejileri tasarlarken zaman aşımlarını göz önünde bulundurun.
Geçici hata	Kendi kendini düzelten ve uygun bir gecikmeden sonra yeniden denenirse başarılı olma olasılığı olan geçici hata. Anlık ağ kaybı, hizmet kullanılamama durumu veya meşgul hizmetler nedeniyle zaman aşımları bunlara örnek olarak verilebilir.

Geçici Hatalar

Geçici hatalar herhangi bir ortamda, herhangi bir platformda veya işletim sisteminde ve her türlü uygulamada ortaya çıkabilir. 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. Bunun nedeni harici güç kaynağı veya ağ sorunları gibi öngörülemeyen olayların veya olağanüstü durum senaryolarının neden olabileceği 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 bu kaynaklara erişim, kaynakları korumak için kısıtlamaya 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.

Önceden görülebilen tüm koşullar altında kapsamlı olarak test edilmiş olsa bile, geçici hatalar 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 verebilmesini sağlamanız gerekir:

• Uygulama meydana geldiğinde hataları algılayabilmeli ve hataların geçici, uzun süreli veya terminal hataları olup olmadığını belirleyebilir. Bir hata oluştuğunda farklı kaynaklar farklı yanıtlar verebilir ve bu yanıtlar işlemin içeriğine 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.

• Uygulamanın, hatanın geçici olma olasılığı belirlerse 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 bir girişim arasındaki gecikmeyi ve başarısız bir girişimden sonra gerçekleştirilecek eylemleri belirtir. Uygun deneme sayısı 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 göre değişir.

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

Yeniden denemelerin uygulanması

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

• Birçok hizmet, geçici bir hata işleme mekanizması içeren bir SDK veya istemci kitaplığı sağlar. Kullandığı deneme ilkesi genellikle hedef servisin yapısına ve gereksinimlerine göre uyarlanmıştır. Alternatif olarak, servislere yönelik REST arabirimleri, bir yeniden denemenin uygun olup olmadığını ve bir sonraki deneme denemesi için ne kadar beklemeniz gerektiğini belirlemenize yardımcı olabilecek bilgiler döndürebilir.

• Yerleşik bir deneme mekanizması mevcut olduğunda, belirli ve iyi anlaşılmış gereksinimlerinizi karşılayan farklı bir deneme davranışı tercih etmenizi gerektiren özel nedenleriniz yoksa, bu mekanizmayı kullanmalısınız.

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

• Deneme işlemlerini yalnızca hatalar geçici olduğunda (genellikle hatanın yapısıyla gösterilir) ve yeniden denendiğinde işlemin başarılı olma olasılığı en azından biraz 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 gözden geçirmeniz 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 servisi oluşturursanız, hizmet sözleşmelerinizde tanımlanan özel hataları geri almayı düşünün. Genel istemciler bu hataları okuyamasa da, özel istemcilerin oluşturulmasında yararlıdır.

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

• Deneme sayısını ve aralığı kullanım talebi türüne göre en iyi duruma getirme. Yeterli kez yeniden deneme yapmazsanız 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ığı ve deneme denemelerinin sayısı için değerleri işlem türüne uyarlayın. Örneğin, işlem bir kullanıcı etkileşiminin parçasıysa, aralığın kısa olması ve yalnızca birkaç yeniden deneme denenmesi gerekir. 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ın belirlenmesinin, başarılı bir strateji belirlemenin en zor kısmı olduğunu unutmayın. Tipik stratejiler aşağıdaki türlerde yeniden deneme aralığı kullanır:

  • Üstel geri çekilme. Uygulama ilk denemeden önce kısa bir süre bekler ve sonra her sonraki deneme arasındaki süreyi katlanarak artırır. Örneğin, 3 saniye, 12 saniye, 30 saniye vb.'nin ardından işlemi yeniden deneyebilir. Bu stratejiyi daha da geliştirmek için üstel geri çekilmeye değişim ekleyebilirsiniz. Jitır, her yeniden deneme girişiminde rastgele bir gecikme ekler, bu da birden fazla istemcinin aynı anda yeniden denemesini engelleyerek yükte ani artışları önlemeye yardımcı olur.

  • 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 deneme arasında aynı zaman dilimini bekler. Örneğin, işlemi 3 saniyede bir yeniden deneyebilir.

  • Hemen yeniden deneyin. 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 hemen 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.

  • Rastgeleleştirme 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 rastgeleleştirme 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 dalgalanma stratejisiyle üstel geri çekilme kullanın ve etkileşimli işlemler için anında veya düzenli aralıklı yeniden deneme stratejilerini kullanın. Her iki durumda da, tüm deneme denemeleri için en fazla gecikmenin gerekli uçtan uca gecikme gereksinimi içinde olması için gecikmeyi ve deneme sayısını 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 yeniden denemeler arasındaki aralığın her hatadan sonra hızlı bir şekilde büyüdüğü bir katlanan gecikme stratejisi kullandığınızda, uzun genel çalışma sürelerine neden olabilir. Bir sürecin belirli bir servis düzeyi sözleşmesini (HDS) karşılaması gerekiyorsa, tüm zaman aşımı ve gecikmeler de dahil olmak üzere tüm çalışma süresi SLA'da tanımlanan sınırlar içinde olmalıdır.

• Aşırı hırslı yeniden deneme stratejilerini uygulamayın. Bunlar, çok kısa aralıklara sahip veya çok sık tekrarlanan denemelere sahip stratejilerdir. Bunlar hedef kaynak veya servis üzerinde kötü bir etkiye sahip olabilir. Bu stratejiler kaynağın veya hizmetin aşırı yüklü durumdan kurtarılmasını önleyebilir ve istekleri engellemeye veya reddetmeye devam edecektir. Bu senaryo, kaynak veya servise giderek artan istek gönderilen kısır bir döngüyle sonuçlanır. Sonuç olarak, toparlama 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ı istisnalar veya hata kodları (örneğin, yanıt içinde bir Yeniden Deneme-Sonra üst bilgisi ile birlikte HTTP kodu 503, Servis Kullanılamıyor), hatanın ne kadar sürebileceğini veya hizmetin başarısız olup sonraki girişimlere yanıt vermeyeceğini belirtebilir.

• Gelen çağrıdaki tüm bilgilerin, tüm yeniden deneme girişimleri tükendiğinde kaybolmamasını sağlamak için ölü harf kuyruğu yaklaşımını kullanmayı göz önünde bulundurun.

Anti kalıplardan kaçınma

• Çoğu durumda, yinelenen yeniden deneme kodu katmanlarını 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 sıra dışı durumlarda aşırı sayıda yeniden deneme ve gecikme süresini önleyen politikalar kullanın ve sonuçları anladığınızdan emin olun. Örneğin, bir bileşenin diğerine istekte bulunduğunu ve diğerinin ardından hedef hizmete erişim sağladığını varsayalım. Her iki çağrıda da üç deneme sayısıyla deneme uygularsanız, hizmete karşı toplam dokuz deneme olur. Birçok servis ve kaynak yerleşik bir yeniden deneme mekanizması uygular. Daha yüksek düzeyde yeniden denemeler uygulamanız gerekirse bu mekanizmaları nasıl devre dışı bırakabileceğinizi veya değiştirebileceğinizi araştırmanız gerekir.

• Asla sonsuz bir deneme mekanizması uygulamayın. Bunun yapılması, kaynağın veya hizmetin aşırı yük durumlarından kurtulmasını engeller ve kısıtlama ile reddedilen bağlantıların daha uzun süre devam etmesine neden olur. Sonlu sayıda yeniden deneme kullanın veya hizmetin kurtarılması için Devre Kesici gibi bir desen uygulayın.

• Hemen yeniden denemeyi bir kereden fazla 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 kesici özelliğine sahip üstel geri çekilme 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 stratejilerini ve uygulamayı test edin

• Özellikle uygulama ve hedef kaynaklar veya kullandığı servisler aşırı yük altında olduğunda, deneme stratejinizi mümkün olduğunca geniş bir koşullar altında tam olarak sınayın. Sınama sırasında davranışı denetlemek için şunları yapabilirsiniz:

  • Kaos mühendisliği ve hata ekleme uygulamalarınıza geçici hataları üretim dışı ve üretim ortamlarınıza bilerek ekleyerek dahil edin. Örneğin, geçersiz istek gönderin veya test isteklerini algılayan ve farklı hata türleriyle yanıt veren kod ekleyin.

  • Gerçek servisin geri dönebileceği çeşitli hatalar döndüren kaynak veya servisin modelini oluşturun. Deneme stratejinizin algılamak üzere tasarladığı tüm hata türlerini kapsayın.

  • Oluşturduğunuz ve dağıttığınız özel servisler için, geçici hataların, servisi geçici olarak devre dışı bırakarak veya aşırı yükleyerek oluşmasına zorlayın. (Azure'da paylaşılan kaynakları veya paylaşılan servisleri aşırı yüklemeyin.)

  • Otomatikleştirilmiş testlerinizdeki olumsuz senaryoları çoğaltmak için ağ trafiğini kesip 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. 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.

  • İstemci web uygulamasının geçici hatalara karşı dayanıklılığını sınarken, tarayıcının geliştirici araçlarını veya test çerçevenizin ağ isteklerinin 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, denemenin müşterinin çalışması üzerinde olumsuz bir etkisi olmamasını veya istekler arasında kontaminasyona neden olmamasını sağlamaya yardımcı olur.

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.

• Yeniden deneme ilkelerini çalışma zamanında derlemek 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 ancak yalnızca senaryonuza uygun olan yerleşik veya varsayılan yeniden deneme stratejilerinden yararlanın. Bu stratejiler geneldir. Bazı senaryolarda, ihtiyacınız olan hepsi bunlar olabilir, ancak diğer senaryolarda belirli gereksinimlerinize uyacak tam seçenek aralığı sağlamaz. En uygun değerleri belirlemek için, ayarların uygulamanızı nasıl etkilediğini anlamak için sınama gerçekleştirmeniz gerekir.

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

• Yeniden deneme stratejinizin bir parçası olarak, hata yönetimi ve yeniden deneme girişimlerini kaydeden diğer izleme araçlarını ekleyin. Zaman zaman geçici bir hata ve yeniden deneme bekleniyor ve bir sorun göstermez. Ancak, düzenli ve artan sayıda yeniden deneme, genellikle bir hataya neden olabilecek veya uygulama performansını ve kullanılabilirliğini düşürebilecek bir sorunun göstergesidir.

• İzleme sistemlerinin yanlış uyarıları tetikleyebilecek uygulama hatası olarak algılanmalarını önlemek için geçici hataları hata kayıtları yerine uyarı kayıtları olarak günlüğe aktarabilirsiniz.

• Veri çözümlemesi sırasında ayrıştırabilmeniz için günlük girdilerinizde yeniden denemelerin serviste azaltmadan mı yoksa bağlantı hataları gibi diğer türlerden mi kaynaklandığını gösteren bir değeri depolamayı düşünün. Kısıtlama hatalarının sayısındaki artış genellikle uygulamadaki bir tasarım kusurunun veya ayrılmış donanım sunan bir premium hizmete geçme 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ı, yeniden deneme sayısı veya işlemler başarılı olmadan önce geçen genel süreler arttığında uyarıları artırabilecek bir telemetri ve izleme sistemi uygulayın.

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

• Her denemede başarısız olmaya devam eden işlemlerin 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 ne zaman kullanılabilir olduğunu saptamak için servisi düzenli olarak, zaman zaman ve istekler arasında uzun aralıklarla test edebilir. Uygun bir aralık, işlemin kritikliği ve servisin yapısı gibi etmenlere bağlıdır. Birkaç dakika ile birkaç saat arasında bir şey olabilir. Sınama başarılı olduğunda, uygulama normal işlemleri sürdürebilir ve yeni kurtarılan hizmete istekleri iletebilir.

  • 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 için istekleri bir kuyrukta veya veri deposu depolayıp 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.

Yeniden deneme uygulamasını iyileştirme

• Bir ilke için yeniden deneme sayısının ve deneme aralıklarının değerlerine karar verirken, servis veya kaynak üzerindeki işlemin uzun süren bir ya da çok aşamalı bir işlemin parçası olup olmadığını düşünün. 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ı düşünün. Çok adımlı bir sürecin bazı bölümleri yinelenirse ve işlemler idempotent değilse, tutarsızlıklar ortaya çıkabilir. Ö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ı idempotent bir işlem olarak tasarlayın. Daha fazla bilgi için bkz. Idempotency desenleri.

• Yeniden denenen işlemlerin kapsamını düşünün. Örneğin, birkaç işlemi kapsayan bir düzeyde yeniden deneme kodunu uygulamak ve biri başarısız olursa bunları yeniden denemek daha kolay olabilir. Ancak bunun yapılması, özdeşlik 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ı ve hizmetleri paylaşan uygulamalar için artan sayıda geçici hata oluşması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 gerekçelendirmenize yardımcı olabilir.

Uyarı

Dengeler 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 hizmetlerinin kolaylaştırılması

Ç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ığından 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	Politika yapılandırması	Scope	Telemetri özellikleri
Microsoft Entra ID	Microsoft Kimlik Doğrulama Kitaplığı'nda (MSAL) yerel	MSAL kitaplığına eklenmiş	Dahili	Hiç kimse
Azure Cosmos DB	Hizmette yerel	Yapılandırılamaz	Global	TraceSource
Azure Data Lake Storage	İstemciye özgü	Yapılandırılamaz	Tek tek işlemler	Hiç kimse
Azure Event Hubs	İstemciye özgü	Programmatic	Müşteri	Hiç kimse
Azure IoT Hub	İstemci SDK'sında yerleşik	Programmatic	Müşteri	Hiç kimse
Azure Bilişsel Arama	İstemciye özgü	Programmatic	Müşteri	ETW veya özel
Azure Service Bus	İstemciye özgü	Programmatic	NamespaceManager, MessagingFactory ve istemci	ETW
Azure Service Fabric	İstemciye özgü	Programmatic	Müşteri	Hiç kimse
ADO.NET ile Azure SQL Veritabanı	Polly	Bildirim temelli ve programatik	Tek deyimler veya kod blokları	Özelleştirilmiş
Entity Framework ile SQL Veritabanı	İstemciye özgü	Programmatic	AppDomain başına genel	Hiç kimse
Entity Framework Core ile SQL Veritabanı	İstemciye özgü	Programmatic	AppDomain başına genel	Hiç kimse
Azure Depolama	İstemciye özgü	Programmatic	Müşteri ve bireysel işlemler	TraceSource

Uyarı

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 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.

Example

Bu makalede ele alınan 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.

İlgili bağlantılar

• Circuit Breaker tasarımı
• Yeniden Deneme düzeni
• Kısıtlama deseni
• Telafi İşlemi Deseni
• Bağlantı Dayanıklılığı
• Sahte hizmetler ekleme
• Teslim edilemeyen ileti kuyruğu düzeni

Güvenilirlik denetim listesi

Öneriler kümesinin tamamına bakın.

Güvenilirlik denetim listesi