🥇 Deall broceriaid negeseuon. Dysgu mecaneg negeseuon gydag ActiveMQ a Kafka. Pennod 3. Kafka

Parhad o gyfieithu llyfr bach:
Deall Broceriaid Negeseuon
awdur: Jakub Korab, cyhoeddwr: O'Reilly Media, Inc., dyddiad cyhoeddi: Mehefin 2017, ISBN: 9781492049296.

Rhan wedi'i chyfieithu'n flaenorol: Deall broceriaid negeseuon. Dysgu mecaneg negeseuon gydag ActiveMQ a Kafka. Pennod 1 Rhagymadrodd

PENNOD 3

Kafka

Datblygwyd Kafka gan LinkedIn i fynd o gwmpas rhai o gyfyngiadau broceriaid negeseuon traddodiadol ac osgoi gorfod sefydlu broceriaid negeseuon lluosog ar gyfer gwahanol ryngweithiadau pwynt-i-bwynt, a ddisgrifir yn y llyfr hwn o dan "Scaling up and out" ar dudalen 28 ■ Achosion defnydd Mae LinkedIn wedi dibynnu i raddau helaeth ar amlyncu symiau mawr iawn o ddata un ffordd, megis cliciau tudalennau a logiau mynediad, tra'n dal i ganiatáu i'r data hwnnw gael ei ddefnyddio gan systemau lluosog heb effeithio ar gynhyrchiant cynhyrchwyr neu ddefnyddwyr eraill. Mewn gwirionedd, y rheswm y mae Kafka yn bodoli yw cael y math o bensaernïaeth negeseuon y mae'r Piblinell Data Cyffredinol yn ei ddisgrifio.

O ystyried y nod eithaf hwn, cododd gofynion eraill yn naturiol. Dylai Kafka:

Byddwch yn hynod o gyflym
Darparu mwy o led band wrth weithio gyda negeseuon
Cefnogi modelau Cyhoeddwr-Tanysgrifiwr a Phwynt-i-Bwynt
Peidiwch ag arafu wrth ychwanegu defnyddwyr. Er enghraifft, mae perfformiad y ciw a'r pwnc yn ActiveMQ yn diraddio wrth i nifer y defnyddwyr ar y cyrchfan gynyddu.
Bod yn scalable llorweddol; os gall un brocer sy'n parhau â negeseuon wneud hynny ar gyflymder disg uchaf yn unig, yna mae'n gwneud synnwyr mynd y tu hwnt i enghraifft brocer sengl i gynyddu perfformiad
Cyfyngu mynediad i storio ac adalw negeseuon

Er mwyn cyflawni hyn oll, mabwysiadodd Kafka bensaernïaeth a ailddiffiniodd rolau a chyfrifoldebau cleientiaid a broceriaid negeseuon. Mae model JMS yn canolbwyntio ar froceriaid, lle mae'r brocer yn gyfrifol am ddosbarthu negeseuon a dim ond am anfon a derbyn negeseuon y mae'n rhaid i gleientiaid boeni. Mae Kafka, ar y llaw arall, yn canolbwyntio ar y cleient, gyda'r cleient yn cymryd llawer o nodweddion brocer traddodiadol, megis dosbarthiad teg o negeseuon perthnasol i ddefnyddwyr, yn gyfnewid am frocer hynod gyflym a graddadwy. I bobl sydd wedi gweithio gyda systemau negeseuon traddodiadol, mae gweithio gyda Kafka yn gofyn am newid meddwl sylfaenol.
Mae'r cyfeiriad peirianneg hwn wedi arwain at greu seilwaith negeseuon sy'n gallu cynyddu trwybwn yn ôl llawer o orchmynion maint o'i gymharu â brocer confensiynol. Fel y byddwn yn gweld, daw'r dull hwn gyda chyfaddawdau, sy'n golygu nad yw Kafka yn addas ar gyfer rhai mathau o lwythi gwaith a meddalwedd wedi'i osod.

Model Cyrchfan Unedig

Er mwyn cyflawni'r gofynion a ddisgrifir uchod, mae Kafka wedi cyfuno cyhoeddi-tanysgrifio a negeseuon pwynt-i-bwynt o dan un math o gyrchfan - pwnc. Mae hyn yn ddryslyd i bobl sydd wedi gweithio gyda systemau negeseuon, lle mae'r gair "pwnc" yn cyfeirio at fecanwaith darlledu y mae darllen (o'r pwnc) ohono yn anhydrin. Dylid ystyried pynciau Kafka yn fath o gyrchfan hybrid, fel y'i diffinnir yn y cyflwyniad i'r llyfr hwn.

Am weddill y bennod hon, oni bai ein bod yn datgan yn benodol fel arall, bydd y term "pwnc" yn cyfeirio at bwnc Kafka.

Er mwyn deall yn llawn sut mae pynciau'n ymddwyn a pha warantau y maent yn eu darparu, mae angen inni edrych yn gyntaf ar sut y cânt eu gweithredu yn Kafka.
Mae gan bob pwnc yn Kafka ei log ei hun.
Mae cynhyrchwyr sy'n anfon negeseuon at Kafka yn ysgrifennu at y log hwn, ac mae defnyddwyr yn darllen o'r log gan ddefnyddio awgrymiadau sy'n symud ymlaen yn gyson. O bryd i'w gilydd, mae Kafka yn dileu rhannau hynaf y log, p'un a yw'r negeseuon yn y rhannau hynny wedi'u darllen ai peidio. Rhan ganolog o ddyluniad Kafka yw nad yw'r brocer yn poeni a yw negeseuon yn cael eu darllen ai peidio - dyna gyfrifoldeb y cleient.

Nid yw'r termau "log" a "pointer" yn ymddangos yn Dogfennaeth Kafka. Defnyddir y termau adnabyddus hyn yma i gynorthwyo dealltwriaeth.

Mae'r model hwn yn hollol wahanol i ActiveMQ, lle mae negeseuon o bob ciw yn cael eu storio yn yr un log, ac mae'r brocer yn nodi bod y negeseuon wedi'u dileu ar ôl iddynt gael eu darllen.
Gadewch i ni nawr gloddio ychydig yn ddyfnach ac edrych ar y log pwnc yn fwy manwl.
Mae log Kafka yn cynnwys sawl rhaniad (Ffigur 3 1-). Mae Kafka yn gwarantu archebu llym ym mhob rhaniad. Mae hyn yn golygu y bydd negeseuon a ysgrifennwyd at y rhaniad mewn trefn benodol yn cael eu darllen yn yr un drefn. Gweithredir pob rhaniad fel ffeil log dreigl sy'n cynnwys is-set (is-set) o'r holl negeseuon a anfonwyd at y pwnc gan ei gynhyrchwyr. Mae'r pwnc a grëwyd yn cynnwys, yn ddiofyn, un rhaniad. Y syniad o raniadau yw'r syniad canolog o Kafka ar gyfer graddio llorweddol.

Ffigur 3-1. Rhaniadau Kafka

Pan fydd cynhyrchydd yn anfon neges at bwnc Kafka, mae'n penderfynu i ba raniad i anfon y neges. Byddwn yn edrych ar hyn yn fanylach yn nes ymlaen.

Darllen negeseuon

Mae'r cleient sydd eisiau darllen y negeseuon yn rheoli pwyntydd a enwir o'r enw grŵp defnyddwyr, sy'n pwyntio at gwrthbwyso negeseuon yn y rhaniad. Mae gwrthbwyso yn safle cynyddrannol sy'n dechrau ar 0 ar ddechrau rhaniad. Mae'r grŵp defnyddwyr hwn, y cyfeirir ato yn yr API trwy'r group_id a ddiffinnir gan y defnyddiwr, yn cyfateb i un defnyddiwr neu system resymegol.

Mae'r rhan fwyaf o systemau negeseuon yn darllen data o'r cyrchfan gan ddefnyddio sawl enghraifft ac edafedd i brosesu negeseuon ochr yn ochr. Felly, fel arfer bydd llawer o achosion defnyddwyr yn rhannu'r un grŵp defnyddwyr.

Gellir cynrychioli problem darllen fel a ganlyn:

Mae gan y pwnc raniadau lluosog
Gall grwpiau lluosog o ddefnyddwyr ddefnyddio pwnc ar yr un pryd
Gall grŵp o ddefnyddwyr gael sawl achos ar wahân

Mae hon yn broblem llawer-i-lawer nad yw'n ddibwys. Er mwyn deall sut mae Kafka yn trin perthnasoedd rhwng grwpiau defnyddwyr, achosion defnyddwyr, a rhaniadau, gadewch i ni edrych ar gyfres o senarios darllen cynyddol gymhleth.

Defnyddwyr a grwpiau defnyddwyr

Gadewch i ni gymryd pwnc ag un rhaniad fel man cychwyn (Ffigur 3 2-).

Ffigur 3-2. Defnyddiwr yn darllen o'r rhaniad

Pan fydd enghraifft defnyddiwr yn cysylltu â'i grŵp_id ei hun â'r pwnc hwn, rhoddir rhaniad darllen iddo a gwrthbwyso yn y rhaniad hwnnw. Mae lleoliad y gwrthbwyso hwn wedi'i ffurfweddu yn y cleient fel pwyntydd i'r sefyllfa ddiweddaraf (neges fwyaf newydd) neu'r safle cynharaf (neges hynaf). Mae'r defnyddiwr yn gofyn am (pôl) negeseuon o'r pwnc, sy'n achosi iddynt gael eu darllen yn olynol o'r log.
Mae'r sefyllfa wrthbwyso yn cael ei hymrwymo'n rheolaidd yn ôl i Kafka a'i storio fel negeseuon mewn pwnc mewnol _defnyddiwr_wrthbwyso. Nid yw negeseuon darllen yn cael eu dileu o hyd, yn wahanol i frocer rheolaidd, a gall y cleient ailddirwyn y gwrthbwyso i ail-brosesu negeseuon a welwyd eisoes.

Pan fydd ail ddefnyddiwr rhesymegol yn cysylltu gan ddefnyddio grŵp_id gwahanol, mae'n rheoli ail bwyntydd sy'n annibynnol ar y cyntaf (Ffigur 3 3-). Felly, mae pwnc Kafka yn gweithredu fel ciw lle mae un defnyddiwr ac fel pwnc cyhoeddi-danysgrifio arferol (tafarn-is) y mae defnyddwyr lluosog yn tanysgrifio iddo, gyda'r fantais ychwanegol bod pob neges yn cael ei storio ac y gellir ei phrosesu sawl gwaith.

Ffigur 3-3. Mae dau ddefnyddiwr mewn gwahanol grwpiau defnyddwyr yn darllen o'r un rhaniad

Defnyddwyr mewn grŵp defnyddwyr

Pan fydd un enghraifft defnyddiwr yn darllen data o raniad, mae ganddo reolaeth lawn o'r pwyntydd ac mae'n prosesu negeseuon fel y disgrifiwyd yn yr adran flaenorol.
Pe bai sawl achos o ddefnyddwyr yn gysylltiedig â'r un grŵp_id â phwnc ag un rhaniad, yna bydd yr enghraifft a gysylltodd ddiwethaf yn cael rheolaeth dros y pwyntydd ac o'r eiliad honno ymlaen bydd yn derbyn pob neges (Ffigur 3 4-).

Ffigur 3-4. Darllenodd dau ddefnyddiwr yn yr un grŵp defnyddwyr o'r un rhaniad

Gellir meddwl am y dull hwn o brosesu, lle mae nifer yr achosion defnyddwyr yn fwy na nifer y rhaniadau, yn fath o ddefnyddiwr unigryw. Gall hyn fod yn ddefnyddiol os oes angen clystyru "gweithredol-goddefol" (neu "gynnes-boeth") o'ch achosion defnyddwyr, er bod rhedeg defnyddwyr lluosog ochr yn ochr ("active-active" neu "hot-hot") yn llawer mwy nodweddiadol na defnyddwyr, wrth law.

Gall yr ymddygiad dosbarthu negeseuon a ddisgrifir uchod fod yn syndod o gymharu â sut mae ciw JMS arferol yn ymddwyn. Yn y model hwn, bydd negeseuon a anfonir i'r ciw yn cael eu dosbarthu'n gyfartal rhwng y ddau ddefnyddiwr.

Yn fwyaf aml, pan fyddwn yn creu achosion lluosog o ddefnyddwyr, rydym yn gwneud hyn naill ai i brosesu negeseuon yn gyfochrog, neu i gynyddu cyflymder darllen, neu i gynyddu sefydlogrwydd y broses ddarllen. Gan mai dim ond un enghraifft defnyddiwr all ddarllen data o raniad ar y tro, sut mae hyn yn cael ei gyflawni yn Kafka?

Un ffordd o wneud hyn yw defnyddio enghraifft defnyddiwr sengl i ddarllen yr holl negeseuon a'u trosglwyddo i'r gronfa edau. Er bod y dull hwn yn cynyddu trwybwn prosesu, mae'n cynyddu cymhlethdod rhesymeg y defnyddiwr ac nid yw'n gwneud dim i gynyddu cadernid y system ddarllen. Os bydd un copi o'r defnyddiwr yn mynd i lawr oherwydd methiant pŵer neu ddigwyddiad tebyg, yna mae'r tynnu yn dod i ben.

Y ffordd ganonaidd o ddatrys y broblem hon yn Kafka yw defnyddio bОmwy o raniadau.

Rhaniad

Rhaniadau yw'r prif fecanwaith ar gyfer cyfochrog darllen a graddio pwnc y tu hwnt i lled band enghraifft brocer sengl. I ddeall hyn yn well, gadewch i ni ystyried sefyllfa lle mae pwnc gyda dau raniad ac mae un defnyddiwr yn tanysgrifio i'r pwnc hwn (Ffigur 3 5-).

Ffigur 3-5. Mae un defnyddiwr yn darllen o raniad lluosog

Yn y senario hwn, mae'r defnyddiwr yn cael rheolaeth dros yr awgrymiadau sy'n cyfateb i'w group_id yn y ddau raniad ac yn dechrau darllen negeseuon o'r ddau raniad.
Pan ychwanegir defnyddiwr ychwanegol ar gyfer yr un grŵp_id at y pwnc hwn, mae Kafka yn ailddyrannu un o'r rhaniadau o'r defnyddiwr cyntaf i'r ail ddefnyddiwr. Ar ôl hynny, bydd pob enghraifft o'r defnyddiwr yn darllen o un rhaniad o'r pwnc (Ffigur 3 6-).

Er mwyn sicrhau bod negeseuon yn cael eu prosesu ochr yn ochr mewn 20 edefyn, mae angen o leiaf 20 rhaniad arnoch. Os oes llai o raniadau, byddwch yn cael eich gadael gyda defnyddwyr nad oes ganddynt ddim i weithio arno, fel y disgrifiwyd yn gynharach yn y drafodaeth ar ddefnyddwyr unigryw.

Ffigur 3-6. Darllenodd dau ddefnyddiwr yn yr un grŵp defnyddwyr o wahanol raniadau

Mae'r cynllun hwn yn lleihau cymhlethdod y brocer Kafka yn fawr o'i gymharu â'r dosbarthiad neges sydd ei angen i gynnal y ciw JMS. Yma nid oes angen i chi boeni am y pwyntiau canlynol:

Pa ddefnyddiwr ddylai dderbyn y neges nesaf, yn seiliedig ar ddyraniad rownd-robin, cynhwysedd cyfredol byfferau rhagosodedig, neu negeseuon blaenorol (fel ar gyfer grwpiau neges JMS).
Pa negeseuon sy'n cael eu hanfon at ba ddefnyddwyr ac a ddylid eu hail-ddosbarthu rhag ofn y byddant yn methu.

Y cyfan sy'n rhaid i frocer Kafka ei wneud yw trosglwyddo negeseuon yn olynol i'r defnyddiwr pan fydd yr olaf yn gofyn amdanynt.

Fodd bynnag, nid yw'r gofynion ar gyfer paraleleiddio'r prawfddarllen ac ail-anfon negeseuon a fethwyd yn diflannu - yn syml, mae'r cyfrifoldeb amdanynt yn mynd o'r brocer i'r cleient. Mae hyn yn golygu bod yn rhaid eu cymryd i ystyriaeth yn eich cod.

Anfon negeseuon

Cyfrifoldeb cynhyrchydd y neges honno yw penderfynu i ba raniad i anfon neges. Er mwyn deall y mecanwaith ar gyfer gwneud hyn, yn gyntaf mae angen inni ystyried beth yn union yr ydym yn ei anfon mewn gwirionedd.

Tra yn JMS rydym yn defnyddio strwythur neges gyda metadata (penawdau a phriodweddau) a chorff sy'n cynnwys y llwyth tâl (payload), yn Kafka y neges yw pâr "gwerth allweddol". Anfonir llwyth tâl y neges fel gwerth. Mae'r allwedd, ar y llaw arall, yn cael ei ddefnyddio'n bennaf ar gyfer rhaniad a rhaid iddo gynnwys allwedd rhesymeg busnes penodoli roi negeseuon cysylltiedig yn yr un rhaniad.

Ym Mhennod 2, buom yn trafod y senario betio ar-lein lle mae angen i un defnyddiwr brosesu digwyddiadau cysylltiedig mewn trefn:

Mae'r cyfrif defnyddiwr wedi'i ffurfweddu.
Mae arian yn cael ei gredydu i'r cyfrif.
Gwneir bet sy'n tynnu arian o'r cyfrif.

Os yw pob digwyddiad yn neges sy'n cael ei phostio i bwnc, yna'r allwedd naturiol fyddai ID y cyfrif.
Pan anfonir neges gan ddefnyddio API Cynhyrchydd Kafka, fe'i trosglwyddir i swyddogaeth rhaniad sydd, o ystyried y neges a chyflwr presennol clwstwr Kafka, yn dychwelyd ID y rhaniad y dylid anfon y neges ato. Mae'r nodwedd hon yn cael ei gweithredu yn Java trwy'r rhyngwyneb Partitioner.

Mae'r rhyngwyneb hwn yn edrych fel hyn:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

Mae gweithrediad y Rhannwr yn defnyddio'r algorithm stwnsio cyffredinol-bwrpas diofyn dros yr allwedd i bennu'r rhaniad, neu'r robin crwn os nad oes allwedd wedi'i nodi. Mae'r gwerth rhagosodedig hwn yn gweithio'n dda yn y rhan fwyaf o achosion. Fodd bynnag, yn y dyfodol byddwch am ysgrifennu un eich hun.

Ysgrifennu eich strategaeth rhannu eich hun

Gadewch i ni edrych ar enghraifft lle rydych chi am anfon metadata ynghyd â llwyth cyflog y neges. Mae'r llwyth tâl yn ein hesiampl yn gyfarwyddyd i wneud blaendal i'r cyfrif gêm. Mae cyfarwyddyd yn rhywbeth yr hoffem fod yn sicr o beidio â chael ei addasu wrth drosglwyddo ac rydym am fod yn siŵr mai dim ond system i fyny'r afon y gellir ymddiried ynddi a all roi'r cyfarwyddyd hwnnw ar waith. Yn yr achos hwn, mae'r systemau anfon a derbyn yn cytuno ar ddefnyddio llofnod i ddilysu'r neges.
Mewn JMS arferol, rydym yn syml yn diffinio priodwedd "llofnod neges" a'i ychwanegu at y neges. Fodd bynnag, nid yw Kafka yn darparu mecanwaith ar gyfer pasio metadata, dim ond allwedd a gwerth.

Gan mai llwyth tâl trosglwyddiad banc yw'r gwerth yr ydym am ei gadw, nid oes gennym unrhyw ddewis ond diffinio'r strwythur data i'w ddefnyddio yn yr allwedd. Gan dybio bod angen ID cyfrif arnom ar gyfer rhannu, gan fod yn rhaid prosesu'r holl negeseuon sy'n ymwneud â chyfrif mewn trefn, byddwn yn llunio'r strwythur JSON canlynol:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

Oherwydd y bydd gwerth y llofnod yn amrywio yn dibynnu ar y llwyth tâl, ni fydd strategaeth stwnsio ddiofyn y rhyngwyneb Rhannwr yn grwpio negeseuon cysylltiedig yn ddibynadwy. Felly, bydd angen inni ysgrifennu ein strategaeth ein hunain a fydd yn dosrannu'r allwedd hon ac yn rhannu gwerth accountId.

Mae Kafka yn cynnwys sieciau i ganfod llygredd negeseuon yn y siop ac mae ganddo set lawn o nodweddion diogelwch. Serch hynny, mae gofynion diwydiant-benodol, fel yr un uchod, yn ymddangos weithiau.

Rhaid i strategaeth rhaniad y defnyddiwr sicrhau bod yr holl negeseuon cysylltiedig yn yr un rhaniad yn y pen draw. Er bod hyn yn ymddangos yn syml, gall y gofyniad gael ei gymhlethu gan bwysigrwydd trefnu negeseuon cysylltiedig a pha mor sefydlog yw nifer y rhaniadau mewn pwnc.

Gall nifer y rhaniadau mewn pwnc newid dros amser, oherwydd gellir eu hychwanegu os yw traffig yn mynd y tu hwnt i ddisgwyliadau cychwynnol. Felly, gall allweddi neges fod yn gysylltiedig â'r rhaniad y cawsant eu hanfon ato yn wreiddiol, gan awgrymu darn o gyflwr i'w rannu rhwng achosion cynhyrchydd.

Ffactor arall i'w ystyried yw dosbarthiad cyfartal negeseuon ar draws rhaniadau. Yn nodweddiadol, nid yw allweddi'n cael eu dosbarthu'n gyfartal ar draws negeseuon, ac nid yw swyddogaethau hash yn gwarantu dosbarthiad teg o negeseuon ar gyfer set fach o allweddi.
Mae'n bwysig nodi, sut bynnag y byddwch yn dewis rhannu negeseuon, efallai y bydd angen ailddefnyddio'r gwahanydd ei hun.

Ystyried y gofyniad i ddyblygu data rhwng clystyrau Kafka mewn gwahanol leoliadau daearyddol. At y diben hwn, mae Kafka yn dod ag offeryn llinell orchymyn o'r enw MirrorMaker, a ddefnyddir i ddarllen negeseuon o un clwstwr a'u trosglwyddo i un arall.

Rhaid i MirrorMaker ddeall allweddi'r testun a atgynhyrchwyd er mwyn cynnal trefn gymharol rhwng negeseuon wrth atgynhyrchu rhwng clystyrau, oherwydd efallai na fydd nifer y rhaniadau ar gyfer y testun hwnnw yr un peth mewn dau glwstwr.

Mae strategaethau rhaniad personol yn gymharol brin, gan fod stwnsio diofyn neu robin crwn yn gweithio'n dda yn y rhan fwyaf o senarios. Fodd bynnag, os oes angen gwarantau archebu cryf arnoch neu os oes angen tynnu metadata o lwythi tâl, yna mae rhannu yn rhywbeth y dylech edrych yn agosach arno.

Daw manteision scalability a pherfformiad Kafka o symud rhai o gyfrifoldebau'r brocer traddodiadol i'r cleient. Yn yr achos hwn, gwneir penderfyniad i ddosbarthu negeseuon a allai fod yn gysylltiedig â nifer o ddefnyddwyr sy'n gweithio ochr yn ochr.

Mae angen i froceriaid JMS hefyd ymdrin â gofynion o'r fath. Yn ddiddorol, mae'r mecanwaith ar gyfer anfon negeseuon cysylltiedig at yr un defnyddiwr, a weithredir trwy JMS Message Groups (amrywiad ar y strategaeth cydbwyso llwyth gludiog (SLB)), hefyd yn ei gwneud yn ofynnol i'r anfonwr nodi negeseuon fel rhai cysylltiedig. Yn achos JMS, y brocer sy'n gyfrifol am anfon y grŵp hwn o negeseuon cysylltiedig at un defnyddiwr allan o lawer, a throsglwyddo perchnogaeth y grŵp os bydd y defnyddiwr yn methu.

Cytundebau Cynhyrchwyr

Nid rhannu yw'r unig beth i'w ystyried wrth anfon negeseuon. Gadewch i ni edrych ar ddulliau anfon () y dosbarth Cynhyrchydd yn yr API Java:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

Dylid nodi ar unwaith bod y ddau ddull yn dychwelyd Dyfodol, sy'n dangos nad yw'r gweithrediad anfon yn cael ei berfformio ar unwaith. Y canlyniad yw bod neges (ProducerRecord) yn cael ei ysgrifennu at y byffer anfon ar gyfer pob rhaniad gweithredol a'i anfon at y brocer fel edefyn cefndir yn llyfrgell cleientiaid Kafka. Er bod hyn yn gwneud pethau'n anhygoel o gyflym, mae'n golygu y gall cymhwysiad dibrofiad golli negeseuon os caiff ei broses ei hatal.

Fel bob amser, mae yna ffordd i wneud y gweithrediad anfon yn fwy dibynadwy ar gost perfformiad. Gellir gosod maint y byffer hwn i 0, a bydd yr edefyn cais anfon yn cael ei orfodi i aros nes bod y trosglwyddiad neges i'r brocer wedi'i gwblhau, fel a ganlyn:

RecordMetadata metadata = producer.send(record).get();

Mwy am ddarllen negeseuon

Mae gan ddarllen negeseuon gymhlethdodau ychwanegol y mae angen dyfalu yn eu cylch. Yn wahanol i'r API JMS, sy'n gallu rhedeg gwrandäwr neges mewn ymateb i neges, mae'r Defnyddwyr polau Kafka yn unig. Gadewch i ni edrych yn agosach ar y dull pleidleisio ()a ddefnyddir at y diben hwn:

ConsumerRecords < K, V > poll(long timeout);

Mae gwerth dychwelyd y dull yn strwythur cynhwysydd sy'n cynnwys gwrthrychau lluosog cofnod defnyddiwr o sawl rhaniad o bosibl. cofnod defnyddiwr yn wrthrych daliwr ei hun ar gyfer pâr gwerth bysell gyda metadata cysylltiedig, megis y rhaniad y mae'n deillio ohono.

Fel y trafodwyd ym Mhennod 2, rhaid inni gadw mewn cof beth sy’n digwydd i negeseuon ar ôl iddynt gael eu prosesu’n llwyddiannus neu’n aflwyddiannus, er enghraifft, os nad yw’r cleient yn gallu prosesu’r neges neu os yw’n erthylu. Yn JMS, ymdriniwyd â hyn trwy ddull cydnabod. Bydd y brocer naill ai'n dileu'r neges a broseswyd yn llwyddiannus, neu'n ail-gyflwyno'r neges amrwd neu ffug (gan dybio bod trafodion wedi'u defnyddio).
Mae Kafka yn gweithio'n wahanol iawn. Nid yw negeseuon yn cael eu dileu yn y brocer ar ôl prawfddarllen, a'r hyn sy'n digwydd ar fethiant yw cyfrifoldeb y cod prawfddarllen ei hun.

Fel y dywedasom, mae'r grŵp defnyddwyr yn gysylltiedig â'r gwrthbwyso yn y log. Mae'r safle log sy'n gysylltiedig â'r gwrthbwyso hwn yn cyfateb i'r neges nesaf i'w chyhoeddi mewn ymateb iddi pleidleisio (). Mae'r adeg pan fydd y gwrthbwyso hwn yn cynyddu yn bendant ar gyfer darllen.

Gan ddychwelyd at y model darllen a drafodwyd yn gynharach, mae prosesu negeseuon yn cynnwys tri cham:

Adalw neges i'w darllen.
Prosesu'r neges.
Cadarnhau neges.

Daw'r defnyddiwr Kafka ag opsiwn cyfluniad galluogi.auto.comisiwn. Mae hwn yn osodiad rhagosodedig a ddefnyddir yn aml, fel sy'n gyffredin gyda gosodiadau sy'n cynnwys y gair "auto".

Cyn Kafka 0.10, byddai cleient sy'n defnyddio'r opsiwn hwn yn anfon gwrthbwyso'r neges olaf a ddarllenwyd ar yr alwad nesaf pleidleisio () ar ôl prosesu. Roedd hyn yn golygu y gellid ailbrosesu unrhyw negeseuon a oedd eisoes wedi'u casglu pe bai'r cleient eisoes wedi eu prosesu ond wedi'u dinistrio'n annisgwyl cyn ffonio pleidleisio (). Gan nad yw'r brocer yn cadw unrhyw gyflwr ynghylch faint o weithiau y mae neges wedi'i darllen, ni fydd y defnyddiwr nesaf sy'n adfer y neges honno'n gwybod bod rhywbeth drwg wedi digwydd. Roedd yr ymddygiad hwn yn ffug-drafodiadol. Dim ond os cafodd y neges ei phrosesu'n llwyddiannus y cafodd y gwrthbwyso ei ymrwymo, ond pe bai'r cleient yn rhoi'r gorau iddi, byddai'r brocer yn anfon yr un neges eto at gleient arall. Roedd yr ymddygiad hwn yn gyson â'r warant cyflenwi neges "o leiaf unwaith".

Yn Kafka 0.10, mae'r cod cleient wedi'i newid fel bod y ymrwymiad yn cael ei ysgogi o bryd i'w gilydd gan lyfrgell y cleient, fel y'i ffurfweddwyd awto.ymrwymo.cyfwng.ms. Mae'r ymddygiad hwn rhywle rhwng y moddau JMS AUTO_ACKNOWLEDGE a DUPS_OK_ACKNOWLEDGE. Wrth ddefnyddio awtocommit, gellid ymrwymo negeseuon ni waeth a oeddent wedi'u prosesu mewn gwirionedd - gallai hyn ddigwydd yn achos defnyddiwr araf. Pe bai defnyddiwr yn rhoi'r gorau iddi, byddai negeseuon yn cael eu hanfon gan y defnyddiwr nesaf, gan ddechrau yn y safle ymrwymedig, a allai arwain at golli neges. Yn yr achos hwn, ni chollodd Kafka y negeseuon, ni wnaeth y cod darllen eu prosesu.

Mae gan y modd hwn yr un addewid ag yn fersiwn 0.9: gellir prosesu negeseuon, ond os yw'n methu, efallai na fydd y gwrthbwyso'n cael ei ymrwymo, a allai achosi dyblu'r danfoniad. Po fwyaf o negeseuon a gewch wrth weithredu pleidleisio (), po fwyaf y broblem hon.

Fel y trafodwyd yn “Darllen Negeseuon o Ciw” ar dudalen 21, nid oes y fath beth â chyfleu neges un-amser mewn system negeseuon pan fydd moddau methu yn cael eu hystyried.

Yn Kafka, mae dwy ffordd o gyflawni (cyflawni) gwrthbwyso (gwrthbwyso): yn awtomatig ac â llaw. Yn y ddau achos, gellir prosesu negeseuon sawl gwaith os cafodd y neges ei phrosesu ond ei bod wedi methu cyn ymrwymo. Gallwch hefyd ddewis peidio â phrosesu'r neges o gwbl os digwyddodd yr ymrwymiad yn y cefndir a bod eich cod wedi'i gwblhau cyn y gellid ei brosesu (efallai yn Kafka 0.9 ac yn gynharach).

Gallwch reoli'r broses ymrwymo gwrthbwyso â llaw yn API defnyddwyr Kafka trwy osod y paramedr galluogi.auto.comisiwn i alw un o’r dulliau canlynol yn ffug ac yn benodol:

void commitSync();
void commitAsync();

Os ydych chi am brosesu'r neges "o leiaf unwaith", rhaid i chi ymrwymo'r gwrthbwyso â llaw ymrwymoSync()trwy weithredu'r gorchymyn hwn yn syth ar ôl prosesu'r negeseuon.

Nid yw'r dulliau hyn yn caniatáu i negeseuon gael eu cydnabod cyn iddynt gael eu prosesu, ond nid ydynt yn gwneud dim i ddileu oedi posibl mewn prosesu wrth roi'r argraff eu bod yn drafodol. Nid oes unrhyw drafodion yn Kafka. Nid oes gan y cleient y gallu i wneud y canlynol:

Rholiwch neges ffug yn ôl yn awtomatig. Rhaid i ddefnyddwyr eu hunain ymdrin ag eithriadau sy'n deillio o lwythi cyflog problematig a thoriadau ôl-ben, gan na allant ddibynnu ar y brocer i ail-gyflwyno negeseuon.
Anfon negeseuon i bynciau lluosog mewn un gweithrediad atomig. Fel y gwelwn yn fuan, gall rheolaeth dros wahanol bynciau a pharwydydd fod ar wahanol beiriannau yng nghlwstwr Kafka nad ydynt yn cydlynu trafodion pan fyddant yn cael eu hanfon. Ar adeg ysgrifennu hwn, mae rhywfaint o waith wedi'i wneud i wneud hyn yn bosibl gyda'r KIP-98.
Cysylltwch ddarllen un neges o un pwnc ag anfon neges arall i bwnc arall. Eto, mae pensaernïaeth Kafka yn dibynnu ar lawer o beiriannau annibynnol yn rhedeg fel un bws ac ni wneir unrhyw ymdrech i guddio hyn. Er enghraifft, nid oes unrhyw gydrannau API a fyddai'n caniatáu ichi gysylltu defnyddiwr и Cynhyrchydd mewn trafodiad. Yn JMS, darperir hyn gan y gwrthrych sesiwno ba rai y creir MessageProducers и Defnyddwyr Neges.

Os na allwn ddibynnu ar drafodion, sut allwn ni ddarparu semanteg yn agosach at y rhai a ddarperir gan systemau negeseuon traddodiadol?

Os oes posibilrwydd y gall gwrthbwyso'r defnyddiwr gynyddu cyn i'r neges gael ei phrosesu, megis yn ystod damwain defnyddiwr, yna nid oes gan y defnyddiwr unrhyw ffordd o wybod a yw ei grŵp defnyddwyr wedi methu'r neges pan roddir rhaniad iddo. Felly un strategaeth yw ailddirwyn y gwrthbwyso i'r sefyllfa flaenorol. Mae API defnyddwyr Kafka yn darparu'r dulliau canlynol ar gyfer hyn:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

Dull ceisio () gellir ei ddefnyddio gyda dull
offsetsForTimes(Map stampiau amserIChwilio) i ailddirwyn i gyflwr ar ryw adeg benodol yn y gorffennol.

Yn ymhlyg, mae defnyddio’r dull hwn yn golygu ei bod yn debygol iawn y bydd rhai negeseuon a oedd wedi’u prosesu’n flaenorol yn cael eu darllen a’u prosesu eto. Er mwyn osgoi hyn, gallwn ddefnyddio darllen analluog, fel y disgrifir ym Mhennod 4, i gadw golwg ar negeseuon a welwyd yn flaenorol a dileu copïau dyblyg.

Fel arall, gellir cadw eich cod defnyddiwr yn syml, cyn belled â bod colli neges neu ddyblygu neges yn dderbyniol. Pan fyddwn yn ystyried achosion defnydd y mae Kafka yn cael ei ddefnyddio'n gyffredin ar eu cyfer, megis trin digwyddiadau log, metrigau, olrhain clic, ac ati, rydym yn deall nad yw colli negeseuon unigol yn debygol o gael effaith sylweddol ar gymwysiadau cyfagos. Mewn achosion o'r fath, mae'r gwerthoedd rhagosodedig yn gwbl dderbyniol. Ar y llaw arall, os oes angen i'ch cais anfon taliadau, rhaid i chi ofalu am bob neges unigol yn ofalus. Daw'r cyfan i lawr i'r cyd-destun.

Mae arsylwadau personol yn dangos, wrth i ddwysedd negeseuon gynyddu, fod gwerth pob neges unigol yn lleihau. Mae negeseuon mawr yn tueddu i fod yn werthfawr o'u gweld ar ffurf agregedig.

Argaeledd Uchel

Mae agwedd Kafka at argaeledd uchel yn wahanol iawn i ddull ActiveMQ. Mae Kafka wedi'i gynllunio o amgylch clystyrau graddfa lle mae pob achos brocer yn derbyn ac yn dosbarthu negeseuon ar yr un pryd.

Mae clwstwr Kafka yn cynnwys achosion lluosog o froceriaid yn rhedeg ar wahanol weinyddion. Dyluniwyd Kafka i redeg ar galedwedd annibynnol arferol, lle mae gan bob nod ei storfa bwrpasol ei hun. Ni argymhellir defnyddio storfa gysylltiedig â rhwydwaith (SAN) oherwydd gall nodau cyfrifiadurol lluosog gystadlu am amser.Ыd cyfnodau storio a chreu gwrthdaro.

Kafka yw bob amser ymlaen system. Nid yw llawer o ddefnyddwyr Kafka mawr byth yn cau eu clystyrau ac mae'r feddalwedd bob amser yn diweddaru gydag ailgychwyn dilyniannol. Cyflawnir hyn trwy warantu cydnawsedd â'r fersiwn flaenorol ar gyfer negeseuon a rhyngweithio rhwng broceriaid.

Broceriaid sy'n gysylltiedig â chlwstwr gweinydd SwCeidwad, sy'n gweithredu fel cofrestrfa ddata ffurfweddu ac fe'i defnyddir i gydlynu rolau pob brocer. Mae ZooKeeper ei hun yn system ddosbarthedig sy'n darparu argaeledd uchel trwy ddyblygu gwybodaeth trwy sefydlu cworwm.

Yn yr achos sylfaenol, crëir pwnc mewn clwstwr Kafka gyda'r priodweddau canlynol:

Nifer y rhaniadau. Fel y trafodwyd yn gynharach, mae'r union werth a ddefnyddir yma yn dibynnu ar y lefel ddymunol o ddarllen cyfochrog.
Mae'r ffactor atgynhyrchu (ffactor) yn pennu faint o achosion broceriaid yn y clwstwr ddylai gynnwys logiau ar gyfer y rhaniad hwn.

Gan ddefnyddio ZooKeepers ar gyfer cydgysylltu, mae Kafka yn ceisio dosbarthu rhaniadau newydd yn deg ymhlith y broceriaid yn y clwstwr. Gwneir hyn trwy un enghraifft sy'n gweithredu fel Rheolydd.

Ar amser rhedeg ar gyfer pob rhaniad testun Rheolwr aseinio rolau i frocer arweinydd (arweinydd, meistr, cyflwynydd) a dilynwyr (dilynwyr, caethweision, is-weithwyr). Mae'r brocer, sy'n gweithredu fel arweinydd y rhaniad hwn, yn gyfrifol am dderbyn yr holl negeseuon a anfonir ato gan y cynhyrchwyr a dosbarthu'r negeseuon i'r defnyddwyr. Pan anfonir negeseuon i raniad pwnc, cânt eu hailadrodd i bob nod brocer sy'n gweithredu fel dilynwyr ar gyfer y rhaniad hwnnw. Gelwir pob nod sy'n cynnwys logiau ar gyfer rhaniad replica. Gall brocer weithredu fel arweinydd ar gyfer rhai rhaniadau ac fel dilynwr i eraill.

Gelwir dilynwr sy'n cynnwys yr holl negeseuon sydd gan yr arweinydd replica cydamserol (replica sydd mewn cyflwr cydamserol, replica mewn-sync). Os bydd brocer sy'n gweithredu fel arweinydd ar gyfer rhaniad yn mynd i lawr, gall unrhyw frocer sy'n gyfredol neu wedi'i gydamseru ar gyfer y rhaniad hwnnw gymryd drosodd rôl yr arweinydd. Mae'n ddyluniad hynod gynaliadwy.

Rhan o gyfluniad y cynhyrchydd yw'r paramedr acau, sy'n pennu faint o atgynyrchiadau sy'n gorfod cydnabod (cydnabod) derbyn neges cyn i'r edefyn cais barhau i anfon: 0, 1, neu'r cyfan. Os gosod i bob, yna pan dderbynnir neges, bydd yr arweinydd yn anfon cadarnhad yn ôl at y cynhyrchydd cyn gynted ag y bydd yn derbyn cadarnhad (cydnabyddiaeth) o'r cofnod o sawl ciwiau (gan gynnwys ei hun) a ddiffinnir gan y gosodiad pwnc min.insync.replicas (diofyn 1). Os na ellir ailadrodd y neges yn llwyddiannus, yna bydd y cynhyrchydd yn taflu eithriad cais (NotDigon Replicas neu DimDigon o ReplicasAr ÔlAtodiad).

Mae ffurfweddiad nodweddiadol yn creu pwnc gyda ffactor atgynhyrchu o 3 (1 arweinydd, 2 ddilynwr fesul rhaniad) a'r paramedr min.insync.replicas wedi'i osod i 2. Yn yr achos hwn, bydd y clwstwr yn caniatáu i un o'r broceriaid sy'n rheoli'r rhaniad pwnc fynd i lawr heb effeithio ar geisiadau cleientiaid.

Daw hyn â ni yn ôl at y cyfaddawdu sydd eisoes yn gyfarwydd rhwng perfformiad a dibynadwyedd. Mae atgynhyrchu yn digwydd ar draul amser aros ychwanegol am gadarnhad (cydnabyddiaeth) gan ddilynwyr. Er, oherwydd ei fod yn rhedeg ochr yn ochr, mae gan ddyblygu i o leiaf dri nod yr un perfformiad â dau (gan anwybyddu'r cynnydd yn y defnydd o led band rhwydwaith).

Trwy ddefnyddio'r cynllun atgynhyrchu hwn, mae Kafka yn osgoi'r angen i ysgrifennu pob neges yn gorfforol ar ddisg gyda'r llawdriniaeth cysoni (). Bydd pob neges a anfonir gan y cynhyrchydd yn cael ei ysgrifennu i'r log rhaniad, ond fel y trafodwyd ym Mhennod 2, mae ysgrifennu at ffeil yn cael ei wneud i ddechrau yn byffer y system weithredu. Os yw'r neges hon yn cael ei hailadrodd i enghraifft arall o Kafka a'i bod yn ei chof, nid yw colli'r arweinydd yn golygu bod y neges ei hun wedi'i cholli - gellir ei chymryd drosodd gan replica cydamserol.
Gwrthod cyflawni'r llawdriniaeth cysoni () yn golygu y gall Kafka dderbyn negeseuon mor gyflym ag y gall eu hysgrifennu i'r cof. I'r gwrthwyneb, gorau po hiraf y gallwch chi osgoi fflysio cof i ddisg. Am y rheswm hwn, nid yw'n anghyffredin i froceriaid Kafka gael 64 GB neu fwy o gof. Mae'r defnydd cof hwn yn golygu y gall un enghraifft Kafka redeg yn hawdd ar gyflymder filoedd o weithiau'n gyflymach na brocer negeseuon traddodiadol.

Gellir hefyd ffurfweddu Kafka i gymhwyso'r llawdriniaeth cysoni () i becynnau neges. Gan fod popeth yn Kafka yn canolbwyntio ar becynnau, mewn gwirionedd mae'n gweithio'n eithaf da ar gyfer llawer o achosion defnydd ac mae'n offeryn defnyddiol i ddefnyddwyr sydd angen gwarantau cryf iawn. Daw llawer o berfformiad pur Kafka o'r negeseuon a anfonir at y brocer fel pecynnau a bod y negeseuon hyn yn cael eu darllen gan y brocer mewn blociau dilyniannol gan ddefnyddio sero copi gweithrediadau (gweithrediadau pan na chyflawnir y dasg o gopïo data o un maes cof i un arall). Mae'r olaf yn gynnydd mawr o ran perfformiad ac adnoddau a dim ond trwy ddefnyddio strwythur data log sylfaenol sy'n diffinio'r cynllun rhaniad y mae'n bosibl.

Mae perfformiad llawer gwell yn bosibl mewn clwstwr Kafka na chydag un brocer Kafka, oherwydd gall rhaniadau pwnc ehangu ar draws llawer o beiriannau ar wahân.

Canlyniadau

Yn y bennod hon, buom yn edrych ar sut mae pensaernïaeth Kafka yn ail-ddychmygu'r berthynas rhwng cleientiaid a broceriaid i ddarparu piblinell negeseuon hynod gadarn, gyda mewnbwn lawer gwaith yn fwy na brocer negeseuon confensiynol. Rydym wedi trafod y swyddogaethau y mae'n eu defnyddio i gyflawni hyn ac wedi edrych yn fyr ar saernïaeth y cymwysiadau sy'n darparu'r swyddogaeth hon. Yn y bennod nesaf, byddwn yn edrych ar broblemau cyffredin y mae angen i gymwysiadau sy'n seiliedig ar negeseuon eu datrys a thrafod strategaethau ar gyfer delio â nhw. Byddwn yn gorffen y bennod trwy amlinellu sut i siarad am dechnolegau negeseuon yn gyffredinol fel y gallwch werthuso eu haddasrwydd ar gyfer eich achosion defnydd.

Rhan wedi'i chyfieithu'n flaenorol: Deall broceriaid negeseuon. Dysgu mecaneg negeseuon gydag ActiveMQ a Kafka. Pennod 1

Cyfieithiad wedi'i wneud: tele.gg/canol_java

I'w barhau…

Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. Mewngofnodios gwelwch yn dda.

A ddefnyddir Kafka yn eich sefydliad?

Oes
Dim
Defnyddiwyd o'r blaen, yn awr ddim
Rydyn ni'n bwriadu defnyddio

Pleidleisiodd 38 o ddefnyddwyr. Ataliodd 8 o ddefnyddwyr.

Ffynhonnell: hab.com

Deall broceriaid negeseuon. Dysgu mecaneg negeseuon gydag ActiveMQ a Kafka. Pennod 3. Kafka