Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
VAN TOEPASSING OP: 
NoSQL
Bij het ontwerpen van clienttoepassingen die communiceren met Azure Cosmos DB via een van de SDK's, is het belangrijk om een aantal belangrijke basisprincipes te begrijpen. Dit artikel is een ontwerphandleiding voor het begrijpen van deze basisprincipes en het ontwerpen van tolerante toepassingen.
Zie voor een videooverzicht van de concepten die in dit artikel worden besproken:
Connectiviteitsmodi
Azure Cosmos DB SDK's kunnen verbinding maken met de service in twee connectiviteitsmodi. De .NET- en Java SDK's kunnen verbinding maken met de service in de gateway - of directe modus, terwijl de anderen alleen verbinding kunnen maken in de gatewaymodus. De gatewaymodus maakt gebruik van het HTTP-protocol en de directe modus maakt doorgaans gebruik van het TCP-protocol.
De gatewaymodus wordt altijd gebruikt om metagegevens op te halen, zoals het account, de container en routeringsgegevens, ongeacht welke modus-SDK is geconfigureerd voor gebruik. Deze informatie wordt in de cache opgeslagen in het geheugen en wordt gebruikt om verbinding te maken met de servicereplica's.
Kortom, voor SDK's in de gatewaymodus kunt u HTTP-verkeer verwachten, terwijl u voor SDK's in de directe modus een combinatie van HTTP- en TCP-verkeer kunt verwachten onder verschillende omstandigheden, zoals initialisatie, het ophalen van metagegevens of routeringsgegevens.
Clientexemplaren en verbindingen
Ongeacht de connectiviteitsmodus is het essentieel om een singleton-exemplaar van de SDK-client per account per toepassing te onderhouden. Verbindingen, zowel HTTP als TCP, zijn gericht op het clientexemplaren. De meeste rekenomgevingen hebben beperkingen in termen van het aantal verbindingen dat tegelijkertijd kan worden geopend. Wanneer deze limieten zijn bereikt, wordt de verbinding beïnvloed.
Gedistribueerde toepassingen en netwerken
Wanneer u gedistribueerde toepassingen ontwerpt, zijn er drie belangrijke onderdelen:
- Uw toepassing en de omgeving waarop deze wordt uitgevoerd
- Het netwerk, dat een onderdeel bevat tussen uw toepassing en het Azure Cosmos DB-service-eindpunt
- Het Azure Cosmos DB-service-eindpunt
Wanneer er fouten optreden, vallen ze vaak in een van deze drie gebieden en is het belangrijk om te begrijpen dat het vanwege de gedistribueerde aard van het systeem niet praktisch is om 100% beschikbaarheid voor een van deze onderdelen te verwachten.
Azure Cosmos DB heeft een uitgebreide set beschikbaarheids-SLA's, maar geen van deze is 100%. De netwerkonderdelen die uw toepassing verbinden met het service-eindpunt kunnen tijdelijke hardwareproblemen hebben en pakketten verliezen. Zelfs de rekenomgeving waarin uw toepassing wordt uitgevoerd, kan een CPU-piek hebben die van invloed is op bewerkingen. Deze foutvoorwaarden kunnen van invloed zijn op de bewerkingen van de SDK's en normaal gesproken worden weergegeven als fouten met bepaalde codes.
Uw toepassing moet bestand zijn tegen een bepaalde mate van mogelijke fouten in deze onderdelen door implementatie van beleid voor het opnieuw proberen op de antwoorden van de SDK's.
Moet mijn toepassing opnieuw proberen bij fouten?
Het korte antwoord is ja, maar niet alle fouten zijn zinvol om het opnieuw te proberen. Sommige fout- of statuscodes zijn niet tijdelijk. In de volgende tabel worden deze in detail beschreven:
| Statuscode | Moet hernieuwde poging toevoegen | SDKs opnieuw proberen | Beschrijving |
|---|---|---|---|
| 400 | Nee | Nee | Ongeldige aanvraag |
| 401 | Nee | Nee | Niet geautoriseerd |
| 403 | Optioneel | Nee | Verboden |
| 404 | Nee | Nee | Resource niet gevonden |
| 408 | Ja | Ja | Verzoek is verlopen |
| 409 | Nee | Nee | Een conflictfout optreedt wanneer de id en partitiesleutel die zijn opgegeven voor een resource in een schrijfbewerking, in gebruik zijn door een bestaande resource of wanneer een unieke sleutelbeperking wordt geschonden. |
| 410 | Ja | Ja | Verdwenen uitzonderingen (tijdelijke fout die de SLA niet mag schenden) |
| 412 | Nee | Nee | Voorwaardefout is de plaats waar de bewerking een eTag heeft opgegeven die verschilt van de versie die beschikbaar is op de server. Dit is een optimistische gelijktijdigheidsfout . Voer de aanvraag opnieuw uit nadat u de meest recente versie van de resource hebt gelezen en de eTag voor de aanvraag hebt bijgewerkt. |
| 413 | Nee | Nee | Aanvraagentiteit te groot |
| 429 | Ja | Ja | Het is veilig om het opnieuw te proberen op een 429. Raadpleeg de handleiding voor het oplossen van problemen met HTTP 429. |
| 449 | Ja | Ja | Tijdelijke fout die alleen optreedt bij schrijfbewerkingen en veilig is om het opnieuw te proberen. Dit kan wijzen op een ontwerpprobleem waarbij te veel gelijktijdige bewerkingen hetzelfde object proberen bij te werken in Azure Cosmos DB. |
| 500 | Nee | Nee | De bewerking is mislukt vanwege een onverwachte servicefout. Neem contact op met de ondersteuning door een ondersteuning voor Azure probleem op te geven. |
| 503 | Ja | Ja | Service niet beschikbaar |
Alle statuscodes die zijn gemarkeerd met Ja in de tweede kolom, moeten een zekere mate van dekking voor nieuwe pogingen in uw toepassing hebben.
HTTP 403
De Azure Cosmos DB SDK's proberen het in het algemeen niet opnieuw op HTTP 403-fouten, maar er zijn bepaalde fouten die zijn gekoppeld aan HTTP 403 die ervoor kunnen zorgen dat uw toepassing reageert. Als u bijvoorbeeld een foutmelding krijgt die aangeeft dat een partitiesleutel vol is, kunt u besluiten om de partitiesleutel van het document dat u probeert te schrijven, te wijzigen op basis van een bepaalde bedrijfsregel.
HTTP 429
De Azure Cosmos DB SDK's proberen standaard opnieuw te verbinden bij HTTP 429-fouten volgens de clientconfiguratie en met inachtneming van de reactieheader x-ms-retry-after-ms van de service, door te wachten op de aangegeven tijd en daarna opnieuw te proberen.
Wanneer het aantal pogingen van de SDK is overschreden, wordt de fout aan uw toepassing geretourneerd. In het ideale voorbeeld kan het controleren van de x-ms-retry-after-ms header in het antwoord worden gebruikt als hint om te bepalen hoe lang moet worden gewacht voordat de aanvraag opnieuw wordt geprobeerd. Een ander alternatief is een exponentieel terugvalalgoritme of het configureren van de client om de herhaalde pogingen op HTTP 429 uit te breiden.
HTTP 449
De Azure Cosmos DB SDK's proberen het opnieuw op HTTP 449 met een incrementele back-off gedurende een bepaalde periode om de meeste scenario's mogelijk te maken.
Wanneer de automatische SDK-herhalingen worden overschreden, wordt de fout teruggegeven aan uw applicatie. HTTP 449-fouten kunnen veilig opnieuw worden geprobeerd. Vanwege de zeer gelijktijdige aard van schrijfbewerkingen is het beter om een willekeurig uitstelalgoritme te hebben om te voorkomen dat dezelfde mate van gelijktijdigheid na een vast interval wordt herhaald.
Time-outs en connectiviteitsproblemen (HTTP 408/503)
Netwerktime-outs en verbindingsfouten behoren tot de meest voorkomende fouten. De Azure Cosmos DB SDK's zijn zelf tolerant en proberen time-outs en verbindingsproblemen in de HTTP- en TCP-protocollen opnieuw als het mogelijk is om het opnieuw te proberen:
- Voor leesbewerkingen proberen de SDK's een time-out of connectiviteitsfout opnieuw.
- Voor schrijfbewerkingen worden de SDK's niet opnieuw geprobeerd omdat deze bewerkingen niet idempotent zijn. Wanneer er een time-out optreedt die wacht op het antwoord, is het niet mogelijk om te weten of de aanvraag de service heeft bereikt.
Als het account meerdere regio's beschikbaar heeft, proberen de SDK's ook een poging in andere regio's.
Vanwege de aard van time-outs en connectiviteitsfouten worden deze mogelijk niet weergegeven in de metrische gegevens van uw account, omdat deze alleen betrekking hebben op fouten aan de servicezijde.
Het wordt aanbevolen dat toepassingen hun eigen herhalingsbeleid voor deze scenario's hebben en rekening houden met hoe schrijftime-outs opgelost kunnen worden. Als u bijvoorbeeld een time-out bij maken opnieuw probeert, kan dit resulteren in een HTTP 409 (Conflict) als het vorige verzoek de service heeft bereikt, maar het zou lukken als dat niet het geval was.
Taalspecifieke implementatiedetails
Zie voor implementatiedetails met betrekking tot een taal:
Zijn nieuwe pogingen van invloed op mijn latentie?
Vanuit het perspectief van de client hebben alle nieuwe pogingen invloed op de end-to-end-latentie van een bewerking. Wanneer de P99-latentie van uw toepassing wordt beïnvloed, is het belangrijk om de herhalingen die plaatsvinden te begrijpen en te weten hoe u deze kunt aanpakken.
Azure Cosmos DB SDK's bieden gedetailleerde informatie in hun logboeken en diagnostische gegevens waarmee kan worden vastgesteld welke nieuwe pogingen worden uitgevoerd. Zie Diagnostische gegevens vastleggen voor .NET SDK en Java SDK voor meer informatie.
Hoe kan ik latentie bij opnieuw proberen beperken?
Afhankelijk van de omstandigheden routeert de SDK in de meeste gevallen aanvragen naar de lokale regio, de schrijfregio (in een scenario voor schrijven in één regio) of de eerste regio in de lijst met voorkeursregio's . Deze prioriteitsaanduiding minimaliseert de latentie in gezonde scenario's door voornamelijk verbinding te maken met het dichtstbijzijnde of meest optimale datacenter.
Deze prioriteitsaanduiding betekent echter ook dat aanvragen die resulteren in een fout altijd eerst in één specifieke regio worden geprobeerd voor een gegeven foutscenario. Als failover naar een andere regio in dat scenario de voorkeur heeft, wordt dit meestal afgehandeld op de infrastructuurlaag (Traffic Manager) in plaats van op SDK-niveau. De juiste installatie en configuratie van uw infrastructuur kunnen ervoor zorgen dat verkeer efficiënt wordt omgeleid tijdens regionale storingen, waardoor de latentie wordt beperkt die voortkomt uit nieuwe pogingen tussen regio's in een storingsscenario. Raadpleeg de documentatie van Azure Traffic Manager voor meer informatie over het instellen van failover op infrastructuurniveau. Sommige SDK's bieden ondersteuning voor het rechtstreeks implementeren van vergelijkbare failoverstrategieën op SDK-niveau. Zie bijvoorbeeld hoge beschikbaarheid voor Java SDK en .NET SDK.
Hoe zit het met regionale storingen?
De Azure Cosmos DB SDK's hebben betrekking op regionale beschikbaarheid en kunnen nieuwe pogingen uitvoeren voor andere accountregio's. Als u wilt weten welke scenario's betrekking hebben op andere regio's, raadpleegt u scenario's en configuraties voor meerdere regionale omgevingen.
Wanneer neemt u contact op met de klantondersteuning
Voer de volgende stappen uit voordat u contact op neemt met de klantondersteuning:
- Wat is de impact gemeten in omvang van de getroffen bewerkingen vergeleken met de geslaagde bewerkingen? Bevindt deze zich binnen de service-SLA's?
- Is de P99-latentie beïnvloed?
- Zijn de fouten gerelateerd aan foutcodes waarop mijn toepassing opnieuw moet proberen en heeft de toepassing betrekking op dergelijke nieuwe pogingen?
- Zijn de fouten van invloed op al uw toepassingsexemplaren of alleen op een deel ervan? Wanneer het probleem wordt beperkt tot een beperkt aantal exemplaren, betreft het doorgaans een probleem met betrekking tot deze exemplaren.
- Hebt u de gerelateerde documenten voor probleemoplossing in de voorgaande tabel doorlopen om een probleem in de toepassingsomgeving uit te sluiten?
Neem contact op met de klantondersteuning als alle toepassingsexemplaren worden beïnvloed of als het percentage betrokken bewerkingen buiten service-SLA's valt of van invloed is op uw eigen sla's voor toepassingen en P99s.