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 lagringstillstå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 hantering av fel.
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ök ä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 för flera klienter som förbrukar ändringar. Om till exempel en klient 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 något av push-modellalternativen. Det finns dock några scenarier där du kanske vill ha ytterligare kontroll på låg nivå för pull-modellen. Dessa omfattar:
- Läsa ändringar från en viss partitionsnyckel
- Kontrollera i vilken takt klienten tar emot ändringar för bearbetning
- Gör 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 över containerns partitioner.
Att utveckla med Azure Functions är en enkel upplevelse och kan vara 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 har 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 Azure Functions och Använda ändringsflöde med Azure Functions artiklar.
Ändringsflödesprocessorbibliotek
Ändringsflödesprocessorn ger dig mer kontroll över ändringsflödet och döljer fortfarande den största komplexiteten. Ändringsflödesprocessorbiblioteket följer övervakningsmönstret, där din bearbetningsfunktion anropas av biblioteket. Ändringsflödesprocessorn söker automatiskt efter ändringar och om ändringar hittas "pushar" de till klienten. Om du har en ändringsfeed för högt dataflöde kan du instansiera flera klienter för att läsa ändringsflödet. Ändringsflödesprocessorn delar automatiskt 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, om undantagsvis, 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 ombudskoden för att vid undantag skriva dokument 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 bearbetning av nästa ändring. Azure-funktionen försöker inte göra samma misslyckade ändring igen.
Precis som 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. Ändringsflödesprocessorbiblioteket är en del av Azure Cosmos DB SDK V3.
Läsa ändringsflöde med en pull-modell
Med hämtningsmodellen 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 "bokmrätta" den senast bearbetade ändringen permanent (ungefär som 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 på låg nivå av ändringsflödet. 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. En FeedRange omfattar 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 leveransgaranti "minst en gång" 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 CHANGE Data Capture (CDC), 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. Ändringsflödesfunktionen 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 ändringsfeed i följande artiklar: