Geçici hata işlemeTransient fault handling

Uzak hizmetler ve kaynaklarla iletişim kuran tüm uygulamaların geçici hatalara karşı duyarlı olması gerekir.All applications that communicate with remote services and resources must be sensitive to transient faults. 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.This is especially the case for applications that run in the cloud, where the nature of the environment and connectivity over the Internet means these types of faults are likely to be encountered more often. 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.Transient faults include the momentary loss of network connectivity to components and services, the temporary unavailability of a service, or timeouts that arise when a service is busy. Bu hatalar genellikle kendi kendini düzeltir ve uygun bir gecikmeden sonra eylem yinelenirse başarılı olma olasılığı yüksektir.These faults are often self-correcting, and if the action is repeated after a suitable delay it is likely succeed.

Bu belge geçici hata işlemeye yönelik genel yönergeleri içerir.This document covers general guidance for transient fault handling. Microsoft Azure hizmetlerini kullanırken geçici hataları işleme hakkında bilgi için bkz. Azure hizmete özgü yeniden deneme yönergeleri.For information about handling transient faults when using Microsoft Azure services, see Azure service-specific retry guidelines.

Neden bulutta geçici hatalar oluşur?Why do transient faults occur in the cloud?

Geçici hatalar her türlü ortamda, herhangi bir platformda veya işletim sisteminde ve herhangi bir uygulama türünde gerçekleşebilir.Transient faults can occur in any environment, on any platform or operating system, and in any kind of application. Yerel, şirket içi altyapıda çalışan çözümlerde uygulama ve bileşenlerinin performans ve kullanılabilirliği genellikle pahalı ve çoğunlukla az kullanılan donanım yedekliliği ile sağlanır ve bileşenler ile kaynaklar birbirine yakın konumlandırılır.In solutions that run on local, on-premises infrastructure, performance and availability of the application and its components is typically maintained through expensive and often under-used hardware redundancy, and components and resources are located close to each another. Bu durum hata olasılığını azaltsa da hala geçici hatalarla ve hatta dış güç kaynağı veya ağ sorunları gibi öngörülemeyen olaylarla ya da diğer olağanüstü durum senaryoları ile sonuçlanabilir.While this makes a failure less likely, it can still result in transient faults - and even an outage through unforeseen events such as external power supply or network issues, or other disaster scenarios.

Özel bulut sistemleri dahil olmak üzere bulut barındırma, çok sayıda ticari işlem düğümleri arasında paylaşılan kaynak, yedeklilik, otomatik yük devretme ve dinamik kaynak ayırmayı kullanarak daha yüksek bir genel kullanılabilirlik sunabilir.Cloud hosting, including private cloud systems, can offer a higher overall availability by using shared resources, redundancy, automatic failover, and dynamic resource allocation across a huge number of commodity compute nodes. Ancak, bu ortamların niteliği geçici hataların gerçekleşme olasılığını artırabilir.However, the nature of these environments can mean that transient faults are more likely to occur. Bunun birkaç nedeni vardır:There are several reasons for this:

  • Bir bulut ortamında birçok kaynak paylaşılır ve bu kaynaklara erişim, kaynağı korumak için ağ kapasitesi azaltmaya tabidir.Many resources in a cloud environment are shared, and access to these resources is subject to throttling in order to protect the resource. 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.Some services will refuse connections when the load rises to a specific level, or a maximum throughput rate is reached, in order to allow processing of existing requests and to maintain performance of the service for all users. 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.Throttling helps to maintain the quality of service for neighbors and other tenants using the shared resource.

  • Bulut ortamları, çok sayıda ticari donanım birimi kullanılarak oluşturulur.Cloud environments are built using vast numbers of commodity hardware units. 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.They deliver performance by dynamically distributing the load across multiple computing units and infrastructure components, and deliver reliability by automatically recycling or replacing failed units. Bu dinamik yapı, geçici hataların ve geçici bağlantı hatalarının arı sıra oluşabileceği anlamına gelir.This dynamic nature means that transient faults and temporary connection failures may occasionally occur.

  • 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.There are often more hardware components, including network infrastructure such as routers and load balancers, between the application and the resources and services it uses. Bu ek altyapı zaman zaman ek bağlantı gecikme süresi ve geçici bağlantı hataları oluşturabilir.This additional infrastructure can occasionally introduce additional connection latency and transient connection faults.

  • İstemci ile sunucu arasındaki ağ koşulları, özellikle iletişim İnternet’ten geçtiğinde değişken olabilir.Network conditions between the client and the server may be variable, especially when communication crosses the Internet. Şirket içi konumlarda bile çok ağır trafik yükleri iletişimi yavaşlatabilir ve aralıklı bağlantı hatalarına neden olabilir.Even in on-premises locations, very heavy traffic loads may slow communication and cause intermittent connection failures.

ZorluklarChallenges

Geçici hatalar, öngörülebilir tüm koşullar altında kapsamlı testlerden geçirilmiş olsa bile bir uygulamanın algılanan kullanılabilirliğini önemli ölçüde etkileyebilir.Transient faults can have a huge impact on the perceived availability of an application, even if it has been thoroughly tested under all foreseeable circumstances. 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:To ensure that cloud-hosted applications operate reliably, they must be able to respond to the following challenges:

  • Uygulama, oluşan hataları algılayabilmeli ve bu hataların geçici, daha uzun süreli veya terminal hataları olup olmadığını belirleyebilmelidir.The application must be able to detect faults when they occur, and determine if these faults are likely to be transient, more long-lasting, or are terminal failures. 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.Different resources are likely to return different responses when a fault occurs, and these responses may also vary depending on the context of the operation; for example, the response for an error when reading from storage may be different from response for an error when writing to storage. Birçok kaynak ve hizmet, iyi belgelenmiş geçici hata sözleşmelerine sahiptir.Many resources and services have well-documented transient failure contracts. Ancak, bu tür bilgilerin mevcut olmadığı durumlarda hatanın niteliğini bulmak ve geçici olup olmadığını anlamak zor olabilir.However, where such information is not available, it may be difficult to discover the nature of the fault and whether it is likely to be transient.

  • Uygulama, arızanın geçici olabileceğini belirlerse işlemi yeniden deneyebilmeli ve işlemin kaç kez denendiğini takip edebilmelidir.The application must be able to retry the operation if it determines that the fault is likely to be transient and keep track of the number of times the operation was retried.

  • Uygulama, yeniden denemeler için uygun bir strateji kullanmalıdır.The application must use an appropriate strategy for the retries. 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.This strategy specifies the number of times it should retry, the delay between each attempt, and the actions to take after a failed attempt. 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.The appropriate number of attempts and the delay between each one are often difficult to determine, and vary based on the type of resource as well as the current operating conditions of the resource and the application itself.

Genel yönergelerGeneral guidelines

Aşağıdaki yönergeler uygulamalarınız için uygun bir geçici hata işleme mekanizması tasarlamanıza yardımcı olur:The following guidelines will help you to design a suitable transient fault handing mechanism for your applications:

  • Yerleşik bir yeniden deneme mekanizması olup olmadığını belirleyin:Determine if there is a built-in retry mechanism:

    • Birçok hizmet, geçici hata işleme mekanizması içeren bir SDK ya da istemci kitaplığı sağlar.Many services provide an SDK or client library that contains a transient fault handling mechanism. Kullandığı yeniden deneme ilkesi genellikle hedef hizmetin niteliğine ve gereksinimlerine uygun hale getirilir.The retry policy it uses is typically tailored to the nature and requirements of the target service. 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.Alternatively, REST interfaces for services may return information that is useful in determining whether a retry is appropriate, and how long to wait before the next retry attempt.

    • Farklı bir yeniden deneme davranışının daha uygun olduğu anlamına gelen belirli ve iyi anlaşılmış gereksinimleriniz olmadıkça, mevcut olduğunda yerleşik yeniden deneme mekanizmasını kullanın.Use the built-in retry mechanism where one is available unless you have specific and well-understood requirements that mean a different retry behavior is more appropriate.

  • İşlemin yeniden deneme için uygun olup olmadığını belirleyin:Determine if the operation is suitable for retrying:

    • 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.You should only retry operations where the faults are transient (typically indicated by the nature of the error), and if there is at least some likelihood that the operation will succeed when reattempted. Var olmayan bir öğede veritabanı güncelleştirmesi ya da önemli hata ile karşılaşmış bir hizmet ya da kaynağa gönderilen istekler gibi geçersiz bir işlemi belirten işlemleri yeniden denemenin bir faydası yokturThere is no point in reattempting operations that indicate an invalid operation such as a database update to an item that does not exist, or requests to a service or resource that has suffered a fatal error

    • Genel olarak, yalnızca tam etkisi belirlenebilen ve koşulların iyi anlaşıldığı ve doğrulanabildiği yeniden denemeleri uygulamanız gerekir.In general, you should implement retries only where the full impact of this can be determined, and the conditions are well understood and can be validated. Aksi durumda, yeniden deneme uygulamalarını çağıran koduna bırakın.If not, leave it to the calling code to implement retries. 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.Remember that the errors returned from resources and services outside your control may evolve over time, and you may need to revisit your transient fault detection logic.

    • 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.When you create services or components, consider implementing error codes and messages that will help clients determine whether they should retry failed operations. Ö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.In particular, indicate if the client should retry the operation (perhaps by returning an isTransient value) and suggest a suitable delay before the next retry attempt. Bir web hizmeti derliyorsanız hizmet sözleşmenizde tanımlanmış özel hataları döndürmeyi düşünün.If you build a web service, consider returning custom errors defined within your service contracts. Genel istemciler okuyamıyor olsa da, özel istemciler oluştururken bunlar yararlı olacaktır.Even though generic clients may not be able to read these, they will be useful when building custom clients.

  • Uygun bir yeniden deneme sayısı ve aralığı belirleyin:Determine an appropriate retry count and interval:

    • Yeniden deneme sayısı ve aralığının kullanım örneği türüne en uygun duruma getirmek önemlidir.It is vital to optimize the retry count and the interval to the type of use case. Yeterli sayıda yeniden deneme yapmazsanız, uygulama işlemi tamamlayamaz ve bir hatayla karşılaşabilir.If you do not retry a sufficient number of times, the application will be unable to complete the operation and is likely to experience a failure. Ç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.If you retry too many times, or with too short an interval between tries, the application can potentially hold resources such as threads, connections, and memory for long periods, which will adversely affect the health of the application.

    • Zaman aralığı ve yeniden deneme sayısı için uygun değerler, denenen işlemin türüne bağlıdır.The appropriate values for the time interval and the number of retry attempts depend on the type of operation being attempted. Ö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.For example, if the operation is part of a user interaction, the interval should be short and only a few retries attempted to avoid making users wait for a response (which holds open connections and can reduce availability for other users). İşlem, iptal edilmesi veya yeniden başlatılması pahalı olan ya da zaman harcayan uzun süreli veya kritik bir iş akışının parçası ise, girişimler arasında daha uzun süre bekleyip daha fazla yeniden deneme yapmak uygundur.If the operation is part of a long running or critical workflow, where cancelling and restarting the process is expensive or time-consuming, it is appropriate to wait longer between attempts and retry more times.

    • Yeniden denemeler arasında uygun aralıkların belirlenmesi başarılı bir strateji tasarlamanın en zor kısmıdır.Determining the appropriate intervals between retries is the most difficult part of designing a successful strategy. Tipik stratejiler aşağıdaki yeniden deneme aralığı türlerini kullanır:Typical strategies use the following types of retry interval:

      • Üstel geri alma.Exponential back-off. Uygulama ilk yeniden deneme öncesinde kısa bir süre bekler ve sonraki her yeniden deneme arasındaki süreyi üstel olarak artırır.The application waits a short time before the first retry, and then exponentially increasing times between each subsequent retry. Örneğin, işlemi 3 saniye, 12 saniye, 30 saniye vb. sonra yeniden deneyebilir.For example, it may retry the operation after 3 seconds, 12 seconds, 30 seconds, and so on.

      • Artımlı aralıklar.Incremental intervals. Uygulama ilk yeniden deneme öncesinde kısa bir süre bekler ve sonraki her yeniden deneme arasındaki süreyi kademeli olarak artırır.The application waits a short time before the first retry, and then incrementally increasing times between each subsequent retry. Örneğin, işlemi 3 saniye, 7 saniye, 13 saniye vb. sonra yeniden deneyebilir.For example, it may retry the operation after 3 seconds, 7 seconds, 13 seconds, and so on.

      • Düzenli aralıklar.Regular intervals. Uygulama her girişimden önce aynı süre boyunca bekler.The application waits for the same period of time between each attempt. Örneğin, işlemi 3 saniyede bir yeniden deneyebilir.For example, it may retry the operation every 3 seconds.

      • Hemen yeniden deneme.Immediate retry. Bazen geçici bir hata, ağ paketi çakışması veya bir donanım bileşenindeki ani artış gibi nedenlerle son derece kısa sürer.Sometimes a transient fault is extremely short, perhaps caused by an event such as a network packet collision or a spike in a hardware component. 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.In this case, retrying the operation immediately is appropriate because it may succeed if the fault has cleared in the time it takes the application to assemble and send the next request. Ancak hiçbir zaman birden fazla hemen yeniden deneme girişimi olmamalıdır ve hemen yeniden deneme başarısız olursa üstel geri alma ya da geri dönüş eylemleri gibi alternatif stratejilere geçiş yapmanız gerekir.However, there should never be more than one immediate retry attempt, and you should switch to alternative strategies, such as such as exponential back-off or fallback actions, if the immediate retry fails.

      • Rastgele seçim.Randomization. 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.Any of the retry strategies listed above may include a randomization to prevent multiple instances of the client sending subsequent retry attempts at the same time. Ö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 yeniden deneyebilir.For example, one instance may retry the operation after 3 seconds, 11 seconds, 28 seconds, and so on while another instance may retry the operation after 4 seconds, 12 seconds, 26 seconds, and so on. Rastgele seçim, diğer stratejilerle birleştirilebilen yararlı bir tekniktir.Randomization is a useful technique that may be combined with other strategies.

    • 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.As a general guideline, use an exponential back-off strategy for background operations, and immediate or regular interval retry strategies for interactive operations. 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.In both cases, you should choose the delay and the retry count so that the maximum latency for all retry attempts is within the required end-to-end latency requirement.

    • 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.Take into account the combination of all the factors that contribute to the overall maximum timeout for a retried operation. 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.These factors include the time taken for a failed connection to produce a response (typically set by a timeout value in the client) as well as the delay between retry attempts and the maximum number of retries. Özellikle yeniden denemeler arasındaki aralığın her hatadan sonra hızla büyüdüğü bir üstel gecikme stratejisi kullanılırken tüm bu sayıların toplamı çok büyük bir genel işlem sayısı ile sonuçlanabilir.The total of all these times can result in very large overall operation times, especially when using an exponential delay strategy where the interval between retries grows rapidly after each failure. Bir işlemi belirli bir hizmet düzeyi sözleşmesi (SLA) karşılaması gerekiyorsa, tüm zaman aşımları ve gecikmeler dahil olmak üzere genel işlem süresi o SLA'da tanımlanmış olmalıdır.If a process must meet a specific service level agreement (SLA), the overall operation time, including all timeouts and delays, must be within that defined in the SLA.

    • Sahip çok kısa aralıklar veya çok fazla yeniden deneme sayısı içeren aşırı agresif yeniden deneme stratejileri, hedef kaynağı veya hizmeti üzerinde olumsuz bir etkisi olabilir.Over-aggressive retry strategies, which have too short intervals or too many retries, can have an adverse effect on the target resource or service. Bu durum, kaynak veya hizmetin aşırı yüklenmiş durumundan kurtulmasını engelleyebilir ve istekleri engellemeye ya da reddetmeye devam eder.This may prevent the resource or service from recovering from its overloaded state, and it will continue to block or refuse requests. 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.This results in a vicious circle where more and more requests are sent to the resource or service, and consequently its ability to recover is further reduced.

    • 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).Take into account the timeout of the operations when choosing the retry intervals to avoid launching a subsequent attempt immediately (for example, if the timeout period is similar to the retry interval). 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.Also consider if you need to keep the total possible period (the timeout plus the retry intervals) to below a specific total time. 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.Operations that have unusually short or very long timeouts may influence how long to wait, and how often to retry the operation.

    • 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.Use the type of the exception and any data it contains, or the error codes and messages returned from the service, to optimize the interval and the number of retries. Ö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.For example, some exceptions or error codes (such as the HTTP code 503 Service Unavailable with a Retry-After header in the response) may indicate how long the error might last, or that the service has failed and will not respond to any subsequent attempt.

  • Anti düzenler kullanmaktan kaçının:Avoid anti-patterns:

    • Örneklerin büyük çoğunluğunda yeniden deneme kodunun yinelenen katmanlarını içeren uygulamalardan kaçınmanız gerekir.In the vast majority of cases, you should avoid implementations that include duplicated layers of retry code. 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.Avoid designs that include cascading retry mechanisms, or that implement retry at every stage of an operation that involves a hierarchy of requests, unless you have specific requirements that demand this. 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.In these exceptional circumstances, use policies that prevent excessive numbers of retries and delay periods, and make sure you understand the consequences. Ö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.For example, if one component makes a request to another, which then accesses the target service, and you implement retry with a count of three on both calls there will be nine retry attempts in total against the service. Ç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.Many services and resources implement a built-in retry mechanism and you should investigate how you can disable or modify this if you need to implement retries at a higher level.

    • Hiçbir zaman sonsuz bir yeniden deneme mekanizması uygulamayın.Never implement an endless retry mechanism. 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.This is likely to prevent the resource or service recovering from overload situations, and cause throttling and refused connections to continue for a longer period. 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.Use a finite number or retries, or implement a pattern such as Circuit Breaker to allow the service to recover.

    • Hemen yeniden denemeyi hiçbir zaman birden çok kez gerçekleştirmeyin.Never perform an immediate retry more than once.

    • Ö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.Avoid using a regular retry interval, especially when you have a large number of retry attempts, when accessing services and resources in Azure. Bu senaryodaki en iyi yaklaşım, devre kesici özelliğine sahip bir üstel geri alma stratejisidir.The optimum approach is this scenario is an exponential back-off strategy with a circuit-breaking capability.

    • Aynı istemcinin birden çok örneğinin veya farklı istemcilerin birden çok örneğinin aynı anda yeniden denemeler göndermesini önleyin.Prevent multiple instances of the same client, or multiple instances of different clients, from sending retries at the same times. Bu durumun olasılığı yüksekse, yeniden deneme aralıklarına rastgele seçim ekleyin.If this is likely to occur, introduce randomization into the retry intervals.

  • Yeniden deneme stratejinizi ve uygulamanızı test edin:Test your retry strategy and implementation:

    • Ö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.Ensure you fully test your retry strategy implementation under as wide a set of circumstances as possible, especially when both the application and the target resources or services it uses are under extreme load. Test sırasında davranışı denetlemek için şunları yapabilirsiniz:To check behavior during testing, you can:

      • Hizmete geçici ve geçici olmayan hatalar ekleyin.Inject transient and non-transient faults into the service. Örneğin, geçersiz istekler gönderin veya test isteklerini algılayıp farklı hata türleri ile yanıt veren kodlar ekleyin.For example, send invalid requests or add code that detects test requests and responds with different types of errors. 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.For an example using TestApi, see Fault Injection Testing with TestApi and Introduction to TestApi – Part 5: Managed Code Fault Injection APIs.

      • Gerçek hizmetin döndürebileceği bir dizi hatayı döndüren yapay bir kaynak ya da hizmet oluşturun.Create a mock of the resource or service that returns a range of errors that the real service may return. Yeniden deneme stratejinizin algılamak üzere tasarlandığı tüm hata türlerini kapsama aldığınızdan emin olun.Ensure you cover all the types of error that your retry strategy is designed to detect.

      • Hizmet sizin oluşturup dağıttığınız özel bir hizmetse hizmeti geçici olarak devre dışı bırakarak veya aşırı yükleyerek geçici hataları oluşmaya zorlayın (elbette Azure içindeki paylaşılan kaynakları veya paylaşılan hizmetleri aşırı yüklemeye çalışmamalısınız).Force transient errors to occur by temporarily disabling or overloading the service if it is a custom service that you created and deployed (you should not, of course, attempt to overload any shared resources or shared services within Azure).

      • 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.For HTTP-based APIs, consider using the FiddlerCore library in your automated tests to change the outcome of HTTP requests, either by adding extra roundtrip times or by changing the response (such as the HTTP status code, headers, body, or other factors). 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.This enables deterministic testing of a subset of the failure conditions, whether transient faults or other types of failure. Daha fazla bilgi için bkz. FiddlerCore.For more information, see FiddlerCore. Başta HttpMangler sınıfı olmak üzere kitaplığı kullanma örnekleri için Azure Depolama SDK'sı kayna kodunu inceleyin.For examples of how to use the library, particularly the HttpMangler class, examine the source code for the Azure Storage SDK.

      • 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.Perform high load factor and concurrent tests to ensure that the retry mechanism and strategy works correctly under these conditions, and does not have an adverse effect on the operation of the client or cause cross-contamination between requests.

  • Yeniden deneme ilkesi yapılandırmalarını yönetin:Manage retry policy configurations:

    • Yeniden deneme ilkesi, yeniden deneme stratejinizin tüm öğelerinin bir birleşimidir.A retry policy is a combination of all of the elements of your retry strategy. 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.It defines the detection mechanism that determines whether a fault is likely to be transient, the type of interval to use (such as regular, exponential back-off, and randomization), the actual interval value(s), and the number of times to retry.

    • Yeniden denemeler en basit uygulamada bile birçok yerde ve daha karmaşık uygulamaların her katmanında uygulanmalıdır.Retries must be implemented in many places within even the simplest application, and in every layer of more complex applications. Her bir ilkenin birden fazla konumdaki öğelerini sabit kodlamak yerine tüm ilkeleri depolamaya yönelik merkezi bir nokta kullanmayı düşünün.Rather than hard-coding the elements of each policy at multiple locations, consider using a central point for storing all the policies. Ö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.For example, store the values such as the interval and retry count in application configuration files, read them at runtime, and programmatically build the retry policies. Bunun yapılması, ayarları yönetmeyi ve değişen gereksinimler ile senaryolara yanıt vermek üzere değerleri değiştirmeyi ve ince ayarlar yapmayı kolaylaştırır.This makes it easier to manage the settings, and to modify and fine tune the values in order to respond to changing requirements and scenarios. 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.However, design the system to store the values rather than rereading a configuration file every time, and ensure suitable defaults are used if the values cannot be obtained from configuration.

    • 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.In an Azure Cloud Services application, consider storing the values that are used to build the retry policies at runtime in the service configuration file so that they can be changed without needing to restart the application.

    • Senaryonuz için uygun olduğunda, kullandığınız istemci API’lerinde mevcut olan yerleşik veya varsayılan yeniden deneme stratejilerinden yararlanın.Take advantage of built-in or default retry strategies available in the client APIs you use, but only where they are appropriate for your scenario. Bu stratejiler tipik olarak genel amaçlıdır.These strategies are typically general-purpose. Bazı senaryolarda tüm gerekli olan bunlardır, ancak bazı senaryolarda gereksinimlerinize uyacak tüm seçenekleri sunmayabilirler.In some scenarios they may be all that is required, but in other scenarios they may not offer the full range of options to suit your specific requirements. En uygun değerleri belirlemek için ayarların uygulamanızı testlerle nasıl etkileyeceğini anlamanız gerekir.You must understand how the settings will affect your application through testing to determine the most appropriate values.

  • Geçici ve geçici olmayan hataları günlüğe kaydedin ve izleyin:Log and track transient and non-transient faults:

    • Yeniden deneme girişimleri olduğunda günlüğe kaydedilen özel durum işleme ve diğer izlemeleri yeniden deneme stratejinize dahil edin.As part of your retry strategy, include exception handling and other instrumentation that logs when retry attempts are made. Geçici hata ve yeniden denemelerin ara sıra gerçekleşmesi beklenir ve bir sorunu ifade etmez; ancak sayıları düzenli olan ve artan yeniden denemeler genellikle hata neden olabilecek ya da o anda uygulama performansını ve kullanılabilirliğini etkileyen bir sorunun göstergesidir.While an occasional transient failure and retry are to be expected, and do not indicate a problem, regular and increasing numbers of retries are often an indicator of an issue that may cause a failure, or is currently impacting application performance and availability.

    • İ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.Log transient faults as Warning entries rather than Error entries so that monitoring systems do not detect them as application errors that may trigger false alerts.

    • 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.Consider storing a value in your log entries that indicates if the retries were caused by throttling in the service, or by other types of faults such as connection failures, so that you can differentiate them during analysis of the data. 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.An increase in the number of throttling errors is often an indicator of a design flaw in the application or the need to switch to a premium service that offers dedicated hardware.

    • Yeniden deneme mekanizması içeren işlemler için geçen toplam süreyi ölçmeyi ve günlüğe kaydetmeyi düşünün.Consider measuring and logging the overall time taken for operations that include a retry mechanism. 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.This is a good indicator of the overall effect of transient faults on user response times, process latency, and the efficiency of the application use cases. 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.Also log the number of retries occurred in order to understand the factors that contributed to the response time.

    • 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.Consider implementing a telemetry and monitoring system that can raise alerts when the number and rate of failures, the average number of retries, or the overall times taken for operations to succeed, is increasing.

  • Sürekli olarak başarısız olan işlemleri yönetin:Manage operations that continually fail:

    • İş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:There will be circumstances where the operation continues to fail at every attempt, and it is vital to consider how you will handle this situation:

      • 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.Although a retry strategy will define the maximum number of times that an operation should be retried, it does not prevent the application repeating the operation again, with the same number of retries. Ö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.For example, if an order processing service fails with a fatal error that puts it out of action permanently, the retry strategy may detect a connection timeout and consider it to be a transient fault. Kod, işlemi belirtilen sayıda yeniden dener ve sonra bırakır.The code will retry the operation a specified number of times and then give up. 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.However, when another customer places an order, the operation will be attempted again - even though it is sure to fail every time.

      • 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.To prevent continual retries for operations that continually fail, consider implementing the Circuit Breaker pattern. 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.In this pattern, if the number of failures within a specified time window exceeds the threshold, requests are returned to the caller immediately as errors, without attempting to access the failed resource or service.

      • Uygulama, kullanılabilir olduğunu algılamak için hizmeti düzenli aralıklarla veya istekler arasında aralıklı olarak ve çok uzun aralıklarla test edebilir.The application can periodically test the service, on an intermittent basis and with very long intervals between requests, to detect when it becomes available. 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.An appropriate interval will depend on the scenario, such as the criticality of the operation and the nature of the service, and might be anything between a few minutes and several hours. Testin başarılı olduğu noktada uygulama normal işlemlerine devam edebilir ve istekleri yeni kurtarılan hizmete geçirebilir.At the point where the test succeeds, the application can resume normal operations and pass requests to the newly recovered service.

      • 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.In the meantime, it may be possible to fall back to another instance of the service (perhaps in a different datacenter or application), use a similar service that offers compatible (perhaps simpler) functionality, or perform some alternative operations in the hope that the service will become available soon. Örneğin, hizmete ilişkin isteklerin bir kuyrukta veya veri deposunda depolanması ve daha sonra yeniden yürütülmesi uygun olabilir.For example, it may be appropriate to store requests for the service in a queue or data store and replay them later. 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.Otherwise you might be able to redirect the user to an alternative instance of the application, degrade the performance of the application but still offer acceptable functionality, or just return a message to the user indicating that the application is not available at present.

  • Diğer konularOther considerations

    • Bir ilkenin yeniden deneme sayısı ve yeniden deneme aralıklarına ait değerlere karar verirken, hizmet veya kaynak üzerindeki işlemin uzun süreli veya çok adımlı bir işleme ait olduğuna dikkat edin.When deciding on the values for the number of retries and the retry intervals for a policy, consider if the operation on the service or resource is part of a long-running or multi-step operation. 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.It may be difficult or expensive to compensate all the other operational steps that have already succeeded when one fails. 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.In this case, a very long interval and a large number of retries may be acceptable as long as it does not block other operations by holding or locking scarce resources.

    • Aynı işlemi yeniden denemenin verilerde tutarsızlıklara neden olabileceğini göz önünde bulundurun.Consider if retrying the same operation may cause inconsistencies in data. Çok adımlı bir işlemin bazı bölümleri yinelenirse ve işlemler bir kez etkili değilse bir tutarsızlığa neden olabilir.If some parts of a multi-step process are repeated, and the operations are not idempotent, it may result in an inconsistency. Örneğin, bir değeri artıran işlem yinelenirse geçersiz bir sonuç oluşturur.For example, an operation that increments a value, if repeated, will produce an invalid result. Bir kuyruğa ileti gönderen bir işlemin tekrarlanması, yinelenen iletileri agılayamıyorsa ileti tüketicisinde bir tutarsızlığa neden olabilir.Repeating an operation that sends a message to a queue may cause an inconsistency in the message consumer if it cannot detect duplicate messages. Bunu önlemek için her adımı bir kez etkili bir işlem olarak tasarladığınızdan emin olun.To prevent this, ensure that you design each step as an idempotent operation. Teklik hakkında daha fazla bilgi için bkz: Teklik düzenleri.For more information about idempotency, see Idempotency patterns.

    • Yeniden denenecek işlemlerin kapsamını göz önünde bulundurun.Consider the scope of the operations that will be retried. Ö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.For example, it may be easier to implement retry code at a level that encompasses several operations, and retry them all if one fails. Ancak, bunun yapılması teklik sorunlarına veya gereksiz geri alma işlemlerine neden olabilir.However, doing this may result in idempotency issues or unnecessary rollback operations.

    • 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.If you choose a retry scope that encompasses several operations, take into account the total latency of all of them when determining the retry intervals, when monitoring the time taken, and before raising alerts for failures.

    • 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.Consider how your retry strategy may affect neighbors and other tenants in a shared application, or when using shared resources and services. 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.Aggressive retry policies can cause an increasing number of transient faults to occur for these other users and for applications that share the resources and services. Benzer şekilde, uygulamanız kaynak ve hizmetlerin diğer kullanıcıları tarafından uygulanan yeniden ilkelerinden etkilenebilir.Likewise, your application may be affected by the retry policies implemented by other users of the resources and services. Kritik görev uygulamaları için paylaşılmayan premium hizmetleri kullanmaya karar verebilirsiniz.For mission-critical applications, you may decide to use premium services that are not shared. 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.This provides you with much more control over the load and consequent throttling of these resources and services, which can help to justify the additional cost.

Daha fazla bilgiMore information