Kuelewa madalali wa ujumbe. Kujifunza mbinu za kutuma ujumbe na ActiveMQ na Kafka. Sura ya 3. Kafka

Muendelezo wa tafsiri ya kitabu kidogo:
Kuelewa Madalali wa Ujumbe
mwandishi: Jakub Korab, mchapishaji: O'Reilly Media, Inc., tarehe ya kuchapishwa: Juni 2017, ISBN: 9781492049296.

Sehemu iliyotafsiriwa hapo awali: Kuelewa madalali wa ujumbe. Kujifunza mbinu za kutuma ujumbe na ActiveMQ na Kafka. Sura ya 1 Utangulizi

SURA YA 3

Kafka

Kafka ilitengenezwa katika LinkedIn ili kukabiliana na baadhi ya mapungufu ya madalali wa ujumbe wa kitamaduni na kuzuia kulazimika kusanidi madalali wengi wa ujumbe kwa mwingiliano tofauti wa hatua kwa hatua, ambao umefafanuliwa katika kitabu hiki chini ya "Kuongeza na kutoka" kwenye ukurasa wa 28. .Kesi za utumiaji LinkedIn imeegemea kwa kiasi kikubwa katika kumeza kwa njia moja kiasi kikubwa sana cha data, kama vile mibofyo ya kurasa na kumbukumbu za ufikiaji, huku bado ikiruhusu data hiyo kutumiwa na mifumo mingi bila kuathiri tija ya wazalishaji au watumiaji wengine. Kwa kweli, sababu ya Kafka kuwepo ni kupata aina ya usanifu wa ujumbe ambao Bomba la Data la Universal linaelezea.

Kwa kuzingatia lengo hili kuu, mahitaji mengine yaliibuka. Kafka inapaswa:

• Kuwa mwepesi sana
• Toa kipimo data zaidi unapofanya kazi na ujumbe
• Msaada wa Mchapishaji-Mteja na mifano ya Point-to-Point
• Usipunguze kasi kwa kuongeza watumiaji. Kwa mfano, utendakazi wa foleni na mada katika ActiveMQ hupungua kadri idadi ya watumiaji inavyoongezeka kwenye lengwa.
• Kuwa scalable usawa; ikiwa wakala mmoja anayedumisha ujumbe anaweza kufanya hivyo kwa kasi ya juu ya diski, basi inaleta maana kwenda zaidi ya mfano mmoja wa wakala ili kuongeza utendaji.
• Weka kikomo cha ufikiaji wa kuhifadhi na kurejesha ujumbe

Ili kufanikisha haya yote, Kafka ilipitisha usanifu ambao ulifafanua upya majukumu na majukumu ya wateja na madalali wa ujumbe. Muundo wa JMS una mwelekeo wa wakala sana, ambapo wakala anawajibika kusambaza ujumbe na wateja wanapaswa tu kuwa na wasiwasi kuhusu kutuma na kupokea ujumbe. Kafka, kwa upande mwingine, inazingatia mteja, mteja akichukua sifa nyingi za wakala wa jadi, kama vile usambazaji wa haki wa ujumbe muhimu kwa watumiaji, badala ya wakala wa haraka sana na hatari. Kwa watu ambao wamefanya kazi na mifumo ya jadi ya ujumbe, kufanya kazi na Kafka kunahitaji mabadiliko ya kimsingi ya akili.
Mwelekeo huu wa uhandisi umesababisha kuundwa kwa miundombinu ya ujumbe inayoweza kuongeza upitishaji kwa maagizo mengi ya ukubwa ikilinganishwa na wakala wa kawaida. Kama tutakavyoona, mbinu hii inakuja na biashara, ambayo ina maana kwamba Kafka haifai kwa aina fulani za mzigo wa kazi na programu zilizowekwa.

Muundo Uliounganishwa wa Lengwa

Ili kutimiza mahitaji yaliyoelezwa hapo juu, Kafka imeunganisha uchapishaji-jisajili na ujumbe wa uhakika chini ya aina moja ya lengwa - mada. Hii inachanganya kwa watu ambao wamefanya kazi na mifumo ya ujumbe, ambapo neno "mada" hurejelea utaratibu wa utangazaji ambao (kutoka kwa mada) usomaji hauwezi kudumu. Mada za Kafka zinafaa kuchukuliwa kama aina ya lengwa la mseto, kama ilivyofafanuliwa katika utangulizi wa kitabu hiki.

Kwa sehemu iliyosalia ya sura hii, isipokuwa tuseme vinginevyo kwa uwazi, neno "mada" litarejelea mada ya Kafka.

Ili kuelewa kikamilifu jinsi mada zinavyofanya kazi na ni dhamana gani zinatoa, tunahitaji kwanza kuangalia jinsi yanavyotekelezwa katika Kafka.
Kila mada katika Kafka ina logi yake.
Watayarishaji wanaotuma ujumbe kwa Kafka huandika kwa kumbukumbu hii, na watumiaji husoma kutoka kwa kumbukumbu kwa kutumia viashiria vinavyosonga mbele kila mara. Mara kwa mara, Kafka hufuta sehemu kuu za kumbukumbu, iwe ujumbe katika sehemu hizo umesomwa au la. Sehemu kuu ya muundo wa Kafka ni kwamba wakala hajali ikiwa ujumbe unasomwa au la - hilo ni jukumu la mteja.

Maneno "logi" na "pointer" hayaonekani Nyaraka za Kafka. Maneno haya yanayojulikana sana hutumiwa hapa kusaidia kuelewa.

Muundo huu ni tofauti kabisa na ActiveMQ, ambapo ujumbe kutoka kwa foleni zote huhifadhiwa kwenye kumbukumbu moja, na wakala huweka alama kuwa ujumbe umefutwa baada ya kusomwa.
Wacha sasa tuchimbe kwa undani zaidi na tuangalie logi ya mada kwa undani zaidi.
Logi ya Kafka ina sehemu kadhaa (Kielelezo 3-1) Kafka inahakikisha kuagiza kali katika kila kizigeu. Hii inamaanisha kuwa ujumbe ulioandikwa kwa kizigeu kwa mpangilio fulani utasomwa kwa mpangilio sawa. Kila kizigeu kinatekelezwa kama faili ya kumbukumbu inayozunguka ambayo ina kikundi kidogo (seti ndogo) ya jumbe zote zinazotumwa kwa mada na watayarishaji wake. Mada iliyoundwa ina, kwa chaguo-msingi, kizigeu kimoja. Wazo la partitions ni wazo kuu la Kafka kwa kuongeza usawa.

Kielelezo 3-1. Sehemu za Kafka

Mtayarishaji anapotuma ujumbe kwa mada ya Kafka, huamua ni sehemu gani ya kutuma ujumbe huo. Tutaliangalia hili kwa undani zaidi baadaye.

Kusoma ujumbe

Mteja anayetaka kusoma ujumbe anasimamia kielekezi kilichoitwa kinachoitwa kikundi cha watumiaji, ambayo inaashiria kukabiliana ujumbe katika sehemu. Kusawazisha ni nafasi ya nyongeza inayoanzia 0 mwanzoni mwa kizigeu. Kikundi hiki cha watumiaji, kinachorejelewa katika API kupitia kitambulisho cha mtumiaji-kinacholingana na mtumiaji mmoja mwenye mantiki au mfumo.

Mifumo mingi ya utumaji ujumbe husoma data kutoka lengwa kwa kutumia matukio na nyuzi nyingi kuchakata ujumbe kwa sambamba. Kwa hivyo, kutakuwa na matukio mengi ya watumiaji kushiriki kundi moja la watumiaji.

Tatizo la kusoma linaweza kuwakilishwa kama ifuatavyo:

• Mada ina sehemu nyingi
• Mada inaweza kutumika na vikundi vingi vya watumiaji kwa wakati mmoja
• Kundi la watumiaji linaweza kuwa na matukio mengi tofauti

Hili ni tatizo lisilo dogo la wengi kwa wengi. Ili kuelewa jinsi Kafka inavyoshughulikia uhusiano kati ya vikundi vya watumiaji, hali za watumiaji, na sehemu, wacha tuangalie mfululizo wa hali ngumu zaidi za usomaji.

Watumiaji na vikundi vya watumiaji

Wacha tuchukue mada na kizigeu kimoja kama sehemu ya kuanzia (Kielelezo 3-2).

Kielelezo 3-2. Mtumiaji anasoma kutoka kwa kizigeu

Mfano wa mtumiaji unapounganishwa na group_id yake kwa mada hii, hupewa kizigeu cha kusoma na kukabiliana katika kizigeu hicho. Nafasi ya urekebishaji huu inaweza kusanidiwa katika mteja kama kiashirio cha nafasi ya hivi karibuni (ujumbe mpya zaidi) au nafasi ya mapema zaidi (ujumbe wa zamani zaidi). Mtumiaji huomba (ujumbe) kutoka kwa mada, ambayo husababisha kusomwa kwa mpangilio kutoka kwa logi.
Nafasi ya kukabiliana mara kwa mara hutolewa kwa Kafka na kuhifadhiwa kama ujumbe katika mada ya ndani _mapunguzo_ya_mtumiaji. Barua pepe zilizosomwa bado hazijafutwa, tofauti na wakala wa kawaida, na mteja anaweza kurudisha nyuma urekebishaji ili kuchakata tena ujumbe uliotazamwa.

Wakati mtumiaji wa pili wa kimantiki anapounganisha kwa kutumia group_id tofauti, inasimamia pointer ya pili ambayo ni huru na ya kwanza (Kielelezo 3-3) Kwa hivyo, mada ya Kafka hufanya kama foleni ambapo kuna mtumiaji mmoja na kama mada ya kawaida ya uchapishaji wa kuchapisha (pub-sub) ambayo watumiaji wengi hujiandikisha, kwa manufaa ya ziada kwamba ujumbe wote huhifadhiwa na unaweza kuchakatwa mara nyingi.

Kielelezo 3-3. Watumiaji wawili katika vikundi tofauti vya watumiaji husoma kutoka kwa kizigeu sawa

Watumiaji katika kikundi cha watumiaji

Wakati tukio moja la mtumiaji linasoma data kutoka kwa kizigeu, ina udhibiti kamili wa kielekezi na kuchakata ujumbe kama ilivyoelezwa katika sehemu iliyotangulia.
Ikiwa matukio kadhaa ya watumiaji yaliunganishwa na group_id sawa kwa mada yenye kizigeu kimoja, basi mfano uliounganishwa mwisho utapewa udhibiti wa pointer na kuanzia wakati huo itapokea ujumbe wote (Kielelezo 3-4).

Kielelezo 3-4. Watumiaji wawili katika kundi moja la watumiaji walisoma kutoka kwa kizigeu sawa

Njia hii ya usindikaji, ambayo idadi ya matukio ya watumiaji huzidi idadi ya kizigeu, inaweza kuzingatiwa kama aina ya watumiaji wa kipekee. Hii inaweza kuwa muhimu ikiwa unahitaji mkusanyiko wa "active-passive" (au "hot-joto") wa matukio yako ya watumiaji, ingawa kuendesha watumiaji wengi sambamba ("active-active" au "hot-hot") ni kawaida zaidi kuliko watumiaji katika hali ya kusubiri.

Tabia hii ya usambazaji wa ujumbe iliyoelezwa hapo juu inaweza kushangaza ikilinganishwa na jinsi foleni ya kawaida ya JMS inavyofanya kazi. Katika mfano huu, ujumbe uliotumwa kwenye foleni utasambazwa sawasawa kati ya watumiaji wawili.

Mara nyingi, tunapounda hali nyingi za watumiaji, tunafanya hivi ama kuchakata ujumbe kwa sambamba, au kuongeza kasi ya kusoma, au kuongeza uthabiti wa mchakato wa kusoma. Kwa kuwa mfano mmoja tu wa watumiaji unaweza kusoma data kutoka kwa kizigeu kwa wakati mmoja, hii inafikiwaje huko Kafka?

Njia moja ya kufanya hivyo ni kutumia mfano mmoja wa watumiaji kusoma ujumbe wote na kuupitisha kwenye dimbwi la nyuzi. Ingawa mbinu hii inaongeza uchakataji, huongeza ugumu wa mantiki ya watumiaji na haifanyi chochote kuongeza uimara wa mfumo wa kusoma. Ikiwa nakala moja ya mtumiaji itapungua kwa sababu ya kushindwa kwa nguvu au tukio kama hilo, basi uondoaji unaacha.

Njia ya kisheria ya kutatua tatizo hili katika Kafka ni kutumia bОpartitions zaidi.

Kugawanya

Vigawanyiko ndio njia kuu ya kulinganisha usomaji na kuongeza mada zaidi ya kipimo data cha mfano mmoja wa wakala. Ili kuelewa hili vyema, hebu tuzingatie hali ambapo kuna mada iliyo na sehemu mbili na mtumiaji mmoja anajiandikisha kwa mada hii (Kielelezo 3-5).

Kielelezo 3-5. Mtumiaji mmoja anasoma kutoka kwa sehemu nyingi

Katika hali hii, mtumiaji anapewa udhibiti wa viashiria vinavyolingana na group_id yake katika sehemu zote mbili na kuanza kusoma ujumbe kutoka kwa sehemu zote mbili.
Mtumiaji wa ziada anapoongezwa kwa mada hii kwa group_id sawa, Kafka hugawa upya (kugawa upya) moja ya sehemu kutoka kwa kwanza hadi kwa mtumiaji wa pili. Baada ya hapo kila mfano wa mtumiaji utasoma kutoka sehemu moja ya mada (Kielelezo 3-6).

Ili kuhakikisha kuwa ujumbe unachakatwa kwa sambamba katika nyuzi 20, unahitaji angalau sehemu 20. Ikiwa kuna sehemu chache, utaachwa na watumiaji ambao hawana chochote cha kufanya kazi, kama ilivyoelezwa hapo awali katika majadiliano ya watumiaji wa kipekee.

Kielelezo 3-6. Watumiaji wawili katika kundi moja la watumiaji walisoma kutoka kwa sehemu tofauti

Mpango huu hupunguza kwa kiasi kikubwa utata wa wakala wa Kafka ikilinganishwa na usambazaji wa ujumbe unaohitajika ili kudumisha foleni ya JMS. Hapa huna haja ya kuwa na wasiwasi kuhusu pointi zifuatazo:

• Ni mtumiaji gani anapaswa kupokea ujumbe unaofuata, kulingana na mgao wa robin-raundi, uwezo wa sasa wa bafa za kuleta mapema, au ujumbe wa awali (kama kwa vikundi vya ujumbe wa JMS).
• Ni ujumbe gani unatumwa kwa watumiaji gani na ikiwa unapaswa kuwasilishwa tena ikiwa utashindwa.

Kinachohitajika kufanywa na wakala wa Kafka ni kupitisha ujumbe kwa mfuatano kwa mtumiaji wakati mtumiaji anapoziomba.

Walakini, mahitaji ya kusawazisha kusahihisha na kutuma tena ujumbe ulioshindwa hayaondoki - jukumu kwao hupita kutoka kwa wakala kwenda kwa mteja. Hii ina maana kwamba ni lazima izingatiwe katika msimbo wako.

Kutuma ujumbe

Ni jukumu la mtayarishaji wa ujumbe huo kuamua ni sehemu gani ya kutuma ujumbe. Ili kuelewa utaratibu ambao hii inafanywa, kwanza tunahitaji kuzingatia ni nini hasa tunatuma.

Ingawa katika JMS tunatumia muundo wa ujumbe wenye metadata (vichwa na mali) na chombo kilicho na mzigo wa malipo (mzigo), katika Kafka ujumbe ni jozi "thamani ya ufunguo". Upakiaji wa ujumbe unatumwa kama thamani. Ufunguo, kwa upande mwingine, hutumiwa hasa kwa kugawanya na lazima iwe na ufunguo maalum wa mantiki ya biasharakuweka ujumbe unaohusiana katika kizigeu sawa.

Katika Sura ya 2, tulijadili hali ya kamari mtandaoni ambapo matukio yanayohusiana yanahitaji kuchakatwa ili na mtumiaji mmoja:

1. Akaunti ya mtumiaji imesanidiwa.
2. Pesa huwekwa kwenye akaunti.
3. Dau inafanywa ambayo hutoa pesa kutoka kwa akaunti.

Ikiwa kila tukio ni ujumbe uliotumwa kwa mada, basi ufunguo wa asili utakuwa kitambulisho cha akaunti.
Ujumbe unapotumwa kwa kutumia API ya Mtayarishaji wa Kafka, hupitishwa kwa kazi ya kugawa ambayo, kutokana na ujumbe na hali ya sasa ya kundi la Kafka, hurejesha kitambulisho cha kizigeu ambacho ujumbe unapaswa kutumwa. Kipengele hiki kinatekelezwa katika Java kupitia kiolesura cha Partitioner.

Kiolesura hiki kinaonekana kama hii:

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

Utekelezaji wa Kihesabu hutumia algoriti chaguo-msingi ya madhumuni ya jumla ya kuharakisha juu ya ufunguo ili kubainisha kizigeu, au mzunguko-robin ikiwa hakuna ufunguo uliobainishwa. Thamani hii chaguo-msingi hufanya kazi vizuri katika hali nyingi. Hata hivyo, katika siku zijazo utataka kuandika yako mwenyewe.

Kuandika mkakati wako wa kugawa

Hebu tuangalie mfano ambapo unataka kutuma metadata pamoja na upakiaji wa ujumbe. Mzigo katika mfano wetu ni maagizo ya kuweka pesa kwenye akaunti ya mchezo. Maagizo ni jambo ambalo tungependa kuhakikishiwa lisirekebishwe tunapotuma na tunataka kuwa na uhakika kwamba ni mfumo unaoaminika tu wa juu unaoweza kuanzisha maagizo hayo. Katika kesi hii, mifumo ya kutuma na kupokea inakubaliana juu ya matumizi ya saini ili kuthibitisha ujumbe.
Katika JMS ya kawaida, tunafafanua tu sifa ya "saini ya ujumbe" na kuiongeza kwenye ujumbe. Hata hivyo, Kafka haitupi utaratibu wa kupitisha metadata, ufunguo na thamani pekee.

Kwa kuwa thamani ni malipo ya uhamisho wa benki ambayo uaminifu wake tunataka kuhifadhi, hatuna chaguo ila kufafanua muundo wa data wa kutumia katika ufunguo. Kwa kuchukulia kuwa tunahitaji kitambulisho cha akaunti kwa ajili ya kugawa, kwa kuwa barua pepe zote zinazohusiana na akaunti lazima zichakatwa kwa mpangilio, tutakuja na muundo ufuatao wa JSON:

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

Kwa sababu thamani ya sahihi itatofautiana kulingana na upakiaji, mkakati chaguo-msingi wa hashing wa kiolesura cha Partitioner hautaweka katika vikundi ujumbe unaohusiana. Kwa hivyo, tutahitaji kuandika mkakati wetu wenyewe ambao utachanganua ufunguo huu na kugawanya thamani ya accountId.

Kafka inajumuisha pesa za hundi za kugundua ufisadi wa ujumbe kwenye duka na ina seti kamili ya vipengele vya usalama. Hata hivyo, mahitaji mahususi ya tasnia, kama ilivyo hapo juu, wakati mwingine huonekana.

Mkakati wa kugawa wa mtumiaji lazima uhakikishe kuwa barua pepe zote zinazohusiana zinaishia katika sehemu sawa. Ingawa hii inaonekana rahisi, hitaji linaweza kutatanishwa na umuhimu wa kuagiza ujumbe unaohusiana na jinsi idadi ya sehemu kwenye mada ilivyosasishwa.

Idadi ya sehemu katika mada inaweza kubadilika kwa wakati, kwani zinaweza kuongezwa ikiwa trafiki itapita zaidi ya matarajio ya awali. Kwa hivyo, funguo za ujumbe zinaweza kuhusishwa na sehemu ambazo zilitumwa hapo awali, ikimaanisha sehemu ya hali ya kushirikiwa kati ya matukio ya mzalishaji.

Jambo lingine la kuzingatia ni usambazaji sawa wa ujumbe kwenye sehemu zote. Kwa kawaida, funguo hazisambazwi sawasawa katika ujumbe wote, na vitendaji vya heshi havihakikishii usambazaji sawa wa ujumbe kwa seti ndogo ya vitufe.
Ni muhimu kutambua kwamba hata hivyo unachagua kugawanya ujumbe, kitenganishi chenyewe kinaweza kuhitaji kutumiwa tena.

Zingatia hitaji la kunakili data kati ya nguzo za Kafka katika maeneo tofauti ya kijiografia. Kwa kusudi hili, Kafka inakuja na zana ya mstari wa amri inayoitwa MirrorMaker, ambayo hutumiwa kusoma ujumbe kutoka kwa nguzo moja na kuhamisha hadi nyingine.

MirrorMaker lazima ielewe funguo za mada iliyorudiwa ili kudumisha mpangilio linganifu kati ya ujumbe wakati wa kunakili kati ya makundi, kwa kuwa idadi ya sehemu za mada hiyo inaweza isiwe sawa katika makundi mawili.

Mikakati maalum ya kugawanya ni nadra sana, kwani hashing chaguo-msingi au robin ya pande zote hufanya kazi vyema katika hali nyingi. Walakini, ikiwa unahitaji dhamana kali ya kuagiza au unahitaji kutoa metadata kutoka kwa upakiaji, basi kugawa ni jambo ambalo unapaswa kuliangalia kwa karibu.

Manufaa na utendakazi wa Kafka hutoka kwa kuhamisha baadhi ya majukumu ya wakala wa jadi kwa mteja. Katika kesi hii, uamuzi unafanywa ili kusambaza ujumbe unaowezekana kati ya watumiaji kadhaa wanaofanya kazi kwa sambamba.

Madalali wa JMS pia wanahitaji kushughulikia mahitaji kama haya. Jambo la kufurahisha ni kwamba utaratibu wa kutuma ujumbe unaohusiana kwa mtumiaji yule yule, unaotekelezwa kupitia Vikundi vya Ujumbe wa JMS (tofauti kwenye mkakati wa kusawazisha mzigo unaonata (SLB)), pia unahitaji mtumaji kutia alama kuwa ujumbe unahusiana. Kwa upande wa JMS, wakala anawajibika kutuma kikundi hiki cha jumbe zinazohusiana kwa mtumiaji mmoja kati ya nyingi, na kuhamisha umiliki wa kikundi iwapo mtumiaji atashindwa.

Makubaliano ya Watayarishaji

Kugawanya sio jambo pekee la kuzingatia wakati wa kutuma ujumbe. Wacha tuangalie send() njia za darasa la Mtayarishaji kwenye API ya Java:

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

Inapaswa kuzingatiwa mara moja kwamba njia zote mbili zinarudi Future, ambayo inaonyesha kwamba operesheni ya kutuma haifanyiki mara moja. Matokeo yake ni kwamba ujumbe (ProducerRecord) unaandikwa kwa bafa ya kutuma kwa kila sehemu inayotumika na kutumwa kwa wakala kama usuli katika maktaba ya mteja wa Kafka. Ingawa hii inafanya mambo kuwa ya haraka sana, inamaanisha kuwa programu isiyo na uzoefu inaweza kupoteza ujumbe ikiwa mchakato wake utasimamishwa.

Kama kawaida, kuna njia ya kufanya operesheni ya kutuma iwe ya kuaminika zaidi kwa gharama ya utendakazi. Saizi ya bafa hii inaweza kuwekwa kuwa 0, na mkondo wa kutuma maombi utalazimika kusubiri hadi uhamishaji wa ujumbe kwa wakala ukamilike, kama ifuatavyo:

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

Zaidi kuhusu kusoma ujumbe

Kusoma jumbe kuna matatizo ya ziada ambayo yanahitaji kukisiwa. Tofauti na API ya JMS, ambayo inaweza kuendesha msikilizaji wa ujumbe kwa kujibu ujumbe, the Consumer Uchaguzi wa Kafka pekee. Hebu tuangalie kwa karibu mbinu kura ()kutumika kwa madhumuni haya:

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

Thamani ya kurudi kwa njia ni muundo wa chombo kilicho na vitu vingi rekodi ya watumiaji kutoka kwa uwezekano wa sehemu kadhaa. rekodi ya watumiaji yenyewe ni kitu cha kishikiliaji kwa jozi ya thamani-funguo na metadata inayohusishwa, kama vile kizigeu ambacho imetolewa.

Kama ilivyojadiliwa katika Sura ya 2, ni lazima tukumbuke kile kinachotokea kwa ujumbe baada ya kushughulikiwa kwa ufanisi au bila mafanikio, kwa mfano, ikiwa mteja hawezi kushughulikia ujumbe au ukiacha. Katika JMS, hili lilishughulikiwa kupitia hali ya kukiri. Wakala atafuta ujumbe uliochakatwa kwa ufanisi, au atatoa tena ujumbe mbichi au ghushi (ikizingatiwa kuwa miamala ilitumika).
Kafka inafanya kazi tofauti sana. Ujumbe haufutwa katika wakala baada ya kusahihisha, na kinachotokea kwa kushindwa ni jukumu la msimbo wa kusahihisha yenyewe.

Kama tulivyosema, kikundi cha watumiaji kinahusishwa na kukabiliana kwenye logi. Nafasi ya kumbukumbu inayohusishwa na urekebishaji huu inalingana na ujumbe unaofuata utakaotolewa kujibu kura (). Hatua kwa wakati wakati urekebishaji huu unaongezeka ni uamuzi wa kusoma.

Kurudi kwa modeli ya kusoma iliyojadiliwa hapo awali, usindikaji wa ujumbe una hatua tatu:

1. Rejesha ujumbe kwa ajili ya kusoma.
2. Mchakato wa ujumbe.
3. Thibitisha ujumbe.

Mtumiaji wa Kafka anakuja na chaguo la usanidi wezesha.auto.commit. Huu ni mpangilio chaguo-msingi unaotumiwa mara kwa mara, kama ilivyo kawaida kwa mipangilio iliyo na neno "otomatiki".

Kabla ya Kafka 0.10, mteja anayetumia chaguo hili atatuma kukabiliana na ujumbe wa mwisho uliosomwa kwenye simu inayofuata. kura () baada ya usindikaji. Hii ilimaanisha kuwa ujumbe wowote ambao tayari umeshaletwa unaweza kuchakatwa tena ikiwa mteja alikuwa tayari ameuchakata lakini ukaharibiwa bila kutarajiwa kabla ya kupiga simu. kura (). Kwa kuwa wakala haweki hali yoyote kuhusu ni mara ngapi ujumbe umesomwa, mtumiaji anayefuata ambaye anapata ujumbe huo hatajua kuwa kuna kitu kibaya kimetokea. Tabia hii ilikuwa ya shughuli za uwongo. Urekebishaji ulifanyika tu ikiwa ujumbe ulichakatwa kwa ufanisi, lakini ikiwa mteja aliahirisha, wakala atatuma ujumbe sawa tena kwa mteja mwingine. Tabia hii iliambatana na hakikisho la uwasilishaji ujumbe "angalau mara moja".

Katika Kafka 0.10, nambari ya mteja imebadilishwa ili ahadi ianzishwe mara kwa mara na maktaba ya mteja, kama ilivyosanidiwa. auto.commit.interval.ms. Tabia hii ni mahali fulani kati ya modi za JMS AUTO_ACKNOWLEDGE na DUPS_OK_ACKNOWLEDGE. Unapotumia kujitolea kiotomatiki, ujumbe unaweza kutekelezwa bila kujali kama ulichakatwa - hii inaweza kutokea kwa mtumiaji wa polepole. Ikiwa mtumiaji alikatiza kazi, ujumbe ulirejeshwa na mtumiaji mwingine kuanzia nafasi iliyojitolea, ambayo inaweza kusababisha ujumbe kukosekana. Katika kesi hii, Kafka haikupoteza ujumbe, msimbo wa kusoma haukuzishughulikia.

Hali hii ina ahadi sawa na katika toleo la 0.9: ujumbe unaweza kuchakatwa, lakini ikishindikana, utatuzi unaweza kutotekelezwa, na hivyo kusababisha uwasilishaji kuongezeka maradufu. Kadiri ujumbe unavyozidi kuleta wakati wa kutekeleza kura (), zaidi tatizo hili.

Kama ilivyojadiliwa katika "Kusoma Ujumbe kutoka kwa Foleni" kwenye ukurasa wa 21, hakuna kitu kama uwasilishaji wa mara moja wa ujumbe katika mfumo wa ujumbe wakati hali za kutofaulu zinazingatiwa.

Katika Kafka, kuna njia mbili za kufanya (kufanya) kukabiliana (kukabiliana): moja kwa moja na kwa manually. Katika visa vyote viwili, ujumbe unaweza kuchakatwa mara kadhaa ikiwa ujumbe ulichakatwa lakini umeshindwa kabla ya ahadi. Unaweza pia kuchagua kutochakata ujumbe kabisa ikiwa ahadi ilifanyika chinichini na nambari yako ikakamilika kabla ya kuchakatwa (labda katika Kafka 0.9 na mapema).

Unaweza kudhibiti mchakato wa kujitolea wa kushughulikia kwa mwongozo katika API ya watumiaji wa Kafka kwa kuweka kigezo wezesha.auto.commit kwa uwongo na kuita moja ya njia zifuatazo:

void commitSync();
void commitAsync();

Ikiwa unataka kuchakata ujumbe "angalau mara moja", lazima utekeleze kukabiliana na wewe mwenyewe commitSync()kwa kutekeleza amri hii mara baada ya kuchakata ujumbe.

Mbinu hizi haziruhusu ujumbe kutambuliwa kabla ya kuchakatwa, lakini hazifanyi chochote ili kuondoa ucheleweshaji unaowezekana wa uchakataji huku zikitoa mwonekano wa kuwa wa shughuli. Hakuna shughuli katika Kafka. Mteja hana uwezo wa kufanya yafuatayo:

• Rejesha nyuma ujumbe ulioghushiwa kiotomatiki. Wateja wenyewe lazima washughulikie vighairi vinavyotokana na matatizo ya upakiaji na kukatika kwa nyuma, kwa kuwa hawawezi kumtegemea wakala kuwasilisha tena ujumbe.
• Tuma ujumbe kwa mada nyingi katika operesheni moja ya atomiki. Kama tutakavyoona hivi punde, udhibiti wa mada na sehemu tofauti unaweza kukaa kwenye mashine tofauti kwenye nguzo ya Kafka ambayo hairatibu shughuli za malipo zinapotumwa. Wakati wa uandishi huu, kazi fulani imefanywa ili kufanya hili liwezekane na KIP-98.
• Unganisha usomaji wa ujumbe mmoja kutoka kwa mada moja na utumaji wa ujumbe mwingine hadi mada nyingine. Tena, usanifu wa Kafka unategemea mashine nyingi za kujitegemea zinazoendesha kama basi moja na hakuna jaribio linalofanywa kuficha hili. Kwa mfano, hakuna vipengele vya API ambavyo vinaweza kukuwezesha kuunganisha mtumiaji и Mzalishaji katika shughuli. Katika JMS, hii inatolewa na kitu Kipindiambayo imeundwa Watayarishaji wa Ujumbe и UjumbeWatumiaji.

Ikiwa hatuwezi kutegemea miamala, tunawezaje kutoa semantiki karibu na zile zinazotolewa na mifumo ya jadi ya utumaji ujumbe?

Ikiwa kuna uwezekano kwamba urekebishaji wa mlaji unaweza kuongezeka kabla ya ujumbe kuchakatwa, kama vile wakati wa ajali ya watumiaji, basi mtumiaji hana njia ya kujua ikiwa kikundi chake cha watumiaji kilikosa ujumbe wakati kilipewa kizigeu. Kwa hivyo mkakati mmoja ni kurudisha nyuma mkao kwa nafasi ya awali. API ya watumiaji wa Kafka hutoa njia zifuatazo za hii:

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

Mbinu tafuta() inaweza kutumika na mbinu
offsetsForTimes(Ramani mihuri ya nyakatiToSearch) kurudi kwenye hali wakati fulani mahususi hapo awali.

Kwa hakika, kutumia mbinu hii ina maana kwamba kuna uwezekano mkubwa kwamba baadhi ya ujumbe ambao ulichakatwa hapo awali utasomwa na kuchakatwa tena. Ili kuepuka hili, tunaweza kutumia usomaji usio na uwezo, kama ilivyoelezwa katika Sura ya 4, ili kufuatilia ujumbe uliotazamwa awali na kuondoa nakala.

Vinginevyo, msimbo wako wa mtumiaji unaweza kuwekwa rahisi, mradi upotezaji wa ujumbe au kurudiwa kunakubalika. Tunapoangalia hali za utumiaji ambazo Kafka hutumiwa sana, kama vile kushughulikia matukio ya kumbukumbu, vipimo, ufuatiliaji wa mibofyo, n.k., tunagundua kuwa upotezaji wa ujumbe mahususi hauwezekani kuwa na athari kubwa kwa programu zinazozunguka. Katika hali kama hizi, maadili ya msingi yanakubalika kabisa. Kwa upande mwingine, ikiwa ombi lako linahitaji kutuma malipo, lazima utunze kwa uangalifu kila ujumbe wa kibinafsi. Yote inakuja chini ya muktadha.

Uchunguzi wa kibinafsi unaonyesha kwamba ukubwa wa ujumbe unavyoongezeka, thamani ya kila ujumbe wa mtu binafsi hupungua. Ujumbe mkubwa huwa na thamani unapotazamwa katika fomu iliyojumlishwa.

Upatikanaji wa Juu

Mbinu ya Kafka ya upatikanaji wa juu ni tofauti sana na mbinu ya ActiveMQ. Kafka imeundwa karibu na vikundi vya kusambaza data ambapo matukio yote ya wakala hupokea na kusambaza ujumbe kwa wakati mmoja.

Kundi la Kafka lina matukio mengi ya wakala wanaoendesha kwenye seva tofauti. Kafka iliundwa ili kukimbia kwenye vifaa vya kawaida vya kujitegemea, ambapo kila nodi ina uhifadhi wake wa kujitolea. Matumizi ya hifadhi iliyoambatishwa ya mtandao (SAN) haipendekezwi kwa sababu nodi nyingi za kukokotoa zinaweza kushindana kwa muda.Ыe vipindi vya kuhifadhi na kuunda migogoro.

Kafka ni daima mfumo. Watumiaji wengi wakubwa wa Kafka hawajawahi kufunga vikundi vyao na programu husasishwa kila wakati na kuanza tena kwa mpangilio. Hii inafanikiwa kwa kuhakikisha utangamano na toleo la awali la ujumbe na mwingiliano kati ya madalali.

Madalali waliounganishwa kwenye kundi la seva Mtunza Zoo, ambayo hufanya kazi kama sajili ya data ya usanidi na hutumika kuratibu majukumu ya kila wakala. ZooKeeper yenyewe ni mfumo uliosambazwa ambao hutoa upatikanaji wa juu kupitia urudufu wa habari kwa kuanzisha akidi.

Katika kesi ya msingi, mada huundwa katika nguzo ya Kafka na mali zifuatazo:

• Idadi ya partitions. Kama ilivyojadiliwa hapo awali, thamani halisi iliyotumiwa hapa inategemea kiwango kinachohitajika cha usomaji sambamba.
• Kipengele cha kurudia (sababu) huamua ni matukio ngapi ya wakala kwenye nguzo yanapaswa kuwa na kumbukumbu za kizigeu hiki.

Kwa kutumia ZooKeepers kwa uratibu, Kafka inajaribu kusambaza sehemu mpya kati ya madalali kwenye nguzo. Hii inafanywa na mfano mmoja ambao hufanya kama Mdhibiti.

Wakati wa kukimbia kwa kila sehemu ya mada Mdhibiti kupeana majukumu kwa wakala kiongozi (kiongozi, bwana, mtangazaji) na wafuasi (wafuasi, watumwa, wasaidizi). Dalali, kama kiongozi wa kizigeu hiki, ana jukumu la kupokea ujumbe wote uliotumwa kwake na watayarishaji na kusambaza ujumbe kwa watumiaji. Barua pepe zinapotumwa kwa kizigeu cha mada, zinaigwa kwa nodi zote za wakala zinazofanya kazi kama wafuasi wa kizigeu hicho. Kila nodi iliyo na magogo ya kizigeu inaitwa nakala. Dalali anaweza kuwa kiongozi kwa sehemu fulani na kama mfuasi wa zingine.

Mfuasi aliye na jumbe zote zilizohifadhiwa na kiongozi anaitwa nakala iliyosawazishwa (nakili ambayo iko katika hali iliyosawazishwa, nakala iliyosawazishwa). Iwapo wakala anayefanya kazi kama kiongozi wa kizigeu atapungua, wakala yeyote ambaye amesasishwa au aliyesawazishwa kwa ugawaji huo anaweza kuchukua jukumu la kiongozi. Ni muundo endelevu wa ajabu.

Sehemu ya usanidi wa mtayarishaji ni parameter acks, ambayo huamua ni nakala ngapi lazima zikiri (kukubali) upokezi wa ujumbe kabla ya mazungumzo ya programu kuendelea kutuma: 0, 1, au yote. Ikiwa imewekwa zote, kisha ujumbe unapopokelewa, kiongozi atatuma uthibitisho kwa mtayarishaji mara tu inapopokea uthibitisho (uthibitisho) wa rekodi kutoka kwa vidokezo kadhaa (pamoja na yenyewe) vilivyofafanuliwa na mpangilio wa mada. min.insync.replicas (chaguo-msingi 1). Ikiwa ujumbe hauwezi kuigwa kwa ufanisi, basi mtayarishaji atatupa ubaguzi wa programu (NotEnoughReplicas au NotEnoughReplicasAfterAppend).

Usanidi wa kawaida huunda mada yenye kipengele cha replication cha 3 (kiongozi 1, wafuasi 2 kwa kila kizigeu) na kigezo. min.insync.replicas imewekwa kuwa 2. Katika kesi hii, nguzo itaruhusu mmoja wa madalali wanaosimamia ugawaji wa mada kwenda chini bila kuathiri programu za mteja.

Hii inaturudisha kwenye biashara ambayo tayari inajulikana kati ya utendaji na kutegemewa. Kurudia hutokea kwa gharama ya muda wa ziada wa kusubiri kwa uthibitisho (shukrani) kutoka kwa wafuasi. Ingawa, kwa sababu inaendesha sambamba, replication kwa angalau nodi tatu ina utendaji sawa na mbili (kupuuza ongezeko la matumizi ya bandwidth ya mtandao).

Kwa kutumia mpango huu wa kuiga, Kafka huepuka kwa busara hitaji la kuandika kila ujumbe kwa diski na operesheni. kusawazisha (). Kila ujumbe unaotumwa na mtayarishaji utaandikwa kwa logi ya kizigeu, lakini kama ilivyojadiliwa katika Sura ya 2, uandishi wa faili unafanywa mwanzoni kwenye bafa ya mfumo wa uendeshaji. Ikiwa ujumbe huu unaigwa kwa mfano mwingine wa Kafka na uko kwenye kumbukumbu yake, kupoteza kwa kiongozi haimaanishi kuwa ujumbe wenyewe ulipotea - unaweza kuchukuliwa na nakala iliyosawazishwa.
Kukataa kufanya operesheni kusawazisha () ina maana kwamba Kafka inaweza kupokea ujumbe kwa haraka kama inaweza kuandika kwa kumbukumbu. Kinyume chake, kwa muda mrefu unaweza kuepuka kufuta kumbukumbu kwenye diski, ni bora zaidi. Kwa sababu hii, sio kawaida kwa madalali wa Kafka kutengewa GB 64 au zaidi ya kumbukumbu. Utumiaji huu wa kumbukumbu unamaanisha kuwa mfano mmoja wa Kafka unaweza kukimbia kwa kasi mara elfu nyingi zaidi kuliko wakala wa jadi wa ujumbe.

Kafka pia inaweza kusanidiwa ili kutumia operesheni kusawazisha () kwa vifurushi vya ujumbe. Kwa kuwa kila kitu katika Kafka kimeelekezwa kwa kifurushi, inafanya kazi vizuri kwa visa vingi vya utumiaji na ni zana muhimu kwa watumiaji wanaohitaji dhamana kali sana. Utendaji mwingi wa Kafka unatokana na ujumbe ambao hutumwa kwa wakala kama pakiti na kwamba ujumbe huu husomwa kutoka kwa wakala katika vitalu vilivyofuatana kwa kutumia. nakala sifuri shughuli (operesheni wakati ambapo kazi ya kunakili data kutoka eneo moja la kumbukumbu hadi nyingine haifanyiki). Mwisho ni utendakazi mkubwa na faida ya rasilimali na inawezekana tu kupitia utumizi wa muundo msingi wa data wa kumbukumbu ambao unafafanua mpango wa kugawa.

Utendaji bora zaidi unawezekana katika kundi la Kafka kuliko kwa wakala mmoja wa Kafka, kwa sababu sehemu za mada zinaweza kuenea kwenye mashine nyingi tofauti.

Matokeo ya

Katika sura hii, tuliangalia jinsi usanifu wa Kafka unavyofikiria upya uhusiano kati ya wateja na madalali ili kutoa bomba thabiti la kutuma ujumbe, lenye utumaji mara nyingi zaidi kuliko ule wa wakala wa kawaida wa ujumbe. Tumejadili utendaji unaotumia kufanikisha hili na tumeangalia kwa ufupi usanifu wa programu zinazotoa utendakazi huu. Katika sura inayofuata, tutaangalia matatizo ya kawaida ambayo maombi yanayotegemea ujumbe yanahitaji kutatua na kujadili mikakati ya kuyashughulikia. Tutamalizia sura hii kwa kuelezea jinsi ya kuzungumza kuhusu teknolojia za utumaji ujumbe kwa ujumla ili uweze kutathmini kufaa kwao kwa hali za matumizi yako.

Sehemu iliyotafsiriwa hapo awali: Kuelewa madalali wa ujumbe. Kujifunza mbinu za kutuma ujumbe na ActiveMQ na Kafka. Sura ya 1

Tafsiri imefanywa: tele.gg/middle_java

Kuendelea ...

Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. Weka sahihitafadhali.

Je, Kafka inatumika katika shirika lako?

• Да

• Hakuna

• Iliyotumiwa hapo awali, sasa sio

• Tunapanga kutumia

Watumiaji 38 walipiga kura. Watumiaji 8 walijizuia.

Chanzo: mapenzi.com