Tutustu muutossyötettä Azure Cosmos DB:ssä

Valmis

Azure Cosmos DB:n muutossyöte on pysyvä tietue säiliöön muutoksista siinä järjestyksessä, jossa ne tapahtuvat. Azure Cosmos DB:n syöttötuen muuttaminen toimii kuuntelemalla Azure Cosmos DB -säilöä. Sen jälkeen se tulostaa lajitellun luettelon asiakirjoista, jotka on muutettu siinä järjestyksessä, jossa niitä on muutettu. Pysyvät muutokset voidaan käsitellä asynkronisesti ja asteittain, ja tuotos voidaan jakaa vähintään yhdelle kuluttajalle rinnakkaiskäsittelyä varten.

Muuta syötettä ja eri toimintoja

Näet tänään kaikki muutossyötteen lisäykset ja päivitykset. Et voi suodattaa muutossyötettä tietyntyyppisessä toiminnossa. Tällä hetkellä muutossyöte ei kirjaa toimintoja. Vaihtoehtoisena menetelmänä voit lisätä poistettavat kohteet pehmeän merkinnän. Voit esimerkiksi lisätä kohteelle määritteen nimeltä "poistettu", määrittää sen arvoksi "true" ja asettaa kohteelle sitten live-tilaan (TTL) -arvon. Kun määrität TTL:n, varmistat, että kohde poistetaan automaattisesti.

Azure Cosmos DB:n muutossyötteen lukeminen

Voit käsitellä Azure Cosmos DB-muutossyötettä käyttämällä joko push-mallia tai pull-mallia. Push-mallissa muutoksen syöttökäsittely siirtää työnnön asiakkaaseen, jolla on liiketoimintalogiikka tämän työn käsittelemiseen. Työn tarkistamisen ja viimeisen käsitellyn työn tallennustavan monimutkaisuutta kuitenkin käsitellään muutoksenkäsittelyssä.

Pull-mallin avulla asiakkaan on nostettava työt palvelimelta. Tässä tapauksessa asiakkaalla on liiketoimintalogiikka työn käsittelyä varten ja se tallentaa myös viimeisen käsitellyn työn tilan. Asiakas käsittelee kuormituksen tasaamisen useilta asiakkailta, jotka käsittelevät kuormitusta rinnakkain ja käsittelevät virheitä.

Muistiinpano

Push-mallin käyttäminen on suositeltavaa, koska sinun ei tarvitse huolehtia kyselystä muutossyötteessä tulevia muutoksia varten, tilan tallentamisesta viimeiselle käsitellylle muutokselle ja muista eduista.

Useimmissa Skenaarioissa, joissa käytetään Azure Cosmos DB-muutossyötettä, käytetään yhtä push-mallin vaihtoehdoista. On kuitenkin joitakin tilanteita, joissa saatat haluta pull-mallin ylimääräisen alemman tason ohjausobjektin. Alemman tason lisäohjausobjekti sisältää:

  • Muutosten lukeminen tietystä osion avaimesta
  • Hallita nopeutta, jolla asiakas vastaanottaa muutoksia käsiteltäviksi
  • Kertalukeminen muutossyötteen olemassa olevista tiedoista (esimerkiksi tietojen siirtämiseksi)

Muutossyötteen lukeminen push-mallilla

Voit lukea muutossyötteestä kahdella tavalla push-mallin avulla: Azure Functions Azure Cosmos DB -käynnistimet ja syöttöprosessorin muutoskirjasto. Azure-funktiot käyttävät vaihtosyötteen suoritinta taustalla, joten nämä molemmat ovat samanlaisia tapoja lukea muutossyöte. Azure-funktiot ovat ikään kuin yksinkertaisesti syöttökäsittelyn isännöintialusta, joka ei ole täysin erilainen tapa lukea muutossyötettä. Azure-funktiot käyttävät vaihtosyötteen suoritinta taustalla. Se rinnakkaisesti muutosten käsittelyn säilön osioissa.

Azure-funktiot

Voit luoda pieniä, reagoivia Azure-funktioita, jotka käynnistyvät automaattisesti jokaisessa uudessa tapahtumassa Azure Cosmos DB -säilön muutossyötteessä. Azure Cosmos DB :n Azure-funktioiden-käynnistimen avulla voit käyttää Muuta syötteen prosessorin skaalauksen ja luotettavan tapahtuman tunnistamisen toimintoja ilman, että sinun tarvitsee ylläpitää työntekijäinfrastruktuuria.

kaavio, joka näyttää, että muutossyöte käynnistää Azure-funktiot käsiteltäviksi.

Vaihda syötteenkäsittelyä

Vaihtosyötteen suoritin on osa Azure Cosmos DB .NET V3 - ja Java V4 SDK:ita. Se yksinkertaistaa muutossyötteen lukemisprosessia ja jakaa tapahtuman käsittelyn tehokkaasti useille kuluttajille.

Muutoksensyöttösuorittimen käyttöönotossa on neljä pääosaa:

  1. Valvotun säilön: Valvotussa säilössä on tiedot, joista muutossyöte luodaan. Kaikki valvotun säilön lisäykset ja päivitykset näkyvät säilön muutossyötteessä.

  2. Vuokrasäilö: Vuokrasäilö toimii valtion tallennustilana ja koordinoi muutossyötteen käsittelyä useiden työntekijöiden välillä. Vuokrasäilö voidaan tallentaa samalle tilille kuin valvottu säilö tai erilliselle tilille.

  3. Käsittelyesiintymä: Käsittelyesiintymä isännöi muutoksen syöttökäsittelyä muutosten kuuntelemista varten. Käyttöympäristöstä riippuen sitä voi edustaa näennäiskone, kubernetes-pod, Azure-sovelluspalvelun esiintymä, todellinen fyysinen kone. Tässä artikkelissa on yksilöivä tunniste, johon on viitattu esiintymän nimenä.

  4. Edustaja-: Edustaja on koodi, joka määrittää, mitä sinä, kehittäjä, haluat tehdä kullekin muutoserälle, jonka muutoksen syötönkäsittely lukee.

Kun vaihdat syötteenkäsittelyä, syöttöpiste on aina valvottu säilö, Container esiintymästä kutsut GetChangeFeedProcessorBuilder:

/// <summary>
/// Start the Change Feed Processor to listen for changes and process them with the HandleChangesAsync implementation.
/// </summary>
private static async Task<ChangeFeedProcessor> StartChangeFeedProcessorAsync(
    CosmosClient cosmosClient,
    IConfiguration configuration)
{
    string databaseName = configuration["SourceDatabaseName"];
    string sourceContainerName = configuration["SourceContainerName"];
    string leaseContainerName = configuration["LeasesContainerName"];

    Container leaseContainer = cosmosClient.GetContainer(databaseName, leaseContainerName);
    ChangeFeedProcessor changeFeedProcessor = cosmosClient.GetContainer(databaseName, sourceContainerName)
        .GetChangeFeedProcessorBuilder<ToDoItem>(processorName: "changeFeedSample", onChangesDelegate: HandleChangesAsync)
            .WithInstanceName("consoleHost")
            .WithLeaseContainer(leaseContainer)
            .Build();

    Console.WriteLine("Starting Change Feed Processor...");
    await changeFeedProcessor.StartAsync();
    Console.WriteLine("Change Feed Processor started.");
    return changeFeedProcessor;
}

Jossa ensimmäinen parametri on erillinen nimi, joka kuvaa tämän suorittimen tavoitetta, ja toinen nimi on delegointi, joka käsittelee muutoksia. Seuraavassa on esimerkki edustajasta:

/// <summary>
/// The delegate receives batches of changes as they are generated in the change feed and can process them.
/// </summary>
static async Task HandleChangesAsync(
    ChangeFeedProcessorContext context,
    IReadOnlyCollection<ToDoItem> changes,
    CancellationToken cancellationToken)
{
    Console.WriteLine($"Started handling changes for lease {context.LeaseToken}...");
    Console.WriteLine($"Change Feed request consumed {context.Headers.RequestCharge} RU.");
    // SessionToken if needed to enforce Session consistency on another client instance
    Console.WriteLine($"SessionToken ${context.Headers.Session}");

    // We may want to track any operation's Diagnostics that took longer than some threshold
    if (context.Diagnostics.GetClientElapsedTime() > TimeSpan.FromSeconds(1))
    {
        Console.WriteLine($"Change Feed request took longer than expected. Diagnostics:" + context.Diagnostics.ToString());
    }

    foreach (ToDoItem item in changes)
    {
        Console.WriteLine($"Detected operation for item with id {item.id}, created at {item.creationTime}.");
        // Simulate some asynchronous operation
        await Task.Delay(10);
    }

    Console.WriteLine("Finished handling changes.");
}

Myöhemmin määrität tietojenkäsittelyesiintymän nimen tai yksilöivän tunnuksen WithInstanceNameavulla. Tämän tulee olla yksilöllinen ja erilainen jokaisessa käsiteltävässä käsittelyesiintymässä. Lisäksi se on säilö, joka ylläpitää vuokravaltiota WithLeaseContainer.

Kun Build kutsutaan, saat sen käsittelyesiintymän, jonka voit aloittaa kutsumalla StartAsync.

Isäntäesiintymän normaali elinkaari on seuraava:

  1. Lue muutossyöte.
  2. Jos muutoksia ei tehdä, nuku ennalta määritetyn ajan (mukautettava niin, että WithPollIntervalBuilder) ja siirry kohtaan #1.
  3. Jos muutoksia on tehty, lähetä ne edustajalle.
  4. Kun edustaja on käsitellyt muutokset onnistuneesti, päivitä vuokrasäilö uusimpaan käsiteltyyn kohtaan ajassa ja siirry kohtaan #1.