Geçici hata işleme
Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara karşı duyarlı olması gerekir. Bu durum özellikle ortamın niteliği ve İnternet üzerinden bağlantı nedeniyle bu tür hatalarla karşılaşma sıklığının arttığı bulutta çalışan uygulamalar için geçerlidir. Bileşen ve hizmetlerle ağ bağlantısının anlık olarak kaybedilmesi, bir hizmetin geçici olarak kullanım dışı kalması veya bir hizmet meşgul olduğunda gerçekleşen zaman aşımları bu geçici hatalar arasında yer alır. Bu hatalar genellikle kendi kendini düzelter ve eylem uygun bir gecikmeden sonra tekrarlanırsa başarılı olma olasılığı vardır.
Bu belge geçici hata işlemeye yönelik genel yönergeleri içerir. Microsoft Azure hizmetlerini kullanırken geçici hataları işleme hakkında bilgi için bkz. Azure hizmete özgü yeniden deneme yönergeleri.
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ıştırilen çözümlerde, uygulamanın ve bileşenlerinin performansı ve kullanılabilirliği genellikle pahalı ve çoğunlukla az kullanılan donanım yedekliliği aracılığıyla korunur ve bileşenler ve kaynaklar birbirine yakın bulunur. Bu yaklaşım hata olasılığı düşük olsa da geçici hatalara ve hatta dış güç kaynağı veya ağ sorunları ya da diğer olağanüstü durum senaryoları gibi öngörülemeyen olaylarla kesintiye neden olabilir.
Özel bulut sistemleri de dahil olmak üzere bulut barındırma, paylaşılan kaynaklar, yedeklilik, otomatik yük devretme ve birçok ticari işlem düğümünde dinamik kaynak ayırmayı kullanarak daha yüksek genel kullanılabilirlik sunabilmektedir. Ancak, bu ortamların niteliği geçici hataların gerçekleşme olasılığını artırabilir. Bunun birkaç nedeni vardır:
Bir bulut ortamında birçok kaynak paylaşılır ve bu kaynaklara erişim, kaynağı korumak için ağ kapasitesi azaltmaya tabidir. Yük belirli bir düzeye yükseldiğinde veya en yüksek aktarım hızına ulaşıldığında, mevcut isteklerin işlenmesine izin vermek ve hizmetin tüm kullanıcılar için performansını sürdürmek amacıyla bazı hizmetler bağlantıları reddeder. Ağ kapasitesini azaltma, hizmetin komşular ve paylaşılan kaynağı kullanan diğer kiracılar için hizmet kalitesini sürdürmesine yardımcı olur.
Bulut ortamları, çok sayıda ticari donanım birimi kullanılarak oluşturulur. Bunlar yükü birden fazla işleme birimi arasında dinamik olarak dağıtarak performans sunar ve başarısız birimleri otomatik olarak geri dönüştürerek ya da değiştirerek güvenilirlik sağlar. Bu dinamik yapı, geçici hataların ve geçici bağlantı hatalarının arı sıra oluşabileceği anlamına gelir.
Uygulama ile kullandığı kaynak ve hizmetler arasında genellikle yönlendiriciler ve yük dengeleyiciler gibi ağ altyapıları dahil olmak üzere daha fazla donanım bileşeni mevcuttur. 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 iletişim İnternet’ten geçtiğinde değişken olabilir. Şirket içi konumlarda bile ağır trafik yükleri iletişimi yavaşlatarak aralıklı bağlantı hatalarına neden olabilir.
Zorluklar
Geçici hatalar, öngörülebilir tüm koşullarda kapsamlı olarak test edilmiş olsa bile 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ışması için bu uygulamaların aşağıdaki sorunlara yanıt verebilmesi gerekir:
Uygulama, oluşan hataları algılayabilmeli ve bu hataların geçici, daha uzun süreli veya terminal hataları olup olmadığını belirleyebilmelidir. Bir hata oluştuğunda farklı kaynaklar farklı yanıtlar döndürebilir ve bu yanıtlar da işlemin bağlamına göre farklılık görebilir; örneğin, bir hata için depolama alanından okurken verilen yanıt, depolama alanına yazarken verilen yanıttan farklı olabilir. Birçok kaynak ve hizmet, iyi belgelenmiş geçici hata sözleşmelerine sahiptir. Ancak, bu tür bilgilerin mevcut olmadığı durumlarda hatanın niteliğini bulmak ve geçici olup olmadığını anlamak zor olabilir.
Uygulama, arızanın geçici olabileceğini belirlerse işlemi yeniden deneyebilmeli ve işlemin kaç kez denendiğini takip edebilmelidir.
Uygulama, yeniden denemeler için uygun bir strateji kullanmalıdır. Bu strateji, kaç kez yeniden denemesi gerektiğini, her girişim arasındaki gecikmeyi ve başarısız bir girişimden sonra yapılacak işlemleri belirtir. Uygun girişim sayısını ve her girişim arasındaki gecikmeyi belirlemek genellikle zordur ve kaynağın türüne ve kaynak ile uygulamanın geçerli çalışma koşullarına göre farklılık gösterir.
Genel yönergeler
Aşağıdaki yönergeler, uygulamalarınız için uygun bir geçici hata işleme mekanizması tasarlamanıza yardımcı olur:
Yerleşik bir yeniden deneme mekanizması olup olmadığını belirleyin:
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, REST hizmet arabirimleri bir yeniden denemenin uygun olup olmadığını ve sonraki yeniden deneme girişiminden önce ne kadar beklenmesi gerektiğini belirlemede yararlı bilgiler döndürebilir.
Farklı bir yeniden deneme davranışını daha uygun hale alan belirli ve iyi anlaşılmış gereksinimleriniz yoksa, kullanılabilir olduğunda yerleşik yeniden deneme mekanizmasını kullanın.
İşlemin yeniden deneme için uygun olup olmadığını belirleyin:
Yalnızca hatalar geçici olduğunda (genellikle hatanın niteliği ile belirtilir) ve yeniden denendiğinde işlemin başarılı olacağına dair en azından bir olasılık varsa işlemleri yeniden deneyin. Mevcut olmayan bir öğeye yapılan veritabanı güncelleştirmesi ya da önemli bir hatanın yaşanmasına neden olan bir hizmete veya kaynağa istekler gibi geçersiz bir işlemi gösteren işlemleri yeniden oluşturmanın hiçbir anlamı yoktur.
Genel olarak, yalnızca tam etkisi belirlenebilen ve koşulların iyi anlaşıldığı ve doğrulanabildiği yeniden denemeleri uygulamanız gerekir. Aksi durumda, yeniden deneme uygulamalarını çağıran koduna bırakın. Denetiminiz dışındaki kaynak 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.
Hizmet veya bileşenler oluştururken istemcilerin başarısız işlemleri yeniden denemesi gerekip gerekmediğini belirlemesine yardımcı olacak hata kodlarını ve iletileri uygulamayı düşünün. Özellikle, istemcinin işlemi yeniden denemesinin (belki de bir isTransient değeri döndürerek) gerekli olup olmadığını belirtin ve sonraki yeniden deneme girişiminden önce uygun bir gecikme önerin. Bir web hizmeti derliyorsanız hizmet sözleşmenizde tanımlanmış özel hataları döndürmeyi düşünün. Genel istemciler okuyamıyor olsa da, özel istemciler oluştururken bunlar yararlı olacaktır.
Uygun bir yeniden deneme sayısı ve aralığı belirleyin:
Yeniden deneme sayısı ve aralığının kullanım örneği türüne en uygun duruma getirmek önemlidir. Yeterli sayıda yeniden deneme yapmazsanız, uygulama işlemi tamamlayamaz ve bir hatayla karşılaşabilir. Çok fazla sayıda yeniden deneme yaparsanız ya da denemeler arasında çok kısa bir aralık bırakırsanız, uygulama iş parçacıkları, bağlantılar ve bellek gibi kaynakları uzun süreler boyunca tutabilir ve uygulama sağlığı olumsuz yönde etkilenebilir.
Zaman aralığı ve yeniden deneme sayısı için uygun değerler, denenen işlemin türüne bağlıdır. Örneğin, işlem bir kullanıcı etkileşiminin parçası ise, kullanıcıların bir yanıt beklemesini (bağlantıları açık tutan ve diğer kullanıcılar için kullanılabilirliği azaltabilen bir durumdur) önlemek için aralık kısa tutulmalı ve yalnızca birkaç yeniden deneme yapılmalıdır. İşlem, işlemi iptal edip yeniden başlatmanın pahalı veya zaman alıcı olduğu uzun süre çalışan veya kritik bir iş akışının parçası ise, denemeler arasında daha uzun beklemek ve daha fazla kez yeniden denemek uygun olur.
Yeniden denemeler arasında uygun aralıkların belirlenmesi başarılı bir strateji tasarlamanın en zor kısmıdır. 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 izleyen her yeniden deneme arasındaki zamanı üstel olarak artırmaktadı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ında artımlı olarak zamanı artırmaktadı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 ağ paketi çakışması veya donanım bileşeninde ani artış gibi bir olay nedeniyle geçici bir hata kısa olabilir. Bu durumda, uygulamanın sonraki isteği toplayıp göndermesi için geçen sürede hata giderildiyse başarılı olabileceği için işlemin hemen yeniden denenmesi uygundur. Ancak, hiçbir zaman birden fazla anında yeniden deneme girişimi olması ve hemen yeniden denemenin başarısız olması durumunda üstel geri alma veya geri dönüş eylemleri gibi alternatif stratejilere geçmelisiniz.
Rastgele . Yukarıda listelenen yeniden deneme stratejilerinin herhangi biri, istemcinin birden fazla örneğinin sonraki yeniden deneme girişimlerini aynı anda göndermesini önlemek üzere bir rastgele seçim içerebilir. Örneğin, bir örnek işlemi 3 saniye, 11 saniye, 28 saniye gibi bir süre sonra yeniden denese de, başka bir örnek işlemi 4 saniye, 12 saniye, 26 saniye gibi bir süre sonra yeniden sınıyor olabilir. Rastgele seçim, diğer stratejilerle birleştirilebilen yararlı bir tekniktir.
Genel bir kural olarak, arka plan işlemleri için üstel geri alma stratejisini ve etkileşimli işlemler için hemen ya da düzenli aralıklarla 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şlemin genel en uzun zaman aşımı değerine katkıda bulunan tüm faktörlerin birleşimini göz önünde bulundurun. Bu faktörler başarısız bir bağlantının yanıt oluşturması için geçen süreyi (genellikle istemcideki bir zaman aşımı değeri ile belirlenir) ve yeniden deneme girişimleri arasındaki gecikme ile en fazla yeniden deneme sayısını içerir. Tüm bu sürelerin toplamı, özellikle yeniden denemeler arasındaki aralığın her hatadan sonra hızla arttıkça üstel gecikme stratejisini kullanırken uzun bir genel işlem süresine neden olabilir. Bir sürecin belirli bir hizmet düzeyi sözleşmesine (SLA) uygun olması gerekirse, tüm zaman aşımı ve gecikmeler de dahil olmak üzere genel işlem süresi SLA'da tanımlanan sınırlar içinde yer almalıdır.
Çok kısa aralıklara veya çok sık yeniden denemelere sahip olan aşırı agresif yeniden deneme stratejileri, hedef kaynak veya hizmeti olumsuz yönde etkileyene neden olabilir. Bu durum, kaynak veya hizmetin aşırı yüklenmiş durumundan kurtulmasını engelleyebilir ve istekleri engellemeye ya da reddetmeye devam eder. Bu durum, kaynağa ya da hizmete giderek daha fazla isteğin gönderildiği ve sonuç olarak kurtarma becerisinin daha da azaldığı kısır bir döngüyle sonuçlanabilir.
Sonraki bir girişimi hemen başlatmaktan kaçınmak için yeniden deneme aralıklarını seçerek işlemlerin zaman aşımını hesaba katı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ın gerekli olup olmadığını düşünün. Olağan dışı derecede kısa veya çok uzun zaman aşımlarına sahip işlemler ne kadar süre bekleneceğini ve işlemin ne sıklıkla deneneceğini etkileyebilir.
Aralığı ve yeniden deneme sayısını en iyi duruma getirmek için özel durumun türünü ve içerdiği verileri ya da hizmetten döndürülen hata kodları ile iletileri kullanın. Örneğin, bazı özel durumlar veya hata kodları (yanıtta Retry-After üst bilgisini içeren 503 Hizmet Kullanılamıyor HTTP kodu gibi) hatanın ne kadar sürebileceğini veya hizmetin başarısız olduğunu ve sonraki denemelere yanıt vermeyeceğini gösterebilir.
Anti düzenler kullanmaktan kaçının:
Örneklerin büyük çoğunluğunda yeniden deneme kodunun yinelenen katmanlarını içeren uygulamalardan kaçınmanız gerekir. Bunu gerektiren özel gereksinimleriniz olmadıkça, basamaklı yeniden deneme mekanizmaları içeren veya istek hiyerarşisinin bulunduğu bir işlemin her aşamasında yeniden deneme uygulayan tasarımlardan uzak durun. 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şen başka bir bileşene hedef hizmete erişecek bir istekte bulunursa ve her iki çağrıda da üç yeniden deneme uygularsanız, toplamda hizmete yönelik dokuz yeniden deneme girişimi olur. Çok sayıda hizmet ve kaynak, yerleşik bir yeniden deneme mekanizması uygular ve daha yüksek düzeyde yeniden denemeler uygulamanız gerekiyorsa bunu nasıl devre dışı bırakacağınızı veya değiştirebileceğinizi araştırmanız gerekir.
Hiçbir zaman sonsuz bir yeniden deneme mekanizması uygulamayın. Bu mekanizma, kaynağın veya hizmetin aşırı yük durumlarından kurtulmasını önleyebilir ve ağ kapasitesi azaltmaya ve reddedilen bağlantıların daha uzun süre devam etmesine neden olur. Sınırlı sayıda yeniden deneme yapın veya hizmetin kurtulmasına izin vermek için Devre Kesici gibi bir düzen uygulayın.
Hemen yeniden denemeyi hiçbir zaman birden çok kez gerçekleştirmeyin.
Özellikle çok sayıda yeniden deneme girişiminiz olduğunda, Azure’da hizmet ve kaynaklara erişirken düzenli bir yeniden deneme aralığı kullanmaktan kaçının. Bu senaryodaki en iyi yaklaşım, devre kesici özelliğine sahip bir üstel geri alma stratejisidir.
Aynı istemcinin birden çok örneğinin veya farklı istemcilerin birden çok örneğinin aynı anda yeniden denemeler göndermesini önleyin. Bu durumun olasılığı yüksekse, yeniden deneme aralıklarına rastgele seçim ekleyin.
Yeniden deneme stratejinizi ve uygulamanızı test edin:
Özellikle hem uygulama hem de kullandığı hedef kaynaklar veya hizmetler aşırı yük altında olduğunda yeniden deneme stratejisi uygulamanızı mümkün olduğunca çeşitli koşullar altında tamamen test ettiğinizden emin olun. 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’si kullanma örneği için bkz. TestApi ile Hata Ekleme Testi ve TestApi’sine Giriş – Bölüm 5: Yönetilen Kod Hata Ekleme API’leri.
Gerçek hizmetin döndürebileceği bir dizi hatayı döndüren yapay bir kaynak ya da hizmet oluşturun. Yeniden deneme stratejinizin algılamak üzere tasarlandığı tüm hata türlerini kapsama aldığınızdan emin olun.
Geçici hataları, oluşturduğunuz ve dağıttığınız özel bir hizmet olan hizmeti geçici olarak devre dışı bırakarak veya aşırı yükleyerek ortaya çıkmaya zorlamak (Tabii ki, paylaşılan kaynakları veya Azure 'da paylaşılan hizmetleri aşırı yüklemeyi denememelisiniz).
HTTP tabanlı API’ler için, fazladan gidiş dönüş sayıları 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 üzere otomatikleştirilmiş testlerinizde FiddlerCore kitaplığını kullanmayı deneyin. Bunun yapılması, geçici hatalar ya da diğer hata türleri için hata koşullarının bir alt kümesinin belirleyici bir testten geçirilmesini sağlar. Daha fazla bilgi için bkz. FiddlerCore. Başta HttpMangler sınıfı olmak üzere kitaplığı kullanma örnekleri için Azure Depolama SDK'sı kayna kodunu inceleyin.
Yeniden deneme mekanizması ve stratejisinin bu koşullar altında doğru şekilde çalıştığından ve istemcinin çalışmasını olumsuz yönde etkilemediğinden ya da istekler arasında çapraz kirlenmeye yol açmadığından emin olun.
Yeniden deneme ilkesi yapılandırmalarını yönetin:
Yeniden deneme ilkesi, yeniden deneme stratejinizin tüm öğelerinin bir birleşimidir. Bir hatanın geçici olma olasılığını, kullanılacak aralığın türünü (düzenli, üstel geri alma ve rastgele seçim gibi), gerçek aralık değerlerini ve yeniden deneme sayısını belirleyen algılama mekanizmasını tanımlar.
Yeniden denemeler en basit uygulamada bile birçok yerde ve daha karmaşık uygulamaların her katmanında uygulanmalıdır. Her bir ilkenin birden fazla konumdaki öğelerini sabit kodlamak yerine tüm ilkeleri depolamaya yönelik merkezi bir nokta kullanmayı düşünün. Ö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 ilkeleri oluşturun. Bu, ayarları yönetmeyi ve değişen gereksinimlere ve senaryolara yanıt vermek için değerlerin değişiklik ve ince ayar yapma işlemlerini kolaylaştırır. Ancak, sistemi her defasında bir yapılandırma dosyasını yeniden okumak yerine değerleri depolayacak şekilde tasarlayın ve değerler yapılandırma dosyasından alınamıyorsa uygun varsayılanların kullanıldığından emin olun.
Bir Azure Cloud Services uygulamasında, çalışma zamanında yeniden deneme ilkeleri oluşturmak için kullanılan değerleri, uygulamayı yeniden başlatmaya gerek kalmadan değiştirilebilmeleri için hizmet yapılandırma dosyasında depolamayı düşünün.
Senaryonuz için uygun olduğunda, kullandığınız istemci API’lerinde mevcut olan yerleşik veya varsayılan yeniden deneme stratejilerinden yararlanın. Bu stratejiler genellikle genel amaçlardır. Bazı senaryolarda tüm gerekli olan bunlardır, ancak bazı senaryolarda gereksinimlerinize uyacak tüm seçenekleri sunmayabilirler. En uygun değerleri belirlemek için ayarların uygulamanızı testlerle nasıl etkileyeceğini anlamanız gerekir.
Geçici ve geçici olmayan hataları günlüğe kaydet ve izle:
Yeniden deneme girişimleri olduğunda günlüğe kaydedilen özel durum işleme ve diğer izlemeleri yeniden deneme stratejinize dahil edin. Geçici olarak geçici bir hata ve yeniden deneme beklenirken, bir sorun belirtmediğinden, düzenli ve yeniden deneme sayısı genellikle hataya neden olabilecek veya uygulama performansını ve kullanılabilirliğini düşürmeye yönelik bir göstergedir.
İzleme sistemlerinin geçici hataları hatalı uyarılar tetikleyebilecek uygulama hataları olarak algılamaması için geçici hataları Hata girişleri yerine Uyarı girişleri olarak günlüğe kaydedin.
Yeniden denemelerin nedeni hizmetteki bir kapasite azalması veya bağlantı hataları gibi diğer hata türleri ise, verilerin analizi sırasında ayırt edebilmeniz için değeri günlük girişlerinizde depolamayı düşünün. 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 toplam süreyi ölçmeyi ve günlüğe kaydetmeyi düşünün. Bu, 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. Yanıt süresine katkıda bulunan faktörleri anlamak için gerçekleşen yeniden denemelerin sayısını da günlüğe kaydedin.
Hata sayısı ve oranı, ortalama yeniden deneme sayısı veya işlemlerin başarılı olması için geçen toplam süreler arttığında uyarılar oluşturabilen bir telemetri ve izleme sistemi uygulamayı düşünün.
Sürekli olarak başarısız olan işlemleri yönetin:
İşlemin her girişimde başarısız olmaya devam edeceği durumlar olacaktır ve bu durumla nasıl başa çıkacağınızı düşünmeniz önemlidir:
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ı önlemez. Örneğin, bir sipariş işleme hizmeti onu kalıcı olarak işlem dışı bırakan önemli bir hata ile başarısız olursa, yeniden deneme stratejisi bir bağlantı zaman aşımı algılayabilir ve bunu geçici hata olarak kabul edebilir. Kod, işlemi belirtilen sayıda yeniden dener ve sonra bırakır. Ancak, başka bir müşteri sipariş verdiğinde, her defasında başarısız olacağı kesin olmasına rağmen işlem tekrar denenir.
Sürekli başarısız olan işlemler için sürekli yeniden denemeyi önlemek için Devre Kesici düzenini uygulamayı düşünün. Bu düzende, belirtilen bir zaman penceresi içinde hata sayısı eşiği aşarsa istekler, başarısız kaynağa veya hizmete erişim girişimi olmadan hemen hata olarak çağırana döndürülür.
Uygulama, hizmetin ne zaman kullanılabilir hale geldiğini algılamak için hizmeti düzenli aralıklarla ve istekler arasında uzun aralıklara göre düzenli olarak test edebilir. Uygun bir aralık, işlemin kritikliği ve hizmetin niteliği gibi senaryoya bağlı olarak değişir ve birkaç dakika ile birkaç saat arasında olabilir. Testin başarılı olduğu noktada uygulama normal işlemlerine devam edebilir ve istekleri yeni kurtarılan hizmete geçirebilir.
Bu sırada hizmetin başka bir örneğine (farklı bir veri merkezi veya uygulamada olabilir) geri dönmek, uyumlu (belki de daha basit) işlevler sunan benzer bir hizmet kullanmak ya da hizmetin yakın zamanda kullanılabilir duruma geleceği umuduyla bazı alternatif işlemler gerçekleştirmek mümkündür. Örneğin, hizmete ilişkin isteklerin bir kuyrukta veya veri deposunda depolanması ve daha sonra yeniden yürütülmesi uygun olabilir. Aksi takdirde kullanıcıyı uygulamanın alternatif bir örneğine yönlendirebilir, uygulamanın performansını bozabilir ancak diğer yandan hala kabul edilebilir işlevsellik sunabilir ya da yalnızca kullanıcıya uygulamanın o anda kullanılabilir olmadığını belirten bir ileti döndürebilirsiniz.
Diğer önemli noktalar
Yeniden deneme sayısı ve bir ilke için yeniden deneme aralığı değerlerini belirlerken, hizmet veya kaynaktaki işlemin uzun süre çalışan veya çok adımlı bir işlemin parçası olup olmadığını göz önünde bulundurun. Bir işlem adımı başarısız olduğunda zaten başarılı olmuş diğer tüm işlem adımlarını dengelemek zor veya pahalı olabilir. Bu durumda, nadir kaynakları tutarak veya kilitleyerek diğer işlemleri engellemediği sürece çok uzun bir aralık ve çok fazla sayıda yeniden deneme kabul edilebilir.
Aynı işlemi yeniden denemenin verilerde tutarsızlıklara neden olabileceğini göz önünde bulundurun. Çok adımlı bir işlemin bazı bölümleri yinelenirse ve işlemler ıdempotent değilse, tutarsızlığa neden olabilir. Örneğin, bir değeri artıran işlem yinelenirse geçersiz bir sonuç oluşturur. Bir kuyruğa ileti gönderen bir işlemin tekrarlanması, yinelenen iletileri agılayamıyorsa ileti tüketicisinde bir tutarsızlığa neden olabilir. Bunu önlemek için her adımı bir kez etkili bir işlem olarak tasarladığınızdan emin olun. Idempotlik hakkında daha fazla bilgi için bkz. ıdempotlik desenleri.
Yeniden denenecek işlemlerin kapsamını göz önünde bulundurun. Örneğin, yeniden deneme kodunu çeşitli işlemleri kapsayan bir düzeyde uygulamak ve biri başarısız olursa tümünü yeniden denemek daha kolay olabilir. Ancak, bunun yapılması teklik 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, geçen süreyi izlerken ve hatalar için uyarılar oluşturmadan önce tümünün toplam gecikmesini hesaba katın.
Yeniden deneme stratejinizin paylaşılan bir uygulamada veya paylaşılan kaynak ve hizmetler kullanılırken komşuları ve diğer kiracıları nasıl etkileyebileceğini 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 kaynak ve hizmetlerin diğer kullanıcıları tarafından uygulanan yeniden ilkelerinden etkilenebilir. Kritik görev uygulamaları için paylaşılmayan premium hizmetleri kullanmaya karar verebilirsiniz. Bunun yapılması, bu kaynak ve hizmetlerin yükü ve sonuç olarak kapasite azaltması üzerinde daha fazla denetiminizin olmasını sağlar ve ek maliyetleri açıklamaya yardımcı olabilir.