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

Eseményreplikációs feladatok mintái

  • Cikk

Az összevonási áttekintés és a replikátorfüggvények áttekintése ismerteti a replikációs feladatok indokait és alapvető elemeit, ezért a cikk folytatása előtt érdemes megismerkednie velük.

Ebben a cikkben részletesen bemutatjuk az áttekintés szakaszban kiemelt minták implementálási útmutatóját.

Replikáció

A replikációs minta eseményeket másol egyik eseményközpontból a másikba, vagy egy eseményközpontból egy másik helyre, például egy Service Bus-üzenetsorba. Az eseményeket a rendszer anélkül továbbítja, hogy módosításokat végezne az esemény hasznos adatain.

Ennek a mintának a megvalósítását az Event Hubs és a Service Bus-minták közötti eseményreplikáció és eseményreplikáció, valamint az Apache Kafka MirrorMaker használata az Event Hubs-oktatóanyaggal az Apache Kafka-közvetítő adatainak az Event Hubsba való replikálásának konkrét esete fedi le.

adatfolyamok és a rend megőrzése

Az Azure Functionsen vagy az Azure Stream Analyticsen keresztüli replikáció nem célja, hogy biztosítsa a forrás eseményközpont pontos 1:1 klónjainak létrehozását egy céleseményközpontba, hanem az alkalmazás által igényelt események relatív sorrendjének megőrzésére összpontosít. Az alkalmazás ezt úgy kommunikálja, hogy a kapcsolódó eseményeket ugyanarra a partíciókulcsra csoportosítja, és az Event Hubs ugyanabban a partícióban egymás után rendezi az azonos partíciókulcsú üzeneteket.

Fontos

Az "eltolás" információ minden eseményközpont esetében egyedi, és az azonos események eltolásai az Event Hub-példányok között eltérőek lesznek. A másolt eseménystreamek helyének megkereséséhez használjon időalapú eltolásokat, és tekintse meg a propagált szolgáltatás által hozzárendelt metaadatokat.

Az időalapú eltolások egy adott időpontban indítják el a fogadót:

  • EventPosition.FromStart() – Olvassa újra az összes megtartott adatot.
  • EventPosition.FromEnd() – Az összes új adat beolvasása a kapcsolat időpontjából.
  • EventPosition.FromEnqueuedTime(dateTime) – Minden adat egy adott dátumtól és időponttól kezdve.

Az EventProcessorban a pozíciót az EventProcessorOptions InitialOffsetProviderén keresztül állíthatja be. A többi fogadó API-kkal a helyzet áthalad a konstruktoron.

Az Azure Functions-alapú útmutatóban használt mintákként megadott előre összeállított replikációs függvény-segítők biztosítják, hogy a forráspartícióból lekért azonos partíciókulcsú eseménystreamek az eredeti streamben kötegként és ugyanazzal a partíciókulcsmal legyenek elküldve a cél eseményközpontba.

Ha a forrás és a cél eseményközpont partíciószáma azonos, a célban lévő összes stream ugyanarra a partícióra lesz megfeleltetve, mint a forrásban. Ha a partíciók száma eltérő, ami az alábbiakban ismertetett további minták némelyikében számít, a leképezés eltérő lesz, de a streamek mindig együtt és sorrendben maradnak.

A különböző streamekhez vagy független eseményekhez tartozó események relatív sorrendje a célpartíció partíciókulcsa nélkül mindig eltérhet a forráspartíciótól.

Szolgáltatáshoz rendelt metaadatok

A forrás Eseményközpontból beszerzett esemény szolgáltatás által hozzárendelt metaadatait, az eredeti lekérési időt, a sorszámot és az eltolást a cél eseményközpont új, szolgáltatáshoz rendelt értékei váltják fel, de a segédfüggvényekkel, a mintáinkban megadott replikációs feladatokkal az eredeti értékek megmaradnak a felhasználói tulajdonságokban: repl-enqueue-time (ISO8601 sztring), repl-sequence, repl-offset.

Ezek a tulajdonságok típussztringek, és tartalmazzák a megfelelő eredeti tulajdonságok sztringezett értékét. Ha az eseményt többször továbbítja a rendszer, a rendszer hozzáfűzi az azonnali forrás szolgáltatás által hozzárendelt metaadatait a már meglévő tulajdonságokhoz, pontosvesszővel elválasztott értékekkel.

Feladatátvétel

Ha replikációt használ vészhelyreállítási célokra, az Event Hubs szolgáltatásban a regionális rendelkezésre állási események elleni védelemhez vagy a hálózat megszakadása ellen, az ilyen meghibásodási forgatókönyvekhez feladatátvételre lesz szükség az egyik Eseményközpontból a következőre, és meg kell kérni a gyártókat és/vagy a fogyasztókat a másodlagos végpont használatára.

Minden feladatátvételi forgatókönyv esetében feltételezzük, hogy a névterek szükséges elemei szerkezetileg azonosak, ami azt jelenti, hogy az Event Hubs és a fogyasztói csoportok neve azonos, és a közös hozzáférés-aláírási szabályok és/vagy szerepköralapú hozzáférés-vezérlési szabályok ugyanúgy vannak beállítva. Létrehozhat (és frissíthet) egy másodlagos névteret a névterek áthelyezésével és a törlési lépés kihagyásával kapcsolatos útmutatást követve.

Ahhoz, hogy a gyártókat és a fogyasztókat váltásra kényszerítse, meg kell adnia az információkat arról, hogy melyik névteret kell használnia a kereséshez egy könnyen elérhető és frissíthető helyen. Ha a gyártók vagy a fogyasztók gyakori vagy állandó hibákba ütköznek, konzultálniuk kell ezen a helyen, és módosítaniuk kell a konfigurációjukat. Ezt a konfigurációt többféleképpen is megoszthatja, de az alábbiakban két elemet mutatunk be: DNS- és fájlmegosztásokat.

DNS-alapú feladatátvételi konfiguráció

Az egyik jelölt megközelítés az, hogy egy ön által vezérelt DNS-ben tárolja a DNS SRV-rekordjainak adatait, és a megfelelő Event Hub-végpontokra mutat.

Fontos

Ne feledje, hogy az Event Hubs nem teszi lehetővé, hogy a végpontok közvetlenül CNAME rekordokkal aliasosodjanak, ami azt jelenti, hogy a DNS-t rugalmas keresési mechanizmusként fogja használni a végpontcímekhez, és nem fogja közvetlenül feloldani az IP-címadatokat.

Tegyük fel, hogy Ön a tartomány example.com tulajdonosa, és az alkalmazás számára egy zóna test.example.com. Két alternatív Event Hub esetében most két további beágyazott zónát és egy SRV rekordot fog létrehozni mindegyikben.

Az SRV-rekordok a gyakori konvenciók szerint két végpontrekorddal vannak előtaggal _azure_eventhubs._amqp elnevezve és tárolva: egyet az AMQP-over-TLS-hez az 5671-es porton, egyet pedig a 443-as porton lévő AMQP-over-WebSocketshez, mindkettő a zónának megfelelő névtér Event Hubs-végpontjára mutat.

Zóna SRV rekord
eh1.test.example.com _azure_servicebus._amqp.eh1.test.example.com
1 1 5671 eh1-test-example-com.servicebus.windows.net
2 2 443 eh1-test-example-com.servicebus.windows.net
eh2.test.example.com _azure_servicebus._amqp.eh2.test.example.com
1 1 5671 eh2-test-example-com.servicebus.windows.net
2 2 443 eh2-test-example-com.servicebus.windows.net

Az alkalmazás zónájában ezután létre fog hozni egy CNAME bejegyzést, amely az elsődleges eseményközpontnak megfelelő alárendelt zónára mutat:

CNAME-rekord Alias
eventhub.test.example.com eh1.test.example.com

Ha olyan DNS-ügyfelet használ, amely lehetővé teszi a CNAME- és SRV-rekordok explicit lekérdezését (a Java és a .NET beépített ügyfelei csak a nevek egyszerű feloldását teszik lehetővé AZ IP-címekre), akkor feloldhatja a kívánt végpontot. A DnsClient.NET esetében például a keresési függvény a következő:

static string GetEventHubName(string aliasName)
{
    const string SrvRecordPrefix = "_azure_eventhub._amqp.";
    LookupClient lookup = new LookupClient();

    return (from CNameRecord alias in (lookup.Query(aliasName, QueryType.CNAME).Answers)
            from SrvRecord srv in lookup.Query(SrvRecordPrefix + alias.CanonicalName, QueryType.SRV).Answers
            where srv.Port == 5671
            select srv.Target).FirstOrDefault()?.Value.TrimEnd('.');
}

A függvény a zóna 5671-as portjához regisztrált cél gazdagépnevet adja vissza, amely jelenleg a CNAME-val van aliasban, a fent látható módon.

A feladatátvétel végrehajtásához szerkeszteni kell a CNAME rekordot, és a másik zónára kell mutatni.

A DNS és különösen az Azure DNS használatának előnye, hogy az Azure DNS-információk globálisan replikálódnak, és így rugalmasak az egyrégiós kimaradásokkal szemben.

Ez az eljárás hasonló az Event Hubs Geo-DR működéséhez, de teljes mértékben saját felügyelete alatt áll, és aktív/aktív forgatókönyvekkel is működik.

Fájlmegosztás-alapú feladatátvételi konfiguráció

A legegyszerűbb alternatíva a DNS használata a végpontadatok megosztásához, ha az elsődleges végpont nevét egy egyszerű szöveges fájlba helyezi, és egy olyan infrastruktúrából szolgáltatja a fájlt, amely robusztus a kimaradásokkal szemben, és továbbra is lehetővé teszi a frissítéseket.

Ha már futtat egy magas rendelkezésre állású webhelyinfrastruktúrát globális rendelkezésre állással és tartalomreplikációs szolgáltatással, adjon hozzá egy ilyen fájlt, és szükség esetén tegye közzé újra a fájlt.

Figyelemfelhívás

A végpont nevét csak így teheti közzé, a titkos kulcsokat tartalmazó teljes kapcsolati sztring nem.

További szempontok a fogyasztók feladatátvétele esetén

Az Event Hub felhasználói számára a feladatátvételi stratégia további szempontjai az eseményfeldolgozó igényeitől függnek.

Ha olyan katasztrófa történik, amely szükségessé teszi egy rendszer , köztük az adatbázisok újraépítését a biztonsági mentési adatokból, és az adatbázisokat közvetlenül vagy köztes feldolgozással eteti az Eseményközpontban tárolt eseményekből, akkor visszaállítja a biztonsági mentést, majd meg szeretné kezdeni az események újratelepítését a rendszerbe attól a pillanattól kezdve, amikor az adatbázis biztonsági mentését létrehozták, és nem attól a pillanattól kezdve, amikor az eredeti rendszer megsemmisült.

Ha egy hiba csak a rendszer egy szeletét érinti, vagy csak egyetlen eseményközpontot, amely elérhetetlenné vált, valószínűleg körülbelül ugyanabból a helyről szeretné folytatni az események feldolgozását, ahol a feldolgozás megszakadt.

A forgatókönyvek megvalósításához és a megfelelő Azure SDK eseményfeldolgozójának használatához létre fog hozni egy új ellenőrzőpont-tárolót, és megadja a kezdeti partíciópozíciót a feldolgozás folytatásához használt időbélyeg alapján.

Ha továbbra is rendelkezik hozzáféréssel az átkapcsolt Eseményközpont ellenőrzőpont-tárához, a fent ismertetett propagált metaadatok segítségével kihagyhatja a már kezelt eseményeket, és pontosan onnan folytathatja azokat, ahol legutóbb abbahagyta.

Összefűzés

Az egyesítési minta egy vagy több replikációs feladattal rendelkezik, amely egy célra mutat, esetleg egyidejűleg a rendszeres gyártók is ugyanahhoz a célhoz küldik az eseményeket.

Ezeknek a pattereknek a változatai a következők:

  • Két vagy több replikációs függvény egyidejűleg különböző forrásokból szerzi be az eseményeket, és ugyanahhoz a célhoz küldi őket.
  • Még egy replikációs függvény, amely eseményeket szerez be egy forrásból, miközben a célértéket közvetlenül a gyártók is használják.
  • Az előző minta, de két vagy több Event Hub között tükrözve, így az eseményközpontok ugyanazokat a streameket tartalmazzák, függetlenül attól, hogy hol jönnek létre események.

Az első két mintaváltozat triviális, és nem különbözik az egyszerű replikációs feladatoktól.

Az utolsó forgatókönyvben a már replikált események ismételt replikálásának kizárása szükséges. A technikát az EventHubToEventHubMerge mintában mutatjuk be és mutatjuk be.

Szerkesztő

A szerkesztőminta a replikációs mintára épül, de az üzenetek továbbításuk előtt módosulnak.

Ilyen módosítások például a következők:

  • Átkódolás – Ha az esemény tartalma (más néven "törzs" vagy "hasznos adat") az Apache Avro formátummal vagy valamilyen védett szerializálási formátummal kódolt forrásból érkezik, de a célrendszer elvárása, hogy a tartalom JSON-kódolású legyen, a transzkódolási replikációs feladat először deszerializálja az Apache Avro hasznos adatait egy memórián belüli objektumgráfba, majd szerializálja a gráfot a JSON-ba formátumot a továbbított eseményhez. A transzkódolás tartalomtömörítési és dekompressziós feladatokat is tartalmaz.
  • Átalakítás – A strukturált adatokat tartalmazó események szükségessé tehetik az adatok átalakítását az alsóbb rétegbeli felhasználók általi könnyebb felhasználás érdekében. Ez magában foglalhatja a beágyazott struktúrák simítását, a felesleges adatelemek metszését, vagy a hasznos adatoknak az adott sémához való igazítását.
  • Kötegelés – Az események kötegekben (több esemény egyetlen átvitelben) fogadhatók egy forrásból, de egyenként kell továbbítani egy célnak, vagy fordítva. A tevékenységek ezért több eseményt is továbbíthatnak egyetlen bemeneti eseményátvitel alapján, vagy összesíthetik azokat az eseményeket, amelyeket aztán együtt adnak át.
  • Ellenőrzés – A külső forrásokból származó eseményadatokat gyakran ellenőrizni kell, hogy azok megfelelnek-e egy szabálykészletnek, mielőtt továbbítanák őket. A szabályok sémák vagy kódok használatával fejezhetők ki. Előfordulhat, hogy a nem megfelelő eseményeket a naplókban feljegyzett problémával együtt elvetik, vagy egy speciális célhelyre továbbítják, hogy tovább kezeljék őket.
  • Bővítés – Egyes forrásokból származó eseményadatok további környezettel bővíthetők ahhoz, hogy felhasználhatók legyenek a célrendszerekben. Ez magában foglalhatja a referenciaadatok megtekintését és az adatok eseménybe való beágyazását, vagy a replikációs feladat által ismert, de az eseményekben nem szereplő forrás információinak hozzáadását.
  • Szűrés – Előfordulhat, hogy a forrásból érkező egyes eseményeket valamilyen szabály alapján el kell zárni a céltól. Egy szűrő ellenőrzi az eseményt egy szabályon, és elveti az eseményt, ha az esemény nem felel meg a szabálynak. Az ismétlődő események kiszűrése bizonyos feltételek megfigyelésével és az azonos értékekkel rendelkező későbbi események elvetésével a szűrés egyik formája.
  • Titkosítás – Előfordulhat, hogy egy replikációs feladatnak vissza kell fejtenie a forrásból érkező tartalmakat, és/vagy titkosítania kell a célnak továbbított tartalmat, és/vagy ellenőriznie kell a tartalom és a metaadatok integritását az esemény során szállított aláíráshoz képest, vagy csatolnia kell egy ilyen aláírást.
  • Igazolás – A replikációs feladat a potenciálisan digitális aláírással védett metaadatokat csatolhatja egy olyan eseményhez, amely igazolja, hogy az esemény egy adott csatornán keresztül vagy adott időpontban érkezett.
  • Láncolás – A replikációs feladat aláírásokat alkalmazhat az események streamjeire, így a stream integritása védett, és a hiányzó események észlelhetők.

Az átalakítás, a kötegelés és a bővítési minták általában az Azure Stream Analytics-feladatok esetében a legjobban implementálódnak.

Ezek a minták az Azure Functions használatával implementálhatók az Event Hubs-eseményindítóval az események beszerzéséhez és az Event Hub kimeneti kötésének használatával.

Útválasztás

Az útválasztási minta a replikációs mintára épül, de egy forrás és egy cél helyett a replikációs feladat több célhoz is tartozik, amelyet itt a C#-ban mutatunk be:

[FunctionName("EH2EH")]
public static async Task Run(
    [EventHubTrigger("source", Connection = "EventHubConnectionAppSetting")] EventData[] events,
    [EventHub("dest1", Connection = "EventHubConnectionAppSetting")] EventHubClient output1,
    [EventHub("dest2", Connection = "EventHubConnectionAppSetting")] EventHubClient output2,
    ILogger log)
{
    foreach (EventData eventData in events)
    {
        // send to output1 and/or output2 based on criteria
        EventHubReplicationTasks.ConditionalForwardToEventHub(input, output1, log, (eventData) => {
            return ( inputEvent.SystemProperties.SequenceNumber%2==0 ) ? inputEvent : null;
        });
        EventHubReplicationTasks.ConditionalForwardToEventHub(input, output2, log, (eventData) => {
            return ( inputEvent.SystemProperties.SequenceNumber%2!=0 ) ? inputEvent : null;
        });
    }
}

Az útválasztási függvény figyelembe veszi az üzenet metaadatait és/vagy az üzenet hasznos adatait, majd kiválasztja az elérhető célhelyek egyikét.

Az Azure Stream Analyticsben ugyanezt úgy érheti el, hogy több kimenetet határoz meg, majd kimenetenként végrehajt egy lekérdezést.

select * into dest1Output from inputSource where Info = 1
select * into dest2Output from inputSource where Info = 2

Naplóvetítés

A naplóvetítési minta egy indexelt adatbázisba simítja az eseményfolyamot, és az események rekordjai lesznek az adatbázisban. Az események általában ugyanahhoz a gyűjteményhez vagy táblához vannak hozzáadva, és az Event Hub partíciókulcsa az elsődleges kulcs részévé válik, és egyedivé teszi a rekordot.

A naplóvetítés az eseményadatok idősoros történészét vagy egy tömörített nézetet hozhat létre, amellyel minden partíciókulcshoz csak a legújabb esemény marad meg. A céladatbázis alakja végső soron Önön és az alkalmazás igényein múlik. Ezt a mintát "esemény-forrásnak" is nevezik.

Tipp.

Az Azure Stream Analyticsben egyszerűen hozhat létre naplóvetítéseket az Azure SQL Database-ben és az Azure Cosmos DB-ben, és ezt a lehetőséget érdemes előnyben részesítenie.

Az alábbi Azure-függvény egy Azure Cosmos DB-gyűjteménybe tömörített Event Hub tartalmát alakítja ki.

[FunctionName("Eh1ToCosmosDb1Json")]
[ExponentialBackoffRetry(-1, "00:00:05", "00:05:00")]
public static async Task Eh1ToCosmosDb1Json(
    [EventHubTrigger("eh1", ConsumerGroup = "Eh1ToCosmosDb1", Connection = "Eh1ToCosmosDb1-source-connection")] EventData[] input,
    [CosmosDB(databaseName: "SampleDb", collectionName: "foo", ConnectionStringSetting = "CosmosDBConnection")] IAsyncCollector<object> output,
    ILogger log)
{
    foreach (var ev in input)
    {
        if (!string.IsNullOrEmpty(ev.SystemProperties.PartitionKey))
        {
            var record = new
            {
                id = ev.SystemProperties.PartitionKey,
                data = JsonDocument.Parse(ev.Body),
                properties = ev.Properties
            };
            await output.AddAsync(record);
        }
    }
}

Következő lépések