Kafka är ett högpresterande, distribuerat meddelandesystem utvecklat av LinkedIn som används i stor utsträckning i scenarier som logginsamling, strömmande databehandling, online- och offline-meddelandedistribution och mer. Även om det inte är designat som en traditionell MQ kan Kafaka i de flesta fall ersätta traditionella meddelandesystem som ActiveMQ.
Kafka organiserar flödet av meddelanden efter ämnen, och servern som håller meddelandena kallas en mäklare, och konsumenter kan prenumerera på ett eller flera ämnen. För att balansera belastningen kan meddelandena i ett ämne delas in i flera partitioner, och ju fler partitioner, desto högre parallellism och genomströmning hos Kafka.
Kafka-kluster kräver zookeeper-stöd för att implementera kluster, och zookeeper ingår redan i den senaste Kafka-distributionen, som kan distribueras för att starta en zookeeper-server och en Kafka-server samtidigt, eller använda andra befintliga zookeeper-kluster.
Till skillnad från traditionell MQ behöver konsumenter behålla en offset själva, och när de får meddelanden från kafka, hämtar de bara meddelanden efter den aktuella offseten. Kafkas scala/java-klient implementerar redan denna del av logiken genom att spara offsetet till zookeepern. Varje konsument kan välja ett ID, och konsumenter med samma ID får bara samma meddelande en gång.Om konsumenter av ett ämne alla använder samma id är det en traditionell kö. Om varje konsument använder ett eget ID är det en traditionell pub-sub.
Recension:
Kafkakonsumtion
1. Konsumenter av samma group_id, endast en konsument kan konsumera meddelanden (kö-kö-läge）
2. Konsumenter av olika group_id får samma nyheter
Fördelar med Kafka
Distribuerat och mycket skalbart. Kafka-kluster kan skalas transparent för att lägga till nya servrar i klustret.
Hög prestanda. Kafkas prestanda överträffar vida traditionella MQ-implementationer som ActiveMQ och RabbitMQ, särskilt Kafka, som också stödjer batchoperationer. Följande bild visar resultaten från LinkedIns konsumentprestandatest:
Feltolerans. Data från varje partition i Kafka replikeras till flera servrar. När en mäklare misslyckas meddelar ZooKeeper-tjänsten producenten och konsumenten, som sedan byter till en annan mäklare.
Nackdelar med Kafka:
Upprepa meddelanden. Kafka garanterar bara att varje meddelande levereras minst en gång, och även om oddsen är små finns det en chans att ett meddelande levereras flera gånger.
Nyheterna är ur ordning. Även om meddelanden inom en partition garanteras vara ordnade, är det inte garanterat att meddelandeleveransen mellan partitioner är ordnad om ett ämne har flera partitioner.
Komplexitet. Kafka kräver stöd från zookeeper-kluster, och ämnen kräver vanligtvis manuellt arbete för att skapa, distribuera och underhålla dyrare än vanliga meddelandeköer
.NET/C# meddelandekö Kafka-operationer
Först, använd .NET Core 3.1 för att skapa två nya konsolprojekt, nämligen Kafka-Consumer och Kafka-Producer
Använd nuget för att referera till Confluent.Kafka-paketet så här, med följande kommando:
GitHub-adress:Inloggningen med hyperlänken är synlig.
Vi startar Producer-programmet först, och om vi startar konsumenten först får vi följande fel:
Fel uppstod: Mäklare: Okänt ämne eller partition
Den här artikeln kommer att ta upp inställningarnaEnableAutoOffsetStore är falsk, det vill säga manuellt att ställa in offset-lagringen (liknande ett manuellt bekräftelsemeddelande)
Konsumenter ställer inte in OffsetStore efter konsumtion
Försök använda producenten för att producera två meddelanden, slå på konsumentförbrukning, MaxPollIntervalMs = 10000 // 10 sekunder utan manuell inställning, låt andra klienter konsumera, självklart kommer det inte att konsumeras av andra klienter inom 10 sekunder
MaxPollIntervalMs förklarar
För avancerade konsumenter är den maximala tillåtna tiden att konsumera meddelanden mellan samtal (till exempel rd_kafka_consumer_poll()). Om detta intervall överskrids anses konsumenten ha misslyckats och gruppen balanseras om så att partitionen tilldelas en annan medlem i konsumentgruppen. Varning: Offset-commits kan vara omöjliga just nu. Observera: Det rekommenderas att ställa in "enable.auto.offset.store=false" för applikationer som bearbetar under lång tid, och sedan uttryckligen lagra offsetet (med offsets_store()) efter att meddelandet har behandlats* för att säkerställa att offsetet inte automatiskt committeras innan bearbetningen är klar. Kontrollera en gång per sekund med två intervaller. För mer information, se KIP-62.
Renderingarna är följande:
OffsetStore är inställd efter att konsumenten har avslutat sina utgifter
kod
När installationen är klar, vänta 10 sekunder så gör den det fortfarandeMottagit det sista meddelandet(När konsumenten kopplar upp sig till mäklaren,Starta konsumtionen från offset-positionenOm c.Commit(cr) är satt; Det sista meddelandet kommer inte att tas emot upprepade gånger.
Visa källkod
commit offset + 1 commit, och anropa slutligen Librdkafka.topic_partition_list_destroy(cOffsets);
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Sätt ett annat GroupId
Prova att ställa in ett annat GroupId via kommandoradsparametern och skicka sedan ett meddelande via producenten, som visas i följande bild:
Både clinet1 och klient2Ta emot historiska meddelanden, och efter att producenten skickat ut ett meddelande, kommer båda nästan att varaTa emot meddelanden samtidigt。
Nya konsumenter får bara nya meddelanden
Hur får man en ny kund att bara ta emot nya meddelanden och ignorera historisk data?
Inställningarna är följande:
Som visas nedan:
Producentkod
Följande följer:
Konsumentkod
Följande följer:
Källkodsnedladdning
Turister, om ni vill se det dolda innehållet i detta inlägg, snälla Svar
|
Publicerad på 2021-04-13 11:45:31
|
|
|
|
Hyresvärd|
Publicerad på 2021-04-15 09:31:05
|
Publicerad på 2021-06-16 12:41:09
|
