Kafka ir LinkedIn izstrādāta augstas veiktspējas, izplatīta ziņojumapmaiņas sistēma, kas tiek plaši izmantota tādos scenārijos kā žurnālu vākšana, straumēšanas datu apstrāde, tiešsaistes un bezsaistes ziņojumu izplatīšana un citi. Lai gan Kafaka nav izstrādāts kā tradicionāls MQ, vairumā gadījumu tas var aizstāt tradicionālās ziņojumapmaiņas sistēmas, piemēram, ActiveMQ.
Kafka organizē ziņojumu plūsmu pēc tēmām, un serveri, kurā atrodas ziņojumi, sauc par brokeri, un patērētāji var abonēt vienu vai vairākas tēmas. Lai līdzsvarotu slodzi, tēmas ziņojumus var iedalīt vairākos nodalījumos, un jo vairāk starpsienu, jo lielāks ir Kafkas paralēlisms un caurlaidspēja.
Kafkas klasteriem ir nepieciešams zooturētāja atbalsts, lai ieviestu klasterus, un zookeeper jau ir iekļauts jaunākajā kafkas izplatījumā, ko var izvietot, lai vienlaikus startētu zookeeper serveri un Kafka serveri vai izmantotu citus esošos zookeeper klasterus.
Atšķirībā no tradicionālā MQ, patērētājiem pašiem ir jāsaglabā nobīde, un, saņemot ziņojumus no kafkas, tikai pēc pašreizējās nobīdes. Kafkas scala/java klients jau īsteno šo loģikas daļu, saglabājot nobīdi zoodārza turētājam. Katrs patērētājs var izvēlēties ID, un patērētāji ar vienu un to pašu ID saņems vienu un to pašu ziņojumu tikai vienu reizi.Ja tēmas patērētāji izmanto vienu un to pašu ID, tā ir tradicionālā rinda. Ja katrs patērētājs izmanto atšķirīgu ID, tas ir tradicionāls krogs.
Pārskats:
Kafkas patēriņš
1. Viena group_id patērētāji tikai viens patērētājs var patērēt ziņojumus (Rindas rindas režīms）
2. Dažādu group_id patērētāji saņem vienas un tās pašas ziņas
Kafkas priekšrocības
Izplatīts un ļoti mērogojams. Kafkas klasterus var pārredzami mērogot, lai klasterim pievienotu jaunus serverus.
Augsta veiktspēja. Kafka veiktspēja ievērojami pārsniedz tradicionālo MQ ieviešanu, piemēram, ActiveMQ un RabbitMQ, īpaši Kafka, kas atbalsta arī pakešu operācijas. Nākamajā attēlā parādīti LinkedIn patērētāju veiktspējas stresa testa rezultāti:
Kļūdu tolerance. Dati no katra Kafkas nodalījuma tiek replicēti uz vairākiem serveriem. Ja brokeris neizdodas, ZooKeeper pakalpojums paziņos ražotājam un patērētājam, kuri pāriet uz citu brokeri.
Kafkas trūkumi:
Atkārtojiet ziņojumus. Kafka garantē tikai to, ka katrs ziņojums tiks piegādāts vismaz vienu reizi, un, lai gan izredzes ir niecīgas, pastāv iespēja, ka ziņojums tiks piegādāts vairākas reizes.
Ziņas nav kārtībā. Lai gan tiek garantēts, ka ziņojumi nodalījumā ir sakārtoti, ja tēmai ir vairāki nodalījumi, ziņojumu piegāde starp nodalījumiem nav garantēta.
Sarežģītība. Kafka prasa zoodārza kopu atbalstu, un tēmas parasti prasa manuālu darbu, lai izveidotu, izvietotu un uzturētu dārgāk nekā vispārējās ziņojumu rindas
.NET/C# ziņojumu rindas Kafka operācijas
Pirmkārt, izmantojiet .NET Core 3.1, lai izveidotu divus jaunus konsoles projektus, proti, Kafka-Consumer un Kafka-Producer
Izmantojiet nuget, lai atsauktos uz Confluent.Kafka pakotni šādi, ar šādu komandu:
GitHub adrese:Hipersaites pieteikšanās ir redzama.
Mēs vispirms sākam producenta programmu, un, ja mēs vispirms sākam patērētāju, mēs saņemsim šādu kļūdu:
Radās kļūda: Brokeris: nezināma tēma vai nodalījums
Šajā rakstā tiks izmantoti iestatījumiEnableAutoOffsetStore ir nepatiess, tas ir, manuāli iestatot nobīdes krātuvi (līdzīgi manuālam apstiprinājuma ziņojumam)
Patērētāji neiestata OffsetStore pēc patēriņa
Mēģiniet izmantot ražotāju, lai radītu divus ziņojumus, ieslēgtu patērētāju patēriņu, MaxPollIntervalMs = 10000 // 10 sekundes bez manuālas iestatīšanas, ļaujiet citiem klientiem patērēt, protams, citi klienti to nepatērēs 10 sekunžu laikā
MaxPollIntervalMs skaidro
Pieredzējušiem patērētājiem maksimālais atļautais laiks ziņojumu patēriņam starp zvaniem (piemēram, rd_kafka_consumer_poll()). Ja šis intervāls tiek pārsniegts, tiek uzskatīts, ka patērētājs ir cietis neveiksmi, un grupa tiek līdzsvarota tā, lai nodalījums tiktu piešķirts citam patērētāju grupas dalībniekam. Brīdinājums: Šobrīd nobīdes saistības var nebūt iespējamas. Piezīme: Ieteicams iestatīt "enable.auto.offset.store=false" lietojumprogrammām, kas apstrādā ilgu laiku, un pēc tam skaidri saglabāt nobīdi (izmantojot offsets_store()) pēc ziņojuma apstrādes*, lai nodrošinātu, ka nobīde netiek automātiski veikta pirms apstrādes pabeigšanas. Pārbaudiet reizi sekundē ar divu intervālu. Plašāku informāciju skatiet KIP-62.
Atveidojumi ir šādi:
OffsetStore tiek iestatīts pēc tam, kad patērētājs ir pabeidzis tērēt
kods
Kad iestatīšana ir pabeigta, pagaidiet 10 sekundes, un tas joprojām tiks darītsSaņēmu pēdējo ziņojumu(Kad patērētājs pieslēdzas brokerim,Sākt patēriņu no nobīdes pozīcijasJa ir iestatīts c.Commit(cr); Pēdējais ziņojums netiks saņemts atkārtoti.
Skatīt avota kodu
veikt nobīdi + 1 commit un galu galā izsaukt Librdkafka.topic_partition_list_destroy(cOffsets);
Hipersaites pieteikšanās ir redzama.
Hipersaites pieteikšanās ir redzama.
Cita GroupId iestatīšana
Mēģiniet iestatīt citu GroupId, izmantojot komandrindas parametru, un pēc tam nosūtiet ziņojumu caur ražotāju, kā parādīts šajā attēlā:
Gan clinet1, gan client2Vēsturisko ziņojumu saņemšana, un pēc tam, kad producents nosūtīs ziņu, abi būs gandrīzSaņemiet ziņojumus vienlaicīgi。
Jaunie patērētāji saņem tikai jaunus ziņojumus
Kā panākt, lai jauns klients saņemtu tikai jaunus ziņojumus un ignorētu vēsturiskos datus?
Iestatījumi ir šādi:
Kā parādīts zemāk:
Ražotāja kods
Šādi:
Patērētāju kods
Šādi:
Avota koda lejupielāde
Tūristi, ja vēlaties redzēt šīs ziņas slēpto saturu, lūdzu Atbildi
|
Publicēts 13.04.2021 11:45:31
|
|
|
|
Saimnieks|
Publicēts 15.04.2021 09:31:05
|
Publicēts 16.06.2021 12:41:09
|
