🥇Pagsabot sa mga broker sa mensahe. Pagkat-on sa mga mekaniko sa pagmemensahe sa ActiveMQ ug Kafka. Kapitulo 3. Kafka

Pagpadayon sa paghubad sa usa ka gamay nga libro:
Pagsabot sa mga Broker sa Mensahe
awtor: Jakub Korab, magmamantala: O'Reilly Media, Inc., petsa sa pagmantala: Hunyo 2017, ISBN: 9781492049296.

Nauna nga gihubad nga bahin: Pagsabut sa mga broker sa mensahe. Pagkat-on sa mga mekaniko sa pagmemensahe sa ActiveMQ ug Kafka. Kapitulo 1 Pasiuna

KAPITULO 3

Kafka

Ang Kafka gimugna sa LinkedIn aron makalikay sa pipila ka mga limitasyon sa tradisyonal nga mga tigpahibalo sa mensahe ug makalikay sa pag-set up ug daghang mga mensahero sa mensahe alang sa lain-laing punto-sa-punto nga mga interaksyon, nga gihulagway niini nga libro ubos sa "Pagtaas ug paggawas" sa panid 28 Mga kaso sa paggamit Ang LinkedIn sa kadaghanan nagsalig sa usa ka paagi nga pag-ingestion sa daghan kaayo nga mga datos, sama sa mga pag-klik sa panid ug mga log sa pag-access, samtang gitugotan gihapon kana nga datos nga magamit sa daghang mga sistema nga wala makaapekto sa produktibidad sa mga prodyuser o uban pang mga konsumedor. Sa tinuud, ang hinungdan nga naglungtad ang Kafka mao ang pagkuha sa klase sa arkitektura sa pagmemensahe nga gihulagway sa Universal Data Pipeline.

Tungod niining katapusang tumong, natural nga mitungha ang ubang mga kinahanglanon. Ang Kafka kinahanglan:

Pagmapaspas kaayo
Paghatag dugang nga bandwidth kung nagtrabaho uban ang mga mensahe
Suportahi ang Publisher-Subscriber ug Point-to-Point nga mga modelo
Ayaw paghinayhinay sa pagdugang sa mga konsumidor. Pananglitan, ang pasundayag sa pila ug ang hilisgutan sa ActiveMQ nag-us-os samtang ang gidaghanon sa mga konsumedor sa destinasyon modako.
Mahimong horizontally scalable; kung ang usa ka broker nga nagpadayon sa mga mensahe mahimo lamang kini sa labing taas nga katulin sa disk, nan makatarunganon nga molapas sa usa ka pananglitan sa broker aron madugangan ang pasundayag
Limitahi ang pag-access sa pagtipig ug pagkuha pag-usab sa mga mensahe

Aron makab-ot kining tanan, gisagop ni Kafka ang usa ka arkitektura nga nagbag-o sa mga tahas ug mga responsibilidad sa mga kliyente ug mga broker sa pagmemensahe. Ang modelo sa JMS mao ang kaayo broker oriented, diin ang broker mao ang responsable sa pag-apod-apod sa mga mensahe ug ang mga kliyente kinahanglan lamang nga mabalaka mahitungod sa pagpadala ug pagdawat sa mga mensahe. Ang Kafka, sa laing bahin, mao ang client-centric, uban sa kliyente nga nagkuha sa daghang mga bahin sa usa ka tradisyonal nga broker, sama sa patas nga pag-apod-apod sa may kalabutan nga mga mensahe ngadto sa mga konsumedor, baylo sa usa ka hilabihan ka paspas ug scalable nga broker. Alang sa mga tawo nga nagtrabaho sa tradisyonal nga mga sistema sa pagmemensahe, ang pagtrabaho kauban ang Kafka nanginahanglan usa ka sukaranan nga pagbag-o sa hunahuna.
Kini nga direksyon sa engineering misangpot sa paghimo sa usa ka imprastraktura sa pagmemensahe nga makahimo sa pagdugang sa throughput sa daghang mga order sa kadako kumpara sa usa ka naandan nga broker. Sama sa atong makita, kini nga pamaagi adunay mga trade-off, nga nagpasabot nga ang Kafka dili angay alang sa pipila ka mga matang sa mga workloads ug na-install nga software.

Nahiusa nga Destinasyon nga Modelo

Aron matuman ang mga kinahanglanon nga gihulagway sa ibabaw, ang Kafka naghiusa sa pag-publish-subscribe ug point-to-point nga pagmemensa sa ilawom sa usa ka matang sa destinasyon − hilisgutan. Makalibog kini sa mga tawo nga nagtrabaho sa mga sistema sa pagmemensahe, diin ang pulong nga "topic" nagtumong sa usa ka mekanismo sa pagsibya diin (gikan sa hilisgutan) ang pagbasa dili mapadayon. Ang mga hilisgutan sa Kafka kinahanglan nga isipon nga usa ka hybrid nga tipo sa destinasyon, ingon nga gipasabut sa pasiuna niini nga libro.

Alang sa nahabilin niini nga kapitulo, gawas kung klaro nga among gisulti kung dili, ang termino nga "topiko" magtumong sa usa ka hilisgutan sa Kafka.

Aron hingpit nga masabtan kung giunsa ang paggawi sa mga hilisgutan ug kung unsa ang mga garantiya nga gihatag niini, kinahanglan naton una nga tan-awon kung giunsa kini gipatuman sa Kafka.
Ang matag hilisgutan sa Kafka adunay kaugalingon nga log.
Ang mga prodyuser nga nagpadala mga mensahe sa Kafka nagsulat niini nga log, ug ang mga konsumedor nagbasa gikan sa log gamit ang mga pointer nga kanunay nga nagpadayon. Matag karon ug unya, gitangtang ni Kafka ang labing karaan nga mga bahin sa log, bisan kung ang mga mensahe sa mga bahin nabasa na o wala. Ang sentro nga bahin sa disenyo ni Kafka mao nga ang broker wala magtagad kung ang mga mensahe mabasa o dili - kana ang responsibilidad sa kliyente.

Ang mga termino nga "log" ug "pointer" wala makita sa Dokumentasyon sa Kafka. Kining iladong mga termino gigamit dinhi aron sa pagtabang sa pagsabot.

Kini nga modelo hingpit nga lahi sa ActiveMQ, diin ang mga mensahe gikan sa tanan nga mga pila gitipigan sa parehas nga log, ug gimarkahan sa broker ang mga mensahe nga natangtang pagkahuman nabasa.
Atong tun-an karon ug mas detalyado ug tan-awon ang log sa hilisgutan.
Ang Kafka log naglangkob sa daghang mga partisyon (Hulagway 3-1). Gigarantiyahan sa Kafka ang higpit nga pag-order sa matag partisyon. Kini nagpasabut nga ang mga mensahe nga gisulat sa partisyon sa usa ka piho nga han-ay basahon sa parehas nga pagkasunud. Ang matag partisyon gipatuman isip usa ka rolling log file nga adunay sulod usa ka subset (subset) sa tanang mensahe nga gipadala ngadto sa hilisgutan sa mga prodyuser niini. Ang gibuhat nga hilisgutan naglangkob, sa default, usa ka partisyon. Ang ideya sa mga partisyon mao ang sentro nga ideya sa Kafka alang sa horizontal scaling.

Hulagway 3-1. Mga partisyon sa Kafka

Kung ang usa ka prodyuser nagpadala usa ka mensahe sa usa ka hilisgutan sa Kafka, kini ang magdesisyon kung asa nga partisyon ipadala ang mensahe. Atong tan-awon kini sa mas detalyado sa ulahi.

Pagbasa sa mga mensahe

Ang kliyente nga gustong mobasa sa mga mensahe nagdumala sa usa ka ginganlan nga pointer nga gitawag grupo sa mga konsumidor, nga nagpunting sa offset mga mensahe sa partisyon. Ang offset usa ka incremental nga posisyon nga magsugod sa 0 sa pagsugod sa partition. Kini nga grupo sa mga konsumidor, nga gi-refer sa API pinaagi sa user-defined group_id, katumbas sa usa ka lohikal nga konsumidor o sistema.

Kadaghanan sa mga sistema sa pagmemensahe nagbasa sa datos gikan sa destinasyon gamit ang daghang mga higayon ug mga hilo aron maproseso ang mga mensahe nga managsama. Sa ingon, kasagaran adunay daghang mga higayon sa mga konsumedor nga nag-ambit sa parehas nga grupo sa mga konsumedor.

Ang problema sa pagbasa mahimong irepresentar sa mosunod:

Ang hilisgutan adunay daghang mga partisyon
Daghang mga grupo sa mga konsumedor ang mahimong mogamit usa ka hilisgutan sa parehas nga oras
Ang usa ka grupo sa mga konsumedor mahimong adunay daghang lahi nga mga higayon

Kini usa ka dili trivial nga daghang-sa-daghan nga problema. Aron masabtan kung giunsa pagdumala sa Kafka ang mga relasyon tali sa mga grupo sa mga konsumidor, mga higayon sa mga konsumedor, ug mga partisyon, atong tan-awon ang sunod-sunod nga labi ka komplikado nga mga senaryo sa pagbasa.

Mga konsumedor ug grupo sa mga konsumidor

Atong kuhaon isip sinugdanan ang usa ka hilisgutan nga adunay usa ka partisyon (Hulagway 3-2).

Hulagway 3-2. Gibasa sa konsumedor gikan sa partisyon

Kung ang usa ka pananglitan sa konsumidor nagkonektar sa kaugalingon nga grupo_id sa kini nga hilisgutan, gihatagan kini usa ka gibasa nga partisyon ug usa ka offset sa kana nga partisyon. Ang posisyon niini nga offset gi-configure sa kliyente isip pointer sa pinakabag-o nga posisyon (labing bag-o nga mensahe) o pinakaunang posisyon (labing karaan nga mensahe). Ang mga hangyo sa konsyumer (mga botohan) nga mga mensahe gikan sa hilisgutan, nga hinungdan nga kini sunodsunod nga pagbasa gikan sa log.
Ang offset nga posisyon kanunay nga gitugyan balik sa Kafka ug gitipigan isip mga mensahe sa usa ka internal nga hilisgutan _consumer_offsets. Ang pagbasa sa mga mensahe wala gihapon mapapas, dili sama sa usa ka regular nga broker, ug ang kliyente mahimong i-rewind ang offset aron maproseso pag-usab ang natan-aw na nga mga mensahe.

Kung ang usa ka ikaduha nga lohikal nga konsumidor nagkonektar gamit ang usa ka lahi nga grupo_id, nagdumala kini usa ka ikaduha nga pointer nga independente sa una (Hulagway 3-3). Sa ingon, ang usa ka hilisgutan sa Kafka naglihok sama sa usa ka pila diin adunay usa ka konsumedor ug sama sa usa ka normal nga publish-subscribe (pub-sub) nga hilisgutan nga gi-subscribe sa daghang mga konsumedor, uban ang dugang nga benepisyo nga ang tanan nga mga mensahe gitipigan ug mahimong maproseso sa daghang mga higayon.

Hulagway 3-3. Duha ka mga konsumidor sa lainlaing mga grupo sa mga konsumedor nagbasa gikan sa parehas nga partisyon

Mga konsumidor sa usa ka grupo sa mga konsumidor

Kung ang usa ka pananglitan sa konsyumer nagbasa sa datos gikan sa usa ka partisyon, kini adunay bug-os nga kontrol sa pointer ug nagproseso sa mga mensahe sama sa gihulagway sa miaging seksyon.
Kung daghang mga higayon sa mga konsumedor ang konektado sa parehas nga grupo_id sa usa ka hilisgutan nga adunay usa ka partisyon, nan ang higayon nga konektado sa katapusan hatagan kontrol sa pointer ug gikan nianang higayona makadawat kini sa tanan nga mga mensahe (Hulagway 3-4).

Hulagway 3-4. Duha ka mga konsumidor sa parehas nga grupo sa mga konsumedor nagbasa gikan sa parehas nga partisyon

Kini nga paagi sa pagproseso, diin ang gidaghanon sa mga kaso sa konsyumer milapas sa gidaghanon sa mga partisyon, mahimong isipon nga usa ka matang sa eksklusibong konsumidor. Mahimong mapuslanon kini kung kinahanglan nimo ang "aktibo-passive" (o "mainit-init") nga clustering sa imong mga higayon sa mga konsumidor, bisan kung ang pagpadagan sa daghang mga konsumedor nga managsama ("aktibo-aktibo" o "init-init") labi ka kasagaran kaysa sa mga konsumidor. Sa standby.

Kini nga pamatasan sa pag-apod-apod sa mensahe nga gihulagway sa taas mahimo’g makapahingangha kung itandi kung giunsa ang usa ka normal nga pila sa JMS naglihok. Sa kini nga modelo, ang mga mensahe nga gipadala sa pila ipanghatag parehas sa duha nga mga konsumedor.

Kasagaran, kung maghimo kami daghang mga higayon sa mga konsumedor, buhaton namon kini aron maproseso ang mga mensahe nga managsama, o aron madugangan ang katulin sa pagbasa, o aron madugangan ang kalig-on sa proseso sa pagbasa. Tungod kay usa ra ka higayon sa mga konsumedor ang makabasa sa datos gikan sa usa ka partisyon matag higayon, giunsa kini pagkab-ot sa Kafka?

Usa ka paagi sa pagbuhat niini mao ang paggamit sa usa ka pananglitan sa konsyumer aron mabasa ang tanan nga mga mensahe ug ipasa kini sa thread pool. Samtang kini nga pamaagi nagdugang sa pagproseso sa throughput, kini nagdugang sa pagkakomplikado sa lohika sa mga konsumedor ug wala’y mahimo aron madugangan ang kalig-on sa sistema sa pagbasa. Kung ang usa ka kopya sa konsumedor mawala tungod sa pagkapakyas sa kuryente o parehas nga panghitabo, unya ang pag-undang mohunong.

Ang kanonikal nga paagi sa pagsulbad niini nga problema sa Kafka mao ang paggamit sa bОdugang nga mga partisyon.

Pagbahinbahin

Ang mga partisyon mao ang panguna nga mekanismo alang sa pagparis sa pagbasa ug pag-scale sa usa ka hilisgutan lapas sa bandwidth sa usa ka pananglitan sa broker. Aron mas masabtan kini, atong tagdon ang usa ka sitwasyon diin adunay usa ka hilisgutan nga adunay duha ka partisyon ug usa ka konsumidor nag-subscribe niini nga hilisgutan (Hulagway 3-5).

Hulagway 3-5. Usa ka konsumidor nagbasa gikan sa daghang mga partisyon

Niini nga senaryo, ang konsumidor gihatagan og kontrol sa mga punto nga katumbas sa grupo_id niini sa duha ka partisyon ug magsugod sa pagbasa sa mga mensahe gikan sa duha ka partisyon.
Kung ang usa ka dugang nga konsumidor alang sa parehas nga grupo_id idugang sa kini nga hilisgutan, gi-relocate ni Kafka ang usa sa mga partisyon gikan sa una hangtod sa ikaduha nga konsumedor. Pagkahuman niana, ang matag higayon sa konsumedor magbasa gikan sa usa ka partisyon sa hilisgutan (Hulagway 3-6).

Aron masiguro nga ang mga mensahe giproseso nga managsama sa 20 nga mga hilo, kinahanglan nimo ang labing menos 20 nga mga partisyon. Kung adunay gamay nga mga partisyon, mahibilin ka sa mga konsumedor nga wala’y trabaho, sama sa gihulagway sa sayo pa sa paghisgot sa mga eksklusibo nga mga konsumedor.

Hulagway 3-6. Duha ka mga konsumidor sa parehas nga grupo sa mga konsumedor nagbasa gikan sa lainlaing mga partisyon

Kini nga laraw makapakunhod pag-ayo sa pagkakomplikado sa Kafka broker kumpara sa pag-apod-apod sa mensahe nga gikinahanglan aron mapadayon ang pila sa JMS. Dinhi dili ka kinahanglan mabalaka mahitungod sa mosunod nga mga punto:

Kinsa nga konsumidor ang makadawat sa sunod nga mensahe, base sa round-robin nga alokasyon, kasamtangan nga kapasidad sa prefetch buffers, o sa nangaging mga mensahe (sama sa mga grupo sa mensahe sa JMS).
Unsang mga mensahe ang gipadala kung kinsa ang mga konsumedor ug kung kinahanglan ba silang ipadala pag-usab kung adunay kapakyasan.

Ang kinahanglan nga buhaton sa Kafka broker mao ang pagpasa sa mga mensahe nga sunud-sunod sa konsumedor kung gihangyo sila sa ulahi.

Bisan pa, ang mga kinahanglanon alang sa pagparis sa pag-proofread ug pagpadala pag-usab sa mga napakyas nga mga mensahe dili mawala - ang responsibilidad alang kanila ipasa lang gikan sa broker ngadto sa kliyente. Kini nagpasabut nga sila kinahanglan nga tagdon sa imong code.

Pagpadala og mga mensahe

Responsibilidad sa prodyuser sa maong mensahe ang pagdesisyon kung asa nga partisyon ipadala ang mensahe. Aron masabtan ang mekanismo diin kini nahimo, kinahanglan una natong tagdon kung unsa gyud ang atong gipadala.

Samtang sa JMS naggamit kami usa ka istruktura sa mensahe nga adunay metadata (mga ulohan ug mga kabtangan) ug usa ka lawas nga adunay sulud nga payload (payload), sa Kafka ang mensahe mao ang pares nga "key-value". Ang payload sa mensahe gipadala isip usa ka bili. Ang yawe, sa laing bahin, gigamit sa kadaghanan alang sa pagbahin ug kinahanglan nga adunay sulod negosyo nga lohika piho nga yawearon ibutang ang mga may kalabutan nga mga mensahe sa parehas nga partisyon.

Sa Kapitulo 2, among gihisgutan ang senaryo sa pagpusta sa online diin ang mga may kalabutan nga mga panghitabo kinahanglan nga maproseso sa pagkasunud-sunod sa usa ka konsumedor:

Ang user account gi-configure.
Ang kwarta gi-kredito sa account.
Ang usa ka pusta gihimo nga nag-withdraw sa kwarta gikan sa account.

Kung ang matag panghitabo usa ka mensahe nga gi-post sa usa ka hilisgutan, nan ang natural nga yawe mao ang account ID.
Kung ang usa ka mensahe gipadala gamit ang Kafka Producer API, gipasa kini sa usa ka partition function nga, gihatagan ang mensahe ug ang karon nga kahimtang sa Kafka cluster, ibalik ang ID sa partition diin kinahanglan ipadala ang mensahe. Kini nga bahin gipatuman sa Java pinaagi sa Partitioner interface.

Kini nga interface ingon niini:

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

Ang pagpatuman sa Partitioner naggamit sa default nga general-purpose hashing algorithm sa ibabaw sa yawe aron mahibal-an ang partition, o round-robin kung walay key nga gitino. Kini nga default nga bili molihok nga maayo sa kadaghanan nga mga kaso. Bisan pa, sa umaabot gusto nimong isulat ang imong kaugalingon.

Pagsulat sa imong kaugalingon nga estratehiya sa pagbahin

Atong tan-awon ang usa ka pananglitan kung diin gusto nimo ipadala ang metadata kauban ang payload sa mensahe. Ang payload sa among panig-ingnan usa ka panudlo sa paghimo og deposito sa account sa dula. Ang instruksyon usa ka butang nga gusto namo nga garantiya nga dili mabag-o sa transmission ug gusto nga makasiguro nga usa ra ka kasaligan nga upstream nga sistema ang makasugod sa kana nga panudlo. Sa kini nga kaso, ang mga sistema sa pagpadala ug pagdawat nagkauyon sa paggamit sa usa ka pirma aron mapamatud-an ang mensahe.
Sa normal nga JMS, among gihubit ang usa ka "pirma sa mensahe" nga kabtangan ug idugang kini sa mensahe. Bisan pa, ang Kafka wala maghatag kanato og mekanismo sa pagpasa sa metadata, usa lamang ka yawe ug usa ka bili.

Tungod kay ang kantidad usa ka payload sa pagbalhin sa bangko kansang integridad gusto namon nga mapreserbar, wala kami kapilian gawas sa paghubit sa istruktura sa datos nga gamiton sa yawe. Sa pag-ingon nga kinahanglan namon ang usa ka ID sa account alang sa pagbahin, tungod kay ang tanan nga mga mensahe nga may kalabutan sa usa ka account kinahanglan nga maproseso sa han-ay, maghimo kami sa mosunod nga istruktura sa JSON:

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

Tungod kay ang kantidad sa pirma magkalainlain depende sa payload, ang default nga estratehiya sa hashing sa interface sa Partitioner dili kasaligan nga mga mensahe nga may kalabotan sa grupo. Busa, kinahanglan namong isulat ang among kaugalingon nga estratehiya nga mag-parse niini nga yawe ug magbahin sa kantidad sa accountId.

Ang Kafka naglakip sa mga checksum aron mahibal-an ang korapsyon sa mga mensahe sa tindahan ug adunay usa ka bug-os nga hugpong sa mga bahin sa seguridad. Bisan pa, ang mga kinahanglanon nga piho sa industriya, sama sa usa sa ibabaw, usahay makita.

Ang estratehiya sa pagbahin sa user kinahanglan nga masiguro nga ang tanan nga may kalabutan nga mga mensahe mahuman sa parehas nga partisyon. Samtang kini daw yano, ang kinahanglanon mahimong komplikado pinaagi sa kamahinungdanon sa pag-order sa mga may kalabutan nga mga mensahe ug kung giunsa ang pag-ayo sa gidaghanon sa mga partisyon sa usa ka hilisgutan.

Ang gidaghanon sa mga partisyon sa usa ka hilisgutan mahimong mausab sa paglabay sa panahon, tungod kay kini mahimong idugang kung ang trapiko molapas sa unang mga gilauman. Sa ingon, ang mga yawe sa mensahe mahimo nga kauban sa partisyon nga orihinal nga gipadala, nga nagpasabut nga usa ka piraso sa estado nga ipaambit tali sa mga higayon sa prodyuser.

Laing butang nga angay tagdon mao ang parehas nga pag-apod-apod sa mga mensahe sa mga partisyon. Kasagaran, ang mga yawe dili parehas nga ipang-apod-apod sa mga mensahe, ug ang hash function dili makagarantiya sa patas nga pag-apod-apod sa mga mensahe alang sa gamay nga hugpong sa mga yawe.
Importante nga timan-an nga bisan unsa pa ang imong pilion sa pagbahin sa mga mensahe, ang separator mismo mahimong kinahanglan nga gamiton pag-usab.

Hunahunaa ang kinahanglanon sa pagkopya sa datos tali sa Kafka clusters sa lain-laing geographic nga mga lokasyon. Alang niini nga katuyoan, ang Kafka adunay usa ka himan sa linya sa command nga gitawag og MirrorMaker, nga gigamit sa pagbasa sa mga mensahe gikan sa usa ka cluster ug pagbalhin niini ngadto sa lain.

Kinahanglang masabtan sa MirrorMaker ang mga yawe sa gisubli nga hilisgutan aron mapadayon ang relatibong pagkahan-ay tali sa mga mensahe kung magkopya tali sa mga pungpong, tungod kay ang gidaghanon sa mga partisyon alang sa kana nga hilisgutan mahimo’g dili parehas sa duha nga mga pungpong.

Talagsa ra ang mga pamaagi sa custom partitioning, tungod kay ang default hashing o round robin naglihok nga maayo sa kadaghanan nga mga senaryo. Bisan pa, kung kinahanglan nimo ang lig-on nga mga garantiya sa pag-order o kinahanglan nga makuha ang metadata gikan sa mga payload, nan ang pagbahin usa ka butang nga kinahanglan nimong tan-awon pag-ayo.

Ang scalability ug performance nga mga benepisyo sa Kafka naggikan sa pagbalhin sa pipila ka mga responsibilidad sa tradisyonal nga broker ngadto sa kliyente. Sa kini nga kaso, usa ka desisyon ang gihimo sa pag-apod-apod sa mga potensyal nga may kalabutan nga mga mensahe sa daghang mga konsumedor nga managsama nga nagtrabaho.

Ang mga JMS broker kinahanglan usab nga atubangon ang ingon nga mga kinahanglanon. Makapainteres, ang mekanismo sa pagpadala sa may kalabutan nga mga mensahe ngadto sa samang konsumidor, nga gipatuman pinaagi sa JMS Message Groups (usa ka kalainan sa sticky load balancing (SLB) nga estratehiya), nagkinahanglan usab sa nagpadala sa pagmarka sa mga mensahe ingon nga may kalabutan. Sa kaso sa JMS, ang broker ang responsable sa pagpadala niini nga grupo sa mga may kalabutan nga mga mensahe ngadto sa usa ka konsyumer gikan sa daghan, ug pagbalhin sa pagpanag-iya sa grupo kung ang konsumidor mahulog.

Mga Kasabutan sa Producer

Ang pagbahin dili lamang ang butang nga ikonsiderar kung magpadala mga mensahe. Atong tan-awon ang send() nga mga pamaagi sa Producer nga klase sa Java API:

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

Kinahanglan nga hinumdoman dayon nga ang duha nga mga pamaagi mobalik sa Umaabot, nga nagpaila nga ang pagpadala nga operasyon wala dayon gihimo. Ang resulta mao nga ang usa ka mensahe (ProducerRecord) gisulat sa send buffer alang sa matag aktibong partisyon ug gipadala ngadto sa broker isip background thread sa Kafka client library. Samtang kini naghimo sa mga butang nga hilabihan ka paspas, kini nagpasabot nga ang usa ka walay kasinatian nga aplikasyon mahimong mawad-an sa mga mensahe kung ang proseso niini mahunong.

Sama sa kanunay, adunay usa ka paagi aron mahimo nga mas kasaligan ang operasyon sa pagpadala sa gasto sa pasundayag. Ang gidak-on niini nga buffer mahimong itakda sa 0, ug ang pagpadala sa thread sa aplikasyon mapugos sa paghulat hangtud makompleto ang pagbalhin sa mensahe ngadto sa broker, sama sa mosunod:

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

Dugang pa bahin sa pagbasa sa mga mensahe

Ang pagbasa sa mga mensahe adunay dugang nga mga pagkakomplikado nga kinahanglan nga pangagpas. Dili sama sa JMS API, nga makadagan sa usa ka tigpaminaw sa mensahe isip tubag sa usa ka mensahe, ang consumer Kafka lang polls. Atong tan-awon pag-ayo ang pamaagi poll()gigamit alang niini nga katuyoan:

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

Ang pagbalik nga kantidad sa pamaagi usa ka sulud nga istruktura nga adunay daghang mga butang rekord sa konsumidor gikan sa posibleng daghang partisyon. rekord sa konsumidor mao mismo ang usa ka butang nga naghupot alang sa usa ka pares nga key-value nga adunay kaubang metadata, sama sa partisyon diin kini gikuha.

Sama sa gihisgutan sa Kapitulo 2, kinahanglan natong hinumdoman kung unsa ang mahitabo sa mga mensahe human kini malampuson o dili malampuson nga naproseso, pananglitan, kung ang kliyente dili makahimo sa pagproseso sa mensahe o kung kini mohunong. Sa JMS, kini gidumala pinaagi sa acknowledgement mode. Mahimong tangtangon sa broker ang malampuson nga naproseso nga mensahe, o ihatud pag-usab ang hilaw o peke nga mensahe (nagtuo nga gigamit ang mga transaksyon).
Lahi kaayo ang pagtrabaho sa Kafka. Ang mga mensahe dili matangtang sa broker pagkahuman sa pag-proofread, ug kung unsa ang mahitabo sa kapakyasan mao ang responsibilidad sa code sa pag-proofread mismo.

Sama sa among giingon, ang grupo sa mga konsumedor nalangkit sa offset sa log. Ang posisyon sa log nga nalangkit niini nga offset katumbas sa sunod nga mensahe nga ipagawas agig tubag poll(). Ang punto sa oras kung kanus-a kini nga pagtaas sa offset hinungdanon alang sa pagbasa.

Pagbalik sa modelo sa pagbasa nga gihisgutan sa sayo pa, ang pagproseso sa mensahe naglangkob sa tulo ka yugto:

Pagkuha og mensahe para sa pagbasa.
Iproseso ang mensahe.
Kumpirma ang mensahe.

Ang konsumidor sa Kafka adunay usa ka kapilian sa pag-configure enable.auto.commit. Kini usa ka kanunay nga gigamit nga default setting, sama sa kasagaran sa mga setting nga adunay sulud nga pulong nga "auto".

Sa wala pa ang Kafka 0.10, ang usa ka kliyente nga naggamit niini nga kapilian magpadala sa offset sa katapusang mensahe nga gibasa sa sunod nga tawag poll() human sa pagproseso. Nagpasabot kini nga ang bisan unsang mga mensahe nga nakuha na mahimong maproseso pag-usab kung giproseso na kini sa kliyente apan wala damha nga naguba sa wala pa motawag. poll(). Tungod kay ang broker wala magtipig sa bisan unsang estado kung pila ka beses nga nabasa ang usa ka mensahe, ang sunod nga konsumedor nga nagkuha sa kana nga mensahe dili mahibal-an kung unsa ang daotan nga nahitabo. Kini nga kinaiya kay pseudo-transaktional. Ang offset gihimo lamang kung ang mensahe malampuson nga naproseso, apan kung ang kliyente nag-abort, ang broker magpadala pag-usab sa samang mensahe ngadto sa laing kliyente. Kini nga pamatasan nahiuyon sa garantiya sa paghatud sa mensahe "labing menos kausa".

Sa Kafka 0.10, ang code sa kliyente giusab aron ang commit ma-trigger matag karon ug unya sa librarya sa kliyente, ingon nga gi-configure. auto.commit.interval.ms. Kini nga kinaiya anaa sa taliwala sa JMS AUTO_ACKNOWLEDGE ug DUPS_OK_ACKNOWLEDGE mode. Kung gigamit ang autocommit, ang mga mensahe mahimong mabuhat bisan pa kung kini tinuod nga giproseso - kini mahimong mahitabo sa kaso sa usa ka hinay nga konsumidor. Kung ang usa ka konsumedor gi-abort, ang mga mensahe makuha sa sunod nga konsumidor, sugod sa gipasalig nga posisyon, nga mahimong moresulta sa usa ka wala nga mensahe. Sa kini nga kaso, wala mawala sa Kafka ang mga mensahe, ang code sa pagbasa wala lang magproseso niini.

Kini nga mode adunay parehas nga saad sama sa bersyon 0.9: ang mga mensahe mahimong maproseso, apan kung kini mapakyas, ang offset mahimong dili mahimo, nga mahimo’g hinungdan nga doble ang paghatud. Ang daghang mga mensahe nga imong makuha kung gipatuman poll(), mas daghan kini nga problema.

Sama sa gihisgutan sa "Pagbasa sa mga Mensahe gikan sa usa ka Pila" sa panid 21, wala'y butang nga usa ka higayon nga paghatud sa usa ka mensahe sa usa ka sistema sa pagmemensahe kung ang mga paagi sa pagkapakyas gikonsiderar.

Sa Kafka, adunay duha ka paagi sa pag-commit (pag-commit) og offset (offset): awtomatiko ug mano-mano. Sa duha ka mga kaso, ang mga mensahe mahimong maproseso sa makadaghang higayon kung ang mensahe giproseso apan napakyas sa wala pa ang commit. Mahimo usab nimo pilion nga dili iproseso ang mensahe kung ang commit nahitabo sa background ug ang imong code nahuman sa wala pa kini maproseso (tingali sa Kafka 0.9 ug sa sayo pa).

Mahimo nimong kontrolon ang manual offset commit nga proseso sa Kafka consumer API pinaagi sa pagtakda sa parameter enable.auto.commit sa bakak ug dayag nga pagtawag sa usa sa mosunod nga mga pamaagi:

void commitSync();
void commitAsync();

Kung gusto nimo iproseso ang mensahe "labing menos kausa", kinahanglan nimo nga i-commit ang offset nga mano-mano sa commitSync()pinaagi sa pagpatuman niini nga sugo diha-diha dayon human sa pagproseso sa mga mensahe.

Kini nga mga pamaagi wala magtugot sa mga mensahe nga ilhon sa dili pa kini maproseso, apan wala sila'y mahimo aron mawagtang ang potensyal nga mga paglangan sa pagproseso samtang naghatag sa dagway sa transaksyon. Walay mga transaksyon sa Kafka. Ang kliyente walay abilidad sa pagbuhat sa mosunod:

Awtomatikong ibalik ang usa ka peke nga mensahe. Ang mga konsumedor mismo kinahanglan nga magdumala sa mga eksepsiyon nga naggikan sa mga problema nga kargamento ug mga pagkawala sa backend, tungod kay dili sila makasalig sa broker nga maghatud pag-usab sa mga mensahe.
Pagpadala mga mensahe sa daghang mga hilisgutan sa usa ka atomic nga operasyon. Sama sa atong makita sa dili madugay, ang pagkontrol sa lainlaing mga hilisgutan ug mga partisyon mahimong magpuyo sa lainlaing mga makina sa Kafka cluster nga wala mag-coordinate sa mga transaksyon kung ipadala. Sa panahon sa pagsulat niini, pipila ka trabaho ang nahimo aron mahimo kini nga posible sa KIP-98.
Iuban ang pagbasa sa usa ka mensahe gikan sa usa ka hilisgutan sa pagpadala sa lain nga mensahe sa lain nga hilisgutan. Pag-usab, ang arkitektura sa Kafka nagdepende sa daghang mga independente nga makina nga nagdagan ingon usa ka bus ug wala’y pagsulay nga gihimo aron itago kini. Pananglitan, walay mga sangkap sa API nga magtugot kanimo sa pag-link konsumidor и Taghimo sa usa ka transaksyon. Sa JMS, kini gihatag sa butang Sesyongikan diin gilalang MessageProducers и Mensahe sa mga Konsyumer.

Kung dili kita makasalig sa mga transaksyon, unsaon nato paghatag og mga semantiko nga mas duol sa gihatag sa tradisyonal nga mga sistema sa pagmemensahe?

Kung adunay posibilidad nga ang offset sa konsumedor mahimong motaas sa wala pa maproseso ang mensahe, sama sa panahon sa pagkahagsa sa mga konsumedor, nan ang konsumedor wala’y paagi nga mahibal-an kung ang grupo sa mga konsumedor niini napakyas sa mensahe sa dihang gi-assign kini nga partition. Mao nga ang usa ka estratehiya mao ang pag-rewind sa offset sa miaging posisyon. Ang Kafka consumer API naghatag sa mosunod nga mga pamaagi alang niini:

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

Paagi pangitaa () mahimong gamiton sa pamaagi
offsetsForTimes(Mapa timestampToSearch) sa pag-rewind sa usa ka estado sa usa ka piho nga punto sa nangagi.

Sa tinuud, ang paggamit niini nga pamaagi nagpasabut nga lagmit nga ang pipila ka mga mensahe nga giproseso kaniadto mabasa ug maproseso pag-usab. Aron malikayan kini, mahimo natong gamiton ang idempotent nga pagbasa, sama sa gihulagway sa Kapitulo 4, aron masubay ang natan-aw na nga mga mensahe ug mawagtang ang mga duplicate.

Sa laing bahin, ang imong kodigo sa konsyumer mahimong huptan nga yano, basta ang pagkawala sa mensahe o pagkopya madawat. Kung gikonsiderar namon ang mga kaso sa paggamit diin ang Kafka kasagarang gigamit, sama sa pagdumala sa mga panghitabo sa log, sukatan, pagsubay sa pag-klik, ug uban pa, among nasabtan nga ang pagkawala sa indibidwal nga mga mensahe dili tingali adunay hinungdanon nga epekto sa palibot nga mga aplikasyon. Sa ingon nga mga kaso, ang mga default nga kantidad hingpit nga madawat. Sa laing bahin, kung ang imong aplikasyon kinahanglan magpadala mga bayad, kinahanglan nimo nga ampingan pag-ayo ang matag indibidwal nga mensahe. Kini tanan moabut sa konteksto.

Ang personal nga mga obserbasyon nagpakita nga samtang ang intensity sa mga mensahe nagdugang, ang bili sa matag indibidwal nga mensahe mikunhod. Ang dagkong mga mensahe lagmit nga bililhon kung tan-awon sa usa ka aggregated nga porma.

Taas nga Availability

Ang pamaagi ni Kafka sa taas nga pagkaanaa lahi kaayo sa pamaagi sa ActiveMQ. Gidisenyo ang Kafka sa palibot sa mga scale-out cluster diin ang tanan nga mga higayon sa broker makadawat ug nag-apod-apod sa mga mensahe sa parehas nga oras.

Ang usa ka Kafka cluster naglangkob sa daghang mga higayon sa broker nga nagdagan sa lainlaing mga server. Gidisenyo ang Kafka nga modagan sa ordinaryo nga standalone nga hardware, diin ang matag node adunay kaugalingon nga gipahinungod nga pagtipig. Dili girekomenda ang paggamit sa network attached storage (SAN) tungod kay ang daghang mga compute node mahimong makigkompetensya sa oras.Ыe storage interval ug paghimo og mga panagbangi.

Si Kafka nga kanunay sa sistema. Daghang mga dagkong tiggamit sa Kafka ang wala magsira sa ilang mga cluster ug ang software kanunay nga nag-update sa usa ka sunod-sunod nga pagsugod. Kini makab-ot pinaagi sa paggarantiya sa pagkaangay sa miaging bersyon alang sa mga mensahe ug mga interaksyon tali sa mga brokers.

Ang mga broker nga konektado sa usa ka cluster sa server Tigbantay sa Zoo, nga naglihok isip usa ka rehistro sa datos sa pagsumpo ug gigamit sa pag-coordinate sa mga tahas sa matag broker. Ang ZooKeeper mismo usa ka giapod-apod nga sistema nga naghatag taas nga magamit pinaagi sa pagkopya sa kasayuran pinaagi sa pag-establisar korum.

Sa base nga kaso, usa ka hilisgutan ang gihimo sa usa ka Kafka cluster nga adunay mga mosunod nga kabtangan:

Ang gidaghanon sa mga partisyon. Sama sa gihisgutan sa sayo pa, ang eksaktong bili nga gigamit dinhi nagdepende sa gitinguha nga lebel sa parallel nga pagbasa.
Ang replication factor (factor) nagtino kung pila ang broker nga mga instance sa cluster ang kinahanglan adunay mga log para niini nga partition.

Gamit ang ZooKeepers alang sa koordinasyon, ang Kafka misulay sa patas nga pag-apod-apod sa mga bag-ong partisyon sa mga broker sa cluster. Gihimo kini sa usa ka higayon nga naglihok isip usa ka Controller.

Sa runtime alang sa matag partisyon sa hilisgutan Tigdumala paghatag og mga tahas sa usa ka broker lider (lider, agalon, presenter) ug mga sumusunod (mga sumusunod, mga ulipon, mga sakop). Ang broker, nga naglihok isip lider niini nga partisyon, maoy responsable sa pagdawat sa tanang mensahe nga gipadala niini sa mga prodyuser ug pag-apod-apod sa mga mensahe ngadto sa mga konsumidor. Kung ang mga mensahe gipadala sa usa ka partisyon sa hilisgutan, kini gisundog sa tanan nga mga node sa broker nga naglihok ingon mga sumusunod sa kana nga partisyon. Ang matag node nga adunay mga log alang sa usa ka partisyon gitawag replika. Ang usa ka broker mahimong molihok isip usa ka lider alang sa pipila nga mga partisyon ug ingon usa ka sumusunod sa uban.

Ang usa ka sumusunod nga naglangkob sa tanan nga mga mensahe nga gihuptan sa lider gitawag dungan nga replika (usa ka replica nga naa sa usa ka synchronized nga estado, in-sync nga replika). Kung ang usa ka broker nga naglihok isip usa ka lider alang sa usa ka partisyon moubos, ang bisan kinsa nga broker nga labing bag-o o na-synchronize alang sa kana nga partisyon mahimong mopuli sa papel sa lider. Kini usa ka talagsaon nga malungtaron nga disenyo.

Kabahin sa configuration sa producer mao ang parameter acks, nga nagtino kung pila ka mga replika ang kinahanglan nga moila (ila) nga resibo sa usa ka mensahe sa dili pa magpadayon ang pagpadala sa thread sa aplikasyon: 0, 1, o tanan. Kung gitakda sa sa tanan nga mga, unya kung ang usa ka mensahe madawat, ang lider magpadala usa ka kumpirmasyon balik sa prodyuser sa diha nga kini makadawat mga kumpirmasyon (pag-ila) sa rekord gikan sa daghang mga cue (lakip ang iyang kaugalingon) nga gipasabut sa setting sa hilisgutan min.insync.replicas (default 1). Kung ang mensahe dili malampuson nga makopya, nan ang prodyuser magbutang usa ka eksepsiyon sa aplikasyon (Dili Igo nga mga Replika o Dili Igo nga mga ReplicasPagkatapos).

Ang usa ka tipikal nga configuration nagmugna og usa ka hilisgutan nga adunay usa ka replication factor sa 3 (1 leader, 2 followers matag partition) ug ang parameter min.insync.replicas gitakda sa 2. Sa kini nga kaso, ang cluster magtugot sa usa sa mga broker nga nagdumala sa partition sa hilisgutan nga dili maapektuhan ang mga aplikasyon sa kliyente.

Kini nagdala kanato balik sa pamilyar na nga trade-off tali sa performance ug kasaligan. Ang pagkopya mahitabo sa gasto sa dugang nga oras sa paghulat alang sa mga pagkumpirma (pag-ila) gikan sa mga sumusunod. Bisan pa, tungod kay kini nagdagan nga managsama, ang pagkopya sa labing menos tulo ka mga node adunay parehas nga pasundayag sa duha (wala gibalewala ang pagtaas sa paggamit sa bandwidth sa network).

Pinaagi sa paggamit niini nga pamaagi sa pagkopya, ang Kafka maalamon nga naglikay sa panginahanglan sa pisikal nga pagsulat sa matag mensahe ngadto sa disk nga adunay operasyon. dungan(). Ang matag mensahe nga gipadala sa prodyuser isulat sa partition log, apan sama sa gihisgutan sa Kapitulo 2, ang pagsulat sa usa ka file sa sinugdan gihimo sa buffer sa operating system. Kung kini nga mensahe gisundog sa lain nga pananglitan sa Kafka ug naa sa panumduman niini, ang pagkawala sa lider wala magpasabut nga ang mensahe mismo nawala - mahimo kini nga makuha sa usa ka gi-synchronize nga kopya.
Pagdumili sa pagbuhat sa operasyon dungan() nagpasabot nga ang Kafka makadawat og mga mensahe sa labing paspas nga pagsulat niini sa memorya. Sa kasukwahi, kung mas dugay nimo malikayan ang pag-flush sa memorya sa disk, mas maayo. Tungod niini nga rason, kasagaran alang sa Kafka brokers nga gigahin 64 GB o labaw pa sa memorya. Kini nga paggamit sa panumduman nagpasabot nga ang usa ka kaso sa Kafka dali nga modagan sa katulin sa liboan ka beses nga mas paspas kaysa usa ka tradisyonal nga broker sa mensahe.

Ang Kafka mahimo usab nga ma-configure aron magamit ang operasyon dungan() sa mga pakete sa mensahe. Tungod kay ang tanan sa Kafka kay package-oriented, sa aktuwal kini nagtrabaho nga maayo alang sa daghang mga kaso sa paggamit ug usa ka mapuslanon nga himan alang sa mga tiggamit nga nanginahanglan lig-on nga mga garantiya. Kadaghanan sa puro nga pasundayag sa Kafka naggikan sa mga mensahe nga gipadala sa broker ingon mga pakete ug nga kini nga mga mensahe gibasa gikan sa broker sa sunud-sunod nga mga bloke gamit ang zero nga kopya mga operasyon (mga operasyon diin ang tahas sa pagkopya sa datos gikan sa usa ka lugar sa panumduman ngadto sa lain wala gihimo). Ang naulahi usa ka dako nga performance ug resource gain ug posible lamang pinaagi sa paggamit sa usa ka underlying log data structure nga naghubit sa partition scheme.

Labing maayo nga pasundayag ang posible sa usa ka Kafka cluster kaysa sa usa ka Kafka broker, tungod kay ang mga partisyon sa hilisgutan mahimo’g madugangan sa daghang lainlaing mga makina.

Mga resulta

Niini nga kapitulo, among gitan-aw kung giunsa pag-usab sa arkitektura sa Kafka ang relasyon tali sa mga kliyente ug mga broker aron mahatagan ang usa ka labi ka lig-on nga pipeline sa pagmemensahe, nga adunay throughput nga daghang beses nga mas dako kaysa sa usa ka naandan nga broker sa mensahe. Among gihisgutan ang gamit nga gigamit niini aron makab-ot kini ug kadiyot mitan-aw sa arkitektura sa mga aplikasyon nga naghatag niini nga gamit. Sa sunod nga kapitulo, atong tan-awon ang kasagarang mga problema nga gibase sa pagmemensahe nga mga aplikasyon nga kinahanglang sulbaron ug hisgotan ang mga estratehiya sa pag-atubang niini. Tapuson namo ang kapitulo pinaagi sa paglatid kon unsaon paghisgot bahin sa mga teknolohiya sa pagmemensahe sa kinatibuk-an aron imong masusi ang pagkahaom niini sa imong mga kaso sa paggamit.

Nauna nga gihubad nga bahin: Pagsabot sa mga broker sa mensahe. Pagkat-on sa mga mekaniko sa pagmemensahe sa ActiveMQ ug Kafka. Kapitulo 1

Gihimo ang paghubad: tele.gg/middle_java

Ipadayon…

Ang mga rehistradong tiggamit lamang ang makaapil sa survey. Sign in, walay sapayan.

Gigamit ba ang Kafka sa imong organisasyon?

Oo
Dili
Kaniadto gigamit, karon dili
Nagplano mi nga gamiton

38 ka tiggamit ang nagboto. 8 ka tiggamit ang nag-abstain.

Source: www.habr.com

Pagsabot sa mga broker sa mensahe. Pagkat-on sa mga mekaniko sa pagmemensahe sa ActiveMQ ug Kafka. Kapitulo 3. Kafka