Pamahaman calo pesen. Diajar mékanika olahtalatah sareng ActiveMQ sareng Kafka. Bab 3. Kafka

Tuluyan tina tarjamahan buku leutik:
Pamahaman Pesen calo
nu ngarang: Jakub Korab, penerbit: O'Reilly Media, Inc., tanggal publikasi: Juni 2017, ISBN: 9781492049296.

Bagian anu ditarjamahkeun saméméhna: Pamahaman calo pesen. Diajar mékanika olahtalatah sareng ActiveMQ sareng Kafka. Bab 1 Pendahuluan

BAB 3

Kafka

Kafka dikembangkeun ku LinkedIn pikeun ngurilingan sababaraha watesan calo pesen tradisional sareng ngahindarkeun kedah nyetél sababaraha calo pesen pikeun interaksi titik-ka-titik anu béda-béda, anu dijelaskeun dina buku ieu dina "Scaling up and out" dina kaca 28 . Kasus pamakéan LinkedIn geus sakitu legana relied on ingestion hiji arah tina jumlah anu kacida gedéna data, kayaning clicks kaca jeung aksés log, bari tetep sahingga data nu bisa dipaké ku sababaraha sistem tanpa impacting produktivitas produser atawa konsumén lianna. Nyatana, alesan Kafka aya nyaéta pikeun nampi jinis arsitéktur olahtalatah anu dijelaskeun ku Universal Data Pipeline.

Dibikeun tujuan pamungkas ieu, sarat séjén alami timbul. Kafka kedah:

• Janten gancang pisan
• Nyadiakeun langkung rubakpita nalika damel sareng pesen
• Ngarojong modél Publisher-Subscriber sareng Point-to-Point
• Entong ngalambatkeun sareng nambihan konsumen. Contona, kinerja duanana antrian jeung topik di ActiveMQ degrades sakumaha jumlah konsumén dina tujuan tumuwuh.
• Janten horizontal scalable; lamun salah sahiji calo nu persists pesen ngan bisa ngalakukeunana dina speed disk maksimum, mangka asup akal pikeun buka saluareun hiji conto calo tunggal pikeun ngaronjatkeun kinerja
• Watesan aksés pikeun nyimpen sareng nyandak deui pesen

Pikeun ngahontal sadayana ieu, Kafka ngadopsi arsitéktur anu ngarobih deui peran sareng tanggung jawab klien sareng calo olahtalatah. Model JMS pisan berorientasi calo, dimana calo tanggung jawab nyebarkeun pesen sareng klien ngan ukur kedah hariwang ngeunaan ngirim sareng nampi pesen. Kafka, di sisi anu sanésna, nyaéta klien-centric, sareng klien nyandak seueur fitur calo tradisional, sapertos distribusi anu adil tina pesen anu relevan ka konsumén, pikeun tukeur calo anu gancang pisan sareng skalabel. Pikeun jalma anu parantos damel sareng sistem olahtalatah tradisional, damel sareng Kafka peryogi parobihan dasar.
Arah rékayasa ieu nyababkeun nyiptakeun infrastruktur olahtalatah anu tiasa ningkatkeun throughput ku seueur pesenan gedéna dibandingkeun sareng calo konvensional. Salaku bakal urang tingali, pendekatan ieu hadir kalawan trade-offs, nu hartina Kafka teu cocog pikeun jenis tangtu workloads jeung software dipasang.

Modél Tujuan Ngahijikeun Tatar

Pikeun minuhan sarat ditétélakeun di luhur, Kafka geus ngagabungkeun publish-subscribe jeung point-to-point olahtalatah dina hiji jenis tujuan − jejer. Ieu matak ngabingungkeun pikeun jalma anu parantos damel sareng sistem olahtalatah, dimana kecap "topik" nujul kana mékanisme siaran anu (tina topik) bacaan henteu tahan. Topik Kafka kedah dianggap jinis tujuan hibrid, sakumaha anu didefinisikeun dina bubuka buku ieu.

Pikeun sesa bab ieu, iwal mun urang disebutkeun sacara eksplisit disebutkeun, istilah "topik" bakal nujul ka topik Kafka.

Pikeun pinuh ngartos kumaha jejer kalakuanana sareng naon anu ngajamin aranjeunna, urang kedah ningali heula kumaha aranjeunna dilaksanakeun di Kafka.
Unggal topik di Kafka gaduh log sorangan.
Produser ngirim pesen ka Kafka nyerat kana log ieu, sareng konsumen maca tina log nganggo petunjuk anu terus maju. Périodik, Kafka mupus bagéan log anu pangkolotna, naha pesen dina éta bagian parantos dibaca atanapi henteu. Bagian sentral tina desain Kafka nyaéta yén calo henteu paduli upami pesen dibaca atanapi henteu - éta tanggung jawab klien.

Istilah "log" jeung "pointer" teu muncul dina dokuméntasi Kafka. Istilah-istilah anu terkenal ieu dianggo di dieu pikeun ngabantosan pamahaman.

Modél ieu sagemblengna béda ti ActiveMQ, dimana pesen ti sakabeh antrian disimpen dina log sarua, jeung calo nu nandaan pesen salaku dihapus sanggeus aranjeunna geus dibaca.
Hayu urang ayeuna ngagali sakedik langkung jero sareng ningali log topik sacara langkung rinci.
Log Kafka diwangun ku sababaraha partisi (Gambar 3-1). Kafka ngajamin pesenan anu ketat dina unggal partisi. Ieu ngandung harti yén pesen anu ditulis kana partisi dina urutan anu tangtu bakal dibaca dina urutan anu sami. Unggal partisi dilaksanakeun salaku file log rolling anu ngandung sawaréh (subset) sadaya pesen anu dikirim ka topik ku produsénna. Topik anu diciptakeun ngandung, sacara standar, hiji partisi. Gagasan partisi mangrupikeun ide sentral Kafka pikeun skala horisontal.

Gambar 3-1. Partisi Kafka

Nalika produser ngirim pesen ka topik Kafka, éta mutuskeun partisi mana pikeun ngirim pesen. Urang bakal kasampak di ieu leuwih jéntré engké.

Maca talatah

Klién anu hoyong maca pesen ngatur panunjuk anu namina disebut grup konsumen, nu nunjuk ka ngimbangan pesen dina partisi. Offset nyaéta posisi incremental anu dimimitian dina 0 dina mimiti partisi. grup konsumen ieu, referenced dina API via group_id-diartikeun pamaké, pakait jeung hiji konsumen logis atawa sistem.

Seuseueurna sistem olahtalatah maca data tina tujuan nganggo sababaraha instansi sareng benang pikeun ngolah pesen paralel. Ku kituna, biasana bakal loba instansi konsumen babagi grup konsumen sarua.

Masalah maca bisa digambarkeun saperti kieu:

• Topik ngagaduhan sababaraha partisi
• Sababaraha grup konsumen tiasa nganggo topik dina waktos anu sami
• Sakelompok konsumen tiasa gaduh sababaraha instansi anu misah

Ieu masalah non-trivial loba-ka-loba. Pikeun ngartos kumaha Kafka ngatur hubungan antara grup konsumen, instansi konsumen, sareng partisi, hayu urang tingali séri skénario bacaan anu langkung kompleks.

Konsumen jeung grup konsumen

Hayu urang nyandak salaku titik awal topik sareng hiji partisi (Gambar 3-2).

Gambar 3-2. Konsumén maca tina partisi

Nalika conto konsumen ngahubungkeun sareng group_id sorangan kana topik ieu, ditugaskeun partisi baca sareng offset dina partisi éta. Posisi offset ieu ngonpigurasi dina klien salaku pointer ka posisi panganyarna (pesen newest) atawa posisi pangheubeulna (pesen pangkolotna). Konsumén naroskeun (polling) pesen tina topik, anu nyababkeun aranjeunna dibaca sacara berurutan tina log.
Posisi offset rutin balik deui ka Kafka sareng disimpen salaku pesen dina topik internal _consumer_offsets. Pesen anu dibaca masih henteu dihapus, teu sapertos calo biasa, sareng klien tiasa mundur offset pikeun ngolah deui pesen anu parantos ditingali.

Nalika konsumen logis kadua nyambungkeun ngagunakeun group_id béda, éta ngatur pointer kadua anu bebas tina kahiji (Gambar 3-3). Ku kituna, hiji topik Kafka tindakan kawas antrian dimana aya hiji konsumen na kawas biasa nyebarkeun-ngalanggan (pub-sub) topik nu sababaraha pamakéna ngalanggan, kalawan kauntungan ditambahkeun yén sakabéh pesen disimpen na bisa diolah sababaraha kali.

Gambar 3-3. Dua konsumen dina grup konsumen anu béda maca tina partisi anu sami

Konsumén dina grup konsumen

Nalika hiji conto konsumen maca data tina partisi, éta gaduh kadali pinuh ku pointer sareng ngolah pesen sapertos anu dijelaskeun dina bagian sateuacana.
Upami sababaraha instansi konsumen dihubungkeun sareng group_id anu sami ka topik anu aya hiji partisi, maka instansi anu nyambungkeun terakhir bakal dipasihan kadali kana pointer sareng ti waktos éta bakal nampi sadaya pesen (Gambar 3-4).

Gambar 3-4. Dua konsumen dina grup konsumen anu sami maca tina partisi anu sami

Modeu pamrosésan ieu, dimana jumlah instansi konsumen ngaleuwihan jumlah partisi, tiasa dianggap salaku jinis konsumen ekslusif. Ieu tiasa mangpaat upami anjeun peryogi "aktif-pasif" (atanapi "panas-panas") klaster tina instansi konsumen anjeun, sanaos ngajalankeun sababaraha konsumen sacara paralel ("aktif-aktif" atanapi "panas-panas") langkung umum tibatan konsumen. Dina sayaga.

Ieu paripolah distribusi pesen ditétélakeun di luhur bisa jadi héran dibandingkeun kumaha a JMS antrian normal behaves. Dina modél kieu, pesen anu dikirim ka antrian bakal disebarkeun merata antara dua konsumén.

Paling sering, nalika urang nyieun sababaraha instansi konsumén, urang ngalakukeun ieu boh pikeun ngolah pesen dina paralel, atawa pikeun ngaronjatkeun kagancangan maca, atawa pikeun ngaronjatkeun stabilitas prosés maca. Kusabab ngan ukur hiji conto konsumen anu tiasa maca data tina partisi dina hiji waktos, kumaha ieu dihontal di Kafka?

Salah sahiji cara pikeun ngalakukeun ieu nyaéta ngagunakeun conto konsumen tunggal pikeun maca sadaya pesen sareng ngirimkeunana ka kolam renang benang. Nalika pendekatan ieu ningkatkeun throughput ngolah, éta ningkatkeun pajeulitna logika konsumen sareng teu ngalakukeun nanaon pikeun ningkatkeun kakuatan sistem bacaan. Upami salah sahiji salinan konsumen turun kusabab gagalna listrik atanapi kajadian anu sami, maka panguranganna lirén.

Cara canonical pikeun ngajawab masalah ieu di Kafka nyaéta ngagunakeun bОpartitions langkung.

ngabagi-bagi

Partisi mangrupikeun mékanisme utama pikeun parallelizing bacaan sareng skala topik saluareun bandwidth hiji conto calo tunggal. Pikeun langkung ngartos ieu, hayu urang pertimbangkeun kaayaan dimana aya topik sareng dua partisi sareng hiji konsumen ngalanggan topik ieu (Gambar 3-5).

Gambar 3-5. Hiji konsumen maca tina sababaraha partisi

Dina skénario ieu, konsumen dibéré kontrol kana pointer anu pakait sareng group_id na dina duanana partisi sareng mimiti maca pesen tina duanana partisi.
Nalika hiji konsumen tambahan pikeun group_id sarua ditambahkeun kana topik ieu, Kafka reallocates salah sahiji partitions ti mimiti ka konsumen kadua. Saatos éta, unggal conto konsumen bakal maca tina hiji partisi topik (Gambar 3-6).

Pikeun mastikeun yén pesen diolah sacara paralel dina 20 utas, anjeun peryogi sahenteuna 20 partisi. Mun aya pangsaeutikna partitions, anjeun bakal ditinggalkeun ku pamakéna nu teu boga gawe dina, sakumaha ditétélakeun saméméhna dina sawala ngeunaan pamakéna ekslusif.

Gambar 3-6. Dua konsumen dina grup konsumen anu sami maca tina partisi anu béda

skéma ieu greatly ngurangan pajeulitna calo Kafka dibandingkeun distribusi pesen diperlukeun pikeun ngajaga antrian JMS. Di dieu anjeun teu kedah hariwang ngeunaan titik-titik ieu:

• Konsumén mana anu kedah nampi pesen salajengna, dumasar kana alokasi round-robin, kapasitas panyangga prefetch ayeuna, atanapi pesen sateuacana (sapertos kanggo grup pesen JMS).
• Pesen mana anu dikirim ka konsumen sareng naha éta kedah dikirimkeun deui upami gagal.

Sadaya anu kedah dilakukeun ku calo Kafka nyaéta ngirim pesen sacara berurutan ka konsumen nalika anu terakhir naroskeunana.

Sanajan kitu, sarat pikeun parallelizing nu Koréksi sarta ngirimkeun deui pesen gagal teu dileungitkeun - tanggung jawab aranjeunna saukur ngalirkeun ti calo ka klien nu. Ieu ngandung harti yén maranéhna kudu dibawa kana akun dina kode Anjeun.

Ngirim pesen

Éta tanggung jawab produsén pesen éta pikeun mutuskeun partisi mana anu ngirim pesen. Pikeun ngartos mékanisme anu dilakukeun ieu, urang mimiti kedah mertimbangkeun naon anu leres-leres kami kirimkeun.

Sedengkeun dina JMS urang ngagunakeun struktur pesen kalawan metadata (headers jeung sipat) jeung awak ngandung payload (payload), dina Kafka pesen téh. pasangan "konci-nilai". Payload pesen dikirim salaku nilai. Konci, di sisi anu sanésna, dianggo pikeun ngabagi sareng kedah ngandung konci husus logika bisnispikeun nempatkeun pesen anu aya hubunganana dina partisi anu sami.

Dina Bab 2, urang ngabahas skenario tohan online dimana acara anu aya hubunganana kedah diolah ku hiji konsumen tunggal:

1. Rekening pamaké geus ngonpigurasi.
2. Duit dikreditkeun kana rekening.
3. A alungan dijieun nu withdraws duit ti akun.

Upami unggal acara mangrupikeun pesen anu dipasang dina topik, maka konci alami nyaéta ID akun.
Nalika pesen dikirim nganggo API Produser Kafka, éta disalurkeun ka fungsi partisi anu, upami pesen sareng kaayaan klaster Kafka ayeuna, mulihkeun ID partisi anu pesenna kedah dikirim. Fitur ieu dilaksanakeun di Java ngaliwatan panganteur Partitioner.

Interface ieu kasampak kawas kieu:

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

Palaksanaan Partitioner nganggo algoritma hashing tujuan umum standar dina konci pikeun nangtukeun partisi, atanapi round-robin upami teu aya konci anu ditunjuk. Nilai standar ieu tiasa dianggo saé dina kalolobaan kasus. Nanging, ka hareup anjeun badé nyerat nyalira.

Nulis strategi partisi anjeun sorangan

Hayu urang tingali conto dimana anjeun hoyong ngirim metadata sareng payload pesen. Payload dina conto urang mangrupa parentah pikeun nyieun deposit ka akun kaulinan. Parentah mangrupikeun hal anu urang hoyong dijamin moal dirobih nalika pangiriman sareng hoyong mastikeun yén ngan ukur sistem hulu anu dipercaya tiasa ngamimitian paréntah éta. Dina hal ieu, sistem ngirim sareng nampi satuju kana panggunaan tanda tangan pikeun ngabuktoskeun kaaslianana pesen.
Dina JMS normal, urang ngan saukur nangtukeun sipat "tanda tangan pesen" sareng nambihanana kana pesen. Nanging, Kafka henteu masihan kami mékanisme pikeun ngalirkeun metadata, ngan ukur konci sareng nilai.

Kusabab nilaina nyaéta payload transfer bank anu integritasna kami hoyong jaga, kami henteu gaduh pilihan tapi nangtukeun struktur data anu dianggo dina konci. Anggap urang peryogi ID akun pikeun ngabagi, sabab sadaya pesen anu aya hubunganana sareng akun kedah diolah dina urutan, kami bakal ngahasilkeun struktur JSON ieu:

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

Kusabab nilai tanda tangan bakal rupa-rupa gumantung kana payload, strategi hashing standar tina panganteur Partitioner moal reliably grup pesen patali. Ku alatan éta, urang kudu nulis strategi urang sorangan nu bakal parse konci ieu jeung partisi nilai accountId.

Kafka kalebet checksums pikeun ngadeteksi korupsi pesen di toko sareng gaduh set lengkep fitur kaamanan. Sanaos kitu, syarat khusus industri, sapertos di luhur, kadang muncul.

Strategi partisi pangguna kedah mastikeun yén sadaya pesen anu aya hubunganana mungkas dina partisi anu sami. Sanaos ieu sigana saderhana, syaratna tiasa nyusahkeun ku pentingna mesen pesen anu aya hubunganana sareng kumaha tetep jumlah partisi dina topik.

Jumlah partisi dina topik bisa ngarobah kana waktu, sabab bisa ditambahkeun lamun lalulintas mana saluareun ekspektasi awal. Ku kituna, konci pesen bisa pakait jeung partisi maranéhanana asalna dikirim ka, implying sapotong kaayaan dibagi antara instansi produser.

Faktor séjén anu kedah dipertimbangkeun nyaéta distribusi pesen anu rata dina partisi. Ilaharna, konci teu disebarkeun merata sakuliah seratan, sarta fungsi hash teu ngajamin sebaran adil pesen pikeun set leutik konci.
Penting pikeun dicatet yén kumaha ogé anjeun milih pikeun ngabagi pesen, separator sorangan panginten kedah dianggo deui.

Pertimbangkeun sarat pikeun ngayakeun réplikasi data antara klaster Kafka dina lokasi géografis anu béda. Pikeun tujuan ieu, Kafka hadir sareng alat garis paréntah anu disebut MirrorMaker, anu dianggo pikeun maca pesen tina hiji klaster sareng nransperkeunana ka anu sanés.

MirrorMaker kedah ngartos konci topik replicated guna ngajaga urutan relatif antara pesen nalika ngayakeun réplikasi antara klaster, saprak jumlah partitions pikeun topik nu bisa jadi teu sarua dina dua klaster.

Strategi partisi khusus jarang jarang, sabab hashing atanapi round robin tiasa dianggo saé dina kalolobaan skenario. Nanging, upami anjeun peryogi jaminan pesenan anu kuat atanapi kedah nimba metadata tina payloads, maka partisi mangrupikeun hal anu anjeun kedah tingali.

Kauntungan skalabilitas sareng kinerja Kafka asalna tina mindahkeun sababaraha tanggung jawab calo tradisional ka klien. Dina hal ieu, kaputusan dijieun pikeun ngadistribusikaeun pesen berpotensi patali diantara sababaraha konsumén gawe dina paralel.

calo JMS ogé kudu nungkulan syarat sapertos. Narikna, mékanisme pikeun ngirim pesen anu aya hubunganana ka konsumen anu sami, dilaksanakeun ngaliwatan JMS Message Groups (variasi dina strategi sticky load balancing (SLB)), ogé ngabutuhkeun pangirim pikeun nandaan pesen anu aya hubunganana. Dina kasus JMS, calo nu tanggung jawab ngirim grup ieu pesen patali ka hiji konsumen kaluar loba, sarta mindahkeun kapamilikan grup lamun konsumen ragrag kaluar.

pasatujuan produser

Partisi sanes hiji-hijina hal anu kedah dipertimbangkeun nalika ngirim pesen. Hayu urang tingali metode kirim () kelas Produser dina Java API:

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

Ieu kudu geuwat dicatet yén duanana métode balik Future, nu nunjukkeun yén operasi ngirim teu dilaksanakeun langsung. Hasilna nyaéta pesen (ProducerRecord) ditulis kana panyangga kirim pikeun tiap partisi aktip sareng dikirim ka calo salaku benang latar dina perpustakaan klien Kafka. Sanajan ieu ngajadikeun hal incredibly gancang, eta hartina hiji aplikasi inexperienced bisa leungit pesen lamun prosés na dieureunkeun.

Sapertos biasa, aya cara pikeun ngajantenkeun operasi kirim langkung dipercaya ku biaya kinerja. Ukuran panyangga ieu tiasa disetél ka 0, sareng benang aplikasi anu ngirim bakal kapaksa ngantosan dugi transfer pesen ka calo parantos réngsé, sapertos kieu:

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

Langkung seueur ngeunaan maca pesen

Maca pesen ngagaduhan pajeulitna tambahan anu kedah disangka-sangka. Teu kawas API JMS, nu bisa ngajalankeun pangdéngé pesen di respon kana pesen, éta Nu meuli Kafka ukur polling. Hayu urang nempo leuwih deukeut metoda polling()dipaké pikeun tujuan ieu:

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

Nilai balik metoda nyaeta struktur wadahna ngandung sababaraha objék catetan konsumen tina sababaraha partisi anu berpotensi. catetan konsumen nya éta sorangan objék wadah pikeun pasangan konci-nilai jeung metadata pakait, kayaning partisi ti mana eta diturunkeun.

Sakumaha anu dibahas dina Bab 2, urang kedah émut naon anu lumangsung kana pesen saatos suksés atanapi henteu hasil diolah, contona, upami klien henteu tiasa ngolah pesen atanapi upami éta abort. Dina JMS, ieu diurus ngaliwatan mode pangakuan. Calo bakal ngahapus pesen anu parantos diolah, atanapi ngirimkeun deui pesen atah atanapi palsu (anggap transaksi dianggo).
Kafka dianggo béda pisan. Pesen teu dihapus dina calo sanggeus proofreading, sarta naon kajadian on gagalna tanggung jawab kode proofreading sorangan.

Salaku geus kami ngomong, grup konsumen pakait jeung offset dina log. Posisi log pakait sareng offset ieu pakait jeung pesen salajengna bakal dikaluarkeun dina respon kana polling(). Titik dina waktos nalika offset naek ieu decisive pikeun bacaan.

Balik deui kana modél maca anu dibahas tadi, ngolah pesen diwangun ku tilu tahapan:

1. Kéngingkeun pesen pikeun dibaca.
2. Ngolah pesen.
3. Konfirmasi pesen.

Konsumén Kafka hadir sareng pilihan konfigurasi enable.auto.commit. Ieu mangrupikeun setélan standar anu sering dianggo, sapertos biasa sareng setélan anu ngandung kecap "otomatis".

Sateuacan Kafka 0.10, klien anu nganggo pilihan ieu bakal ngirim offset pesen terakhir anu dibaca dina telepon salajengna. polling() sanggeus ngolah. Ieu hartosna pesen naon waé anu parantos dicandak tiasa diolah deui upami klien parantos ngolahna tapi teu disangka-sangka ancur sateuacan nelepon. polling(). Kusabab calo nu teu tetep kaayaan naon wae ngeunaan sabaraha kali pesen geus dibaca, konsumen salajengna nu retrieves pesen moal nyaho nanaon goréng lumangsung. Paripolah ieu pseudo-transactional. Offset ieu ngan komitmen lamun pesen ieu hasil diolah, tapi lamun klien aborted, calo bakal ngirim pesen sarua deui ka klien sejen. Paripolah ieu konsisten sareng jaminan pangiriman pesen "sahenteuna sakali".

Dina Kafka 0.10, kodeu klien parantos dirobih supados komitmen dipicu périodik ku perpustakaan klien, sakumaha dikonpigurasikeun. auto.commit.interval.ms. Paripolah ieu aya di antara mode JMS AUTO_ACKNOWLEDGE sareng DUPS_OK_ACKNOWLEDGE. Nalika nganggo autocommit, pesen tiasa dilakukeun henteu paduli naha éta leres-leres diolah - ieu tiasa kajantenan dina kasus konsumen anu lambat. Lamun konsumen aborted, pesen bakal fetched ku konsumen salajengna, dimimitian dina posisi komitmen, nu bisa ngakibatkeun pesen lasut. Dina hal ieu, Kafka henteu kaleungitan pesen, kode bacaanna henteu ngolahna.

Modeu ieu gaduh janji anu sami sareng versi 0.9: pesen tiasa diolah, tapi upami gagal, offset moal tiasa dilakukeun, anu berpotensi nyababkeun pangiriman dua kali. Langkung seueur pesen anu anjeun pikahoyong nalika ngalaksanakeun polling(), beuki masalah ieu.

Sapertos anu dibahas dina "Maca Pesen tina Antrian" dina kaca 21, teu aya hiji-waktos pangiriman pesen dina sistem olahtalatah nalika modeu gagal dipertimbangkeun.

Dina Kafka, aya dua cara pikeun ngalakukeun (commit) offset (offset): otomatis sareng manual. Dina duanana kasus, talatah bisa diolah sababaraha kali lamun talatah ieu diolah tapi gagal saméméh komitmen. Anjeun ogé tiasa milih henteu ngolah pesen upami komitna kajantenan di latar tukang sareng kode anjeun parantos réngsé sateuacan tiasa diolah (panginten dina Kafka 0.9 sareng sateuacana).

Anjeun tiasa ngadalikeun prosés komit offset manual dina API konsumen Kafka ku netepkeun parameter enable.auto.commit pikeun palsu sareng sacara eksplisit nyauran salah sahiji metodeu ieu:

void commitSync();
void commitAsync();

Upami anjeun hoyong ngolah pesen "sahenteuna sakali", anjeun kedah ngalakukeun offset ku cara manual commitSync()ku ngajalankeun paréntah ieu langsung saatos ngolah pesen.

Métode ieu henteu ngijinkeun pesen pikeun diakui sateuacan diprosés, tapi aranjeunna henteu ngalakukeun nanaon pikeun ngaleungitkeun poténsi telat ngolah bari masihan penampilan transaksional. Henteu aya transaksi di Kafka. Klién henteu gaduh kamampuan pikeun ngalakukeun ieu:

• Otomatis gulung deui pesen palsu. Konsumén sorangan kedah ngadamel pengecualian anu timbul tina beban masalah sareng gangguan backend, sabab henteu tiasa ngandelkeun calo pikeun ngirimkeun deui pesen.
• Kirim pesen ka sababaraha topik dina hiji operasi atom. Salaku bakal urang tingali sakeudeung, kontrol ngaliwatan jejer béda jeung partitions bisa reside dina mesin béda dina klaster Kafka nu teu koordinat transaksi nalika dikirim. Dina waktos tulisan ieu, sababaraha padamelan parantos dilakukeun pikeun ngajantenkeun ieu sareng KIP-98.
• Kaitkeun maca hiji pesen tina hiji topik sareng ngirim pesen anu sanés ka topik anu sanés. Deui, arsitéktur Kafka gumantung kana loba mesin bebas ngajalankeun salaku hiji beus na euweuh usaha dilakukeun pikeun nyumputkeun ieu. Contona, euweuh komponén API nu bakal ngidinan Anjeun pikeun numbu nu meuli и Produser dina hiji transaksi. Dina JMS, ieu disadiakeun ku obyék sidangti nu dijieun MessageProducers и MessageConsumers.

Lamun urang teu bisa ngandelkeun transaksi, kumaha urang bisa nyadiakeun semantik ngadeukeutan ka nu disadiakeun ku sistem olahtalatah tradisional?

Upami aya kamungkinan yén offset konsumen tiasa ningkat sateuacan pesen diolah, sapertos nalika kacilakaan konsumen, maka konsumen henteu terang upami grup konsumen na sono pesen nalika ditugaskeun partisi. Jadi salah sahiji strategi nyaéta mundur offset ka posisi saméméhna. API konsumen Kafka nyayogikeun metodeu ieu pikeun ieu:

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

Metode neangan() bisa dipaké kalawan métode
offsetsForTimes(Peta cap waktuToSearch) pikeun mundur ka hiji kaayaan dina sababaraha titik nu geus kaliwat.

Sacara implisit, ngagunakeun pendekatan ieu ngandung harti yén kamungkinan pisan yén sababaraha pesen anu diolah saacanna bakal dibaca sareng diolah deui. Pikeun ngahindarkeun ieu, urang tiasa nganggo bacaan idempotent, sakumaha anu dijelaskeun dina Bab 4, pikeun ngalacak pesen anu ditingali sateuacana sareng ngaleungitkeun duplikat.

Alternatipna, kode konsumen Anjeun bisa diteundeun basajan, salami leungitna pesen atawa duplikasi bisa ditarima. Nalika urang nganggap kasus pamakean dimana Kafka biasa dianggo, sapertos nanganan acara log, métrik, pelacak klik, sareng sajabana, urang ngartos yén leungitna pesen individu henteu mungkin gaduh dampak anu signifikan dina aplikasi di sakurilingna. Dina kasus sapertos kitu, nilai standar tiasa ditampi. Di sisi anu sanés, upami aplikasi anjeun kedah ngirim pamayaran, anjeun kedah ati-ati ngurus unggal pesen individu. Éta sadayana turun kana kontéks.

Pengamatan pribadi nunjukkeun yén nalika inténsitas pesen ningkat, nilai unggal pesen individu turun. Talatah badag condong jadi berharga lamun ditempo dina bentuk aggregated.

Kasadiaan tinggi

Pendekatan Kafka pikeun kasadiaan anu luhur béda pisan sareng pendekatan ActiveMQ. Kafka dirarancang sakitar kluster skala dimana sadaya instansi calo nampi sareng nyebarkeun pesen dina waktos anu sami.

Kluster Kafka diwangun ku sababaraha instansi calo anu ngajalankeun dina server anu béda. Kafka dirancang pikeun dijalankeun dina hardware mandiri biasa, dimana unggal titik gaduh panyimpenan khusus sorangan. Pamakéan jaringan attached storage (SAN) henteu disarankeun sabab sababaraha titik komputasi tiasa bersaing pikeun waktos.Ыe interval neundeun jeung nyieun konflik.

Kafka téh salawasna on sistem. Seueur pangguna Kafka anu ageung henteu kantos mareuman klasterna sareng parangkat lunakna sok ngapdet kalayan balikan deui sacara berurutan. Ieu kahontal ku ngajamin kasaluyuan sareng versi sateuacana pikeun pesen sareng interaksi antara calo.

Calo disambungkeun ka klaster server Kebon Binatang, nu tindakan minangka pendaptaran data konfigurasi sarta dipaké pikeun koordinat kalungguhan unggal calo. ZooKeeper sorangan sistem disebarkeun nu nyadiakeun kasadiaan tinggi ngaliwatan réplikasi informasi ku ngadegkeun kuorum.

Dina kasus dasar, topik didamel dina klaster Kafka kalayan sipat ieu:

• Jumlah partisi. Sakumaha anu dibahas sateuacana, nilai pasti anu dianggo di dieu gumantung kana tingkat bacaan paralel anu dipikahoyong.
• Faktor réplikasi (faktor) nangtukeun sabaraha instansi calo dina klaster kudu ngandung log pikeun partisi ieu.

Nganggo ZooKeepers pikeun koordinasi, Kafka nyobian ngadistribusikaeun partisi anyar anu adil diantara calo dina kluster. Hal ieu dilakukeun ku hiji conto anu tindakan minangka Controller.

Dina runtime pikeun tiap partisi topik Kontroller napelkeun kalungguhan ka calo a pamingpin (pamimpin, master, presenter) jeung pengikut (pengikut, budak, bawahan). Calo, anu bertindak salaku pamimpin pikeun partisi ieu, tanggung jawab pikeun nampi sadaya pesen anu dikirim ku produsén sareng nyebarkeun pesen ka konsumén. Nalika pesen dikirim ka partisi topik, aranjeunna direplikasi ka sadaya titik calo anu bertindak salaku pengikut pikeun partisi éta. Unggal titik anu ngandung log pikeun partisi disebut replika. Calo tiasa janten pamimpin pikeun sababaraha partisi sareng salaku pengikut pikeun anu sanés.

A follower ngandung sakabéh pesen dicekel ku pamingpin disebut replika disingkronkeun (replika anu aya dina kaayaan singkronisasi, replika in-sync). Upami calo anu bertindak salaku pamimpin pikeun partisi turun, calo naon waé anu diropéa atanapi disingkronkeun pikeun partisi éta tiasa nyandak alih peran pamimpin. Ieu desain incredibly sustainable.

Bagian tina konfigurasi produser nyaéta parameter acks, nu nangtukeun sabaraha réplika kudu ngaku (ngaku) ​​narima pesen saméméh thread aplikasi terus ngirim: 0, 1, atawa sakabéh. Lamun disetel ka sadaya, teras nalika pesen ditampi, pamimpin bakal ngirim konfirmasi deui ka produser pas nampi konfirmasi (acknowledgements) tina rékaman tina sababaraha cues (kaasup sorangan) ditetepkeun ku setting topik. min.insync.replicas (standar 1). Upami pesen henteu tiasa suksés ditiru, maka produser bakal ngalungkeun pengecualian aplikasi (TeuCukupReplika atawa NotEnoughReplikasAfterAppend).

Konfigurasi has nyiptakeun topik kalayan faktor réplikasi 3 (1 pamimpin, 2 pengikut per partisi) sareng parameter. min.insync.replicas disetel ka 2. Dina hal ieu, klaster bakal ngidinan salah sahiji calo ngatur partisi topik turun tanpa mangaruhan aplikasi klien.

Ieu brings kami balik ka trade-off geus akrab antara kinerja jeung reliabilitas. Réplikasi lumangsung dina biaya waktos ngantosan tambahan pikeun konfirmasi (acknowledgments) ti pengikut. Sanajan, sabab dijalankeun dina paralel, réplikasi ka sahanteuna tilu titik boga kinerja anu sarua sakumaha dua (ignoring kanaékan pamakéan rubakpita jaringan).

Ku ngagunakeun skéma réplikasi ieu, Kafka cleverly avoids kabutuhan fisik nulis unggal pesen ka disk kalawan operasi. singkronisasi (). Unggal pesen anu dikirim ku produsén bakal diserat kana log partisi, tapi sakumaha anu dibahas dina Bab 2, nyerat kana file mimitina dilakukeun dina panyangga sistem operasi. Upami seratan ieu ditiru kana conto Kafka anu sanés sareng aya dina mémorina, leungitna pamimpin henteu hartosna yén pesen éta sorangan leungit - éta tiasa dicandak ku réplika anu disingkronkeun.
Panolakan pikeun ngalakukeun operasi singkronisasi () hartosna Kafka tiasa nampi pesen sagancangna tiasa nyerat kana mémori. Sabalikna, beuki lila anjeun bisa nyingkahan flushing memori ka disk, nu hadé. Ku sabab kitu, teu ilahar keur calo Kafka anu disadiakeun 64 GB atawa leuwih memori. Pamakéan mémori ieu ngandung harti yén hiji conto Kafka bisa kalayan gampang ngajalankeun dina speeds rébuan kali leuwih gancang ti calo pesen tradisional.

Kafka ogé tiasa dikonpigurasi pikeun nerapkeun operasi singkronisasi () mun pesen bungkusan. Kusabab sadayana di Kafka berorientasi pakét, éta leres-leres tiasa dianggo pikeun seueur kasus pamakean sareng mangrupikeun alat anu kapaké pikeun pangguna anu peryogi jaminan anu kuat. Seueur pagelaran murni Kafka asalna tina pesen anu dikirim ka calo salaku pakét sareng pesen ieu dibaca ti calo dina blok sequential nganggo nol salinan operasi (operasi salila tugas nyalin data ti hiji wewengkon memori ka nu sejen teu dipigawé). Kiwari dimungkinkeun mangrupakeun kinerja badag sarta gain sumberdaya sarta ngan mungkin ngaliwatan pamakéan hiji struktur data log kaayaan anu ngahartikeun skéma partisi.

Kinerja anu langkung saé mungkin dina klaster Kafka tibatan ku calo Kafka tunggal, sabab partisi topik tiasa skala dina seueur mesin anu misah.

hasil

Dina bab ieu, urang nempo kumaha arsitéktur Kafka reimagines hubungan antara klien tur calo nyadiakeun hiji pipa olahtalatah incredibly mantap, kalawan throughput sababaraha kali leuwih gede dibandingkeun calo pesen konvensional. Kami parantos ngabahas fungsionalitas anu dianggo pikeun ngahontal ieu sareng sakeudeung ningali arsitektur aplikasi anu nyayogikeun fungsionalitas ieu. Dina bab salajengna, urang bakal ningali masalah umum anu kedah direngsekeun ku aplikasi dumasar olahtalatah sareng ngabahas strategi pikeun nungkulanana. Urang bakal mungkas bab ku outlining cara ngobrol ngeunaan téknologi olahtalatah sacara umum jadi Anjeun bisa evaluate kasesuaian maranéhanana pikeun kasus pamakéan Anjeun.

Bagian anu ditarjamahkeun saméméhna: Pamahaman calo pesen. Diajar mékanika olahtalatah sareng ActiveMQ sareng Kafka. Bab 1

Tarjamahan réngsé: tele.gg/middle_java

Ngalajengkeun…

Ngan pamaké nu kadaptar bisa ilubiung dina survey. Daptar, Punten.

Naha Kafka dianggo dina organisasi anjeun?

• yen

• teu

• Baheula dipaké, ayeuna henteu

• Urang rencanana ngagunakeun

38 pamaké milih. 8 pamaké abstained.

sumber: www.habr.com