Megosztás a következőn keresztül:

Változási adatfolyam feldolgozó az Azure Cosmos DB-ben

A KÖVETKEZŐRE VONATKOZIK: NoSQL

A változáscsatorna-feldolgozó az Azure Cosmos DB .NET V3 és Java V4 SDK-k része, amely leegyszerűsíti a változáscsatorna olvasásának folyamatát, és hatékonyan osztja el az eseményfeldolgozást több felhasználó között.

A változáscsatorna-feldolgozó használatának fő előnye a hibatűrő kialakítás, amely legalább egyszer biztosítja a változáscsatorna összes eseményének kézbesítését.

Támogatott SDK-k

.NET V3 Java Node.JS Python
✓ ✓ ✕ ✕

A változáscsatorna-feldolgozó összetevői

A változáscsatorna-feldolgozó négy fő összetevővel rendelkezik:

  • A figyelt tároló: A figyelt tároló azokat az adatokat adja meg, amelyekből a változáscsatorna létre lett hozva. A monitorozott tárolóba való beszúrások és a tároló frissítései megjelennek a tároló változáscsatornájában.

  • A bérleti tároló: A bérleti tároló állapottárolóként működik, és koordinálja a változási napló feldolgozását több feldolgozó között. A bérlettároló tárolható ugyanabban a fiókban, mint a monitorozott tároló, de akár külön fiókban is.

  • A számítási példány: Egy számítási példány üzemelteti a változáscsatorna-feldolgozót a változások figyeléséhez. A platformtól függően virtuális gép (VM), Kubernetes-pod, Azure-alkalmazás szolgáltatáspéldány vagy tényleges fizikai gép is képviselheti. A számítási példány egyedi azonosítóval rendelkezik, amelyet ebben a cikkben példánynévnek nevezünk.

  • A meghatalmazott: A meghatalmazott az a kód, amely meghatározza, hogy Ön, a fejlesztő mit szeretne elvégezni a változáscsatorna-feldolgozó által beolvasott módosítások minden egyes kötegével.

A változáscsatorna-feldolgozó ezen négy elemének együttműködésének további megértéséhez lássunk egy példát az alábbi ábrán. A figyelt tároló tárolja az elemeket, és a "Város" partíciós kulcsot használja. A partíciókulcs értékei elemeket tartalmazó tartományokban vannak elosztva (minden tartomány egy fizikai partíciót jelöl).

Az ábrán két számítási példány látható, a változáscsatorna feldolgozója pedig különböző tartományokat rendel minden példányhoz a számítási eloszlás maximalizálása érdekében. Minden példánynak más, egyedi neve van.

Az egyes tartományok párhuzamosan lesznek beolvasva. A tartomány előrehaladása a bérlettároló többi tartományától elkülönítve, egy bérletdokumentumon keresztül tartható fenn. A bérletek kombinációja a változáscsatorna-feldolgozó aktuális állapotát tükrözi.

Diagram, amely bemutat egy példát a változáscsatorna-feldolgozóra.

A változáscsatorna-feldolgozó implementálása

A .NET változáscsatorna-feldolgozója a legújabb verziómódhoz, valamint az összes verzióhoz és törlési módhoz érhető el. Az összes verzió és törlés mód előzetes módban elérhető, és a verziótól 3.40.0-preview.0 kezdve támogatott a változáscsatorna-feldolgozó. Mindkét mód belépési pontja mindig a figyelt tároló.

A legújabb verziómóddal való olvasáshoz egy Container példányban a következőt kell meghívnia 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;
}

Az összes verzió és törlési mód használatával történő olvasáshoz hívja meg GetChangeFeedProcessorBuilderWithAllVersionsAndDeletes a Container példányt:

Container leaseContainer = client.GetContainer(Program.databaseName, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(Program.databaseName, containerName);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilderWithAllVersionsAndDeletes<ToDoItem>(processorName: "changeFeedBasic", onChangesDelegate: Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .Build();

Mindkét mód esetében az első paraméter egy külön név, amely leírja a processzor célját. A második név a módosításokat kezelő delegált implementáció.

Íme egy példa egy delegáltra a legújabb verziómódhoz:

/// <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.");
}

Íme egy példa egy meghatalmazottra az összes verzióhoz és törlési módhoz:

static async Task HandleChangesAsync(ChangeFeedProcessorContext context, IReadOnlyCollection<ChangeFeedItem<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 (ChangeFeedItem<ToDoItem> item in changes)
    {
        if (item.Metadata.OperationType == ChangeFeedOperationType.Delete)
        {
            Console.WriteLine($"\tDetected {item.Metadata.OperationType} operation for item.");
        }
        else
        {
            Console.WriteLine($"\tDetected {item.Metadata.OperationType} operation for item with id {item.Current.id}.");
        }
        // Simulate work
        await Task.Delay(1);
    }
}

Ezt követően a számítási példány nevét vagy az egyedi azonosítót a(z) WithInstanceName segítségével határozhatja meg. A számítási példány nevének egyedinek és eltérőnek kell lennie az egyes üzembe helyezett számítási példányok esetében. A tárolót a WithLeaseContainer használatával állíthatja be, hogy fenntartsa a bérlet állapotát.

A Build hívása biztosítja a processzorpéldányt, amelyet a StartAsync hívásával indíthat el.

Fontos

Egyaránt az adatfolyam és a CosmosClient bérlet tárolóinak létrehozásakor, valamint egy új változásfolyam-feldolgozó számítási feladat inicializálásakor:

Globális végpont használata

  • Mindig adjon meg globális végpontot (például contoso.documents.azure.com) regionális végpont helyett (például contoso-westus.documents.azure.com).

Régiók váltása az ApplicationRegion vagy az ApplicationPreferredRegions használatával

  • Annak érdekében, hogy a forgalmat a régiók közötti módosítás érdekében a hírcsatornában átirányítsa, használja a ApplicationRegion vagy a ApplicationPreferredRegions tulajdonságot.
  • A Change Feed Processor bérletdokumentumokat hoz létre, amelyek hatókörét a konfigurált végpont határozza meg, ezért a végpontok módosítása új, független bérletdokumentumok létrehozását eredményezi.

✅ Tegye ezt meg – Globális végpont használata az ApplicationRegion használatával:

CosmosClient client = new CosmosClient(
    "https://contoso.documents.azure.com:443/",  // Global endpoint
    "<account-key>",
    new CosmosClientOptions()
    {
        ApplicationRegion = Regions.WestUS2  // Specify region here
    });

Container monitoredContainer = client.GetContainer("myDatabase", "myContainer");
Container leaseContainer = client.GetContainer("myDatabase", "leases");

✅ Tegye ezt meg – Globális végpont használata az ApplicationPreferredRegions használatával:

CosmosClient client = new CosmosClient(
    "https://contoso.documents.azure.com:443/",  // Global endpoint
    "<account-key>",
    new CosmosClientOptions()
    {
        ApplicationPreferredRegions = new List<string> { Regions.WestUS2, Regions.EastUS2 }
    });

Container monitoredContainer = client.GetContainer("myDatabase", "myContainer");
Container leaseContainer = client.GetContainer("myDatabase", "leases");

❌ Ne tegye ezt – Kerülje a regionális végpontokat:

// DON'T: Using regional endpoint will create region-scoped lease documents
CosmosClient client = new CosmosClient(
    "https://contoso-westus.documents.azure.com:443/",  // Regional endpoint - AVOID
    "<account-key>");

Fontos

Kerülje az aszinkron feldolgozást a delegálási metódusokban: Ha aszinkron API-kat használ a handleChanges() delegált metóduson belül, vegye figyelembe, hogy a változási naplót feldolgozó rendszer az összes aszinkron művelet befejezése előtt ellenőrizheti az engedélyt. Ez kihagyott eseményekhez vezethet, ha az alkalmazás problémákat tapasztal a helyreállítás során. A meghatalmazott visszatérésének engedélyezése előtt fontolja meg a szinkron feldolgozás használatát vagy a megfelelő befejezési nyomon követés implementálását.

Feljegyzés

Az előző kódrészletek a GitHubon található mintákból származnak. A legújabb verziómódhoz, illetve az összes verzióhoz és törlési módhoz is beszerezheti a mintát.

Feldolgozási életciklus

A gazdacélállomás normális életciklusa:

  1. A változáscsatorna olvasása.
  2. Ha nincsenek változások, aludjon egy előre meghatározott ideig (a Builder használatával WithPollInterval testreszabható), és lépjen az 1. lépésre.
  3. Ha vannak módosítások, küldje el őket a meghatalmazottnak.
  4. Amikor a meghatalmazott sikeresen befejezi a módosítások feldolgozását, frissítse a bérlettárolót a legújabb feldolgozott időponttal, és lépjen az 1. lépésre.

Hibakezelés

A változáscsatorna feldolgozója rugalmas a felhasználói kódhibákkal szemben. Ha a delegált implementáció nem kezelt kivételt (4. lépés) tapasztal, az adott módosítási köteget feldolgozó szál leáll, és végül létrejön egy új szál. Az új szál ellenőrzi a legújabb időpontot, amikor a bérlettároló az adott partíciókulcs-értéktartományhoz mentett. Az új szál onnan újraindul, ezzel hatékonyan ugyanazokat a módosításokat küldi el a képviselőnek. Ez a viselkedés mindaddig folytatódik, amíg a meghatalmazott megfelelően nem dolgozza fel a módosításokat, és ez az oka annak, hogy a változáskövető feldolgozó "legalább egyszer" garanciát biztosít.

Feljegyzés

Egyetlen esetben a rendszer nem próbálkozik újra a módosítások kötegével. Ha a hiba az első alkalommal delegált végrehajtáskor következik be, a bérlettároló nem rendelkezik korábbi mentett állapotmal az újrapróbálkozási művelethez. Ezekben az esetekben az újrapróbálkozás a kezdeti indítási konfigurációt használja, amely lehet, hogy nem tartalmazza az utolsó köteget.

Ha meg szeretné akadályozni, hogy a változáscsatorna feldolgozója folyamatosan megakadjon ugyanazon módosítási köteg újrapróbálkozásakor, a delegált kódban logikát kell hozzáadnia, hogy kivétel nélkül dokumentumokat írjon egy hibás üzenetsorba. Ez a kialakítás biztosítja, hogy nyomon tudja követni a feldolgozatlan módosításokat, miközben továbbra is feldolgozhatja a jövőbeli módosításokat. A hibaüzenetek üzenetsora lehet egy másik Azure Cosmos DB-tároló. A pontos adattár nem számít. Egyszerűen csak azt szeretné, hogy a feldolgozatlan módosítások megmaradjanak.

A változáscsatorna-becslést is használhatja a változáscsatorna-feldolgozó példányok előrehaladásának figyelésére a változáscsatorna olvasása közben, vagy életciklus-értesítések használatával észlelheti az alapul szolgáló hibákat.

Győződjön meg arról, hogy az ügyfél hálózati kéréseinek időtúllépése hosszabb a kiszolgálóoldali időtúllépésnél, hogy megakadályozza az időtúllépési eltéréseket, amelyek feldolgozási leállásokhoz vezethetnek. Az alapértelmezett kiszolgálóoldali időtúllépés 5 másodperc. Figyelje az időtúllépéssel kapcsolatos hibákat, és ennek megfelelően módosítsa a konfigurációkat.

Életciklus-értesítések

A változáscsatorna-feldolgozót az életciklusa bármely releváns eseményéhez csatlakoztathatja. Dönthet úgy, hogy értesítést kap egy vagy mindegyikről. A javaslat az, hogy legalább regisztrálja a hibaértesítést:

  • Regisztráljon egy kezelőt a WithLeaseAcquireNotification, hogy értesítést kapjon, amikor az aktuális kiszolgáló bérletet szerez a feldolgozás megkezdéséhez.
  • Regisztráljon egy kezelőt WithLeaseReleaseNotification számára, hogy értesítést kapjon, amikor az aktuális gazdagép felszabadít egy bérletet, és leállítja annak feldolgozását.
  • Regisztráljon egy kezelőt a WithErrorNotification számára, hogy értesítést kapjon, amikor az aktuális gazdagép feldolgozás közben kivételt tapasztal. Meg kell tudnia különböztetni, hogy a forrás a felhasználó delegáltja (nem kezelt kivétel), vagy olyan hiba, amelyet a processzor a figyelt tároló elérésekor tapasztal (például hálózati problémák).

Az életciklus-értesítések mindkét változáscsatorna-módban elérhetők. Íme egy példa az életciklus-értesítésekre a legújabb verzió módban:

Container.ChangeFeedMonitorLeaseAcquireDelegate onLeaseAcquiredAsync = (string leaseToken) =>
{
    Console.WriteLine($"Lease {leaseToken} is acquired and will start processing");
    return Task.CompletedTask;
};

Container.ChangeFeedMonitorLeaseReleaseDelegate onLeaseReleaseAsync = (string leaseToken) =>
{
    Console.WriteLine($"Lease {leaseToken} is released and processing is stopped");
    return Task.CompletedTask;
};

Container.ChangeFeedMonitorErrorDelegate onErrorAsync = (string LeaseToken, Exception exception) =>
{
    if (exception is ChangeFeedProcessorUserException userException)
    {
        Console.WriteLine($"Lease {LeaseToken} processing failed with unhandled exception from user delegate {userException.InnerException}");
    }
    else
    {
        Console.WriteLine($"Lease {LeaseToken} failed with {exception}");
    }

    return Task.CompletedTask;
};

ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedNotifications", handleChanges)
        .WithLeaseAcquireNotification(onLeaseAcquiredAsync)
        .WithLeaseReleaseNotification(onLeaseReleaseAsync)
        .WithErrorNotification(onErrorAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .Build();

Üzembehelyezési egység

Egyetlen változáscsatorna-feldolgozó üzembehelyezési egység egy vagy több számítási példányból áll, amelyek azonos processorName értékkel és bérleménytároló-konfigurációval rendelkeznek, de különböző példányneveik vannak. Számos olyan üzembehelyezési egység lehet, amelyben minden egység eltérő üzleti folyamatokkal rendelkezik a módosításokhoz, és minden üzembe helyezési egység egy vagy több példányból áll.

Előfordulhat például, hogy egy központi telepítési egység minden alkalommal elindít egy külső API-t, amikor változás történt a tárolóban. Egy másik üzembehelyezési egység valós időben helyezheti át az adatokat minden alkalommal, amikor változás történt. Ha változás történik a figyelt tárolóban, az összes üzembehelyezési egység értesítést kap.

Dinamikus méretezés

Ahogy korábban említettük, az üzembe helyezési egységen belül egy vagy több számítási példány is lehet. Az üzembehelyezési egységen belüli számítási eloszlás előnyeinek kihasználásához az egyetlen fő követelmény a következők:

  • Minden példánynak ugyanazzal a lease container konfigurációval kell rendelkeznie.
  • Minden példánynak ugyanazt az értéket kell adni processorName-hoz.
  • Minden példánynak különböző példánynévvel kell rendelkeznie (WithInstanceName).

Ha ez a három feltétel érvényes, akkor a változáscsatorna-feldolgozó elosztja a bérlettárolóban lévő összes bérletet az üzembehelyezési egység összes futó példánya között, és egy egyenlőségelosztó algoritmus használatával párhuzamosítja a számítást. A bérlemények egy időben mindig egy példány tulajdonában vannak, így a példányok száma nem lehet nagyobb, mint a bérlemények száma.

A példányok száma nőhet és csökkenhet. A változáscsatorna-feldolgozó dinamikusan módosítja a terhelést annak megfelelő újraelosztással.

Emellett a változáscsatorna-feldolgozó dinamikusan módosíthatja a tárolók skáláját, ha a tároló átviteli sebessége vagy tárhelye nő. Amikor a tároló mérete növekszik, a változáskezelő folyamatosan és átlátható módon kezeli a helyzetet azzal, hogy dinamikusan növeli a bérletek számát, és szétosztja az újakat a meglévő példányok között.

Kezdési időpont

Alapértelmezés szerint, amikor egy változási folyamat feldolgozó első alkalommal indul el, inicializálja a bérleti tárolót, és elindítja annak feldolgozási életciklusát. A rendszer nem észlel minden olyan módosítást, amely a figyelt tárolóban történt a változáscsatorna-feldolgozó első inicializálása előtt.

Olvasás egy korábbi dátumból és időpontból

A változáscsatorna-feldolgozó inicializálható a egy adott dátumtól és időponttól kezdődő módosítások olvasásához, ha átad egy példányt a DateTime építő bővítménynek WithStartTime.

Container leaseContainer = client.GetContainer(databaseId, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(databaseId, Program.monitoredContainer);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedTime", Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .WithStartTime(particularPointInTime)
        .Build();

A változáscsatorna-feldolgozó az adott dátum és időpont alapján van inicializálva, majd kezdi olvasni az ezt követő módosításokat.

Olvasás az elejétől

Más esetekben, például adatmigráláskor vagy egy tároló teljes előzményeinek elemzésekor a tároló élettartamának kezdettől a változáscsatornát be kell olvasnia. Használhatja az WithStartTime építő bővítményt, de átadja a DateTime.MinValue.ToUniversalTime()-t, amely a legalacsonyabb DateTime érték UTC-ábrázolását állítja elő, mint ebben a példában:

Container leaseContainer = client.GetContainer(databaseId, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(databaseId, Program.monitoredContainer);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedBeginning", Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .WithStartTime(DateTime.MinValue.ToUniversalTime())
        .Build();

A változáscsatorna-feldolgozó inicializálva van, és a tároló élettartamának kezdetétől kezdi olvasni a módosításokat.

Feljegyzés

Ezek a testreszabási lehetőségek csak arra szolgálnak, hogy beállítsák a változáscsatorna-feldolgozó indulási időpontját. A bérlettároló első inicializálása után ezeknek a beállításoknak a módosítása nincs hatással.

A kezdőpont testreszabása csak a legújabb verziómódosítási módhoz érhető el. Ha az összes verziót és törlési módot használja, a processzor indításától kezdve kell elkezdeni az olvasást, vagy a fiók folyamatos biztonsági mentési megőrzési időszakán belüli korábbi bérletállapotból kell folytatnia az olvasást.

A hírcsatorna és a kiosztott átviteli sebesség módosítása

A figyelt tároló adatcsatorna-olvasási műveleteinek módosítása kérelemegységeket használ fel. Győződjön meg arról, hogy a figyelt tároló nem tapasztal teljesítménykorlátozást. A szabályozó késlelteti a változáscsatorna-események fogadását a processzorokon.

A bérlettároló műveletei (az állapot frissítése és karbantartása) kérelemegységeket használnak. Minél több példány használja ugyanazt a bérleti tárolót, annál nagyobb a kérelemegységek potenciális felhasználása. Győződjön meg arról, hogy a bérletkiszolgáló nem tapasztal korlátozást. A limitálás késlelteti a változási adatfolyam eseményeinek fogadását. A korlátozás akár teljesen le is állíthatja a feldolgozást.

A bérlettároló megosztása

Egy bérlettárolót több üzembehelyezési egység között megoszthatja. Megosztott bérlettartályban minden üzembehelyezési egység figyel egy másik figyelt tárolót, vagy más érték van beállítva processorName számára. Ebben a konfigurációban minden üzembe helyezési egység egy független állapotot tart fenn a bérlettárolón. Tekintse át a kérelemegység-felhasználást egy bérlettárolón , és győződjön meg arról, hogy a kiosztott átviteli sebesség elegendő az összes üzembe helyezési egységhez.

Előrehaladott bérleti szerződés konfiguráció

Három kulcskonfiguráció befolyásolhatja a változáscsatorna processzor működését. Minden konfiguráció hatással van a bérlettároló kérelemegység-felhasználására. A változáscsatorna-feldolgozó létrehozásakor az alábbi konfigurációk egyikét állíthatja be, de gondosan használja őket:

  • Bérlet beszerzése: Alapértelmezés szerint 17 másodpercenként. A hoszt rendszeresen ellenőrzi a bérlettároló állapotát, és fontolóra veszi a bérlemények megszerzését a dinamikus skálázási folyamat keretében. Ez a folyamat úgy történik, hogy egy lekérdezést hajt végre a bérlettartályon. Ennek az értéknek a csökkentése felgyorsítja a bérletek újraelosztását és beszerzését, de növeli a kérelemegység-felhasználást a bérlettárolón.
  • Bérlet lejárata: Alapértelmezés szerint 60 másodperc. Meghatározza a maximális időtartamot, amely alatt egy bérlet megújítási tevékenység nélkül létezhet, mielőtt azt egy másik gazdagép átveszi. Amikor egy gazdagép összeomlik, a tulajdonában lévő bérleteket más gazdagépek átvállalják a megadott időtartam után plusz a konfigurált megújítási időköz elteltével. Ennek az értéknek a csökkentése gyorsabb helyreállítást tesz lehetővé a gazdagép összeomlása után, de a lejárati érték soha nem lehet alacsonyabb a megújítási időköznél.
  • Bérlet megújítása: Alapértelmezés szerint 13 másodpercenként. A bérletet birtoklő gazdagép rendszeresen megújítja a bérletet, még akkor is, ha nincsenek új használatban lévő módosítások. A folyamat a bérlet "Replace" parancsának végrehajtásával történik. Ennek az értéknek a csökkentése csökkenti a gazdagép összeomlása által elveszett bérletek észleléséhez szükséges időt, de növeli a kérelemegység-felhasználást a bérlettárolón.

Hol történjen a változáscsatorna feldolgozójának üzemeltetése

A változáscsatorna-feldolgozó bármely olyan platformon üzemeltethető, amely támogatja a hosszú ideig futó folyamatokat vagy feladatokat. Íme néhány példa:

  • Folyamat az Azure Virtual Machines egy példányában
  • Háttérfeladat az Azure Kubernetes Service-ben
  • Kiszolgáló nélküli függvény az Azure Functionsben
  • Egy ASP.NET üzemeltetett szolgáltatás

Bár a változáscsatorna-feldolgozó képes rövid életű környezetekben is működni, mivel a lease konténer fenntartja az állapotot, az ilyen környezetek indítási ciklusa késlelteti az értesítések fogadását, a processzor minden újraindításkor adódó többletterhelés miatt.

Szerepköralapú hozzáférési követelmények

Ha a Microsoft Entra ID-t hitelesítési mechanizmusként használja, győződjön meg arról, hogy az identitás rendelkezik a megfelelő engedélyekkel:

  • A figyelt tárolón:
    • Microsoft.DocumentDB/databaseAccounts/readMetadata
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/readChangeFeed
  • A bérlettárolón:
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/read
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/create
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/delete
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/executeQuery

További erőforrások

Következő lépések

További információ a változáscsatorna-feldolgozóról az alábbi cikkekben:

  • Last updated on