Čtení z kanálu změn služby Azure Cosmos DB
PLATÍ PRO: 
NoSQL
S kanálem změn služby Azure Cosmos DB můžete pracovat pomocí modelu nabízení oznámení nebo vyžádání. V případě modelu push procesor kanálu změn předá práci klientovi, který má obchodní logiku pro zpracování této práce. Složitost kontroly práce a ukládání stavu poslední zpracované práce je však zpracována v rámci procesoru kanálu změn.
U modelu vyžádané replikace musí klient vyžádat práci ze serveru. Klient má v tomto případě nejen obchodní logiku pro zpracování práce, ale také ukládání stavu pro poslední zpracovanou práci, vyrovnávání zatížení mezi více klienty zpracovávající práci paralelně a zpracování chyb.
Při čtení z kanálu změn služby Azure Cosmos DB obvykle doporučujeme použít model nabízených oznámení, protože si nemusíte dělat starosti s:
- Dotazování kanálu změn na budoucí změny
- Ukládání stavu poslední zpracované změny Pokud čtete z procesoru kanálu změn, stav se automaticky uloží do kontejneru zapůjčení.
- Vyrovnávání zatížení napříč několika klienty, kteří využívají změny. Například pokud jeden klient nemůže držet krok se zpracováním změn a jiný má dostupnou kapacitu.
- Zpracování chyb. Například automatické opakování neúspěšných změn, které nebyly správně zpracovány po neošetřené výjimce v kódu nebo přechodném problému se sítí.
Většina scénářů, které používají kanál změn služby Azure Cosmos DB, bude používat jednu z možností modelu nabízení. Existují však scénáře, ve kterých můžete chtít další nízkoúrovňovou kontrolu modelu vyžádání obsahu. Tady jsou některé z nich:
- Čtení změn z konkrétního klíče oddílu
- Řízení tempa, jakým klient přijímá změny ke zpracování
- Jednorázové čtení existujících dat v kanálu změn (například při migraci dat)
Čtení kanálu změn pomocí modelu nabízených oznámení
Nejjednodušší způsob, jak číst z kanálu změn, je použití modelu nabízení. Existují dva způsoby, jak můžete číst z kanálu změn pomocí modelu nabízených oznámení: Azure Functions triggery Služby Azure Cosmos DB a procesor kanálu změn. Azure Functions používá procesor kanálu změn na pozadí, takže oba způsoby čtení kanálu změn jsou podobné. Azure Functions si můžete představit jako jednoduše hostující platformu pro procesor kanálu změn, nikoli jako úplně jiný způsob čtení kanálu změn.
Azure Functions
Azure Functions je nejjednodušší možnost, pokud kanál změn teprve začínáte používat. Vzhledem k jednoduchosti se také doporučuje pro většinu případů použití kanálu změn. Když vytvoříte trigger Azure Functions pro službu Azure Cosmos DB, vyberete kontejner, ke kterému se chcete připojit, a funkce Azure Functions se aktivuje vždy, když dojde ke změně kontejneru. Vzhledem k tomu, že Azure Functions na pozadí používá procesor kanálu změn, automaticky paralelizuje zpracování změn napříč oddíly kontejneru.
Vývoj s využitím Azure Functions je snadné a může být rychlejší než vlastní nasazení procesoru kanálu změn. Triggery je možné vytvářet pomocí portálu Azure Functions nebo programově pomocí sad SDK. Visual Studio a VS Code poskytují podporu pro psaní Azure Functions a můžete dokonce použít Azure Functions CLI pro vývoj pro různé platformy. Kód můžete napsat a ladit na ploše a pak funkci nasadit jedním tlačítkem. Další informace najdete v článcích o bezserverové databázi s využitím Azure Functions a Používání kanálu změn s Azure Functions.
Knihovna procesoru kanálu změn
Procesor kanálu změn poskytuje větší kontrolu nad kanálem změn a stále skrývá většinu složitosti. Knihovna procesoru kanálu změn se řídí vzorem pozorovatele, kde knihovna volá funkci zpracování. Procesor kanálu změn automaticky zkontroluje změny, a pokud se změny najdou, nasdílí je klientovi. Pokud máte kanál změn s vysokou propustností, můžete vytvořit instanci více klientů, aby si mohli kanál změn přečíst. Procesor kanálu změn automaticky rozdělí zatížení mezi různé klienty. Pokud chcete zachovat stav zapůjčení, nebudete muset implementovat žádnou logiku pro vyrovnávání zatížení mezi více klienty ani žádnou logiku.
Procesor kanálu změn zaručuje alespoň jedno doručení všech změn. Jinými slovy, pokud použijete procesor kanálu změn, bude funkce zpracování úspěšně volána pro každou položku v kanálu změn. Pokud je v obchodní logice ve vaší funkci zpracování neošetřená výjimka, neúspěšné změny se budou opakovat, dokud nebudou úspěšně zpracovány. Pokud chcete zabránit tomu, aby se procesor kanálu změn "zasekl" při neustálém opakování stejných změn, přidejte do funkce zpracování logiku pro zápis dokumentů do fronty nedoručených zpráv (pokud je výjimka). Přečtěte si další informace o zpracování chyb.
V Azure Functions je doporučení pro zpracování chyb stejné. Přesto byste měli do kódu delegáta přidat logiku pro zápis dokumentů do fronty nedoručených zpráv(y). Pokud je ale ve vaší funkci Azure Functions neošetřená výjimka, změna, která výjimku vygenerovala, se automaticky opakovat nebude. Pokud je v obchodní logice neošetřená výjimka, funkce Azure Functions přejde ke zpracování další změny. Funkce Azure Functions se nebude opakovat stejnou neúspěšnou změnu.
Stejně jako Azure Functions je vývoj s knihovnou procesoru kanálu změn snadný. Zodpovídáte ale za nasazení jednoho nebo více hostitelů pro procesor kanálu změn. Hostitel je instance aplikace, která používá procesor kanálu změn k naslouchání změnám. I když Azure Functions nabízí možnosti automatického škálování, zodpovídáte za škálování hostitelů vy. Další informace najdete v tématu použití procesoru kanálu změn. Knihovna procesoru kanálu změn je součástí sady Sdk služby Azure Cosmos DB v3.
Čtení kanálu změn s modelem vyžádání
Model vyžádání kanálu změn umožňuje využívat kanál změn vlastním tempem. Změny musí být požadovány klientem a neexistuje žádné automatické dotazování na změny. Pokud chcete trvale "vytvořit záložku" pro poslední zpracovanou změnu (podobně jako kontejner zapůjčení modelu nabízení), budete muset uložit token pro pokračování.
Pomocí modelu vyžádání kanálu změn získáte nižší úroveň kontroly kanálu změn. Při čtení kanálu změn s modelem vyžádání změn máte tři možnosti:
- Čtení změn pro celý kontejner
- Čtení změn pro konkrétní rozsah feedRange
- Čtení změn pro konkrétní hodnotu klíče oddílu
Zpracování změn můžete paralelizovat napříč více klienty stejně jako u procesoru kanálu změn. Model vyžádané replikace ale automaticky nezvládá vyrovnávání zatížení mezi klienty. Když použijete model vyžádání k paralelizaci zpracování kanálu změn, nejprve získáte seznam kategorií FeedRanges. FeedRange zahrnuje rozsah hodnot klíče oddílu. Budete potřebovat proces orchestrátoru, který získá FeedRanges a distribuuje je mezi vaše počítače. Tyto možnosti FeedRanges pak můžete použít k paralelnímu čtení kanálu změn několika počítačům.
U modelu vyžádání není žádná integrovaná záruka doručení "alespoň jednou". Model vyžádání vám poskytuje řízení nízké úrovně, abyste se mohli rozhodnout, jak chcete zpracovávat chyby.
Kanál změn v rozhraních API pro Cassandra a MongoDB
Funkce kanálu změn se v rozhraní API pro MongoDB zobrazí jako streamy změn a v rozhraní API pro Cassandra se zobrazí jako datové proudy změn s predikátem Query s predikátem. Další informace o implementaci rozhraní API pro MongoDB najdete v tématu Změna datových proudů ve službě Azure Cosmos DB pro MongoDB.
Nativní Apache Cassandra poskytuje mechanismus pro zachytávání dat změn (CDC), což je mechanismus pro označování konkrétních tabulek pro archivaci a odmítání zápisů do těchto tabulek, jakmile se dosáhne konfigurovatelné velikosti na disku pro protokol CDC. Funkce kanálu změn ve službě Azure Cosmos DB for Apache Cassandra vylepšuje možnost dotazovat se na změny s predikátem prostřednictvím jazyka CQL. Další informace o implementaci najdete v tématu Kanál změn ve službě Azure Cosmos DB pro Apache Cassandra.
Další kroky
Další informace o kanálu změn teď najdete v následujících článcích: