Rugalmas alkalmazások tervezése az Azure Cosmos DB SDK-kkal

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: NoSQL

Ha olyan ügyfélalkalmazásokat hoz létre, amelyek bármely SDK-val kommunikálnak az Azure Cosmos DB-vel, fontos tisztában lenni néhány alapvető alapismerettel. Ez a cikk egy tervezési útmutató, amely segít megérteni ezeket az alapokat és a rugalmas alkalmazások tervezését.

Áttekintés

A cikkben tárgyalt fogalmak áttekintését a következő videóban tekintheti meg:

Csatlakozási módok

Az Azure Cosmos DB SDK-k két kapcsolati módban tudnak csatlakozni a szolgáltatáshoz. A .NET és a Java SDK-k átjáró és Közvetlen módban is csatlakozhatnak a szolgáltatáshoz, míg a többi csak Átjáró módban. Az átjáró mód a HTTP protokollt használja, a Közvetlen mód pedig általában a TCP protokollt.

Az átjáró mód mindig a metaadatok, például a fiók, a tároló és az útválasztási információk lekérésére szolgál, függetlenül attól, hogy az SDK melyik módra van konfigurálva. Ezeket az adatokat a rendszer gyorsítótárazza a memóriában, és a szolgáltatásreplikákhoz való csatlakozásra szolgál.

Összefoglalva, átjáró módban az SDK-k esetében HTTP-forgalom várható, míg a közvetlen módban lévő SDK-k esetében a HTTP- és TCP-forgalom különböző körülmények között (például inicializálás, metaadatok beolvasása vagy útválasztási információk) kombinációjára számíthat.

Ügyfélpéldányok és kapcsolatok

A kapcsolati módtól függetlenül kritikus fontosságú az SDK-ügyfél Singleton-példányának karbantartása alkalmazásonkénti fiókonként. A HTTP- és TCP-kapcsolatok hatóköre az ügyfélpéldányra terjed ki. A legtöbb számítási környezet korlátozásokkal rendelkezik az egyidejűleg megnyitható kapcsolatok száma tekintetében, és ha eléri ezeket a korlátokat, a kapcsolat is érintett lesz.

Elosztott alkalmazások és hálózatok

Elosztott alkalmazások tervezésekor három fő összetevő áll rendelkezésre:

  • Az alkalmazás és a környezet, amelyen fut.
  • A hálózat, amely az alkalmazás és az Azure Cosmos DB szolgáltatásvégpont közötti bármely összetevőt tartalmazza.
  • Az Azure Cosmos DB szolgáltatásvégpontja.

A hibák gyakran a három terület egyikébe esnek, és fontos tisztában lenni azzal, hogy a rendszer elosztott jellege miatt nem praktikus 100%-os rendelkezésre állásra számítani ezen összetevők bármelyike esetében.

Az Azure Cosmos DB rendelkezésre állási SLA-k átfogó készletével rendelkezik, de egyik sem 100%. Az alkalmazást a szolgáltatásvégponthoz csatlakoztató hálózati összetevők átmeneti hardverproblémákkal és csomagvesztésekkel is rendelkezhetnek. Még a számítási környezetben is, ahol az alkalmazás fut, cpu-kiugrás hatással lehet a műveletekre. Ezek a hibaállapotok hatással lehetnek az SDK-k működésére, és általában bizonyos kódokkal kapcsolatos hibákként jelennek meg.

Az alkalmazásnak rugalmasnak kell lennie a lehetséges hibák bizonyos fokával szemben ezen összetevők esetében azáltal, hogy újrapróbálkozási szabályzatokat implementál az SDK-k által biztosított válaszokon keresztül.

Újrapróbálkoznia az alkalmazásomnak a hibákon?

A rövid válasz igen. De nem minden hiba esetén van értelme újrapróbálkozást végezni, egyes hiba- vagy állapotkódok nem átmenetiek. Az alábbi táblázat részletesen ismerteti őket:

Állapotkód Újrapróbálkozás hozzáadása SDK-k újrapróbálkozása Leírás
400 Nem Nem Hibás kérés
401 Nem Nem Nem engedélyezett
403 Választható No Forbidden
404 Nem Nem Az erőforrás nem található
408 Igen Yes Request timed out
409 Nem Nem Az ütközési hiba akkor jelentkezik, ha egy írási művelet erőforrásához megadott identitást (azonosítót és partíciókulcsot) egy meglévő erőforrás vette át, vagy ha megsértették az egyedi kulcskényszert .
410 Igen Yes Megszűnt kivételek (átmeneti hiba, amely nem sértheti meg az SLA-t)
412 Nem Nem Az előfeltételhiba az, amikor a művelet olyan eTaget adott meg, amely eltér a kiszolgálón elérhető verziótól. Optimista egyidejűségi hiba. Az erőforrás legfrissebb verziójának beolvasása és a kérés eTagjének frissítése után próbálkozzon újra a kéréssel.
413 Nem Nem Túl nagy kérelementitás
429 Igen Yes A 429-et nyugodtan újrapróbálhatja. Tekintse át az útmutatót a HTTP 429 hibaelhárításához.
449 Igen Yes Átmeneti hiba, amely csak az írási műveleteknél fordul elő, és biztonságosan újrapróbálkozhat. Ez olyan tervezési problémára utalhat, amely miatt túl sok egyidejű művelet próbálja frissíteni ugyanazt az objektumot az Azure Cosmos DB-ben.
500 Nem Nem A művelet váratlan szolgáltatáshiba miatt meghiúsult. Lépjen kapcsolatba az ügyfélszolgálattal egy Azure-támogatás probléma bejelentésével.
503 Igen Yes A szolgáltatás nem érhető el

A fenti táblázatban a második oszlopban igennel megjelölt állapotkódoknak bizonyos fokú újrapróbálkozással kell rendelkezniük az alkalmazásban.

HTTP 403

Az Azure Cosmos DB SDK-k általában nem próbálkoznak újra a HTTP 403-as hibákkal, de bizonyos hibák a HTTP 403-mal kapcsolatosak, amelyekre az alkalmazás reagálhat. Ha például hibaüzenetet kap arról, hogy egy partíciókulcs megtelt, dönthet úgy, hogy módosítja az írni kívánt dokumentum partíciókulcsát valamilyen üzleti szabály alapján.

HTTP 429

Az Azure Cosmos DB SDK-k alapértelmezés szerint újrapróbálkoznak HTTP 429-hibákkal az ügyfélkonfigurációt követően, és tiszteletben tartják a szolgáltatás válaszfejlécét x-ms-retry-after-ms a megadott idő várakozásával és az újrapróbálkozással.

Az SDK újrapróbálkozásainak túllépésekor a rendszer visszaadja a hibát az alkalmazásnak. Ideális esetben a válasz fejlécének x-ms-retry-after-ms vizsgálatával eldöntheti, hogy mennyi ideig kell várnia a kérés újrapróbálkozása előtt. Egy másik alternatíva egy exponenciális háttéralgoritmus, vagy az ügyfél konfigurálása az újrapróbálkozási próbálkozások HTTP 429-en való kiterjesztésére.

HTTP 449

Az Azure Cosmos DB SDK-k újrapróbálkoznak a HTTP 449-en, és egy növekményes visszakapcsolással egy meghatározott időtartamon belül, a legtöbb forgatókönyvnek megfelelően.

Amikor az SDK automatikus újrapróbálkozásai elérik a korlátot, ez a hiba lesz visszaadva az alkalmazásnak. A HTTP 449-hibák biztonságosan újrapróbálkozhatók. Az írási műveletek erős párhuzamossága miatt érdemesebb véletlenszerűen visszalépő algoritmust használni, amellyel elkerülhető az azonos szintű egyidejűség rögzített időkoözönkénti ismétlődése.

A hálózati időtúllépések és a csatlakozási hibák a leggyakoribb hibák közé tartoznak. Az Azure Cosmos DB SDK-k maguk is rugalmasak, és újrapróbálkoznak az időtúllépésekkel és csatlakozási problémákkal a HTTP- és TCP-protokollok között, ha az újrapróbálkozás megvalósítható:

  • Olvasási műveletek esetén az SDK-k minden időtúllépéssel vagy kapcsolódással kapcsolatos hibát újrapróbálkoznak.
  • Írási műveletek esetén az SDK-k nem próbálkoznak újra, mert ezek a műveletek nem idempotensek. Ha időtúllépés történik a válaszra várva, nem lehet tudni, hogy a kérés elérte-e a szolgáltatást.

Ha a fiók több régióval is rendelkezik, az SDK-k régióközi újrapróbálkozási kísérletet is megkísérelnek.

Az időtúllépések és a csatlakozási hibák természete miatt előfordulhat, hogy ezek nem jelennek meg a fiókmetrikákban, mivel ezek csak a szolgáltatás oldalán előforduló hibákat fedik le.

Javasoljuk, hogy az alkalmazások saját újrapróbálkozési szabályzattal rendelkezzenek ezekhez a forgatókönyvekhez, és vegyék figyelembe az írási időtúllépések feloldásának módját. A Létrehozás időtúllépéssel való újrapróbálkozás például HTTP 409-et (ütközést) eredményezhet, ha az előző kérés elérte a szolgáltatást, de ha nem, akkor sikeres lesz.

Nyelvspecifikus megvalósítás részletei

A nyelvvel kapcsolatos további megvalósítási részletekért lásd:

Befolyásolják az újrapróbálkozási műveletek a késésemet?

Az ügyfél szempontjából minden újrapróbálkozás hatással lesz egy művelet végpontok közötti késésére. Ha az alkalmazás P99 késése érintett, fontos megérteni a folyamatban lévő újrapróbálkozásokat és azok megoldását.

Az Azure Cosmos DB SDK-k részletes információkat nyújtanak a naplóikban és diagnosztikáikban, amelyek segítenek azonosítani, hogy mely újrapróbálkozások történnek. További információt a .NET SDK-diagnosztikák gyűjtéséről és a Java SDK-diagnosztikák gyűjtéséről talál.

Mi a helyzet a regionális kimaradásokkal?

Az Azure Cosmos DB SDK-k lefedik a regionális rendelkezésre állást, és újrapróbálkozhatnak egy másik fiókrégión. A többrégiós környezetek újrapróbálkozik forgatókönyvekkel és konfigurációkkal foglalkozó cikkből megtudhatja, hogy mely forgatókönyvek érintik más régiókat.

Mikor forduljon az ügyfélszolgálathoz?

Mielőtt kapcsolatba lép az ügyfélszolgálattal, hajtsa végre az alábbi lépéseket:

  • Mi a mért hatás az érintett műveletek számát a sikeres műveletek számával összehasonlítva? A szolgáltatás SLA-jában van?
  • Érintett a P99 késése?
  • A hibák olyan hibakódokkal kapcsolatosak, amelyeken az alkalmazásnak újra kell próbálkoznia, és az alkalmazás lefedi az ilyen újrapróbálkozásokat?
  • A hibák az összes alkalmazáspéldányt érintik, vagy csak egy részüket? Ha a probléma csak a példányok egy részére korlátozódik, a probléma általában az adott példányokkal kapcsolatos.
  • Átnézte a fenti táblázatban található kapcsolódó hibaelhárítási dokumentumokat, hogy kizárjon egy problémát az alkalmazáskörnyezetben?

Ha az összes alkalmazáspéldány érintett, vagy az érintett műveletek százalékos aránya a szolgáltatási SLA-kon kívül esik, vagy a saját alkalmazás-SLA-kat és P99-eket érinti, forduljon az ügyfélszolgálathoz.

Következő lépések