Azure Cosmos DB-változáscsatorna olvasása
A KÖVETKEZŐRE VONATKOZIK: 
NoSQL
Az Azure Cosmos DB változáscsatorna leküldéses vagy lekéréses modellel is használható. Leküldéses modell esetén a változáscsatorna feldolgozója olyan ügyfélnek küldi a munkát, amely üzleti logikával rendelkezik a munka feldolgozásához. Az utolsó feldolgozott munka munka- és tárolási állapotának ellenőrzésének összetettségét azonban a változáscsatorna-feldolgozó kezeli.
Lekéréses modellel az ügyfélnek le kell húznia a munkát a kiszolgálóról. Ebben az esetben az ügyfél nem csak ü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ő egyidejű feldolgozásához és a hibák kezeléséhez.
Az Azure Cosmos DB változáscsatornájából való olvasáskor általában leküldéses modellt 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, módosításokat használó ügyfél között. Ha például az egyik ügyfél nem tud lépést tartani a módosítások feldolgozásával, egy másik pedig rendelkezésre álló kapacitással rendelkezik.
- Hibák kezelése. Például automatikusan újrapróbálkozhat olyan sikertelen módosítások, amelyeket nem megfelelően dolgoztak fel a kód kezeletlen kivétele 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, amelyekben a lekéréses modell további alacsony szintű vezérlésére lehet szükség. Ezek közé tartoznak:
- Változások olvasása egy adott partíciókulcsból
- 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 beolvasása (például adatmigráláshoz)
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: Az Azure Functions Azure Cosmos DB-eseményindítói és a változáscsatorna-feldolgozó. Az Azure Functions a színfalak mögött használja a változáscsatorna-feldolgozót, így mindkettő hasonló módon olvassa be a változáscsatornát. Az Azure Functions egyszerűen egy üzemeltetési platform a változáscsatorna-feldolgozó számára, nem pedig teljesen más módon a változáscsatorna olvasására.
Azure Functions
Az 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 minden alkalommal aktiválódik, amikor változás történik a tárolóban. Mivel az Azure Functions a színfalak mögött használja a változáscsatorna feldolgozóját, automatikusan párhuzamosítja a módosításfeldolgozást a tároló partíciói között.
Az 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, SDK-k használatával hozhatók létre. A Visual Studio és a VS Code támogatja az Azure Functions írását, és akár az Azure Functions CLI-t is használhatja platformfüggetlen fejlesztéshez. A kódot megírhatja és hibakereséssel végezheti el 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 az Azure Functions használatával és változáscsatorna használata az Azure Functions-cikkekkel .
Adatcsatorna processzortárának módosítása
Támogatott SDK-k
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
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ó kódtár 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 fenntartásához nem kell semmilyen logikát implementálnia a több ügyfél közötti terheléselosztáshoz vagy bármilyen logikához.
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 program sikeresen meghívja a feldolgozási függvényt a változáscsatorna minden eleméhez. Ha a feldolgozási függvény üzleti logikájában nem kezelt kivétel van, a rendszer a sikertelen módosításokat újrapróbálkozza, amíg sikeresen fel nem dolgozzák őket. Ha meg szeretné akadályozni, hogy a változáscsatorna feldolgozója folyamatosan újrapróbálkozzon ugyanazon módosításokon, adjon hozzá logikát a feldolgozási függvényhez, hogy kivétel nélkül dokumentumokat írjon egy kézbesítetlen levelek üzenetsorába. További információ a hibakezelésről.
Az Azure Functionsben a hibák kezelésére vonatkozó javaslat ugyanaz. A delegált kódban továbbra is fel kell használnia a logikát, hogy kivétel esetén dokumentumokat írjon egy kézbesítetlen levelek üzenetsorába. Ha azonban nem kezelt kivétel van 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 eredményez, 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 ugyanazt a sikertelen módosítást.
Az Azure Functionshez hasonlóan a változáscsatorna processzortárával való fejlesztés is egyszerű. Ön azonban felelős a változáscsatorna-feldolgozó egy vagy több gazdagépének üzembe helyezéséért. 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éhez. Bár az Azure Functions rendelkezik az automatikus skálázáshoz szükséges képességekkel, ön felel a gazdagépek skálázásáért. További információkért lásd a változáscsatorna processzorának használatát. A változáscsatorna-feldolgozó kódtár 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, hogy a változáscsatornát a saját tempójában használja fel. A módosításokat az ügyfélnek kell kérnie, és nincs automatikus lekérdezés a módosításokról. Ha az utolsó feldolgozott módosítást (a leküldéses modell bérlettárolóhoz hasonlóan) véglegesen "könyvjelzőnek" szeretné nevezni, mentenie kell egy folytatási jogkivonatot.
A változáscsatorna lekérési modelljével alacsonyabb szintű vezérlést kaphat 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:
- Teljes tároló módosításainak olvasása
- Adott FeedRange módosításainak olvasása
- Adott partíciókulcs-érték módosításainak olvasása
A módosítások feldolgozását párhuzamosan több ügyfélen is végezheti, ahogyan a változáscsatorna-feldolgozóval is. A lekéréses modell azonban nem kezeli automatikusan a terheléselosztást az ügyfelek között. Amikor a lekéréses modell használatával 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 beolvassa párhuzamosan a változáscsatornát.
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ói változásfolyamként lesznek felszínre a MongoDB API-ban és a Cassandra API predikátumával rendelkező lekérdezésben. A MongoDB API implementálási részleteiről a Streamek módosítása a MongoDB-hez készült Azure Cosmos DB-ben című témakörben talál további információt.
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ához és írásának elutasításához használható mechanizmus. Az Apache Cassandra-hoz készült Azure Cosmos DB változáscsatorna funkciója javítja a módosítások predikátummal való lekérdezésének lehetőségét a CQL-n keresztül. A megvalósítás részleteiről további információt az Apache Cassandra azure Cosmos DB-jének változáscsatornájában talál.
Következő lépések
A változáscsatornáról a következő cikkekben olvashat bővebben: