Läsa ändringsflödet i Azure Cosmos DB
GÄLLER FÖR: 
NoSQL
Du kan arbeta med Azure Cosmos DB-ändringsflödet med hjälp av antingen en push-modell eller en pull-modell. Med en push-modell skickar ändringsflödesprocessorn arbete till en klient som har affärslogik för bearbetning av det här arbetet. Komplexiteten i att söka efter arbete och lagra tillstånd för det senast bearbetade arbetet hanteras dock i ändringsflödesprocessorn.
Med en pull-modell måste klienten hämta arbetet från servern. Klienten har i det här fallet inte bara affärslogik för bearbetning av arbete utan även lagringstillstånd för det senast bearbetade arbetet, hantering av belastningsutjämning över flera klienter som bearbetar arbete parallellt och hanteringsfel.
När du läser från Azure Cosmos DB-ändringsflödet rekommenderar vi vanligtvis att du använder en push-modell eftersom du inte behöver bekymra dig om:
- Avsöka ändringsflödet för framtida ändringar.
- Lagringstillstånd för den senast bearbetade ändringen. Om du läser från ändringsflödesprocessorn lagras tillståndet automatiskt i en lånecontainer.
- Belastningsutjämning mellan flera klienter som förbrukar ändringar. Om en klient till exempel inte kan hänga med i bearbetningsändringarna och en annan har tillgänglig kapacitet.
- Hantera fel. Du kan till exempel automatiskt försöka utföra misslyckade ändringar som inte bearbetades korrekt efter ett ohanterat undantag i kod eller ett tillfälligt nätverksproblem.
De flesta scenarier som använder Azure Cosmos DB-ändringsflödet använder ett av push-modellalternativen. Det finns dock vissa scenarier där du kanske vill ha ytterligare kontroll på låg nivå av pull-modellen. Dessa kan vara:
- Läsa ändringar från en viss partitionsnyckel
- Kontrollera i vilken takt klienten får ändringar för bearbetning
- Göra en engångsläsning av befintliga data i ändringsflödet (till exempel för att utföra en datamigrering)
Läsa ändringsflöde med en push-modell
Att använda en push-modell är det enklaste sättet att läsa från ändringsflödet. Det finns två sätt att läsa från ändringsflödet med en push-modell: Azure Functions Azure Cosmos DB-utlösare och ändringsflödesprocessorn. Azure Functions använder ändringsflödesprocessorn i bakgrunden, så det här är båda liknande sätt att läsa ändringsflödet. Tänk på Azure Functions som en värdplattform för ändringsflödesprocessorn, inte ett helt annat sätt att läsa ändringsflödet.
Azure Functions
Azure Functions är det enklaste alternativet om du precis har börjat använda ändringsflödet. På grund av enkelheten är det också det rekommenderade alternativet för de flesta användningsfall för ändringsflöde. När du skapar en Azure Functions-utlösare för Azure Cosmos DB väljer du den container som ska anslutas och Azure-funktionen utlöses när det sker en ändring i containern. Eftersom Azure Functions använder ändringsflödesprocessorn i bakgrunden parallelliserar den automatiskt ändringsbearbetningen mellan containerns partitioner.
Att utveckla med Azure Functions är en enkel upplevelse och kan gå snabbare än att distribuera ändringsflödesprocessorn på egen hand. Utlösare kan skapas med hjälp av Azure Functions-portalen eller programmatiskt med hjälp av SDK:er. Visual Studio och VS Code ger stöd för att skriva Azure Functions, och du kan även använda Azure Functions CLI för plattformsoberoende utveckling. Du kan skriva och felsöka koden på skrivbordet och sedan distribuera funktionen med en knapp. Mer information finns i Serverlös databasberäkning med hjälp av Azure Functions och Använda ändringsflöde med Azure Functions-artiklar .
Ändringsflödesprocessorbibliotek
SDK:er som stöds
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
Ändringsflödesprocessorn ger dig mer kontroll över ändringsflödet och döljer fortfarande mest komplexitet. Biblioteket för ändringsflödesprocessorn följer övervakningsmönstret, där din bearbetningsfunktion anropas av biblioteket. Ändringsflödesprocessorn söker automatiskt efter ändringar och , om ändringar hittas, "push" dem till klienten. Om du har ett flöde för ändring av högt dataflöde kan du instansiera flera klienter för att läsa ändringsflödet. Ändringsflödesprocessorn delar automatiskt in belastningen mellan de olika klienterna. Du behöver inte implementera någon logik för belastningsutjämning mellan flera klienter eller någon logik för att upprätthålla lånetillståndet.
Ändringsflödesprocessorn garanterar en "minst en gång"-leverans av alla ändringar. Om du använder ändringsflödesprocessorn anropas med andra ord bearbetningsfunktionen för varje objekt i ändringsflödet. Om det finns ett ohanterat undantag i affärslogik i din bearbetningsfunktion görs de misslyckade ändringarna på nytt tills de har bearbetats. Om du vill förhindra att ändringsflödesprocessorn "fastnar" kontinuerligt försöker göra samma ändringar igen lägger du till logik i bearbetningsfunktionen för att skriva dokument, med undantag, till en kö med obeställbara meddelanden. Läs mer om felhantering.
I Azure Functions är rekommendationen för hantering av fel densamma. Du bör fortfarande lägga till logik i din ombudskod för att skriva dokument, om undantagsfel, till en kö med obeställbara meddelanden. Men om det finns ett ohanterat undantag i din Azure-funktion kommer ändringen som genererade undantaget inte att göras om automatiskt. Om det finns ett ohanterat undantag i affärslogik går Azure-funktionen vidare till att bearbeta nästa ändring. Azure-funktionen försöker inte göra samma misslyckade ändring igen.
Precis som i Azure Functions är det enkelt att utveckla med ändringsflödesprocessorbiblioteket. Du ansvarar dock för att distribuera en eller flera värdar för ändringsflödesprocessorn. En värd är en programinstans som använder ändringsflödesprocessorn för att lyssna efter ändringar. Även om Azure Functions har funktioner för automatisk skalning ansvarar du för att skala dina värdar. Mer information finns i använda ändringsflödesprocessorn. Biblioteket för ändringsflödesprocessor är en del av Azure Cosmos DB SDK V3.
Läsa ändringsflöde med en pull-modell
Med pull-modellen för ändringsflöde kan du använda ändringsflödet i din egen takt. Ändringar måste begäras av klienten och det finns ingen automatisk avsökning för ändringar. Om du vill permanent "bokmärke" den senast bearbetade ändringen (liknar push-modellens lånecontainer) måste du spara en fortsättningstoken.
Med hjälp av pull-modellen för ändringsflöde får du mer kontroll över ändringsflödet på låg nivå. När du läser ändringsflödet med pull-modellen har du tre alternativ:
- Läsa ändringar för en hel container
- Läsa ändringar för en specifik FeedRange
- Läsa ändringar för ett specifikt partitionsnyckelvärde
Du kan parallellisera bearbetningen av ändringar mellan flera klienter, precis som med ändringsflödesprocessorn. Pull-modellen hanterar dock inte automatiskt belastningsutjämning mellan klienter. När du använder pull-modellen för att parallellisera bearbetningen av ändringsflödet får du först en lista över FeedRanges. Ett FeedRange sträcker sig över ett intervall med partitionsnyckelvärden. Du måste ha en orkestreringsprocess som hämtar FeedRanges och distribuerar dem mellan dina datorer. Du kan sedan använda dessa FeedRanges för att låta flera datorer läsa ändringsflödet parallellt.
Det finns ingen inbyggd "minst en gång"-leveransgaranti med pull-modellen. Pull-modellen ger dig låg nivåkontroll för att bestämma hur du vill hantera fel.
Ändringsflöde i API:er för Cassandra och MongoDB
Funktionen för ändringsflöde visas som ändringsströmmar i API för MongoDB och Fråga med predikat i API för Cassandra. Mer information om implementeringsinformation för API för MongoDB finns i Ändra strömmar i Azure Cosmos DB för MongoDB.
Native Apache Cassandra tillhandahåller CDC (Change Data Capture), en mekanism för att flagga specifika tabeller för arkivering och avvisa skrivningar till dessa tabeller när en konfigurerbar storlek på disken för CDC-loggen har nåtts. Funktionen för ändringsflöde i Azure Cosmos DB för Apache Cassandra förbättrar möjligheten att köra frågor mot ändringarna med predikat via CQL. Mer information om implementeringsinformation finns i Ändringsflöde i Azure Cosmos DB för Apache Cassandra.
Nästa steg
Nu kan du fortsätta att lära dig mer om ändringsflöde i följande artiklar: