ProHoster > Blogs > Administrācija > RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība

Š’ pēdējais raksts mēs apskatÄ«jām RabbitMQ klasterus, lai nodroÅ”inātu kļūdu toleranci un augstu pieejamÄ«bu. Tagad iedziļināsimies Apache Kafkā.

Šeit replikācijas vienība ir nodalījums. Katrai tēmai ir viena vai vairākas sadaļas. Katrai sadaļai ir vadītājs ar vai bez sekotājiem. Veidojot tēmu, jūs norādāt nodalījumu skaitu un replikācijas koeficientu. Parastā vērtība ir 3, kas nozīmē trīs kopijas: viens līderis un divi sekotāji.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 1. Četras sadaļas ir sadalītas starp trim brokeriem

Visi lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumi nonāk vadÄ«tājam. Sekotāji periodiski nosÅ«ta vadÄ«tājam pieprasÄ«jumus saņemt jaunākās ziņas. Patērētāji nekad nevērÅ”as pie sekotājiem; pēdējie pastāv tikai atlaiÅ”anas un kļūdu tolerances dēļ.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība

Sadalījuma kļūme

Kad brokeris neizdodas, nereti neizdodas izgāzties vairāku sadaļu vadītāji. Katrā no tiem par līderi kļūst sekotājs no cita mezgla. Faktiski tas ne vienmēr notiek, jo sinhronizācijas faktors arī ietekmē: vai ir sinhronizēti sekotāji, un, ja nē, tad vai ir atļauta pāreja uz nesinhronizētu repliku. Bet pagaidām nesarežģīsim lietas.

Brokeris 3 atstāj tÄ«klu, un 2. sadaļā tiek ievēlēts jauns vadÄ«tājs.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 2. Brokeris 3 nomirst, un viņa sekotājs brokerim 2 tiek ievēlēts par jauno 2. nodalījuma vadītāju.

Tad brokeris 1 aiziet un arī 1. sadaļa zaudē savu līderi, kura loma pāriet 2. brokerim.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 3. Palicis viens brokeris. Visi vadītāji ir pie viena brokera ar nulles atlaiŔanu

Kad brokeris 1 atgriežas tieÅ”saistē, tas pievieno četrus sekotājus, nodroÅ”inot zināmu atlaiÅ”anu katram nodalÄ«jumam. Bet visi lÄ«deri joprojām palika uz 2. brokera.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 4. LÄ«deri paliek 2. brokerim

Kad parādās brokeris 3, mēs atgriežamies pie trim replikām katrā nodalÄ«jumā. Bet visi lÄ«deri joprojām ir brokeris 2.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 5. Nesabalansēts lÄ«deru izvietojums pēc brokeru 1. un 3. atjaunoÅ”anas

Kafkai ir rÄ«ks labākai lÄ«deru lÄ«dzsvara atjaunoÅ”anai nekā RabbitMQ. Tur bija jāizmanto treŔās puses spraudnis vai skripts, kas mainÄ«ja galvenā mezgla migrÄ“Å”anas politikas, samazinot dublÄ“Å”anu migrācijas laikā. Turklāt lielām rindām mums bija jāpieņem nepieejamÄ«ba sinhronizācijas laikā.

Kafkai ir jēdziens ā€œvēlamās kopijasā€ lÄ«dera lomai. Kad tiek izveidoti tēmu nodalÄ«jumi, Kafka mēģina vienmērÄ«gi sadalÄ«t lÄ«derus pa mezgliem un atzÄ«mē Å”os pirmos lÄ«derus kā vēlamos. Laika gaitā servera atsāknÄ“Å”anas, kļūmju un savienojamÄ«bas bojājumu dēļ lÄ«deri var nonākt citos mezglos, kā tas ir iepriekÅ” aprakstÄ«tajā galējā gadÄ«jumā.

Lai to labotu, Kafka piedāvā divas iespējas:

  • Opcija auto.leader.rebalance.enable=true ļauj kontrollera mezglam automātiski atkārtoti pieŔķirt lÄ«derus atpakaļ vēlamajām replikām un tādējādi atjaunot vienotu sadalÄ«jumu.
  • Administrators var palaist skriptu kafka-preferred-replica-election.sh manuālai pārcelÅ”anai.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 6. Replikas pēc balansÄ“Å”anas

Å Ä« bija neveiksmes vienkārÅ”ota versija, taču realitāte ir sarežģītāka, lai gan Å”eit nav nekā pārāk sarežģīta. Tas viss ir saistÄ«ts ar sinhronizētām replikām (In-Sync Replicas, ISR).

Sinhronizētās kopijas (ISR)

ISR ir nodalÄ«juma kopiju kopa, kas tiek uzskatÄ«ta par ā€œsinhronizētuā€ (sinhronizētu). Ir lÄ«deris, bet var nebÅ«t sekotāju. Sekotājs tiek uzskatÄ«ts par sinhronizētu, ja tas ir izveidojis precÄ«zas visu lÄ«dera ziņojumu kopijas pirms intervāla beigām replica.lag.time.max.ms.

Sekotājs tiek noņemts no ISR kopas, ja:

  • neiesniedza pieprasÄ«jumu atlasÄ«t intervālu replica.lag.time.max.ms (domājams, ka miris)
  • intervālā neizdevās atjaunināt replica.lag.time.max.ms (tiek uzskatÄ«ts par lēnu)

Sekotāji veic izlases pieprasījumus intervālā replica.fetch.wait.max.ms, kas pēc noklusējuma ir 500 ms.

Lai skaidri izskaidrotu ISR mērķi, mums ir jāaplūko ražotāja apstiprinājumi un daži neveiksmju scenāriji. Ražotāji var izvēlēties, kad brokeris nosūta apstiprinājumu:

  • acks=0, apstiprinājums nav nosÅ«tÄ«ts
  • acks=1, apstiprinājums tiek nosÅ«tÄ«ts pēc tam, kad vadÄ«tājs ir uzrakstÄ«jis ziņojumu savam lokālajam žurnālam
  • acks=all, apstiprinājums tiek nosÅ«tÄ«ts pēc tam, kad visas ISR kopijas ir ierakstÄ«juÅ”as ziņojumu lokālajos žurnālos

Pēc Kafkas terminoloÄ£ijas, ja ISR ir saglabājis ziņojumu, tas ir ā€œapņēmiesā€. Acks=all ir droŔākā iespēja, taču tā arÄ« pievieno papildu aizkavi. ApskatÄ«sim divus neveiksmju piemērus un to, kā dažādas ā€œackā€ iespējas mijiedarbojas ar ISR koncepciju.

Acks=1 un ISR

Å ajā piemērā mēs redzēsim, ka, ja vadÄ«tājs negaida, lÄ«dz tiks saglabāts katrs ziņojums no visiem sekotājiem, tad ir iespējams datu zudums, ja vadÄ«tājs neizdodas. PārvietoÅ”anos uz nesinhronizētu sekotāju var iespējot vai atspējot, iestatot netÄ«rs.vadÄ«tājs.vēlÄ“Å”anas.iespējot.

Å ajā piemērā ražotāja vērtÄ«ba ir acks=1. Sadaļa ir sadalÄ«ta starp visiem trim brokeriem. Broker 3 ir aiz muguras, tas sinhronizējās ar lÄ«deri pirms astoņām sekundēm un tagad atpaliek par 7456 ziņojumiem. Brokeris 1 atpalika tikai par sekundi. MÅ«su producents nosÅ«ta ziņu un ātri saņem atbildi, bez lēniem vai miruÅ”iem sekotājiem, kurus lÄ«deris negaida.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 7. ISR ar trim replikām

Broker 2 neizdodas, un ražotājs saņem savienojuma kļūdu. Pēc tam, kad vadība tiek nodota brokerim 1, mēs zaudējam 123 ziņojumus. 1. brokera sekotājs bija daļa no ISR, bet nebija pilnībā sinhronizēts ar līderi, kad tas kritās.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 8. Ziņojumi tiek zaudēti, kad tas avarē

Konfigurācijā bootstrap.servers Ražotājam ir norādÄ«ti vairāki brokeri, un tas var jautāt citam brokerim, kurÅ” ir jaunais sadaļas vadÄ«tājs. Pēc tam tas izveido savienojumu ar brokeri 1 un turpina sÅ«tÄ«t ziņojumus.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 9. Ziņojumu sÅ«tÄ«Å”ana tiek atsākta pēc neliela pārtraukuma

Brokeris 3 atpaliek vēl vairāk. Tas veic ieneÅ”anas pieprasÄ«jumus, bet nevar sinhronizēt. Tas var bÅ«t saistÄ«ts ar lēnu tÄ«kla savienojumu starp brokeriem, krātuves problēmu utt. Tas ir noņemts no ISR. Tagad ISR sastāv no viena replika - lÄ«dera! Ražotājs turpina sÅ«tÄ«t ziņojumus un saņemt apstiprinājumus.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 10. Brokera 3 sekotājs tiek noņemts no ISR

Brokeris 1 zaudē spēku, un lÄ«dera loma tiek pieŔķirta brokerim 3, zaudējot 15286 ziņojumus! Ražotājs saņem savienojuma kļūdas ziņojumu. Pāreja uz lÄ«deri ārpus ISR bija iespējama tikai iestatÄ«juma dēļ unclean.leader.election.enable=true. Ja tas ir instalēts nepatiess, tad pāreja nenotiktu un visi lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumi tiktu noraidÄ«ti. Å ajā gadÄ«jumā mēs gaidām, kamēr brokeris 1 atgriezÄ«sies ar neskartiem datiem replikā, kas atkal pārņems vadÄ«bu.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 11. Brokeris 1 krīt. Ja rodas kļūme, tiek zaudēts liels skaits ziņojumu

Producents nodibina saikni ar pēdējo brokeri un redz, ka tagad ir sadaļas vadÄ«tājs. ViņŔ sāk sÅ«tÄ«t ziņojumus brokerim 3.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 12. Pēc neliela pārtraukuma ziņas atkal tiek nosūtītas uz 0. sadaļu

Mēs redzējām, ka, neskaitot Ä«sus pārtraukumus, lai izveidotu jaunus savienojumus un meklētu jaunu vadÄ«tāju, ražotājs nepārtraukti sÅ«tÄ«ja ziņojumus. Å Ä« konfigurācija nodroÅ”ina pieejamÄ«bu uz konsekvences (datu droŔības) rēķina. Kafka pazaudēja tÅ«kstoÅ”iem ziņojumu, bet turpināja pieņemt jaunus rakstus.

Acks=all un ISR

Atkārtosim Å”o scenāriju vēlreiz, bet ar acks=viss. Broker 3 vidējais latentums ir četras sekundes. Ražotājs nosÅ«ta ziņojumu ar acks=viss, un tagad nesaņem ātru atbildi. VadÄ«tājs gaida, lÄ«dz ziņojums tiks saglabāts visās ISR replikās.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 13. ISR ar trim replikām. Viens ir lēns, kā rezultātā ierakstÄ«Å”ana aizkavējas

Pēc četru sekunžu papildu kavÄ“Å”anās brokeris 2 nosÅ«ta apstiprinājumu. Visas kopijas tagad ir pilnÄ«bā atjauninātas.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 14. Visas kopijas saglabā ziņas un nosūta apstiprinājumu

Brokeris 3 tagad atpaliek un tiek noņemts no ISR. Latentums ir ievērojami samazināts, jo ISR nav palicis lēnas kopijas. Brokeris 2 tagad gaida tikai brokeri 1, un viņam ir vidējā nobÄ«de 500 ms.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 15. Brokera 3 kopija tiek noņemta no ISR

Pēc tam 2. brokeris krīt un vadība pāriet 1. brokerim, nezaudējot ziņojumus.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 16. Brokeris 2 krīt

Ražotājs atrod jaunu vadÄ«tāju un sāk viņam sÅ«tÄ«t ziņojumus. Latentums ir vēl vairāk samazināts, jo ISR tagad sastāv no vienas kopijas! Tāpēc iespēja acks=viss nepievieno atlaiÅ”anu.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 17. Broker 1 replika uzņemas vadību, nezaudējot ziņojumus

Pēc tam brokeris 1 avarē, un pārsvars nonāk brokerim 3, zaudējot 14238 ziņojumus!

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 18. Broker 1 nomirst, un vadÄ«bas maiņa ar netÄ«riem iestatÄ«jumiem izraisa plaÅ”u datu zudumu

Mēs nevarējām instalēt opciju netÄ«rs.vadÄ«tājs.vēlÄ“Å”anas.iespējot nozÄ«mē patiess. Pēc noklusējuma tas ir vienāds nepatiess. IestatÄ«jumi acks=viss с unclean.leader.election.enable=true nodroÅ”ina pieejamÄ«bu ar papildu datu droŔību. Bet, kā redzat, mēs joprojām varam zaudēt ziņojumus.

Bet ko darÄ«t, ja mēs vēlamies palielināt datu droŔību? Var likt unclean.leader.election.enable = false, taču tas mÅ«s ne vienmēr pasargās no datu zuduma. Ja vadÄ«tājs smagi nokrita un paņēma datus lÄ«dzi, tad ziņojumi joprojām tiek zaudēti, kā arÄ« tiek zaudēta pieejamÄ«ba, lÄ«dz administrators atjauno situāciju.

Labāk ir nodroÅ”ināt, lai visi ziņojumi bÅ«tu lieki, un citādi atmest ierakstu. Tad, vismaz no brokera viedokļa, datu zudums ir iespējams tikai divu vai vairāku vienlaicÄ«gu kļūmju gadÄ«jumā.

Acks=all, min.insync.replicas un ISR

Ar tēmas konfigurāciju min.insync.replicas Mēs paaugstinām datu droŔības lÄ«meni. Vēlreiz iziesim cauri iepriekŔējā scenārija pēdējai daļai, bet Å”oreiz ar min.insync.replicas=2.

Tātad 2. brokerim ir replikas līderis, un 3. brokera sekotājs tiek noņemts no ISR.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 19. ISR no divām replikām

Brokeris 2 krÄ«t, un vadÄ«ba pāriet brokerim 1, nezaudējot ziņojumus. Bet tagad ISR sastāv tikai no vienas kopijas. Tas neatbilst minimālajam ierakstu saņemÅ”anas skaitam, un tāpēc brokeris uz rakstÄ«Å”anas mēģinājumu reaģē ar kļūdu NotEnoughReplicas.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 20. ISR skaits ir par vienu mazāks, nekā norādīts failā min.insync.replicas

Å Ä« konfigurācija upurē pieejamÄ«bu konsekvences dēļ. Pirms ziņojuma apstiprināŔanas mēs nodroÅ”inām, ka tas ir ierakstÄ«ts vismaz divās replikās. Tas dod ražotājam daudz lielāku pārliecÄ«bu. Å eit ziņojuma zudums ir iespējams tikai tad, ja divas replikas vienlaikus neizdodas Ä«sā intervālā, lÄ«dz ziņojums tiek replicēts papildu sekotājam, kas ir maz ticams. Bet, ja esat ļoti paranoisks, varat iestatÄ«t replikācijas koeficientu uz 5 un min.insync.replicas ar 3. Å eit trÄ«s brokeriem ir jākrÄ«t vienlaikus, lai zaudētu rekordu! Protams, jÅ«s maksājat par Å”o uzticamÄ«bu papildu latentumā.

Kad pieejamība ir nepiecieŔama datu droŔībai

Kā iekŔā korpuss ar RabbitMQ, dažkārt pieejamība ir nepiecieŔama datu droŔībai. Lūk, par ko jums jāpadomā:

  • Vai izdevējs var vienkārÅ”i atgriezt kļūdu un likt augŔējam pakalpojumam vai lietotājam vēlāk mēģināt vēlreiz?
  • Vai izdevējs var saglabāt ziņojumu lokāli vai datu bāzē, lai vēlāk mēģinātu vēlreiz?

Ja atbilde ir nē, pieejamÄ«bas optimizÄ“Å”ana uzlabo datu droŔību. JÅ«s zaudēsiet mazāk datu, ja izvēlēsieties pieejamÄ«bu, nevis neierakstÄ«sit. Tādējādi viss ir lÄ«dzsvara atraÅ”ana, un lēmums ir atkarÄ«gs no konkrētās situācijas.

ISR nozīme

ISR komplekts ļauj izvēlēties optimālo lÄ«dzsvaru starp datu droŔību un latentumu. Piemēram, nodroÅ”iniet pieejamÄ«bu lielākās daļas kopiju atteices gadÄ«jumā, samazinot miruÅ”o vai lēno kopiju ietekmi latentuma ziņā.

Mēs paÅ”i izvēlamies nozÄ«mi replica.lag.time.max.ms atbilstoÅ”i jÅ«su vajadzÄ«bām. BÅ«tÄ«bā Å”is parametrs nozÄ«mē, cik lielu kavÄ“Å”anos mēs esam gatavi pieņemt, kad acks=viss. Noklusējuma vērtÄ«ba ir desmit sekundes. Ja tas jums ir pārāk garÅ”, varat to samazināt. Tad ISR izmaiņu biežums palielināsies, jo sekotāji tiks noņemti un pievienoti biežāk.

RabbitMQ ir vienkārÅ”i spoguļu komplekts, kas ir jāatkārto. Lēni spoguļi ievieÅ” papildu latentumu, un miruÅ”ie spoguļi var gaidÄ«t, lÄ«dz paketes, kas pārbauda katra mezgla pieejamÄ«bu (tÄ«kla atzÄ«me), atbild. ISR ir interesants veids, kā izvairÄ«ties no Ŕīm latentuma problēmām. Bet mēs riskējam zaudēt atlaiÅ”anu, jo ISR var sarukt tikai lÄ«dz lÄ«derim. Lai izvairÄ«tos no Ŕī riska, izmantojiet iestatÄ«jumu min.insync.replicas.

Klienta savienojuma garantija

IestatÄ«jumos bootstrap.servers ražotājs un patērētājs var norādÄ«t vairākus brokerus klientu savienoÅ”anai. Ideja ir tāda, ka, kad viens mezgls pazÅ«d, paliek vairāki rezerves, ar kurām klients var atvērt savienojumu. Tie nav obligāti sekciju lÄ«deri, bet vienkārÅ”i tramplÄ«ns sākotnējai iekrauÅ”anai. Klients var jautāt, kurÅ” mezgls mitina lasÄ«Å”anas/rakstÄ«Å”anas nodalÄ«juma vadÄ«tāju.

Programmā RabbitMQ klienti var izveidot savienojumu ar jebkuru mezglu, un iekŔējā marÅ”rutÄ“Å”ana nosÅ«ta pieprasÄ«jumu uz vietu, kur tam jānonāk. Tas nozÄ«mē, ka RabbitMQ priekŔā varat uzstādÄ«t slodzes balansētāju. Kafka pieprasa klientiem izveidot savienojumu ar mezglu, kurā atrodas atbilstoÅ”ais nodalÄ«juma vadÄ«tājs. Šādā situācijā jÅ«s nevarat instalēt slodzes balansētāju. Saraksts bootstrap.servers Ir ļoti svarÄ«gi, lai klienti pēc kļūmes varētu piekļūt un atrast pareizos mezglus.

Kafkas konsensa arhitektūra

LÄ«dz Å”im neesam apsvēruÅ”i, kā klasteris uzzina par brokera kriÅ”anu un kā tiek ievēlēts jauns vadÄ«tājs. Lai saprastu, kā Kafka darbojas ar tÄ«kla nodalÄ«jumiem, vispirms ir jāsaprot vienprātÄ«bas arhitektÅ«ra.

Katrs Kafka klasteris tiek izvietots kopā ar Zookeeper klasteru, kas ir izplatÄ«ts vienprātÄ«bas pakalpojums, kas ļauj sistēmai panākt vienprātÄ«bu par noteiktu stāvokli, prioritāti izvirzot konsekvenci, nevis pieejamÄ«bu. Lai apstiprinātu lasÄ«Å”anas un rakstÄ«Å”anas darbÄ«bas, ir nepiecieÅ”ama vairuma Zookeeper mezglu piekriÅ”ana.

Zookeeper saglabā klastera stāvokli:

  • Tēmu saraksts, sadaļas, konfigurācija, paÅ”reizējās lÄ«deru kopijas, vēlamās kopijas.
  • Klastera dalÄ«bnieki. Katrs brokeris pings Zookeeper klasterim. Ja noteiktā laika periodā tas nesaņem ping, Zookeeper reÄ£istrē brokeri kā nepieejamu.
  • Kontroliera galveno un rezerves mezglu izvēle.

Kontroliera mezgls ir viens no Kafka brokeriem, kas ir atbildÄ«gs par kopiju vadÄ«tāju ievēlÄ“Å”anu. Zookeeper nosÅ«ta kontrolierim paziņojumus par klastera dalÄ«bu un tēmu izmaiņām, un kontrolierim ir jārÄ«kojas, lai Ŕīs izmaiņas tiktu ievērotas.

Piemēram, ņemsim jaunu tēmu ar desmit nodalÄ«jumiem un replikācijas koeficientu 3. Kontrolierim ir jāievēl vadÄ«tājs katram nodalÄ«jumam, cenÅ”oties optimāli sadalÄ«t lÄ«derus starp brokeriem.

Katram sekcijas kontrollerim:

  • atjaunina informāciju Zookeeper par ISR un vadÄ«tāju;
  • NosÅ«ta LeaderAndISRCommand katram brokerim, kas mitina Ŕī nodalÄ«juma kopiju, informējot brokerus par ISR un vadÄ«tāju.

Kad brokeris ar vadītāju krīt, Zookeeper nosūta paziņojumu kontrolierim, un tas ievēl jaunu vadītāju. Atkal kontrolieris vispirms atjaunina Zookeeper un pēc tam nosūta komandu katram brokerim, informējot par vadības maiņu.

Katrs vadÄ«tājs ir atbildÄ«gs par ISR pieņemÅ”anu darbā. IestatÄ«jumi replica.lag.time.max.ms nosaka, kas tur ienāks. Kad ISR mainās, vadÄ«tājs nosÅ«ta jaunu informāciju Zookeeper.

Zookeeper vienmēr tiek informēts par jebkurām izmaiņām, lai neveiksmes gadījumā vadība vienmērīgi pārietu uz jaunu vadītāju.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 21. Kafkas konsenss

Replikācijas protokols

Izpratne par replikācijas detaļām palīdz labāk izprast iespējamos datu zuduma scenārijus.

Izlases vaicājumi, žurnāla beigu nobīde (LEO) un Highwater Mark (HW)

Mēs uzskatÄ«jām, ka sekotāji periodiski nosÅ«ta vadÄ«tājam pieprasÄ«jumus nolasÄ«t. Noklusējuma intervāls ir 500 ms. Tas atŔķiras no RabbitMQ ar to, ka RabbitMQ replikāciju ierosina nevis rindas spogulis, bet gan galvenais. Meistars piespiež izmaiņas uz spoguļiem.

VadÄ«tājs un visi sekotāji saglabā žurnāla beigu nobÄ«di (LEO) un Highwater (HW) etiÄ·eti. LEO atzÄ«me saglabā pēdējā ziņojuma nobÄ«di vietējā replikā, un HW saglabā pēdējās saistÄ«bas nobÄ«di. Atcerieties, ka, lai nodroÅ”inātu izpildes statusu, ziņojumam ir jābÅ«t saglabātam visās ISR replikās. Tas nozÄ«mē, ka LEO parasti ir nedaudz priekŔā HW.

Kad vadÄ«tājs saņem ziņojumu, tas to saglabā lokāli. Sekotājs veic ieneÅ”anas pieprasÄ«jumu, nosÅ«tot savu LEO. Pēc tam vadÄ«tājs nosÅ«ta ziņojumu sēriju, sākot no Ŕī LEO, kā arÄ« pārsÅ«ta paÅ”reizējo HW. Kad vadÄ«tājs saņem informāciju, ka visas replikas ir saglabājuÅ”as ziņojumu norādÄ«tajā nobÄ«dē, tas pārvieto HW atzÄ«mi. Tikai vadÄ«tājs var pārvietot HW, un tāpēc visi sekotāji atbildēs uz viņu pieprasÄ«jumu zinās paÅ”reizējo vērtÄ«bu. Tas nozÄ«mē, ka sekotāji var atpalikt no lÄ«dera gan vēstÄ«jumā, gan HW zināŔanās. Patērētāji saņem ziņas tikai lÄ«dz paÅ”reizējam HW.

Ņemiet vērā, ka "pastāvēja" nozÄ«mē ierakstÄ«tu atmiņā, nevis diskā. Lai nodroÅ”inātu veiktspēju, Kafka noteiktā intervālā sinhronizējas ar disku. RabbitMQ arÄ« ir Ŕāds intervāls, taču tas nosÅ«tÄ«s apstiprinājumu izdevējam tikai pēc tam, kad meistars un visi spoguļi bÅ«s ierakstÄ«juÅ”i ziņojumu diskā. Kafka izstrādātāji veiktspējas apsvērumu dēļ nolēma nosÅ«tÄ«t apstiprinājumu, tiklÄ«dz ziņojums ir ierakstÄ«ts atmiņā. Kafka der, ka atlaiÅ”ana atsver risku Ä«slaicÄ«gi saglabāt apstiprinātos ziņojumus tikai atmiņā.

LÄ«dera neveiksme

Kad līderis krīt, Zookeeper par to informē kontrolieri, un tas izvēlas jaunu līdera kopiju. Jaunais vadītājs nosaka jaunu HW atzīmi saskaņā ar savu LEO. Pēc tam sekotāji saņem informāciju par jauno vadītāju. Atkarībā no Kafkas versijas sekotājs izvēlēsies vienu no diviem scenārijiem:

  1. Tas saÄ«sinās vietējo žurnālu uz zināmu HW un nosÅ«tÄ«s jaunajam vadÄ«tājam pieprasÄ«jumu pēc ziņojumiem pēc Ŕīs atzÄ«mes.
  2. NosÅ«tÄ«s vadÄ«tājam pieprasÄ«jumu noskaidrot HW brÄ«dÄ«, kad viņŔ tika ievēlēts par vadÄ«tāju, un pēc tam saÄ«sina žurnālu lÄ«dz Å”ai nobÄ«dei. Pēc tam tas sāks veikt periodiskus ielādes pieprasÄ«jumus, sākot ar Å”o nobÄ«di.

Sekotājam, iespējams, bÅ«s jāsaÄ«sina žurnāls Ŕādu iemeslu dēļ:

  • Ja lÄ«derim neizdodas, pirmais sekotājs ISR komplektā, kas reÄ£istrēts Zookeeper, uzvar vēlÄ“Å”anās un kļūst par lÄ«deri. Lai gan visi ISR ā€‹ā€‹sekotāji tiek uzskatÄ«ti par ā€œsinhronizētiemā€, iespējams, nav saņēmuÅ”i visu ziņojumu kopijas no bijuŔā vadÄ«tāja. PilnÄ«gi iespējams, ka piedāvātajam sekotājam nav visjaunākās kopijas. Kafka nodroÅ”ina, ka starp replikām nav atŔķirÄ«bu. Tādējādi, lai izvairÄ«tos no neatbilstÄ«bām, katram sekotājam ir jāsaÄ«sina savs žurnāls lÄ«dz jaunā lÄ«dera HW vērtÄ«bai viņa ievēlÄ“Å”anas brÄ«dÄ«. Tas ir vēl viens iemesls, kāpēc iestatÄ«t acks=viss tik svarÄ«gi konsekvencei.
  • Ziņojumi periodiski tiek ierakstÄ«ti diskā. Ja visi klastera mezgli neizdodas vienlaikus, diskos tiks saglabātas kopijas ar dažādām nobÄ«dēm. Iespējams, ka tad, kad brokeri atgriezÄ«sies tieÅ”saistē, jaunais ievēlētais lÄ«deris bÅ«s aiz saviem sekotājiem, jo ā€‹ā€‹viņŔ tika saglabāts diskā pirms citiem.

AtkalapvienoŔanās ar klasteru

Atkārtoti pievienojoties klasterim, kopijas rÄ«kojas tāpat kā tad, ja lÄ«derim neizdodas: tās pārbauda lÄ«dera kopiju un saÄ«sina savu žurnālu uz tā HW (ievēlÄ“Å”anas laikā). SalÄ«dzinājumam, RabbitMQ atkārtoti apvienotos mezglus uzskata par pilnÄ«gi jauniem. Abos gadÄ«jumos brokeris atmet jebkuru esoÅ”o stāvokli. Ja tiek izmantota automātiskā sinhronizācija, kapteinim ir jāreplicē pilnÄ«gi viss paÅ”reizējais saturs jaunajā spogulÄ«, izmantojot metodi ā€œÄ¼aujiet visai pasaulei gaidÄ«tā€. Å Ä«s darbÄ«bas laikā kapteinis nepieņem nekādas lasÄ«Å”anas vai rakstÄ«Å”anas darbÄ«bas. Å Ä« pieeja rada problēmas lielās rindās.

Kafka ir izplatÄ«ts žurnāls, un kopumā tajā tiek saglabāts vairāk ziņojumu nekā RabbitMQ rindā, kurā dati tiek noņemti no rindas pēc to nolasÄ«Å”anas. AktÄ«vajām rindām jāpaliek salÄ«dzinoÅ”i mazām. Bet Kafka ir žurnāls ar savu saglabāŔanas politiku, kas var noteikt dienu vai nedēļu periodu. Rindas bloÄ·Ä“Å”anas un pilnÄ«gas sinhronizācijas pieeja izplatÄ«tam žurnālam ir absolÅ«ti nepieņemama. Tā vietā Kafkas sekotāji vienkārÅ”i saÄ«sina savu žurnālu lÄ«dz vadÄ«tāja HW (viņa ievēlÄ“Å”anas laikā), ja viņu kopija ir priekŔā vadÄ«tājam. Visticamākajā gadÄ«jumā, kad sekotājs atpaliek, tas vienkārÅ”i sāk veikt ieneÅ”anas pieprasÄ«jumus, sākot ar paÅ”reizējo LEO.

Jauni vai atkārtoti pievienotie sekotāji sāk darboties ārpus ISR un nepiedalās saistÄ«bās. Viņi vienkārÅ”i strādā kopā ar grupu, saņemot ziņas, cik ātri vien iespējams, lÄ«dz panāk vadÄ«tāju un ieiet ISR. Nav bloÄ·Ä“Å”anas un nav jāizmet visi jÅ«su dati.

Savienojuma zudums

Kafka ir vairāk komponentu nekā RabbitMQ, tāpēc tai ir sarežģītāks darbību kopums, kad klasteris tiek atvienots. Taču Kafka sākotnēji bija paredzēta klasteriem, tāpēc risinājumi ir ļoti pārdomāti.

Tālāk ir norādīti vairāki savienojuma kļūmju scenāriji.

  • 1. scenārijs: sekotājs neredz vadÄ«tāju, bet joprojām redz Zoodārza sargu.
  • 2. scenārijs: lÄ«deris neredz nevienu sekotāju, bet joprojām redz Zookeeper.
  • 3. scenārijs: sekotājs redz vadÄ«tāju, bet neredz zoodārza sargu.
  • 4. scenārijs: vadÄ«tājs redz sekotājus, bet neredz Zoodārza sargu.
  • 5. scenārijs: sekotājs ir pilnÄ«bā noŔķirts gan no citiem Kafka mezgliem, gan no Zookeeper.
  • 6. scenārijs: vadÄ«tājs ir pilnÄ«bā noŔķirts no abiem Kafkas mezgliem un Zookeeper.
  • 7. scenārijs: Kafka kontrollera mezgls nevar redzēt citu Kafka mezglu.
  • 8. scenārijs: Kafka kontrolieris neredz Zookeeper.

Katram scenārijam ir sava uzvedība.

1. scenārijs: sekotājs neredz vadītāju, bet joprojām redz Zookeeper

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 22. 1. scenārijs: trÄ«s kopiju ISR

Savienojuma kļūme atdala brokeri 3 no starpniekiem 1 un 2, bet ne no Zookeeper. Brokeris 3 vairs nevar nosÅ«tÄ«t izgÅ«Å”anas pieprasÄ«jumus. Pēc tam, kad pagājis laiks replica.lag.time.max.ms tas tiek noņemts no ISR un nepiedalās ziņojumu apņemÅ”anā. Kad savienojums ir atjaunots, tas atsāks pieprasÄ«jumu ienesÅ”anu un pievienosies ISR, kad tas sasniegs lÄ«deri. Zookeeper turpinās saņemt ping un pieņems, ka brokeris ir dzÄ«vs un vesels.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 23. 1. scenārijs: starpnieks tiek noņemts no ISR, ja intervālā replica.lag.time.max.ms no tā netiek saņemts neviens izgÅ«Å”anas pieprasÄ«jums.

Nav dalÄ«tu smadzeņu vai mezglu apturÄ“Å”anas, piemēram, RabbitMQ. Tā vietā tiek samazināta atlaiÅ”ana.

2. scenārijs: Leader neredz nevienu sekotāju, bet joprojām redz Zookeeper

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 24. Scenārijs 2. Vadītājs un divi sekotāji

TÄ«kla savienojamÄ«bas traucējumi atdala lÄ«deri no sekotājiem, taču brokeris joprojām var redzēt Zookeeper. Tāpat kā pirmajā scenārijā, ISR samazinās, bet Å”oreiz tikai lÄ«dz lÄ«derim, jo ā€‹ā€‹visi sekotāji pārtrauc sÅ«tÄ«t ieneses pieprasÄ«jumus. Atkal nav loÄ£iska iedalÄ«juma. Tā vietā jauniem ziņojumiem tiek zaudēta dublÄ“Å”anās, lÄ«dz tiek atjaunots savienojums. Zookeeper turpina saņemt pingus un uzskata, ka brokeris ir dzÄ«vs un vesels.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 25. Scenārijs 2. ISR ir sarucis tikai līdz līderim

Scenārijs 3. Sekotājs redz vadītāju, bet neredz Zoodārza sargu

Sekotājs ir atdalÄ«ts no Zookeeper, bet ne no brokera ar lÄ«deri. Rezultātā sekotājs turpina iesniegt pieprasÄ«jumus un bÅ«t ISR dalÄ«bnieks. Zookeeper vairs nesaņem pingus un reÄ£istrē brokera avāriju, bet tā kā tas ir tikai sekotājs, tad pēc atveseļoÅ”anās nekādu seku nav.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 26. 3. scenārijs: sekotājs turpina sÅ«tÄ«t ieneses pieprasÄ«jumus vadÄ«tājam

Scenārijs 4. Vadītājs redz sekotājus, bet neredz Zookeeper

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 27. Scenārijs 4. Vadītājs un divi sekotāji

Līderis ir atdalīts no Zookeeper, bet ne no brokeriem ar sekotājiem.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 28. 4. scenārijs: vadÄ«tājs izolēts no Zookeeper

Pēc kāda laika Zookeeper reÄ£istrēs brokera kļūdu un paziņos par to kontrolierim. ViņŔ no saviem sekotājiem izvēlēsies jaunu lÄ«deri. Tomēr sākotnējais vadÄ«tājs turpinās domāt, ka tas ir vadÄ«tājs, un turpinās pieņemt ierakstus no acks=1. Sekotāji viņam vairs nesÅ«ta atneÅ”anas pieprasÄ«jumus, tāpēc viņŔ uzskatÄ«s tos par miruÅ”iem un mēģinās samazināt ISR. Bet, tā kā tam nav savienojuma ar Zookeeper, tas nevarēs to izdarÄ«t un tajā brÄ«dÄ« atsakās pieņemt citus ierakstus.

Š”Š¾Š¾Š±Ń‰ŠµŠ½Šøя acks=viss nesaņems apstiprinājumu, jo ISR vispirms ieslēdz visas kopijas un ziņojumi tos nesasniedz. Kad sākotnējais vadÄ«tājs mēģinās tos noņemt no ISR, tas to nevarēs izdarÄ«t un vispār pārtrauks pieņemt ziņojumus.

Klienti drīz pamana līdera izmaiņas un sāk sūtīt ierakstus uz jauno serveri. Kad tīkls ir atjaunots, sākotnējais vadītājs redz, ka tas vairs nav līderis, un saīsina savu žurnālu līdz HW vērtībai, kas jaunajam vadītājam bija neveiksmes brīdī, lai izvairītos no žurnāla novirzēm. Pēc tam tas sāks sūtīt ielādes pieprasījumus jaunajam vadītājam. Tiek zaudēti visi sākotnējā līdera ieraksti, kas nav replicēti jaunajam līderim. Tas nozīmē, ka tiks zaudēti ziņojumi, kurus sākotnējais vadītājs neatzina tajās dažās sekundēs, kad strādāja divi vadītāji.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 29. 4. scenārijs. 1. brokera lÄ«deris kļūst par sekotāju pēc tÄ«kla atjaunoÅ”anas

5. scenārijs: sekotājs ir pilnÄ«bā noŔķirts gan no citiem Kafka mezgliem, gan no Zookeeper

Sekotājs ir pilnÄ«bā izolēts gan no citiem Kafkas mezgliem, gan no Zookeeper. ViņŔ vienkārÅ”i noņem sevi no ISR, lÄ«dz tÄ«kls tiek atjaunots, un pēc tam panāk pārējos.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 30. 5. scenārijs: no ISR tiek noņemts izolēts sekotājs

6. scenārijs: vadÄ«tājs ir pilnÄ«bā noŔķirts no abiem Kafkas mezgliem un Zookeeper

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 31. Scenārijs 6. Vadītājs un divi sekotāji

VadÄ«tājs ir pilnÄ«bā izolēts no saviem sekotājiem, kontroliera un zoodārza uzrauga. ÄŖsu laiku tas turpinās pieņemt ierakstus no acks=1.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 32. 6. scenārijs: lÄ«dera izolÄ“Å”ana no citiem Kafka un Zookeeper mezgliem

Nav saņemti pieprasījumi pēc derīguma termiņa beigām replica.lag.time.max.ms, tas mēģinās samazināt ISR uz sevi, bet nevarēs to izdarīt, jo nav saziņas ar Zookeeper, tad tas pārtrauks pieņemt rakstus.

Tikmēr Zookeeper atzÄ«mēs izolēto brokeri kā miruÅ”u un kontrolieris ievēlēs jaunu vadÄ«tāju.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 33. 6. scenārijs. Divi līderi

Sākotnējais vadītājs var pieņemt ierakstus dažas sekundes, bet pēc tam pārstāj pieņemt jebkādus ziņojumus. Klienti tiek atjaunināti ik pēc 60 sekundēm ar jaunākajiem metadatiem. Viņi tiks informēti par vadītāja maiņu un sāks sūtīt ierakstus jaunajam vadītājam.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
Rīsi. 34. 6. scenārijs: ražotāji pāriet uz jaunu līderi

Visi apstiprinātie ieraksti, ko sākotnējais vadÄ«tājs veicis kopÅ” savienojuma zaudÄ“Å”anas, tiks zaudēti. Kad tÄ«kls ir atjaunots, sākotnējais vadÄ«tājs ar Zookeeper starpniecÄ«bu atklās, ka tas vairs nav vadÄ«tājs. Pēc tam tas saÄ«sinās savu žurnālu uz jaunā vadÄ«tāja HW ievēlÄ“Å”anas laikā un sāks sÅ«tÄ«t pieprasÄ«jumus kā sekotājs.

RabbitMQ vs Kafka: kļūdu tolerance un augsta pieejamība
RÄ«si. 35. 6. scenārijs: sākotnējais lÄ«deris kļūst par sekotāju pēc tÄ«kla savienojuma atjaunoÅ”anas

Šādā situācijā loÄ£iska atdalÄ«Å”ana var notikt uz Ä«su laiku, bet tikai tad, ja acks=1 Šø min.insync.replicas arÄ« 1. LoÄ£iskā atdalÄ«Å”ana automātiski beidzas vai nu pēc tÄ«kla atjaunoÅ”anas, kad sākotnējais vadÄ«tājs saprot, ka viņŔ vairs nav vadÄ«tājs, vai arÄ« tad, kad visi klienti saprot, ka vadÄ«tājs ir mainÄ«jies un sāk rakstÄ«t jaunajam vadÄ«tājam ā€“ atkarÄ«bā no tā, kas notiek pirmais. Jebkurā gadÄ«jumā daži ziņojumi tiks zaudēti, bet tikai ar acks=1.

Ir vēl viens Ŕī scenārija variants, kad tieÅ”i pirms tÄ«kla sadalÄ«Å”anas sekotāji atpalika un lÄ«deris saspieda ISR tikai sev. Pēc tam tas kļūst izolēts savienojuma zuduma dēļ. Tiek ievēlēts jauns vadÄ«tājs, bet sākotnējais vadÄ«tājs turpina pieņemt ierakstus, pat acks=viss, jo ISR nav neviena cita, izņemot viņu. Å ie ieraksti tiks zaudēti, tiklÄ«dz tÄ«kls tiks atjaunots. VienÄ«gais veids, kā izvairÄ«ties no Ŕīs iespējas, ir min.insync.replicas = 2.

7. scenārijs: Kafka kontrollera mezgls nevar redzēt citu Kafka mezglu

Parasti, kad savienojums ar Kafka mezglu tiek zaudēts, kontrolieris nevarēs pārsÅ«tÄ«t tam informāciju par lÄ«deru izmaiņām. Sliktākajā gadÄ«jumā tas novedÄ«s pie Ä«slaicÄ«gas loÄ£iskas atdalÄ«Å”anas, kā tas ir 6. scenārijā. Biežāk brokeris vienkārÅ”i nekļūs par kandidātu lÄ«dera amatam, ja pēdējais neizdosies.

8. scenārijs: Kafka kontrolieris neredz Zookeeper

Zookeeper nesaņems ping no krituŔā kontroliera un kā kontrolieri izvēlēsies jaunu Kafka mezglu. Sākotnējais kontrolieris var turpināt sevi parādÄ«t kā tādu, taču tas nesaņem paziņojumus no Zookeeper, tāpēc tam nebÅ«s jāveic nekādi uzdevumi. Kad tÄ«kls bÅ«s atjaunots, viņŔ sapratÄ«s, ka vairs nav kontrolieris, bet kļuvis par parastu Kafkas mezglu.

Secinājumi no scenārijiem

Mēs redzam, ka sekotāju savienojuma zudums neizraisa ziņojumu zudumu, bet vienkārÅ”i Ä«slaicÄ«gi samazina dublÄ“Å”anu, lÄ«dz tÄ«kls tiek atjaunots. Tas, protams, var izraisÄ«t datu zudumu, ja tiek zaudēts viens vai vairāki mezgli.

Ja vadÄ«tājs tiek atdalÄ«ts no Zookeeper savienojuma zuduma dēļ, var tikt zaudēti ziņojumi acks=1. Saziņas trÅ«kums ar Zookeeper izraisa Ä«su loÄ£isku ŔķelÅ”anos ar abiem vadÄ«tājiem. Å o problēmu atrisina parametrs acks=viss.

Parametrs min.insync.replicas divās vai vairākās replikās nodroÅ”ina papildu pārliecÄ«bu, ka Ŕādi Ä«stermiņa scenāriji neizraisÄ«s ziņojumu nozaudÄ“Å”anu, kā tas ir 6. scenārijā.

Pazaudēto ziņojumu kopsavilkums

Uzskaitīsim visus veidus, kā varat zaudēt datus programmā Kafka:

  • Jebkura vadÄ«tāja kļūme, ja ziņojumi tika apstiprināti, izmantojot acks=1
  • Jebkura netÄ«ra vadÄ«bas pāreja, tas ir, uz sekotāju ārpus ISR, pat ar acks=viss
  • VadÄ«tāja izolÄ“Å”ana no Zookeeper, ja ziņojumi tika apstiprināti, izmantojot acks=1
  • PilnÄ«ga lÄ«dera izolācija, kurÅ” jau ir samazinājis ISR grupu lÄ«dz paÅ”am sev. Visi ziņojumi tiks zaudēti, pat acks=viss. Tas ir taisnÄ«ba tikai tad, ja min.insync.replicas=1.
  • Visu nodalÄ«jumu mezglu vienlaicÄ«gas atteices. Tā kā ziņojumi tiek apstiprināti no atmiņas, daži, iespējams, vēl nav ierakstÄ«ti diskā. Pēc serveru pārstartÄ“Å”anas dažu ziņojumu var nebÅ«t.

No netÄ«rām vadÄ«bas pārejām var izvairÄ«ties, tos aizliedzot vai nodroÅ”inot vismaz divas atlaiÅ”anas. VisizturÄ«gākā konfigurācija ir kombinācija acks=viss Šø min.insync.replicas virs 1.

TieŔs RabbitMQ un Kafka uzticamības salīdzinājums

Lai nodroÅ”inātu uzticamÄ«bu un augstu pieejamÄ«bu, abas platformas ievieÅ” primāro un sekundāro replikācijas sistēmu. Tomēr RabbitMQ ir Ahileja papēdis. Atkārtoti izveidojot savienojumu pēc kļūmes, mezgli izmet savus datus un sinhronizācija tiek bloķēta. Å Ä« dubultā sadursme liek apÅ”aubÄ«t lielo rindu ilgmūžību RabbitMQ. Jums bÅ«s jāsamierinās ar samazinātu atlaiÅ”anu vai ilgu bloÄ·Ä“Å”anas laiku. Redundances samazināŔana palielina masveida datu zuduma risku. Bet, ja rindas ir mazas, tad atlaiÅ”anas nolÅ«kā var tikt galā ar Ä«siem nepieejamÄ«bas periodiem (dažas sekundes), izmantojot atkārtotus savienojuma mēģinājumus.

Kafkam Ŕīs problēmas nav. Tas izmet datus tikai no lÄ«dera un sekotāja atŔķirÄ«bas punkta. Visi koplietotie dati tiek saglabāti. Turklāt replikācija nebloķē sistēmu. VadÄ«tājs turpina pieņemt amatus, kamēr jaunais sekotājs panāk, tāpēc devops gadÄ«jumā pievienoÅ”anās klasterim vai atkārtota pievienoÅ”anās klasterim kļūst par nenozÄ«mÄ«gu uzdevumu. Protams, joprojām pastāv problēmas, piemēram, tÄ«kla joslas platums replikācijas laikā. Ja vienlaikus pievienosit vairākus sekotājus, var rasties joslas platuma ierobežojums.

RabbitMQ ir pārāks par Kafka uzticamÄ«bas ziņā, ja vairāki serveri klasterÄ« vienlaikus neizdodas. Kā jau teicām, RabbitMQ nosÅ«ta apstiprinājumu izdevējam tikai pēc tam, kad galvenais un visi spoguļi ir ierakstÄ«juÅ”i ziņojumu diskā. Bet tas palielina latentumu divu iemeslu dēļ:

  • fsync ik pēc dažiem simtiem milisekundēm
  • Spoguļa kļūmi var pamanÄ«t tikai pēc tam, kad ir beidzies to pakeÅ”u kalpoÅ”anas laiks, kas pārbauda katra mezgla pieejamÄ«bu (neto Ä·eksÄ«tis). Ja spogulis palēninās vai nokrÄ«t, tas palielina kavÄ“Å”anos.

Kafkas likme ir tāda, ka, ja ziņojums tiek saglabāts vairākos mezglos, tas var apstiprināt ziņojumus, tiklīdz tie nonāk atmiņā. Šī iemesla dēļ pastāv risks pazaudēt jebkāda veida ziņojumus (pat acks=viss, min.insync.replicas=2) vienlaicīgas atteices gadījumā.

Kopumā Kafka uzrāda labāku programmatÅ«ras veiktspēju, un tā jau no paÅ”a sākuma ir izstrādāta klasteriem. Sekotāju skaitu var palielināt lÄ«dz 11, ja nepiecieÅ”ams uzticamÄ«bas labad. ReplicÄ“Å”anas faktors 5 un minimālais repliku skaits sinhronizācijā min.insync.replicas=3 padarÄ«s ziņojumu zaudÄ“Å”anu par ļoti retu notikumu. Ja jÅ«su infrastruktÅ«ra var atbalstÄ«t Å”o replikācijas attiecÄ«bu un dublÄ“Å”anas lÄ«meni, varat izvēlēties Å”o opciju.

RabbitMQ klasterizācija ir piemērota nelielām rindām. Bet pat nelielas rindas var ātri augt, ja ir intensÄ«va satiksme. Kad rindas kļūs lielas, jums bÅ«s jāizdara grÅ«ta izvēle starp pieejamÄ«bu un uzticamÄ«bu. RabbitMQ klasterizācija ir vislabāk piemērota netipiskām situācijām, kad RabbitMQ elastÄ«bas priekÅ”rocÄ«bas atsver visus klasterizācijas trÅ«kumus.

Viens pretlÄ«dzeklis RabbitMQ ievainojamÄ«bai pret lielām rindām ir to sadalÄ«Å”ana daudzās mazākās rindās. Ja neprasa pilnu visas rindas pasÅ«tÄ«Å”anu, bet tikai attiecÄ«gos ziņojumus (piemēram, ziņas no konkrēta klienta), vai arÄ« nepasÅ«tat vispār neko, tad ir pieņemama Ŕāda iespēja: paskaties uz manu projektu LÄ«dzsvarotājs lai sadalÄ«tu rindu (projekts vēl ir sākuma stadijā).

Visbeidzot, neaizmirstiet par vairākām kļūdām gan RabbitMQ, gan Kafka klasterizācijas un replikācijas mehānismos. Laika gaitā sistēmas ir kļuvuÅ”as nobrieduŔākas un stabilākas, taču neviens ziņojums nekad nebÅ«s 100% pasargāts no zuduma! Turklāt datu centros notiek liela mēroga avārijas!

Ja esmu kaut ko palaidis garām, kļūdījies vai jūs nepiekrītat kādam no punktiem, droŔi rakstiet komentāru vai sazinieties ar mani.

Man bieži jautā: ā€œKo izvēlēties, Kafka vai RabbitMQ?ā€, ā€œKura platforma ir labāka?ā€. PatiesÄ«ba ir tāda, ka tas tieŔām ir atkarÄ«gs no jÅ«su situācijas, paÅ”reizējās pieredzes utt. Es vilcinos sniegt savu viedokli, jo bÅ«tu pārāk daudz vienkārÅ”ot ieteikt vienu platformu visiem lietoÅ”anas gadÄ«jumiem un iespējamiem ierobežojumiem. Es rakstÄ«ju Å”o rakstu sēriju, lai jÅ«s varētu izveidot savu viedokli.

Es gribu teikt, ka abas sistēmas ir lÄ«deres Å”ajā jomā. Es varu bÅ«t nedaudz neobjektÄ«vs, jo no savas pieredzes ar projektiem es mēdzu novērtēt tādas lietas kā garantēta ziņojumu secÄ«ba un uzticamÄ«ba.

Es redzu citas tehnoloÄ£ijas, kurām trÅ«kst Ŕīs uzticamÄ«bas un garantētas pasÅ«tÄ«Å”anas, tad skatos uz RabbitMQ un Kafka un saprotu abu Å”o sistēmu neticamo vērtÄ«bu.

Avots: www.habr.com

Pievieno komentāru