Pangertosan makelar pesen. Sinau mekanika olahpesen karo ActiveMQ lan Kafka. Bab 3. Kafka

Lanjutan saka terjemahan buku cilik:
Understanding Pesen Brokers
penulis: Jakub Korab, penerbit: O'Reilly Media, Inc., tanggal diterbitake: Juni 2017, ISBN: 9781492049296.

Bagean terjemahan sadurunge: Pangertosan makelar pesen. Sinau mekanika olahpesen karo ActiveMQ lan Kafka. Bab 1 Pambuka

BAB 3

Kafka

Kafka dikembangake dening LinkedIn kanggo ngatasi sawetara watesan saka makelar pesen tradisional lan ora kudu nyiyapake pirang-pirang makelar pesen kanggo interaksi point-to-point sing beda-beda, sing diterangake ing buku iki ing "Scaling up and out" ing kaca 28 Kasus panggunaan LinkedIn umume ngandelake panggunaan data sing akeh banget, kayata klik kaca lan log akses, nalika isih ngidini data kasebut digunakake dening macem-macem sistem tanpa mengaruhi produktivitas produser utawa konsumen liyane. Nyatane, alesan Kafka ana yaiku kanggo entuk arsitektur olahpesen sing digambarake dening Universal Data Pipeline.

Amarga tujuan utama iki, syarat liyane muncul. Kafka kudu:

• Cepet banget
• Nyedhiyani bandwidth luwih akeh nalika nggarap pesen
• Ndhukung model Publisher-Subscriber lan Point-to-Point
• Aja alon-alon nambahake konsumen. Contone, kinerja antrian lan topik ing ActiveMQ mudhun amarga jumlah konsumen ing panggonan sing dituju mundhak.
• Bisa skala horisontal; yen salah siji makelar sing tetep pesen mung bisa nindakake kanthi kacepetan disk maksimal, mula luwih becik ngluwihi conto broker siji kanggo nambah kinerja
• Matesi akses kanggo nyimpen lan njupuk maneh pesen

Kanggo nggayuh kabeh iki, Kafka nggunakake arsitektur sing nemtokake maneh peran lan tanggung jawab klien lan makelar olahpesen. Model JMS banget berorientasi broker, ing ngendi broker tanggung jawab kanggo nyebarake pesen lan klien mung kudu kuwatir babagan ngirim lan nampa pesen. Kafka, ing sisih liya, minangka klien-sentris, kanthi klien njupuk akeh fitur saka broker tradisional, kayata distribusi pesen sing cocog kanggo konsumen, minangka ijol-ijolan broker sing cepet banget lan bisa diukur. Kanggo wong sing wis nggarap sistem olahpesen tradisional, nggarap Kafka mbutuhake owah-owahan dhasar.
Arah teknik iki nyebabake nggawe infrastruktur olahpesen sing bisa nambah throughput kanthi akeh pesenan dibandhingake karo makelar konvensional. Kaya sing bakal kita deleng, pendekatan iki kalebu trade-off, tegese Kafka ora cocog kanggo jinis beban kerja tartamtu lan piranti lunak sing diinstal.

Model Tujuan Unified

Kanggo nyukupi syarat sing kasebut ing ndhuwur, Kafka wis nggabungake olahpesen publish-subscribe lan point-to-point ing siji jinis tujuan − topik. Iki mbingungake kanggo wong sing wis nggarap sistem olahpesen, ing ngendi tembung "topik" nuduhake mekanisme siaran sing (saka topik) maca ora bisa tahan. Topik Kafka kudu dianggep minangka jinis tujuan hibrida, kaya sing ditegesake ing pambuka buku iki.

Kanggo sisa bab iki, kajaba kita nyatakake kanthi jelas, istilah "topik" bakal nuduhake topik Kafka.

Kanggo ngerti kanthi lengkap babagan tumindak topik lan apa sing menehi jaminan, mula kudu dideleng kepiye carane ditindakake ing Kafka.
Saben topik ing Kafka duwe log dhewe.
Produser ngirim pesen menyang Kafka nulis log iki, lan konsumen maca saka log nggunakake penunjuk sing terus maju. Secara periodik, Kafka mbusak bagean paling tuwa saka log, manawa pesen ing bagean kasebut wis diwaca utawa durung. Bagian tengah desain Kafka yaiku broker ora peduli yen pesen diwaca utawa ora - iku tanggung jawab klien.

Istilah "log" lan "pointer" ora katon ing Dokumentasi Kafka. Istilah-istilah sing kondhang iki digunakake ing kene kanggo mbantu pemahaman.

Model iki temen beda saka ActiveMQ, ngendi pesen saka kabeh antrian disimpen ing log padha, lan makelar tandha pesen dibusak sawise padha wis diwaca.
Ayo saiki digali luwih jero lan deleng log topik kanthi luwih rinci.
Log Kafka kasusun saka sawetara partisi (Gambar 3-1). Kafka njamin pesenan sing ketat ing saben partisi. Iki tegese pesen sing ditulis ing partisi kanthi urutan tartamtu bakal diwaca kanthi urutan sing padha. Saben partisi dileksanakake minangka file log rolling sing ngemot subset (subset) kabeh pesen sing dikirim menyang topik dening produser. Topik sing digawe ngemot, minangka standar, siji partisi. Gagasan partisi minangka ide utama Kafka kanggo skala horisontal.

Gambar 3-1. Partisi Kafka

Nalika produser ngirim pesen menyang topik Kafka, bakal nemtokake partisi sing arep dikirim pesen kasebut. Kita bakal nliti iki kanthi luwih rinci mengko.

Maca pesen

Klien sing pengin maca pesen ngatur pointer sing diarani klompok konsumen, kang nuduhake ngimbangi pesen ing partisi. Offset minangka posisi tambahan sing diwiwiti saka 0 ing wiwitan partisi. Grup konsumen iki, sing dirujuk ing API liwat group_id sing ditemtokake pangguna, cocog karo siji konsumen utawa sistem logis.

Umume sistem olahpesen maca data saka tujuan nggunakake macem-macem conto lan utas kanggo ngolah pesen kanthi podo karo. Mangkono, biasane bakal ana akeh conto konsumen sing nuduhake klompok konsumen sing padha.

Masalah maca bisa dituduhake kaya ing ngisor iki:

• Topik duwe pirang-pirang partisi
• Sawetara klompok konsumen bisa nggunakake topik ing wektu sing padha
• Klompok konsumen bisa duwe sawetara kasus sing kapisah

Iki minangka masalah akeh-kanggo-akeh sing ora pati penting. Kanggo mangerteni carane Kafka nangani hubungan antarane grup konsumen, conto konsumen, lan partisi, ayo deleng seri skenario maca sing luwih rumit.

Konsumen lan kelompok konsumen

Ayo dadi titik wiwitan topik kanthi siji partisi (Gambar 3-2).

Gambar 3-2. Konsumen maca saka partisi

Nalika conto konsumen nyambung karo group_id dhewe kanggo topik iki, diutus partisi diwaca lan offset ing partisi kasebut. Posisi offset iki bisa dikonfigurasi ing klien minangka penunjuk menyang posisi paling anyar (pesen paling anyar) utawa posisi paling awal (pesen paling tuwa). Konsumen njaluk (jajak pendapat) pesen saka topik kasebut, sing nyebabake dheweke diwaca kanthi urutan saka log.
Posisi offset ajeg bali menyang Kafka lan disimpen minangka pesen ing topik internal _consumer_offsets. Pesen sing diwaca isih durung dibusak, ora kaya broker biasa, lan klien bisa mbatalake offset kanggo ngolah maneh pesen sing wis dideleng.

Nalika konsumen logis kaloro nyambung nggunakake group_id beda, iku ngatur pointer kapindho sing ora gumantung saka pisanan (Gambar 3-3). Mangkono, topik Kafka tumindak kaya antrian ing ngendi ana siji konsumen lan kaya topik publish-subscribe (pub-sub) normal sing akeh konsumen langganan, kanthi entuk manfaat tambahan yen kabeh pesen disimpen lan bisa diproses kaping pirang-pirang.

Gambar 3-3. Loro konsumen ing kelompok konsumen sing beda maca saka partisi sing padha

Konsumen ing grup konsumen

Nalika salah sawijining conto konsumen maca data saka partisi, nduweni kontrol lengkap pointer lan ngolah pesen kaya sing diterangake ing bagean sadurunge.
Yen sawetara conto konsumen disambungake karo group_id sing padha menyang topik kanthi siji partisi, mula conto sing disambungake pungkasan bakal diwenehi kontrol pointer lan wiwit iku bakal nampa kabeh pesen (Gambar 3-4).

Gambar 3-4. Loro konsumen ing grup konsumen sing padha maca saka partisi sing padha

Mode pangolahan iki, sing jumlah conto konsumen ngluwihi jumlah partisi, bisa dianggep minangka jinis konsumen eksklusif. Iki bisa migunani yen sampeyan mbutuhake clustering "aktif-pasif" (utawa "panas-panas") saka conto konsumen sampeyan, sanajan nganggo macem-macem konsumen kanthi paralel ("aktif-aktif" utawa "panas-panas") luwih khas tinimbang konsumen. Ing siyaga.

Prilaku distribusi pesen sing kasebut ing ndhuwur bisa nggumunake dibandhingake karo prilaku antrian JMS sing normal. Ing model iki, pesen sing dikirim menyang antrian bakal disebarake kanthi rata ing antarane rong konsumen.

Paling asring, nalika kita nggawe sawetara kedadean saka konsumen, kita nindakake iki salah siji kanggo proses pesen ing podo karo, utawa kanggo nambah kacepetan maca, utawa kanggo nambah stabilitas proses maca. Amarga mung siji conto konsumen sing bisa maca data saka partisi sekaligus, kepiye carane bisa ditindakake ing Kafka?

Salah siji cara kanggo nindakake iki yaiku nggunakake conto konsumen siji kanggo maca kabeh pesen lan ngirim menyang blumbang thread. Nalika pendekatan iki nambah throughput pangolahan, nambah kerumitan logika konsumen lan ora nindakake apa-apa kanggo nambah kekuwatan sistem maca. Yen siji salinan konsumen mudhun amarga gagal daya utawa acara sing padha, mula pangurangan mandheg.

Cara kanonik kanggo ngatasi masalah iki ing Kafka yaiku nggunakake bОpartisi liyane.

Pemisahan

Partisi minangka mekanisme utama kanggo parallelizing maca lan skala topik ngluwihi bandwidth saka conto broker siji. Kanggo luwih ngerti iki, ayo nimbang kahanan sing ana topik kanthi rong partisi lan siji konsumen langganan topik iki (Gambar 3-5).

Gambar 3-5. Siji konsumen maca saka pirang-pirang partisi

Ing skenario iki, konsumen diwenehi kontrol liwat penunjuk sing cocog karo group_id ing loro partisi lan wiwit maca pesen saka loro partisi.
Nalika konsumen tambahan kanggo group_id padha ditambahake kanggo topik iki, Kafka relokasi siji saka sekat saka pisanan kanggo konsumen kaloro. Sawise iku, saben conto konsumen bakal maca saka siji partisi topik (Gambar 3-6).

Kanggo mesthekake yen pesen diproses kanthi podo karo 20 utas, sampeyan butuh paling ora 20 partisi. Yen partisi kurang, sampeyan bakal ditinggalake karo konsumen sing ora duwe apa-apa, kaya sing diterangake sadurunge ing diskusi konsumen eksklusif.

Gambar 3-6. Loro konsumen ing grup konsumen sing padha maca saka partisi sing beda

Skema iki nyuda kerumitan broker Kafka dibandhingake karo distribusi pesen sing dibutuhake kanggo njaga antrian JMS. Ing kene sampeyan ora perlu kuwatir babagan poin ing ngisor iki:

• Konsumen sing kudu nampa pesen sabanjure, adhedhasar alokasi round-robin, kapasitas buffer prefetch saiki, utawa pesen sadurunge (minangka grup pesen JMS).
• Pesen endi sing dikirim menyang konsumen lan apa kudu dikirim maneh yen gagal.

Kabeh sing kudu ditindakake makelar Kafka yaiku ngirim pesen kanthi urutan menyang konsumen nalika sing terakhir njaluk.

Nanging, syarat kanggo paralelisasi proofreading lan ngirim maneh pesen sing gagal ora ilang - tanggung jawab kasebut mung liwat broker menyang klien. Iki tegese padha kudu dijupuk menyang akun ing kode.

Ngirim pesen

Tanggung jawab produser pesen kasebut kanggo mutusake partisi sing bakal dikirim pesen. Kanggo mangerteni mekanisme sing ditindakake, kita kudu nimbang apa sing bener-bener dikirim.

Dene ing JMS nggunakake struktur pesen kanthi metadata (header lan properti) lan awak sing ngemot muatan (payload), ing Kafka pesen kasebut yaiku pasangan "nilai kunci". Payload pesen dikirim minangka nilai. Tombol, ing tangan liyane, utamané digunakake kanggo partisi lan kudu ngemot kunci khusus logika bisniskanggo nyelehake pesen sing gegandhengan ing partisi sing padha.

Ing Bab 2, kita ngrembug skenario totoan online ing ngendi acara sing gegandhengan kudu diproses kanthi urutan dening konsumen siji:

1. Akun pangguna wis diatur.
2. Dhuwit dikreditake menyang akun kasebut.
3. A totohan digawe sing withdraws dhuwit saka akun.

Yen saben acara minangka pesen sing dikirim menyang topik, mula kunci alami yaiku ID akun.
Nalika pesen dikirim nggunakake API Produser Kafka, iku liwati menyang fungsi pemisahan kang, diwenehi pesen lan kahanan saiki klompok Kafka, ngasilake ID saka pemisahan sing pesen kudu dikirim. Fitur iki dileksanakake ing Jawa liwat antarmuka Partitioner.

Antarmuka iki katon kaya iki:

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

Implementasi Partitioner nggunakake algoritma hashing tujuan umum standar ing tombol kanggo nemtokake partisi, utawa round-robin yen ora ana tombol sing ditemtokake. Nilai standar iki dianggo kanthi apik ing pirang-pirang kasus. Nanging, ing mangsa ngarep sampeyan pengin nulis dhewe.

Nulis strategi partisi dhewe

Ayo goleki conto ing ngendi sampeyan pengin ngirim metadata bebarengan karo muatan pesen. Beban ing conto kita minangka pandhuan kanggo nggawe simpenan menyang akun game. Instruksi minangka prekara sing kita pengin dijamin ora bakal diowahi nalika transmisi lan pengin mesthekake yen mung sistem hulu sing dipercaya sing bisa miwiti instruksi kasebut. Ing kasus iki, sistem ngirim lan nampa sarujuk nggunakake teken kanggo otentikasi pesen.
Ing JMS normal, kita mung nemtokake properti "tanda tangan pesen" lan ditambahake menyang pesen kasebut. Nanging, Kafka ora menehi kita mekanisme kanggo ngliwati metadata, mung kunci lan nilai.

Amarga nilai kasebut minangka muatan transfer bank sing integritase pengin dilestarekake, kita ora duwe pilihan nanging nemtokake struktur data sing digunakake ing kunci kasebut. Yen kita butuh ID akun kanggo pemisahan, amarga kabeh pesen sing ana gandhengane karo akun kudu diproses kanthi urutan, kita bakal nggawe struktur JSON ing ngisor iki:

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

Amarga nilai teken bakal beda-beda gumantung saka payload, strategi hashing standar antarmuka Partitioner ora bisa dipercaya klompok pesen sing gegandhengan. Mula, kita kudu nulis strategi dhewe sing bakal ngurai kunci iki lan misahake nilai accountId.

Kafka kalebu checksums kanggo ndeteksi korupsi pesen ing toko lan duwe set lengkap fitur keamanan. Sanajan mangkono, syarat khusus industri, kayata ing ndhuwur, kadhangkala katon.

Strategi partisi pangguna kudu mesthekake yen kabeh pesen sing ana gandhengane bakal ana ing partisi sing padha. Nalika iki katon prasaja, syarat kasebut bisa rumit amarga pentinge pesen kiriman sing gegandhengan lan carane tetep jumlah partisi ing sawijining topik.

Jumlah partisi ing topik bisa owah saka wektu, amarga bisa ditambahake yen lalu lintas ngluwihi pangarepan awal. Mangkono, tombol pesen bisa digandhengake karo partisi sing asline dikirim, tegese bagean negara sing bakal dituduhake ing antarane kedadeyan produser.

Faktor liyane sing kudu ditimbang yaiku distribusi pesen sing rata ing antarane partisi. Biasane, tombol ora disebarake kanthi merata ing kabeh pesen, lan fungsi hash ora njamin distribusi pesen sing adil kanggo sawetara tombol cilik.
Penting kanggo dicathet yen sampeyan milih pamisah pesen, pemisah kasebut bisa uga kudu digunakake maneh.

Coba syarat kanggo niru data ing antarane klompok Kafka ing lokasi geografis sing beda. Kanggo maksud iki, Kafka dilengkapi alat baris perintah sing disebut MirrorMaker, sing digunakake kanggo maca pesen saka siji kluster lan nransfer menyang liyane.

MirrorMaker kudu ngerti kunci topik sing ditiru supaya bisa njaga urutan relatif antarane pesen nalika replikasi antarane klompok, amarga jumlah partisi kanggo topik kasebut bisa uga ora padha ing rong klompok.

Sastranegara partisi khusus relatif langka, amarga hashing standar utawa round robin bisa digunakake ing umume skenario. Nanging, yen sampeyan mbutuhake jaminan pesenan sing kuat utawa kudu ngekstrak metadata saka muatan, mula partisi minangka perkara sing kudu dideleng.

Keuntungan skalabilitas lan kinerja Kafka teka saka mindhah sawetara tanggung jawab broker tradisional menyang klien. Ing kasus iki, keputusan digawe kanggo nyebarake pesen sing ana hubungane karo sawetara konsumen sing makarya bebarengan.

Makelar JMS uga kudu ngatasi syarat kasebut. Apike, mekanisme kanggo ngirim pesen sing gegandhengan karo konsumen sing padha, ditindakake liwat JMS Message Groups (variasi strategi sticky load balancing (SLB)), uga mbutuhake pangirim kanggo menehi tandha pesen minangka gegandhengan. Ing kasus JMS, makelar tanggung jawab kanggo ngirim grup pesen sing gegandhengan karo siji konsumen saka akeh, lan nransfer kepemilikan grup kasebut yen konsumen tiba.

Perjanjian Produsen

Pemisahan ora mung siji sing kudu ditimbang nalika ngirim pesen. Ayo goleki metode send () saka kelas Produser ing Java API:

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

Sampeyan kudu eling yen loro cara bali Future, sing nuduhake yen operasi ngirim ora langsung dileksanakake. Asil iku pesen (ProducerRecord) ditulis kanggo ngirim buffer kanggo saben partisi aktif lan dikirim menyang makelar minangka thread latar mburi ing perpustakaan klien Kafka. Nalika iki nggawe cepet banget, tegese aplikasi sing ora duwe pengalaman bisa ilang pesen yen prosese mandheg.

Kaya biasane, ana cara kanggo nggawe operasi kirim luwih dipercaya kanthi biaya kinerja. Ukuran buffer iki bisa disetel dadi 0, lan thread aplikasi sing dikirim bakal dipeksa ngenteni nganti transfer pesen menyang broker rampung, kaya ing ngisor iki:

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

Liyane babagan maca pesen

Maca pesen duwe kerumitan tambahan sing kudu dipikirake. Boten kados JMS API, kang bisa mbukak pamireng pesen kanggo nanggepi pesen, ing Consumer Kafka mung polling. Ayo dideleng kanthi luwih cetha babagan metode kasebut polling()digunakake kanggo tujuan iki:

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

Nilai bali saka metode kasebut minangka struktur wadhah sing ngemot pirang-pirang obyek cathetan konsumen saka potensial sawetara partisi. cathetan konsumen iku dhewe obyek nduwèni kanggo pasangan kunci-nilai karo metadata gadhah, kayata pemisahan saka kang asalé.

Kaya sing wis dibahas ing Bab 2, kita kudu ngelingi apa sing kedadeyan ing pesen sawise diproses kanthi sukses utawa ora kasil, contone, yen klien ora bisa ngolah pesen kasebut utawa dibatalake. Ing JMS, iki ditangani liwat mode pangenalan. Broker bakal mbusak pesen sing wis diproses, utawa ngirim maneh pesen mentah utawa palsu (assuming transaksi digunakake).
Kafka kerjane beda banget. Pesen ora dibusak ing makelar sawise proofreading, lan apa sing kedadeyan nalika gagal dadi tanggung jawab kode proofreading dhewe.

Kaya sing wis dingerteni, klompok konsumen digandhengake karo offset ing log. Posisi log sing digandhengake karo offset iki cocog karo pesen sabanjure sing bakal ditanggepi kanggo nanggepi polling(). Titik ing wektu nalika offset mundhak iki nemtokake kanggo maca.

Bali menyang model maca sing wis dibahas sadurunge, pangolahan pesen dumadi saka telung tahap:

1. Njupuk pesen kanggo maca.
2. Proses pesen.
3. Konfirmasi pesen.

Konsumen Kafka dilengkapi opsi konfigurasi enable.auto.commit. Iki minangka setelan gawan sing kerep digunakake, kaya biasane karo setelan sing ngemot tembung "otomatis".

Sadurunge Kafka 0.10, klien sing nggunakake opsi iki bakal ngirim offset pesen pungkasan sing diwaca ing telpon sabanjure. polling() sawise proses. Iki tegese pesen apa wae sing wis dijupuk bisa diproses maneh yen klien wis diproses nanging ora sengaja dirusak sadurunge nelpon. polling(). Wiwit makelar ora nyimpen negara babagan kaping pirang-pirang pesen wis diwaca, konsumen sabanjure sing njupuk pesen kasebut ora bakal ngerti manawa ana kedadeyan sing ala. Prilaku iki pseudo-transaksional. Offset mung ditindakake yen pesen kasebut kasil diproses, nanging yen klien dibatalake, broker bakal ngirim pesen sing padha maneh menyang klien liyane. Prilaku iki konsisten karo jaminan pangiriman pesen "paling sapisan".

Ing Kafka 0.10, kode klien wis diganti supaya komit dipicu sacara periodik dening perpustakaan klien, kaya sing dikonfigurasi. auto.commit.interval.ms. Prilaku iki ana ing antarane mode JMS AUTO_ACKNOWLEDGE lan DUPS_OK_ACKNOWLEDGE. Nalika nggunakake autocommit, pesen bisa dileksanakake preduli saka apa padha bener diproses - iki bisa kelakon ing cilik saka konsumen alon. Yen konsumen dibatalake, pesen bakal dijupuk dening konsumen sabanjure, diwiwiti saka posisi sing setya, sing bisa nyebabake pesen sing ora kejawab. Ing kasus iki, Kafka ora ilang pesen, kode maca mung ora diproses.

Mode iki nduweni janji sing padha karo versi 0.9: pesen bisa diproses, nanging yen gagal, offset bisa uga ora ditindakake, bisa nyebabake pangiriman tikel kaping pindho. Pesen liyane sing dijupuk nalika nglakokake polling(), luwih masalah iki.

Kaya sing dibahas ing "Maca Pesen saka Antrian" ing kaca 21, ora ana sing ngirim pesen siji-wektu ing sistem olahpesen nalika mode gagal dianggep.

Ing Kafka, ana rong cara kanggo nindakake (komit) offset (offset): kanthi otomatis lan manual. Ing kasus loro, pesen bisa diproses kaping pirang-pirang yen pesen diproses nanging gagal sadurunge komitmen. Sampeyan uga bisa milih ora ngolah pesen yen komit kedadeyan ing latar mburi lan kode sampeyan wis rampung sadurunge bisa diproses (mbok menawa ing Kafka 0.9 lan sadurunge).

Sampeyan bisa ngontrol proses komit offset manual ing API konsumen Kafka kanthi nyetel parameter enable.auto.commit kanggo palsu lan kanthi jelas nelpon salah siji saka cara ing ngisor iki:

void commitSync();
void commitAsync();

Yen sampeyan pengin ngolah pesen "paling ora sapisan", sampeyan kudu nindakake offset kanthi manual commitSync()kanthi nglakokake printah iki sanalika sawise ngolah pesen.

Cara kasebut ora ngidini pesen diakoni sadurunge diproses, nanging ora nindakake apa-apa kanggo ngilangi tundha pangolahan potensial nalika menehi tampilan minangka transaksional. Ora ana transaksi ing Kafka. Klien ora duwe kemampuan kanggo nindakake ing ngisor iki:

• Muter pesen palsu kanthi otomatis. Konsumen dhewe kudu nangani pangecualian sing muncul saka beban masalah lan gangguan backend, amarga ora bisa ngandelake makelar kanggo ngirim pesen maneh.
• Kirim pesen menyang macem-macem topik ing siji operasi atom. Nalika kita bakal weruh sakcepete, kontrol liwat macem-macem topik lan partisi bisa manggon ing mesin beda ing cluster Kafka sing ora koordinasi transaksi nalika dikirim. Ing wektu iki ditulis, sawetara karya wis rampung kanggo nggawe iki bisa karo KIP-98.
• Sambungake maca pesen saka siji topik karo ngirim pesen liyane menyang topik liyane. Maneh, arsitektur Kafka gumantung ing akeh mesin independen sing mlaku minangka siji bis lan ora ana upaya kanggo ndhelikake iki. Contone, ora ana komponen API sing ngidini sampeyan nyambungake konsumen и Produser ing transaksi. Ing JMS, iki diwenehake dening obyek Sessionsaka kang digawe PesenProduser и Pesen Konsumen.

Yen kita ora bisa ngandelake transaksi, kepiye carane bisa nyedhiyakake semantik sing luwih cedhak karo sing diwenehake dening sistem olahpesen tradisional?

Yen ana kamungkinan sing ngimbangi konsumen bisa nambah sadurunge pesen wis diproses, kayata nalika konsumen kacilakan, banjur konsumen ora bisa ngerti yen klompok konsumen sawijining ora kejawab pesen nalika diutus partisi. Dadi siji strategi yaiku mundurake offset menyang posisi sadurunge. API konsumen Kafka nyedhiyakake cara ing ngisor iki:

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

Cara golek () bisa digunakake kanthi cara
offsetsForTimes(Peta stempel wektuToSearch) kanggo mundur menyang negara ing sawetara titik tartamtu ing jaman kepungkur.

Secara implisit, nggunakake pendekatan iki tegese akeh banget manawa sawetara pesen sing sadurunge diproses bakal diwaca lan diproses maneh. Kanggo ngindhari iki, kita bisa nggunakake maca idempoten, kaya sing diterangake ing Bab 4, kanggo nglacak pesen sing wis dideleng sadurunge lan ngilangi duplikat.

Utawa, kode konsumen sampeyan bisa tetep prasaja, anggere mundhut pesen utawa duplikasi bisa ditampa. Nalika kita ndeleng kasus panggunaan sing umume digunakake Kafka, kayata nangani acara log, metrik, pelacakan klik, lan sapiturute, kita ngerti yen ilang pesen individu ora ana pengaruh sing signifikan ing aplikasi ing saubengé. Ing kasus kaya mengkono, nilai standar bisa ditampa kanthi becik. Ing sisih liya, yen aplikasi sampeyan kudu ngirim pembayaran, sampeyan kudu ngurus saben pesen kanthi ati-ati. Iku kabeh teka menyang konteks.

Pengamatan pribadi nuduhake yen intensitas pesen mundhak, nilai saben pesen individu mudhun. Pesen gedhe cenderung larang regane yen dideleng ing wangun sing dikumpulake.

Kasedhiyan Dhuwur

Pendekatan Kafka kanggo kasedhiyan dhuwur beda banget karo pendekatan ActiveMQ. Kafka dirancang ing sekitar kluster skala ing ngendi kabeh broker nampa lan nyebar pesen bebarengan.

Kluster Kafka kasusun saka pirang-pirang conto broker sing mlaku ing server sing beda-beda. Kafka dirancang kanggo mbukak ing hardware mandiri biasa, ing ngendi saben simpul duwe panyimpenan khusus. Panggunaan panyimpenan terlampir jaringan (SAN) ora dianjurake amarga sawetara node komputasi bisa bersaing kanggo wektu.Ыe interval panyimpenan lan nggawe konflik.

Kafka iku tansah ing sistem. Akeh pangguna Kafka sing gedhe ora nate nutup klompok lan piranti lunak kasebut tansah nganyari kanthi miwiti maneh kanthi urutan. Iki digayuh kanthi njamin kompatibilitas karo versi sadurunge kanggo pesen lan interaksi antarane makelar.

Broker disambungake menyang kluster server Kebon Binatang, sing tumindak minangka registri data konfigurasi lan digunakake kanggo koordinasi peran saben broker. ZooKeeper dhewe minangka sistem sing disebarake sing nyedhiyakake kasedhiyan dhuwur liwat replikasi informasi kanthi netepake kuorum.

Ing kasus dhasar, topik digawe ing kluster Kafka kanthi properti ing ngisor iki:

• Jumlah partisi. Kaya sing wis dibahas sadurunge, nilai pas sing digunakake ing kene gumantung saka tingkat maca paralel sing dikarepake.
• Faktor replikasi (faktor) nemtokake jumlah conto broker ing kluster kudu ngemot log kanggo partisi iki.

Nggunakake ZooKeepers kanggo koordinasi, Kafka nyoba nyebarake partisi anyar kanthi adil ing antarane makelar ing kluster kasebut. Iki rampung dening siji Kayata sing tumindak minangka Controller.

Ing runtime kanggo saben partisi topik Controller nemtokake peran kanggo makelar pimpinan (pimpinan, master, presenter) lan pandherekipun (pandherek, abdi, bawahan). Broker, sing dadi pimpinan kanggo partisi iki, tanggung jawab kanggo nampa kabeh pesen sing dikirim dening produser lan nyebarake pesen kasebut menyang konsumen. Nalika pesen dikirim menyang partisi topik, pesen kasebut ditiru menyang kabeh simpul makelar sing dadi pengikut kanggo partisi kasebut. Saben simpul sing ngemot log kanggo partisi diarani replika. A makelar bisa tumindak minangka pimpinan kanggo sawetara partisi lan minangka pengikut kanggo wong liya.

Pengikut sing ngemot kabeh pesen sing dicekel pimpinan diarani replika sing disinkronake (replika sing ana ing negara sing disinkronake, replika sing sinkron). Yen broker sing dadi pimpinan kanggo partisi mudhun, broker apa wae sing paling anyar utawa disinkronake kanggo partisi kasebut bisa njupuk alih peran pimpinan. Iku desain luar biasa sustainable.

Bagéyan saka konfigurasi produser yaiku parameter aks, sing nemtokake jumlah replika sing kudu ngakoni (ngakoni) nampa pesen sadurunge utas aplikasi terus dikirim: 0, 1, utawa kabeh. Yen disetel kanggo kabeh, banjur nalika pesen ditampa, pimpinan bakal ngirim konfirmasi bali menyang produser sanalika nampa konfirmasi (ngakoni) rekaman saka sawetara isyarat (kalebu dhewe) sing ditemtokake dening setelan topik. min.insync.replicas (standar 1). Yen pesen ora bisa ditiru kanthi sukses, produser bakal mbuwang pengecualian aplikasi (Ora CukupReplika utawa Ora CukupReplikaSawiseLampirake).

Konfigurasi khas nggawe topik kanthi faktor replikasi 3 (1 pimpinan, 2 pengikut saben partisi) lan parameter min.insync.replicas disetel kanggo 2. Ing kasus iki, kluster bakal ngidini salah siji saka makelar ngatur partisi topik mudhun tanpa mengaruhi aplikasi klien.

Iki ndadekke kita bali menyang trade-off wis akrab antarane kinerja lan linuwih. Replikasi dumadi kanthi biaya wektu tunggu tambahan kanggo konfirmasi (pengakuan) saka para pengikut. Senajan, amarga mlaku ing podo karo, réplikasi kanggo paling telung simpul nduweni kinerja padha loro (nglirwakake Tambah ing panggunaan bandwidth jaringan).

Kanthi nggunakake skema replikasi iki, Kafka kanthi pinter ngindhari kabutuhan nulis saben pesen menyang disk kanthi operasi. sinkronisasi(). Saben pesen sing dikirim dening produser bakal ditulis ing log pemisahan, nanging minangka rembugan ing Bab 2, nulis kanggo file pisanan rampung ing buffer sistem operasi. Yen pesen iki ditiru menyang conto Kafka liyane lan ana ing memori, kelangan pimpinan ora ateges pesen kasebut ilang - bisa dijupuk kanthi replika sing disinkronake.
Nolak kanggo nindakake operasi sinkronisasi() tegese Kafka bisa nampa pesen kanthi cepet kaya sing bisa ditulis ing memori. Kosok baline, saya suwe sampeyan bisa ngindhari memori kanggo disk, luwih apik. Mulane, ora umum yen makelar Kafka diwenehi memori 64 GB utawa luwih. Panggunaan memori iki tegese siji conto Kafka bisa mlaku kanthi cepet nganti ewonan luwih cepet tinimbang makelar pesen tradisional.

Kafka uga bisa dikonfigurasi kanggo ngetrapake operasi kasebut sinkronisasi() kanggo pesen paket. Amarga kabeh ing Kafka berorientasi paket, mula bisa digunakake kanthi apik kanggo akeh kasus panggunaan lan minangka alat sing migunani kanggo pangguna sing mbutuhake jaminan sing kuat. Akeh kinerja murni Kafka asale saka pesen sing dikirim menyang makelar minangka paket lan pesen kasebut diwaca saka makelar ing blok urutan nggunakake nul salinan operasi (operasi nalika tugas nyalin data saka siji area memori menyang liyane ora dileksanakake). Sing terakhir minangka kinerja gedhe lan entuk sumber daya lan mung bisa ditindakake kanthi nggunakake struktur data log sing ndasari sing nemtokake skema partisi.

Kinerja sing luwih apik bisa ditindakake ing kluster Kafka tinimbang karo makelar Kafka siji, amarga partisi topik bisa nyebar ing pirang-pirang mesin sing kapisah.

Hasil

Ing bab iki, kita ndeleng carane arsitektur Kafka reimagines hubungan antarane klien lan makelar kanggo nyedhiyani pipeline olahpesen luar biasa kuat, karo throughput kaping pirang-pirang luwih gedhe tinimbang sing saka makelar pesen conventional. Kita wis ngrembug fungsi sing digunakake kanggo entuk iki lan ndeleng kanthi ringkes arsitektur aplikasi sing nyedhiyakake fungsi kasebut. Ing bab sabanjure, kita bakal nliti masalah umum sing kudu dirampungake aplikasi basis olahpesen lan ngrembug strategi kanggo ngatasi. Kita bakal mungkasi bab kanthi njlentrehake babagan carane ngomong babagan teknologi olahpesen kanthi umum supaya sampeyan bisa ngevaluasi kesesuaian kanggo kasus panggunaan sampeyan.

Bagean terjemahan sadurunge: Pangertosan makelar pesen. Sinau mekanika olahpesen karo ActiveMQ lan Kafka. Bab 1

Terjemahan rampung: tele.gg/jawa tengah

Terus ...

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Apa Kafka digunakake ing organisasi sampeyan?

• Ya

• Ora

• Biyen digunakake, saiki ora

• We rencana kanggo nggunakake

38 pangguna milih. 8 kedhaftar abstained.

Source: www.habr.com