Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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.
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 antingen gateway- eller 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.
Gatewayläge används alltid för att hämta metadata, till exempel konto, container och routningsinformation oavsett vilket läge SDK som har konfigurerats för användning. 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, 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. 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 alla fel är inte meningsfulla att försöka igen. Vissa av fel- eller statuskoderna är inte tillfälliga. I följande tabell beskrivs 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 | Förbjuden |
| 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 ID:t och partitionsnyckeln som tillhandahålls för en resurs i en skrivåtgärd tas av en befintlig resurs eller när en unik nyckelbegränsning överträds. |
| 410 | Ja | Ja | Undantag som har försvunnit (tillfälligt fel som inte bör bryta mot SLA) |
| 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 med 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 Support problem. |
| 503 | Ja | Ja | Tjänsten är inte tillgänglig |
Alla statuskoder som har markerats med Ja i den andra kolumnen bör ha en viss grad av återförsökstäckning i ditt program.
HTTP 403
Azure Cosmos DB SDK:er försöker inte igen vid HTTP 403-fel i allmänhet, men det finns vissa fel som är associerade med HTTP 403 som kan få programmet att reagera. 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 återförsöker vid HTTP 429-fel som standard, baserat på klientkonfigurationen, och följer tjänstens svarshuvud x-ms-retry-after-ms genom att vänta den angivna tiden och sedan försöka igen.
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 säkerhetskopiering 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 försöka igen 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.
Tidutgångar och anslutningsrelaterade fel (HTTP 408/503)
Nätverkstimeouter och anslutningsfel är några av de vanligaste felen. Azure Cosmos DB SDK:er är motståndskraftiga och kommer att försöka igen vid timeout- och anslutningsproblem i HTTP- och TCP-protokollen om det är möjligt att omförsöka.
- För läsoperationer försöker SDK:erna igen vid ett timeout- eller anslutningsrelaterat fel.
- För skrivåtgärder försöker SDK:erna inte igen eftersom dessa åtgärder inte är idempotenta. 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 att återställa en tidsgräns vid Skapande kan det resultera i HTTP 409 (Conflict) om den tidigare begäran nådde tjänsten, men det skulle lyckas om den inte gjorde det.
Språkspecifik implementeringsinformation
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 den totala svarstiden ände till ände för en åtgärd. 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. För mer information, se fånga diagnostik för .NET SDK och Java SDK.
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 och .NET 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. Information om vilka scenarier som omfattar andra regioner finns i scenarier och konfigurationer för flerregionala 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 föregående tabell 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.