Utforma elastiska program med Azure Cosmos DB SDK:er

  • Artikel

GÄLLER FÖR: NoSQL

När du redigerar klientprogram som interagerar med Azure Cosmos DB via någon av SDK:erna är det viktigt att förstå några viktiga grunder. Den här artikeln är en designguide som hjälper dig att förstå dessa grunder och utforma elastiska program.

Översikt

En videoöversikt över de begrepp som beskrivs i den här artikeln finns i:

Anslutningslägen

Azure Cosmos DB SDK:er kan ansluta till tjänsten i två anslutningslägen. .NET- och Java-SDK:erna kan ansluta till tjänsten i både gateway- och direktläge, medan de andra bara kan ansluta i gatewayläge. Gateway-läget använder HTTP-protokollet och I direktläge används vanligtvis TCP-protokollet.

Gateway-läget används alltid för att hämta metadata som konto, container och routningsinformation oavsett vilket läge SDK är konfigurerat att använda. Den här informationen cachelagras i minnet och används för att ansluta till tjänstreplikerna.

Sammanfattningsvis för SDK:er i gatewayläge kan du förvänta dig HTTP-trafik, medan du för SDK:er i direktläge kan förvänta dig en kombination av HTTP- och TCP-trafik under olika omständigheter (till exempel initiering eller hämtning av metadata eller routningsinformation).

Klientinstanser och anslutningar

Oavsett anslutningsläge är det viktigt att underhålla en Singleton-instans av SDK-klienten per konto per program. Anslutningar, både HTTP och TCP, är begränsade till klientinstansen. De flesta beräkningsmiljöer har begränsningar vad gäller antalet anslutningar som kan vara öppna samtidigt och när dessa gränser nås påverkas anslutningen.

Distribuerade program och nätverk

När du utformar distribuerade program finns det tre viktiga komponenter:

  • Ditt program och den miljö som det körs på.
  • Nätverket, som innehåller alla komponenter mellan ditt program och Azure Cosmos DB-tjänstslutpunkten.
  • Azure Cosmos DB-tjänstslutpunkten.

När fel uppstår hamnar de ofta i något av dessa tre områden, och det är viktigt att förstå att det på grund av systemets distribuerade karaktär är opraktiskt att förvänta sig 100 % tillgänglighet för någon av dessa komponenter.

Azure Cosmos DB har en omfattande uppsättning serviceavtal för tillgänglighet, men ingen av dem är 100 %. De nätverkskomponenter som ansluter ditt program till tjänstslutpunkten kan ha tillfälliga maskinvaruproblem och förlora paket. Även beräkningsmiljön där programmet körs kan ha en CPU-topp som påverkar åtgärder. Dessa feltillstånd kan påverka driften av SDK:erna och visas normalt som fel med specifika koder.

Ditt program bör vara motståndskraftigt mot en viss grad av potentiella fel i dessa komponenter genom att implementera återförsöksprinciper för de svar som tillhandahålls av SDK:erna.

Ska mitt program försöka igen vid fel?

Det korta svaret är ja. Men inte alla fel är meningsfulla att försöka på igen, vissa av fel- eller statuskoderna är inte tillfälliga. Tabellen nedan beskriver dem i detalj:

Statuskod Bör lägga till nytt försök SDK:er försöker igen Beskrivning
400 Inga Inga Felaktig begäran
401 Inga Inga Saknar behörighet
403 Valfritt Nej Forbidden
404 Inga Inga Resursen hittades inte
408 Ja Ja Begäran uppnådde sin tidsgräns
409 Inga Inga Konfliktfel är när identiteten (ID och partitionsnyckeln) som tillhandahålls för en resurs i en skrivåtgärd har tagits av en befintlig resurs eller när en unik nyckelbegränsning har brutits.
410 Ja Ja Gone-undantag (tillfälligt fel som inte bör bryta mot SLA)
412 Inga Inga Förutsättningsfel är när åtgärden angav en eTag som skiljer sig från den version som är tillgänglig på servern. Det är ett optimistiskt samtidighetsfel . Försök att utföra åtgärden igen när du har läst in den senaste versionen av resursen och uppdaterat eTag i förfrågan.
413 Inga Inga Begärandeentiteten är för stor
429 Ja Ja Det är säkert att försöka igen på en 429. Läs guiden för att felsöka HTTP 429.
449 Ja Ja Tillfälliga fel som endast inträffar vid skrivåtgärder och är säkert att försöka igen. Detta kan peka på ett designproblem där för många samtidiga åtgärder försöker uppdatera samma objekt i Azure Cosmos DB.
500 Inga Inga Åtgärden misslyckades på grund av ett oväntat tjänstfel. Kontakta supporten genom att skicka in ett Azure Support problem.
503 Ja Ja Tjänsten är inte tillgänglig

I tabellen ovan bör alla statuskoder som har markerats med Ja i den andra kolumnen ha en viss grad av täckning för återförsök i ditt program.

HTTP 403

Azure Cosmos DB-SDK:erna försöker inte igen vid HTTP 403-fel i allmänhet, men det finns vissa fel som är associerade med HTTP 403 som ditt program kan besluta att reagera på. Om du till exempel får ett felmeddelande om att en partitionsnyckel är full kan du välja att ändra partitionsnyckeln för dokumentet som du försöker skriva baserat på en affärsregel.

HTTP 429

Azure Cosmos DB-SDK:erna försöker igen på HTTP 429-fel som standard efter klientkonfigurationen och respekterar tjänstens svarshuvud x-ms-retry-after-ms genom att vänta den angivna tiden och försöka igen efteråt.

När SDK-återförsöken överskrids returneras felet till ditt program. Vi rekommenderar att du inspekterar x-ms-retry-after-ms rubriken i svaret som ett tips för att bestämma hur länge du ska vänta innan du försöker utföra begäran igen. Ett annat alternativ är en exponentiell backoff-algoritm eller att konfigurera klienten för att utöka återförsöken på HTTP 429.

HTTP 449

Azure Cosmos DB-SDK:erna försöker igen på HTTP 449 med en inkrementell backoff under en fast tidsperiod för att hantera de flesta scenarier.

När de automatiska SDK-återförsöken överskrids returneras felet till ditt program. HTTP 449-fel kan göras på ett säkert sätt. På grund av den mycket samtidiga typen av skrivåtgärder är det bättre att ha en slumpmässig backoff-algoritm för att undvika att upprepa samma grad av samtidighet efter ett fast intervall.

Tidsgränser för nätverk och anslutningsfel är bland de vanligaste felen. Azure Cosmos DB-SDK:erna är själva motståndskraftiga och kommer att försöka uppnå timeouter och anslutningsproblem på nytt i HTTP- och TCP-protokollen om återförsöket är möjligt:

  • För läsåtgärder kommer SDK:erna att försöka utföra timeout- eller anslutningsrelaterade fel igen.
  • För skrivåtgärder kommer SDK:erna inte att försöka igen eftersom dessa åtgärder inte är idempotent. När en timeout inträffar i väntan på svaret går det inte att veta om begäran har nått tjänsten.

Om kontot har flera tillgängliga regioner försöker SDK:erna också göra ett nytt försök mellan regioner.

På grund av typen av timeouter och anslutningsfel kanske dessa inte visas i dina kontomått, eftersom de endast omfattar fel som inträffar på tjänstsidan.

Vi rekommenderar att program har en egen återförsöksprincip för dessa scenarier och tar hänsyn till hur man löser tidsgränser för skrivåtgärder. Om du till exempel försöker igen på en create-timeout kan det ge http 409 (konflikt) om den tidigare begäran nådde tjänsten, men det skulle lyckas om den inte gjorde det.

Information om språkspecifik implementering

Mer implementeringsinformation om ett språk finns i:

Påverkar återförsök min svarstid?

Från klientperspektivet påverkar alla återförsök svarstiden för en åtgärd från slutpunkt till slutpunkt. När P99-svarstiden för ditt program påverkas är det viktigt att förstå vilka återförsök som görs och hur de ska åtgärdas.

Azure Cosmos DB-SDK:er innehåller detaljerad information i loggarna och diagnostiken som kan hjälpa dig att identifiera vilka återförsök som görs. Mer information finns i samla in .NET SDK-diagnostik och hur du samlar in Java SDK-diagnostik.

Hur är det med regionala avbrott?

Azure Cosmos DB SDK:er täcker regional tillgänglighet och kan utföra återförsök i andra kontoregioner. Läs artikeln om återförsöksscenarier och konfigurationer i miljöer med flera regioner för att förstå vilka scenarier som omfattar andra regioner.

När du ska kontakta kundsupporten

Gå igenom följande steg innan du kontaktar kundsupporten:

  • Hur är påverkan mätt i volymen av åtgärder jämfört med de åtgärder som lyckas? Finns det i serviceavtalen?
  • Påverkas P99-svarstiden?
  • Är felen relaterade till felkoder som mitt program ska försöka igen på och täcker programmet sådana återförsök?
  • Påverkar felen alla programinstanser eller bara en delmängd? När problemet reduceras till en delmängd av instanser är det ofta ett problem som är relaterat till dessa instanser.
  • Har du gått igenom de relaterade felsökningsdokumenten i tabellen ovan för att utesluta ett problem i programmiljön?

Om alla programinstanser påverkas, eller om procentandelen av de berörda åtgärderna ligger utanför serviceavtalen för tjänsten eller påverkar dina egna program-serviceavtal och P99:or, kontaktar du kundsupporten.

Nästa steg