Azure Cosmos DB-változáscsatorna olvasása

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB változáscsatornájával leküldéses vagy lekéréses modellel is dolgozhat. Leküldéses modell esetén a változáscsatorna feldolgozója egy olyan ügyfélnek küldi el a munkát, amely üzleti logikával rendelkezik a munka feldolgozásához. Az utolsó feldolgozott munka munka- és adattárolási állapotának ellenőrzésének összetettségét azonban a változáscsatorna-feldolgozó kezeli.

Lekéréses modell esetén az ügyfélnek le kell vonnia a munkát a kiszolgálóról. Ebben az esetben az ügyfél nemcsak üzleti logikával rendelkezik a munka feldolgozásához, hanem az utolsó feldolgozott munka állapotának tárolásához is, a terheléselosztás több ügyfél között történő párhuzamos feldolgozásához és a hibák kezeléséhez.

Amikor az Azure Cosmos DB változáscsatornájából olvas, általában egy leküldéses modell használatát javasoljuk, mert nem kell aggódnia:

  • A változáscsatorna lekérdezése a jövőbeli változásokhoz.
  • Az utolsó feldolgozott módosítás állapotának tárolása. Ha a változáscsatorna-feldolgozóból olvas, az állapot automatikusan egy bérlettárolóban lesz tárolva.
  • Terheléselosztás több ügyfél között, amely módosításokat használ. Ha például az egyik ügyfél nem tud lépést tartani a módosítások feldolgozásával, és egy másik rendelkezik rendelkezésre álló kapacitással.
  • Hibák kezelése. Például automatikusan újrapróbálkozott azokkal a sikertelen módosításokkal, amelyeket nem sikerült megfelelően feldolgozni egy kódban lévő kezeletlen kivétel vagy egy átmeneti hálózati probléma után.

Az Azure Cosmos DB változáscsatornáját használó legtöbb forgatókönyv a leküldéses modell egyik beállítását fogja használni. Vannak azonban olyan forgatókönyvek, amikor szükség lehet a lekéréses modell további alacsony szintű vezérlésére. Ezek a következők:

  • Egy adott partíciókulcs módosításainak beolvasása
  • Annak szabályozása, hogy az ügyfél milyen ütemben fogadja a módosításokat a feldolgozáshoz
  • A változáscsatorna meglévő adatainak egyszeri olvasása (például adatmigrálás)

Változáscsatorna olvasása leküldéses modellel

A leküldéses modell használata a legegyszerűbb módja a változáscsatornából való olvasásnak. A változáscsatornából kétféleképpen olvashat leküldéses modellel: Azure Functions Azure Cosmos DB-eseményindítókat és a változáscsatorna-feldolgozót. Azure Functions a színfalak mögötti változáscsatorna-feldolgozót használja, így mindkettő hasonló módon olvassa be a változáscsatornát. Gondoljon Azure Functions egyszerűen egy üzemeltetési platform a változáscsatorna processzor, nem teljesen más módon olvasása a változáscsatorna.

Azure Functions

Azure Functions a legegyszerűbb megoldás, ha még csak most kezdi használni a változáscsatornát. Egyszerűsége miatt ez a legtöbb változáscsatorna-használati eset esetében is ajánlott. Amikor létrehoz egy Azure Functions eseményindítót az Azure Cosmos DB-hez, kiválasztja a csatlakoztatni kívánt tárolót, és az Azure-függvény akkor aktiválódik, amikor változás történik a tárolóban. Mivel Azure Functions a színfalak mögött használja a változáscsatorna feldolgozóját, automatikusan párhuzamosítja a változásfeldolgozást a tároló partíciói között.

A Azure Functions használatával történő fejlesztés egyszerű élmény, és gyorsabb lehet, mint a változáscsatorna-feldolgozó önálló üzembe helyezése. Az eseményindítók az Azure Functions portálon vagy programozott módon hozhatók létre SDK-k használatával. A Visual Studio és a VS Code támogatást nyújt a Azure Functions írásához, és a Azure Functions CLI-t platformfüggetlen fejlesztéshez is használhatja. Írhat és hibakeresést végezhet a kódot az asztalon, majd üzembe helyezheti a függvényt egy gombbal. További információ: Kiszolgáló nélküli adatbázis-számítástechnika Azure Functions ésváltozáscsatorna használata Azure Functions cikkekkel.

Adatcsatorna processzortárának módosítása

A változáscsatorna feldolgozója nagyobb mértékben szabályozza a változáscsatornát, és továbbra is elrejti a legnagyobb összetettségeket. A változáscsatorna feldolgozói kódtára a megfigyelői mintát követi, ahol a feldolgozási függvényt a kódtár hívja meg. A változáscsatorna feldolgozója automatikusan ellenőrzi a módosításokat, és ha módosításokat talál, "leküldi" őket az ügyfélnek. Ha nagy átviteli sebességű változáscsatornával rendelkezik, több ügyfelet is létrehozhat a változáscsatorna olvasásához. A változáscsatorna feldolgozója automatikusan elosztja a terhelést a különböző ügyfelek között. A bérlet állapotának fenntartásához nem kell semmilyen logikát implementálnia a terheléselosztáshoz több ügyfél között, és semmilyen logikát sem.

A változáscsatorna feldolgozója garantálja az összes módosítás "legalább egyszer" történő kézbesítését. Más szóval, ha a változáscsatorna-feldolgozót használja, a feldolgozási függvényt a rendszer sikeresen meghívja a változáscsatorna minden eleméhez. Ha a feldolgozási függvény üzleti logikája nem kezelt kivételt jelez, a rendszer a sikertelen módosításokat újrapróbálja, amíg sikeresen fel nem dolgozzák őket. Ha meg szeretné akadályozni, hogy a változáscsatorna-feldolgozó folyamatosan újrapróbálkozzon ugyanazokkal a módosításokkal, adjon hozzá logikát a feldolgozási függvényhez, hogy kivétel nélkül dokumentumokat írjon egy kézbesítetlen üzenetsorba. További információ a hibakezelésről.

A Azure Functions a hibák kezelésére vonatkozó javaslat ugyanaz. A delegált kódban továbbra is hozzá kell adnia logikát, hogy kivétel esetén dokumentumokat írjon egy kézbesítetlen üzenetsorba. Ha azonban nem kezelt kivétel található az Azure-függvényben, a kivételt létrehozó módosítás nem lesz automatikusan újrapróbálkozott. Ha az üzleti logika nem kezelt kivételt jelez, az Azure-függvény továbblép a következő módosítás feldolgozására. Az Azure-függvény nem próbálkozik újra ugyanazzal a sikertelen módosítással.

A Azure Functions-hez hasonlóan a változáscsatorna processzortárával való fejlesztés is egyszerű. Azonban ön a felelős egy vagy több gazdagép üzembe helyezéséért a változáscsatorna-feldolgozóhoz. A gazdagép egy olyan alkalmazáspéldány, amely a változáscsatorna feldolgozóját használja a módosítások figyelésére. Bár Azure Functions rendelkezik automatikus skálázási képességekkel, a gazdagépek skálázásáért Ön a felelős. További információ: A változáscsatorna-feldolgozó használata. A változáscsatorna feldolgozói kódtára az Azure Cosmos DB SDK V3 része.

Változáscsatorna olvasása lekéréses modellel

A változáscsatorna lekérési modellje lehetővé teszi a változáscsatorna saját ütemben történő felhasználását. A módosításokat az ügyfélnek kell kérnie, és nincs automatikus lekérdezés a módosításokról. Ha véglegesen "könyvjelzőként" szeretné megjeleníteni az utolsó feldolgozott módosítást (hasonlóan a leküldéses modell bérlettárolóhoz), mentenie kell egy folytatási jogkivonatot.

A változáscsatorna lekérési modelljével alacsonyabb szintű vezérlést kap a változáscsatorna felett. A változáscsatorna lekéréses modellel való olvasásakor három lehetőség közül választhat:

A módosítások feldolgozását több ügyfél között is párhuzamosíthatja, ugyanúgy, mint a változáscsatorna feldolgozójával. A lekéréses modell azonban nem kezeli automatikusan a terheléselosztást az ügyfelek között. Amikor a lekéréses modellel párhuzamosítja a változáscsatorna feldolgozását, először lekéri a FeedRanges listáját. A FeedRange a partíciókulcs-értékek tartományára terjed ki. Rendelkeznie kell egy vezénylési eljárással, amely lekéri a FeedRanges-eket, és elosztja őket a gépek között. Ezután a FeedRanges használatával több gép is felolvastathatja a változáscsatornát párhuzamosan.

A lekéréses modellhez nincs beépített "legalább egyszer" kézbesítési garancia. A lekéréses modell alacsony szintű vezérlést biztosít, hogy eldöntse, hogyan szeretné kezelni a hibákat.

Változáscsatorna a Cassandra és a MongoDB API-jában

A változáscsatorna-funkció változásstreamekként jelenik meg a MongoDB API-ban és a Cassandra API-ban predikátummal rendelkező Lekérdezésben. A MongoDB API implementálási részleteiről további információt a Streamek módosítása a MongoDB-hez készült Azure Cosmos DB-ben című témakörben talál.

A natív Apache Cassandra módosítási adatrögzítést (CDC) biztosít, amely a cdc-napló konfigurálható lemezméretének elérése után az adott táblák archiválására és az írások elutasítására szolgál. Az Apache Cassandra-hoz készült Azure Cosmos DB változáscsatorna szolgáltatása javítja a módosítások CQL-n keresztüli predikátummal történő lekérdezésének képességét. A megvalósítás részleteiről további információt a Változáscsatorna az Apache Cassandra Azure Cosmos DB-ben című témakörben talál.

Következő lépések

A változáscsatornáról a következő cikkekben olvashat bővebben: