Dela via

Implementera en återförsöksprincip med JavaScript eller TypeScript

  • 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 JavaScript 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 StorageRetryOptions-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
maxRetryDelayInMs number Valfritt. Anger den maximala fördröjning som tillåts innan du försöker utföra en åtgärd igen. 120 sekunder (eller 120 * 1 000 ms)
maxTries number Valfritt. Det maximala antalet återförsök innan du ger upp. 4
retryDelayInMs number Valfritt. Anger hur lång fördröjning som ska användas innan du försöker utföra en åtgärd igen. 4 sekunder (eller 4 * 1 000 ms)
retryPolicyType StorageRetryPolicyType Valfritt. StorageRetryPolicyType är standard exponentiell återförsöksprincip. StorageRetryPolicyType.Exponential
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
tryTimeoutInMs number Valfritt. Maximal tid som tillåts innan en begäran avbryts och antas ha misslyckats. Den här tidsgränsen gäller för åtgärdsbegäran och bör baseras på den bandbredd som är tillgänglig för värddatorn och närheten till lagringstjänsten. Ett värde på 0 eller odefinierat resulterar i ingen standardtimeout på klienten, och standardtidsgränsen på serversidan används. Mer information finns i Timeouter för Blob Service-åtgärder.

I följande kodexempel konfigurerar vi återförsöksalternativen i en instans av StorageRetryOptions, skickar den till en ny StoragePipelineOptions-instans och skickar pipeline när du instansierar BlobServiceClient:

const options = {
  retryOptions: {
    maxTries: 4,
    retryDelayInMs: 3 * 1000,
    maxRetryDelayInMs: 120 * 1000,
    retryPolicyType: StorageRetryPolicyType.EXPONENTIAL
  },
};

const pipeline = newPipeline(credential, options);

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  credential,
  pipeline
);

I det här exemplet använder varje tjänstbegäran som utfärdas från BlobServiceClient objektet återförsöksalternativen enligt definitionen i retryOptions. 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.

Relaterat innehåll