Dela via

Implementera en återförsöksprincip med Java

  • Artikel

Alla program som körs i molnet eller kommunicerar med fjärrtjänster och resurser måste kunna hantera tillfälliga fel. Det är vanligt att dessa program upplever fel på grund av en tillfällig förlust av nätverksanslutning, en tidsgräns för begäranden när en tjänst eller resurs är upptagen eller andra faktorer. Utvecklare bör skapa program för att hantera tillfälliga fel transparent för att förbättra stabilitet och återhämtning.

I den här artikeln får du lära dig hur du använder Azure Storage-klientbiblioteket för Java för att konfigurera en återförsöksprincip för ett program som ansluter till Azure Blob Storage. Återförsöksprinciper definierar hur programmet hanterar misslyckade begäranden och bör alltid justeras för att matcha programmets affärskrav och typen av fel.

Konfigurera alternativ för återförsök

Återförsöksprinciper för Blob Storage konfigureras programmatiskt, vilket ger kontroll över hur återförsöksalternativ tillämpas på olika tjänstbegäranden och scenarier. Till exempel kan en webbapp som utfärdar begäranden baserat på användarinteraktion implementera en princip med färre återförsök och kortare fördröjningar för att öka svarstiden och meddela användaren när ett fel inträffar. Alternativt kan en app eller komponent som kör batchbegäranden i bakgrunden öka antalet återförsök och använda en exponentiell backoff-strategi för att tillåta att begärandetiden slutförs.

I följande tabell visas de parametrar som är tillgängliga när du skapar en RequestRetryOptions-instans , tillsammans med typen, en kort beskrivning och standardvärdet om du inte gör några ändringar. Du bör vara proaktiv när du justerar värdena för dessa egenskaper för att uppfylla appens behov.

Property Type Beskrivning Standardvärde
retryPolicyType RetryPolicyType Valfritt. Den metod som ska användas för att beräkna fördröjningar av återförsök. EXPONENTIELL
maxTries Integer Valfritt. Det maximala antalet återförsök innan du ger upp. 4
tryTimeoutInSeconds Integer Valfritt. Maximal tid som tillåts innan en begäran avbryts och antas ha misslyckats. Observera att tidsgränsen gäller för åtgärdsbegäran, inte den övergripande åtgärden från slutpunkt till slutpunkt. Det här värdet bör baseras på den bandbredd som är tillgänglig för värddatorn och närheten till lagringstjänsten. En bra startpunkt kan vara 60 sekunder per MB förväntad nyttolaststorlek. Integer.MAX_VALUE (sekunder)
retryDelayInMs Long Valfritt. Anger hur lång fördröjning som ska användas innan du försöker utföra en åtgärd igen. 4ms för EXPONENTIAL, 30ms för FIXED
maxRetryDelayInMs Long Valfritt. Anger den maximala fördröjning som tillåts innan du försöker utföra en åtgärd igen. 120 ms
secondaryHost String Valfritt. Sekundär lagringskontoslutpunkt att försöka begäranden mot igen. Innan du anger det här värdet bör du förstå problemen med att läsa inaktuella och potentiellt inkonsekventa data. Mer information finns i Använda geo-redundans för att utforma program med hög tillgänglighet. Ingen

I följande kodexempel konfigurerar vi återförsöksalternativen i en instans av RequestRetryOptions och skickar det till BlobServiceClientBuilder för att skapa ett klientobjekt:

RequestRetryOptions retryOptions = new RequestRetryOptions(RetryPolicyType.FIXED, 2, 3, 1000L, 1500L, null);
BlobServiceClient client = new BlobServiceClientBuilder()
        .endpoint("https://<storage-account-name>.blob.core.windows.net/")
        .credential(credential)
        .retryOptions(retryOptions)
        .buildClient();

I det här exemplet använder varje tjänstbegäran som utfärdas från BlobServiceClient objektet återförsöksalternativen enligt definitionen i instansen RequestRetryOptions . Den här principen gäller för klientbegäranden. Du kan konfigurera olika återförsöksstrategier för tjänstklienter baserat på appens behov.

Nästa steg

  • Den här artikeln är en del av utvecklarguiden för Blob Storage för Java. Se den fullständiga listan över utvecklarguideartiklar i Skapa din app.
  • Arkitekturvägledning och allmänna metodtips för återförsöksprinciper finns i Tillfälliga felhantering.
  • Vägledning om hur du implementerar ett återförsöksmönster för tillfälliga fel finns i Återförsöksmönster.