Dela via

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 du förstår några viktiga grunderna. Den här artikeln är en designguide som hjälper dig att förstå de här grunderna 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 direktläget använder vanligtvis TCP-protokollet.

Gateway-läget används alltid för att hämta metadata, till exempel 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 kan du förvänta dig HTTP-trafik för SDK:er i gatewayläge, 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 när det 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 inträffar 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ärderna. Dessa feltillstånd kan påverka SDK:ernas åtgärder och normalt visas 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 igen, vissa av fel- eller statuskoderna är inte tillfälliga. Tabellen nedan beskriver dem i detalj:

Statuskod Ska lägga till nytt försök SDK:er försöker igen beskrivning
400 Nej Nej Felaktig begäran
401 Nej Nej Ej auktoriserad
403 Valfritt Nej Forbidden
404 Nej Nej Det går inte att hitta resursen
408 Ja Ja Tidsgränsen för begäran har överskriden
409 Nej Nej 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 överträtts.
410 Ja Ja Borta undantag (tillfälligt fel som inte bör bryta mot serviceavtalet)
412 Nej Nej Förhandsvillkorsfel ä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 Nej Nej 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älligt 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 Nej Nej Åtgärden misslyckades på grund av ett oväntat tjänstfel. Kontakta supporten genom att skicka in ett Azure-supportproblem.
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 återförsökstäckning i ditt program.

HTTP 403

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

HTTP 429

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

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 avgöra hur länge du ska vänta innan du försöker utföra begäran igen. Ett annat alternativ skulle vara en exponentiell back-off-algoritm eller att konfigurera klienten för att utöka återförsöken på HTTP 429.

HTTP 449

Azure Cosmos DB SDK:er försöker igen på HTTP 449 med en inkrementell back-off 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 utfö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.

Nätverkstimeouter och anslutningsfel är några av de vanligaste felen. Azure Cosmos DB SDK:er är själva motståndskraftiga och kommer att försöka med timeouter och anslutningsproblem igen i HTTP- och TCP-protokollen om omförsöket är möjligt:

  • För läsåtgärder försöker SDK:erna igen vid eventuell timeout eller anslutningsrelaterade fel.
  • För skrivåtgärder försöker inte SDK:erna 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 nådde 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 skrivning. Om du till exempel försöker igen på en Tidsgräns för att skapa 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 information om implementering av ett språk finns i:

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

Från klientperspektiv påverkar eventuella återförsök svarstiden för en åtgärd från slutpunkt till slutpunkt. När din P99-svarstid påverkas är det viktigt att förstå de återförsök som görs och hur du ska åtgärda dem.

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 hur du samlar in .NET SDK-diagnostik och hur du samlar in Java SDK-diagnostik.

Hur kan jag minska svarstiden för återförsök?

Beroende på omständigheterna dirigerar SDK i de flesta fall begäranden till antingen den lokala regionen, skrivregionen (i ett skrivscenario med en region) eller till den första regionen i listan över prioriterade regioner . Den här prioriteringen minimerar svarstiden i felfria scenarier genom att främst ansluta till närmaste eller mest optimala datacenter.

Den här prioriteringen innebär dock också att begäranden som kommer att resultera i fel alltid prövas i en specifik region först för ett givet felscenario. Om redundansväxling till en annan region föredras i det scenariot hanteras detta vanligtvis på infrastrukturnivån (Traffic Manager) i stället för på SDK-nivå. Korrekt installation och konfiguration av infrastrukturen kan säkerställa att trafiken omdirigeras effektivt under regionala avbrott, vilket minskar svarstiden som kan komma med återförsök mellan regioner i ett avbrottsscenario. Mer detaljerad information om hur du konfigurerar redundans på infrastrukturnivå finns i Dokumentation om Azure Traffic Manager. Vissa SDK:er stöder implementering av liknande redundansstrategier direkt på SDK-nivå. Se till exempel hög tillgänglighet för Java SDK.

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. Mer information om vilka scenarier som omfattar andra regioner finns i artikeln om omprövning av multiregionala miljöer.

När du ska kontakta kundsupporten

Innan du kontaktar kundsupporten går du igenom följande steg:

  • 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 eller påverkar dina egna program-serviceavtal och P99:er, kontaktar du kundsupporten.

Nästa steg