{"id":52541,"date":"2019-11-11T00:00:00","date_gmt":"2019-11-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost"},"modified":"2020-02-18T14:00:17","modified_gmt":"2020-02-18T11:00:17","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/6557ce69c2b3070622feca8b3c228b09.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">p\u0159edchoz\u00edm \u010dl\u00e1nku<\/a><\/noindex> Zkoumali jsme clustering RabbitMQ pro zaji\u0161t\u011bn\u00ed odolnosti a vysok\u00e9 dostupnosti. Nyn\u00ed se pod\u00edv\u00e1me d\u016fkladn\u011bji na Apache Kafka.<\/p>\n<p>Jednotkou replikace je zde partition. Ka\u017ed\u00fd topic m\u00e1 jeden nebo v\u00edce partition\u016f. Ka\u017ed\u00fd partition m\u00e1 leadera s followerem nebo bez n\u011bj. P\u0159i vytv\u00e1\u0159en\u00ed topicu se ud\u00e1v\u00e1 po\u010det partition\u016f a koeficient replikace. Obvykl\u00e1 hodnota 3 znamen\u00e1 t\u0159i repliky: jednoho leadera a dva followery.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/36deb6d506223c2ee2ec147d5c215789.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 1. \u010cty\u0159i partitiony jsou rozlo\u017eeny mezi t\u0159emi brokery<\/i><\/p>\n<p>V\u0161echny po\u017eadavky na \u010dten\u00ed a z\u00e1pis sm\u011b\u0159uj\u00ed k leaderovi. Followe\u0159i pravideln\u011b pos\u00edlaj\u00ed leaderovi po\u017eadavky na z\u00edsk\u00e1n\u00ed posledn\u00edch zpr\u00e1v. Spot\u0159ebitel\u00e9 se nikdy neobrac\u00ed na followery, ti existuj\u00ed pouze pro redundanci a odolnost.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/715c51d75cb45863cfad4b37e81b9a9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>V\u00fdpadek partitionu<\/h1>\n<p>\nKdy\u017e broker vypadne, \u010dasto selh\u00e1vaj\u00ed leaderov\u00e9 n\u011bkolika partition\u016f. V ka\u017ed\u00e9m z nich se leaderem st\u00e1v\u00e1 follower z jin\u00e9ho uzlu. Ve skute\u010dnosti to tak nen\u00ed v\u017edy, proto\u017ee faktory synchronizace hraj\u00ed roli: existuj\u00ed synchronizovan\u00ed followe\u0159i, a pokud ne, je povolen p\u0159echod na nesynchronizovanou repliku. Ale zat\u00edm nebudeme komplikovat.<\/p>\n<p>Z s\u00edt\u011b odch\u00e1z\u00ed broker 3 \u2014 a pro partition 2 je zvolen nov\u00fd leader na brokeru 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/b8cfce64cf6b848b0659de023f9d9b63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 2. Broker 3 um\u00edr\u00e1, a jeho follower na brokeru 2 je zvolen nov\u00fdm leaderem partitionu 2<\/i><\/p>\n<p>Pak odch\u00e1z\u00ed broker 1 a partition 1 tak\u00e9 ztr\u00e1c\u00ed sv\u00e9ho leadera, jeho\u017e roli p\u0159eb\u00edr\u00e1 broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/9f5409c723da7ff059b93f9b23e7d5f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 3. Z\u016fstal pouze jeden broker. V\u0161ichni leaderov\u00e9 jsou na jednom brokeru s nulovou redundanc\u00ed<\/i><\/p>\n<p>Kdy\u017e se broker 1 vrac\u00ed do s\u00edt\u011b, p\u0159id\u00e1v\u00e1 \u010dty\u0159i followery, \u010d\u00edm\u017e zaji\u0161\u0165uje ur\u010ditou redundanci ka\u017ed\u00e9mu partitionu. Ale v\u0161ichni leaderov\u00e9 z\u016fst\u00e1vaj\u00ed na brokeru 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/f9c8e42f51258b7fd7f6f35dc7b8cc3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 4. Leaderov\u00e9 z\u016fst\u00e1vaj\u00ed na brokeru 2<\/i><\/p>\n<p>Kdy\u017e se broker 3 znovu spust\u00ed, vrac\u00edme se k t\u0159em replik\u00e1m na partitionu. Ale v\u0161ichni leaderov\u00e9 st\u00e1le z\u016fst\u00e1vaj\u00ed na brokeru 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/9c8c02be4161f8468b5dbc1e3f6ecb3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 5. Nevyv\u00e1\u017een\u00e9 um\u00edst\u011bn\u00ed leader\u016f po obnoven\u00ed broker\u016f 1 a 3<\/i><\/p>\n<p>Kafka m\u00e1 n\u00e1stroj pro kvalitn\u011bj\u0161\u00ed p\u0159ebalancov\u00e1n\u00ed leader\u016f ne\u017e RabbitMQ. Tam bylo nutn\u00e9 pou\u017e\u00edt extern\u00ed plugin nebo skript, kter\u00fd m\u011bnil politiky pro migraci hlavn\u00edho uzlu na \u00fakor sn\u00ed\u017een\u00ed redundance b\u011bhem migrace. Krom\u011b toho bylo t\u0159eba se u velk\u00fdch front sm\u00ed\u0159it s nedostupnost\u00ed b\u011bhem synchronizace.<\/p>\n<p>V Kafka existuje koncept \u201epreferovan\u00fdch replik\u201c pro roli l\u00eddra. Kdy\u017e se vytv\u00e1\u0159ej\u00ed \u010d\u00e1sti t\u00e9matu, Kafka se sna\u017e\u00ed rovnom\u011brn\u011b rozd\u011blit l\u00eddry mezi uzly a ozna\u010duje tyto prvn\u00ed l\u00eddry jako preferovan\u00e9. V pr\u016fb\u011bhu \u010dasu, kv\u016fli restartu server\u016f, selh\u00e1n\u00edm a poruch\u00e1m konektivity, se l\u00edd\u0159i mohou ocitnout na jin\u00fdch uzlech, jak bylo uvedeno v\u00fd\u0161e v extr\u00e9mn\u00edm p\u0159\u00edpad\u011b.<\/p>\n<p>Aby to napravila, Kafka nab\u00edz\u00ed dv\u011b mo\u017enosti:<\/p>\n<ul>\n<li>Volba <i>auto.leader.rebalance.enable=true<\/i> umo\u017e\u0148uje kontroln\u00edmu uzlu automaticky p\u0159e\u0159adit l\u00eddry zp\u011bt na preferovan\u00e9 repliky a t\u00edm obnovit rovnom\u011brn\u00e9 rozd\u011blen\u00ed.\n<\/li>\n<li>Spr\u00e1vce m\u016f\u017ee spustit skript <i>kafka-preferred-replica-election.sh<\/i> pro ru\u010dn\u00ed p\u0159e\u0159azen\u00ed.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/831930b06809637018fecb6d7d5a558d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr\u00e1zek 6. Repliky po p\u0159ebalancov\u00e1n\u00ed<\/i><\/p>\n<p>Jednalo se o zjednodu\u0161enou verzi selh\u00e1n\u00ed, ale skute\u010dnost je slo\u017eit\u011bj\u0161\u00ed, i kdy\u017e zde nen\u00ed nic p\u0159\u00edli\u0161 komplikovan\u00e9ho. V\u0161e se odv\u00edj\u00ed od synchronizovan\u00fdch replik (In-Sync Replicas, ISR).<\/p>\n<h1>Synchronizovan\u00e9 repliky (ISR)<\/h1>\n<p>\nISR je sada replik \u010d\u00e1sti, kter\u00e1 je pova\u017eov\u00e1na za \u201esynchronizovanou\u201c (in-sync). Existuje zde l\u00eddr a nemus\u00ed b\u00fdt \u017e\u00e1dn\u00ed followerov\u00e9. Follower je pova\u017eov\u00e1n za synchronizovan\u00e9ho, pokud p\u0159esn\u011b zkop\u00edroval v\u0161echny zpr\u00e1vy l\u00eddra p\u0159ed uplynut\u00edm intervalu <i>replica.lag.time.max.ms<\/i>.<\/p>\n<p>Follower je odstran\u011bn ze skupiny ISR, pokud:<\/p>\n<ul>\n<li>neprovedl po\u017eadavek na vyta\u017een\u00ed b\u011bhem intervalu <i>replica.lag.time.max.ms<\/i> (pova\u017eov\u00e1n za mrtv\u00e9ho)\n<\/li>\n<li>nestihl se aktualizovat b\u011bhem intervalu <i>replica.lag.time.max.ms<\/i> (pova\u017eov\u00e1n za pomal\u00e9ho)<\/li>\n<\/ul>\n<p>\nFollowerov\u00e9 prov\u00e1d\u011bj\u00ed po\u017eadavky na vyta\u017een\u00ed b\u011bhem intervalu <i>replica.fetch.wait.max.ms<\/i>, kter\u00fd m\u00e1 ve v\u00fdchoz\u00edm nastaven\u00ed hodnotu 500 ms.<\/p>\n<p>Abychom jasn\u011b vysv\u011btlili \u00fa\u010del ISR, mus\u00edme se pod\u00edvat na potvrzen\u00ed od v\u00fdrobce (producer) a n\u011bkter\u00e9 sc\u00e9n\u00e1\u0159e selh\u00e1n\u00ed. V\u00fdrobci mohou zvolit, kdy broker ode\u0161le potvrzen\u00ed:<\/p>\n<ul>\n<li>acks=0, potvrzen\u00ed se neodes\u00edl\u00e1\n<\/li>\n<li>acks=1, potvrzen\u00ed se odes\u00edl\u00e1 pot\u00e9, co l\u00eddr zap\u00ed\u0161e zpr\u00e1vu do sv\u00e9ho lok\u00e1ln\u00edho logu\n<\/li>\n<li>acks=all, potvrzen\u00ed se odes\u00edl\u00e1 pot\u00e9, co v\u0161echny repliky v ISR zapsaly zpr\u00e1vu do sv\u00fdch lok\u00e1ln\u00edch log\u016f<\/li>\n<\/ul>\n<p>\nV terminologii Kafky, pokud ISR uchoval zpr\u00e1vu, doch\u00e1z\u00ed k jej\u00edmu \u201ecommitnut\u00ed\u201c. Acks=all je nejbezpe\u010dn\u011bj\u0161\u00ed mo\u017enost, ale tak\u00e9 se poj\u00ed s dodate\u010dn\u00fdm zpo\u017ed\u011bn\u00edm. Pod\u00edvejme se na dva p\u0159\u00edklady selh\u00e1n\u00ed a jak r\u016fzn\u00e9 mo\u017enosti 'acks' interaguj\u00ed s konceptem ISR.<\/p>\n<h3>Acks=1 a ISR<\/h3>\n<p>\nV tomto p\u0159\u00edkladu uvid\u00edme, \u017ee pokud v\u016fdce ne\u010dek\u00e1 na potvrzen\u00ed ka\u017ed\u00e9 zpr\u00e1vy od v\u0161ech follower\u016f, m\u016f\u017ee p\u0159i selh\u00e1n\u00ed v\u016fdce doj\u00edt ke ztr\u00e1t\u011b dat. P\u0159echod k nesynchronizovan\u00e9mu followerovi m\u016f\u017ee b\u00fdt povolen nebo zak\u00e1z\u00e1n nastaven\u00edm <i>unclean.leader.election.enable<\/i>.<\/p>\n<p>V tomto p\u0159\u00edkladu v\u00fdrobce nastavuje hodnotu acks=1. Rozd\u011blen\u00ed je rozlo\u017eeno na v\u0161echny t\u0159i brokery. Broker 3 zaost\u00e1v\u00e1, synchronizoval se s v\u016fdcem p\u0159ed osmi sekundami a nyn\u00ed zaost\u00e1v\u00e1 o 7456 zpr\u00e1v. Broker 1 zaost\u00e1v\u00e1 pouze o jednu sekundu. N\u00e1\u0161 v\u00fdrobce odes\u00edl\u00e1 zpr\u00e1vu a rychle obdr\u017e\u00ed zp\u011bt ack, bez zbyte\u010dn\u00e9ho zat\u00ed\u017een\u00ed ze strany pomal\u00fdch nebo mrtv\u00fdch follower\u016f, na kter\u00e9 v\u016fdce ne\u010dek\u00e1.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/f194e6309b732b772574392eff482a8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 7. ISR se t\u0159emi replikami<\/i><\/p>\n<p>Broker 2 sel\u017ee a v\u00fdrobce obdr\u017e\u00ed chybu p\u0159ipojen\u00ed. Po p\u0159echodu veden\u00ed k brokeru 1 ztr\u00e1c\u00edme 123 zpr\u00e1v. Follower na brokeru 1 byl v ISR, ale nebyl pln\u011b synchronizov\u00e1n s v\u016fdcem, kdy\u017e ten selhal.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/367f219daebafefe585059f67fdedf6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 8. P\u0159i selh\u00e1n\u00ed se ztr\u00e1cej\u00ed zpr\u00e1vy<\/i><\/p>\n<p>V konfiguraci <i>bootstrap.servers<\/i> je n\u011bkolik broker\u016f uvedeno u v\u00fdrobce, a m\u016f\u017ee se zeptat jin\u00e9ho brokera, kdo se stal nov\u00fdm v\u016fdcem rozd\u011blen\u00ed. Pot\u00e9 se p\u0159ipojuje k brokeru 1 a pokra\u010duje v odes\u00edl\u00e1n\u00ed zpr\u00e1v.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/ba45c51f4ce1f63f10b2fa0e1487b223.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 9. Odes\u00edl\u00e1n\u00ed zpr\u00e1v se obnovuje po kr\u00e1tk\u00e9 pauze<\/i><\/p>\n<p>Broker 3 je\u0161t\u011b v\u00edce zaost\u00e1v\u00e1. Prov\u00e1d\u00ed dotazy na vy\u017e\u00e1d\u00e1n\u00ed, ale nem\u016f\u017ee se synchronizovat. To m\u016f\u017ee b\u00fdt zp\u016fsobeno pomal\u00fdm s\u00ed\u0165ov\u00fdm p\u0159ipojen\u00edm mezi brokery, probl\u00e9my se skladov\u00e1n\u00edm atd. Je odstran\u011bn z ISR. Nyn\u00ed je ISR slo\u017een pouze z jedn\u00e9 repliky \u2014 v\u016fdce! V\u00fdrobce pokra\u010duje v odes\u00edl\u00e1n\u00ed zpr\u00e1v a dost\u00e1v\u00e1 potvrzen\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/592c74632e3a8d80c2b4fc15bde5d401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 10. Follower na brokeru 3 je odstran\u011bn z ISR<\/i><\/p>\n<p>Broker 1 sel\u017ee a role v\u016fdce p\u0159ech\u00e1z\u00ed na broker 3 se ztr\u00e1tou 15286 zpr\u00e1v! V\u00fdrobce obdr\u017e\u00ed zpr\u00e1vu o chyb\u011b p\u0159ipojen\u00ed. P\u0159echod k v\u016fdci mimo ISR byl mo\u017en\u00fd pouze d\u00edky nastaven\u00ed <i>unclean.leader.election.enable=true<\/i>. Pokud je nastavena na <i>false<\/i>, k p\u0159echodu by nedo\u0161lo a v\u0161echny po\u017eadavky na \u010dten\u00ed a z\u00e1pis by byly odm\u00edtnuty. V tomto p\u0159\u00edpad\u011b \u010dek\u00e1me na n\u00e1vrat brokera 1 s jeho nedot\u010den\u00fdmi daty v replikaci, kter\u00e1 op\u011bt p\u0159evezme veden\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/30f01ca715ccc194890ae061a3ef7396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 11. Broker 1 selh\u00e1v\u00e1. P\u0159i selh\u00e1n\u00ed doch\u00e1z\u00ed k velk\u00e9 ztr\u00e1t\u011b zpr\u00e1v.<\/i><\/p>\n<p>V\u00fdrobce se p\u0159ipojuje k posledn\u00edmu brokerovi a vid\u00ed, \u017ee ten je nyn\u00ed l\u00eddrem sekce. Za\u010d\u00edn\u00e1 pos\u00edlat zpr\u00e1vy brokerovi 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/986532d9b22b6514b6039c8460b1beb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 12. Po kr\u00e1tk\u00e9 pauze se zpr\u00e1vy znovu pos\u00edlaj\u00ed do sekce 0<\/i><\/p>\n<p>Vid\u011bli jsme, \u017ee krom\u011b kr\u00e1tk\u00fdch p\u0159eru\u0161en\u00ed pro nastavov\u00e1n\u00ed nov\u00fdch p\u0159ipojen\u00ed a hled\u00e1n\u00ed nov\u00e9ho l\u00eddra v\u00fdrobce neust\u00e1le pos\u00edlal zpr\u00e1vy. Tato konfigurace zaji\u0161\u0165uje dostupnost na \u00fakor konzistence (bezpe\u010dnosti dat). Kafka ztratila tis\u00edce zpr\u00e1v, ale pokra\u010dovala v p\u0159ij\u00edm\u00e1n\u00ed nov\u00fdch z\u00e1znam\u016f.<\/p>\n<h3>Acks=all a ISR<\/h3>\n<p>\nPoj\u010fme si tento sc\u00e9n\u00e1\u0159 zopakovat je\u0161t\u011b jednou, ale s <i>acks=all<\/i>. Zpo\u017ed\u011bn\u00ed brokeru 3 je v pr\u016fm\u011bru \u010dty\u0159i sekundy. V\u00fdrobce pos\u00edl\u00e1 zpr\u00e1vu s <i>acks=all<\/i>, a nyn\u00ed nedost\u00e1v\u00e1 rychlou odpov\u011b\u010f. L\u00eddrovi trv\u00e1, ne\u017e po\u010dk\u00e1, a\u017e zpr\u00e1vu ulo\u017e\u00ed v\u0161echny repliky v ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/95b1abdc92e699f7bc41ebab249a2e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 13. ISR se t\u0159emi replikami. Jedna pracuje pomalu, co\u017e vede ke zpo\u017ed\u011bn\u00ed z\u00e1pisu<\/i><\/p>\n<p>Po \u010dty\u0159ech sekund\u00e1ch dodate\u010dn\u00e9ho zpo\u017ed\u011bn\u00ed broker 2 ode\u0161le ack. V\u0161echny repliky jsou nyn\u00ed pln\u011b aktualizov\u00e1ny.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/64356dc8d2641a3e22947126dd047f39.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 14. V\u0161echny repliky uchov\u00e1vaj\u00ed zpr\u00e1vy a pos\u00edlaj\u00ed ack<\/i><\/p>\n<p>Broker 3 nyn\u00ed z\u016fst\u00e1v\u00e1 pozadu je\u0161t\u011b v\u00edce a je odstran\u011bn z ISR. Zpo\u017ed\u011bn\u00ed se v\u00fdrazn\u011b sni\u017euje, proto\u017ee v ISR ji\u017e nez\u016fstaly pomal\u00e9 repliky. Broker 2 nyn\u00ed \u010dek\u00e1 pouze na brokera 1, jeho\u017e pr\u016fm\u011brn\u00e9 zpo\u017ed\u011bn\u00ed je 500 ms.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/5d3bd67dc53cb868fa40b358ed483a1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 15. Replika na brokeru 3 je odstran\u011bna z ISR<\/i><\/p>\n<p>Pot\u00e9 dojde k p\u00e1du brokera 2, a veden\u00ed p\u0159ech\u00e1z\u00ed k brokeru 1 bez ztr\u00e1ty zpr\u00e1v.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/e3f0417aa7714ea5eae8a8e8d61662bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 16. Broker 2 selh\u00e1v\u00e1<\/i><\/p>\n<p>V\u00fdrobce najde nov\u00e9ho l\u00eddra a za\u010dne mu pos\u00edlat zpr\u00e1vy. Zpo\u017ed\u011bn\u00ed se d\u00e1le sni\u017euje, proto\u017ee nyn\u00ed se ISR skl\u00e1d\u00e1 z jedn\u00e9 repliky! Proto mo\u017enost <i>acks=all<\/i> nep\u0159id\u00e1v\u00e1 redundanci.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/fec9aae9977757d5f61c2909ceae0536.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 17. Replika na brokeru 1 p\u0159eb\u00edr\u00e1 veden\u00ed bez ztr\u00e1ty zpr\u00e1v<\/i><\/p>\n<p>N\u00e1sledn\u011b dojde k p\u00e1du brokera 1 a veden\u00ed p\u0159ech\u00e1z\u00ed k brokeru 3 se ztr\u00e1tou 14238 zpr\u00e1v!<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/730b3951fb75ab3a782fc6d064615212.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 18. Broker 1 um\u00edr\u00e1, a p\u0159echod veden\u00ed s nastaven\u00edm unclean vede k rozs\u00e1hl\u00e9 ztr\u00e1t\u011b dat<\/i><\/p>\n<p>Mohli bychom nenastavovat mo\u017enost <i>unclean.leader.election.enable<\/i> na hodnotu <i>true<\/i>. Ve v\u00fdchoz\u00edm nastaven\u00ed je nastavena na <i>false<\/i>. Nastaven\u00ed <i>acks=all<\/i> s <i>unclean.leader.election.enable=true<\/i> zaji\u0161\u0165uje dostupnost s ur\u010ditou dodate\u010dnou bezpe\u010dnost\u00ed dat. Jak vid\u00edte, st\u00e1le v\u0161ak m\u016f\u017eeme ztratit zpr\u00e1vy.<\/p>\n<p>Ale co kdy\u017e chceme zv\u00fd\u0161it bezpe\u010dnost dat? M\u016f\u017eeme nastavit <i>unclean.leader.election.enable = false<\/i>, ale to nemus\u00ed zabr\u00e1nit ztr\u00e1t\u011b dat. Pokud v\u016fdce tvrd\u011b padne a s sebou si vezme data, zpr\u00e1vy jsou stejn\u011b ztraceny, plus dostupnost je ztracena, dokud administr\u00e1tor situaci neobnov\u00ed.<\/p>\n<p>Je lep\u0161\u00ed zajistit redundantnost v\u0161ech zpr\u00e1v, nebo jinak se z\u00e1znamu vzd\u00e1t. Pak je z hlediska brokera ztr\u00e1ta dat mo\u017en\u00e1 pouze p\u0159i dvou nebo v\u00edce sou\u010dasn\u00fdch selh\u00e1n\u00edch.<\/p>\n<h3>Acks=all, min.insync.replicas a ISR<\/h3>\n<p>\nS konfigurac\u00ed t\u00e9matu <i>min.insync.replicas<\/i> zvy\u0161ujeme \u00farove\u0148 zabezpe\u010den\u00ed dat. Poj\u010fme se znovu pod\u00edvat na posledn\u00ed \u010d\u00e1st minul\u00e9ho sc\u00e9n\u00e1\u0159e, ale tentokr\u00e1t s <i>min.insync.replicas=2<\/i>.<\/p>\n<p>Tak\u017ee broker 2 m\u00e1 v\u016fdce repliky a sledova\u010d na brokeru 3 byl odstran\u011bn z ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/5831463293f1837d3232756894e97162.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 19. ISR ze dvou replik<\/i><\/p>\n<p>Broker 2 sel\u017ee a v\u016fdcovstv\u00ed p\u0159ech\u00e1z\u00ed na broker 1 bez ztr\u00e1ty zpr\u00e1v. Ale nyn\u00ed ISR se skl\u00e1d\u00e1 pouze z jedn\u00e9 repliky. To neodpov\u00edd\u00e1 minim\u00e1ln\u00edmu po\u010dtu pro z\u00e1znamy, a proto broker odpov\u00edd\u00e1 na pokus o z\u00e1znam chybou <i>NotEnoughReplicas<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/6b2ee477f4c33ec84f3068b792814e5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 20. Po\u010det ISR je o jeden ni\u017e\u0161\u00ed ne\u017e uvedeno v min.insync.replicas<\/i><\/p>\n<p>Tato konfigurace ob\u011btuje dostupnost ve prosp\u011bch konzistence. Ne\u017e potvrd\u00edme zpr\u00e1vu, zaji\u0161\u0165ujeme, \u017ee je zaps\u00e1na alespo\u0148 na dvou replik\u00e1ch. To d\u00e1v\u00e1 v\u00fdrobci mnohem v\u011bt\u0161\u00ed jistotu. Zde je ztr\u00e1ta zpr\u00e1v mo\u017en\u00e1 pouze v p\u0159\u00edpad\u011b sou\u010dasn\u00e9ho selh\u00e1n\u00ed dvou replik b\u011bhem kr\u00e1tk\u00e9ho intervalu, dokud zpr\u00e1va nen\u00ed replikov\u00e1na dal\u0161\u00edmu sledova\u010di, co\u017e je nepravd\u011bpodobn\u00e9. Ale pokud jste superparanoik, m\u016f\u017eete nastavit pom\u011br replikace na 5 a <i>min.insync.replicas<\/i> na 3. Najednou mus\u00ed t\u0159i brokery zkolabovat, aby z\u00e1znam ztratil! Samoz\u0159ejm\u011b za takovou spolehlivost zaplat\u00edte dodate\u010dnou prodlevou.<\/p>\n<h1>Kdy\u017e je dostupnost nezbytn\u00e1 pro bezpe\u010dnost dat<\/h1>\n<p>\nStejn\u011b jako v <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">v p\u0159\u00edpad\u011b RabbitMQ<\/a><\/noindex>, ob\u010das je dostupnost nezbytn\u00e1 pro bezpe\u010dnost dat. Mus\u00edte p\u0159em\u00fd\u0161let o n\u00e1sleduj\u00edc\u00edm:<\/p>\n<ul>\n<li>M\u016f\u017ee publisher jednodu\u0161e vr\u00e1tit chybu a nad\u0159azen\u00e1 slu\u017eba nebo u\u017eivatel to zkusit znovu pozd\u011bji?\n<\/li>\n<li>M\u016f\u017ee publisher ulo\u017eit zpr\u00e1vu lok\u00e1ln\u011b nebo do datab\u00e1ze, aby to zkusil znovu pozd\u011bji?<\/li>\n<\/ul>\n<p>\nPokud je odpov\u011b\u010f z\u00e1porn\u00e1, zlep\u0161en\u00ed dostupnosti zvy\u0161uje bezpe\u010dnost dat. Ztrat\u00edte m\u00e9n\u011b dat, pokud zvol\u00edte dostupnost m\u00edsto zru\u0161en\u00ed z\u00e1pisu. Tak\u017ee v\u0161e spo\u010d\u00edv\u00e1 v hled\u00e1n\u00ed rovnov\u00e1hy a rozhodnut\u00ed z\u00e1vis\u00ed na konkr\u00e9tn\u00ed situaci.<\/p>\n<h1>V\u00fdznam ISR<\/h1>\n<p>\nSada ISR umo\u017e\u0148uje zvolit optim\u00e1ln\u00ed rovnov\u00e1hu mezi bezpe\u010dnost\u00ed dat a latenc\u00ed. Nap\u0159\u00edklad zajistit dostupnost v p\u0159\u00edpad\u011b selh\u00e1n\u00ed v\u011bt\u0161iny replik, p\u0159i\u010dem\u017e se minimalizuje vliv mrtv\u00fdch nebo pomal\u00fdch replik z hlediska latence.<\/p>\n<p>My sami vyb\u00edr\u00e1me hodnotu <i>replica.lag.time.max.ms<\/i> podle sv\u00fdch pot\u0159eb. V podstat\u011b tento parametr znamen\u00e1, jakou latenci jsme ochotni akceptovat p\u0159i <i>acks=all<\/i>. V\u00fdchoz\u00ed hodnota je deset sekund. Pokud je to pro v\u00e1s p\u0159\u00edli\u0161 dlouho, m\u016f\u017eete ji zkr\u00e1tit. Pot\u00e9 se zv\u00fd\u0161\u00ed frekvence zm\u011bn v ISR, proto\u017ee se followe\u0159i budou \u010dast\u011bji odstra\u0148ovat a p\u0159id\u00e1vat.<\/p>\n<p>V RabbitMQ jde pouze o sadu zrcadel, kter\u00e1 je t\u0159eba replikovat. Pomal\u00e1 zrcadla p\u0159in\u00e1\u0161ej\u00ed dodate\u010dnou latenci a na odpov\u011b\u010f mrtv\u00fdch zrcadel m\u016f\u017eete \u010dekat a\u017e do vypr\u0161en\u00ed doby \u017eivotnosti paket\u016f, kter\u00e9 kontroluj\u00ed dostupnost ka\u017ed\u00e9ho uzlu (net tick). ISR je zaj\u00edmav\u00fd zp\u016fsob, jak se vyhnout t\u011bmto probl\u00e9m\u016fm s v\u00fd\u0161e uvedenou latenc\u00ed. Riskujeme v\u0161ak ztr\u00e1tu redundance, proto\u017ee ISR m\u016f\u017ee b\u00fdt sn\u00ed\u017eena pouze na l\u00eddra. Abyste se tomuto riziku vyhnuli, pou\u017eijte nastaven\u00ed <i>min.insync.replicas<\/i>.<\/p>\n<h1>Z\u00e1ruka p\u0159ipojen\u00ed klient\u016f<\/h1>\n<p>\nV nastaven\u00ed <i>bootstrap.servers<\/i> v\u00fdrobce a spot\u0159ebitele m\u016f\u017eete uv\u00e9st n\u011bkolik broker\u016f pro p\u0159ipojen\u00ed klient\u016f. My\u0161lenkou je, \u017ee pokud dojde k v\u00fdpadku jednoho uzlu, z\u016fst\u00e1v\u00e1 n\u011bkolik z\u00e1lo\u017en\u00edch, se kter\u00fdmi m\u016f\u017ee klient nav\u00e1zat spojen\u00ed. Nemus\u00ed to b\u00fdt nutn\u011b l\u00edd\u0159i odd\u011blen\u00ed, ale jen z\u00e1kladna pro po\u010d\u00e1te\u010dn\u00ed na\u010dten\u00ed. Klient se m\u016f\u017ee zeptat, na kter\u00e9m uzlu je um\u00edst\u011bn l\u00eddr odd\u011blen\u00ed pro \u010dten\u00ed\/z\u00e1pis.<\/p>\n<p>V RabbitMQ se klienti mohou p\u0159ipojit k libovoln\u00e9mu uzlu a intern\u00ed sm\u011brov\u00e1n\u00ed ode\u0161le po\u017eadavek tam, kam je t\u0159eba. To znamen\u00e1, \u017ee m\u016f\u017eete nastavit p\u0159ed RabbitMQ vyrovn\u00e1va\u010d z\u00e1t\u011b\u017ee. Kafka vy\u017eaduje, aby se klienti p\u0159ipojili k uzlu, na kter\u00e9m je um\u00edst\u011bn l\u00eddr p\u0159\u00edslu\u0161n\u00e9ho odd\u011blen\u00ed. V takov\u00e9 situaci nelze um\u00edstit vyrovn\u00e1va\u010d z\u00e1t\u011b\u017ee. Seznam <i>bootstrap.servers<\/i> je kriticky d\u016fle\u017eit\u00fd, aby se klienti mohli obracet na pot\u0159ebn\u00e9 uzly a naj\u00edt je po selh\u00e1n\u00ed.<\/p>\n<h1>Architektura konsensu Kafka<\/h1>\n<p>\nDosud jsme se nezab\u00fdvali t\u00edm, jak cluster zjist\u00ed, \u017ee do\u0161lo k selh\u00e1n\u00ed brokera, a jak je vybr\u00e1n nov\u00fd l\u00eddr. Abychom pochopili, jak Kafka pracuje s s\u00ed\u0165ov\u00fdmi d\u011blen\u00edmi, mus\u00edme nejprve pochopit architekturu konsensu.<\/p>\n<p>Ka\u017ed\u00fd cluster Kafka je nasazen spolu s clusterem Zookeeper \u2014 to je slu\u017eba distribuovan\u00e9ho konsensu, kter\u00e1 umo\u017e\u0148uje syst\u00e9mu dos\u00e1hnout konsensu o ur\u010dit\u00e9m stanoven\u00e9m stavu s prioritou na konzistenci p\u0159ed dostupnost\u00ed. Pro schv\u00e1len\u00ed operac\u00ed \u010dten\u00ed a z\u00e1pisu je zapot\u0159eb\u00ed souhlas v\u011bt\u0161iny uzl\u016f Zookeeper.<\/p>\n<p>Zookeeper uchov\u00e1v\u00e1 stav clusteru:<\/p>\n<ul>\n<li>Seznam t\u00e9mat, segment\u016f, konfiguraci, aktu\u00e1ln\u00ed repliky l\u00eddra, preferovan\u00e9 repliky.\n<\/li>\n<li>\u010clenov\u00e9 clusteru. Ka\u017ed\u00fd broker ping\u00e1 clusteru Zookeeper. Pokud nedostane ping b\u011bhem stanoven\u00e9ho \u010dasov\u00e9ho obdob\u00ed, Zookeeper zaznamen\u00e1 brokera jako nedostupn\u00e9ho.\n<\/li>\n<li>V\u00fdb\u011br hlavn\u00edch a z\u00e1lo\u017en\u00edch uzl\u016f pro kontroler.<\/li>\n<\/ul>\n<p>\nKontroler uzlu \u2014 je jedn\u00edm z broker\u016f Kafka, kter\u00fd je zodpov\u011bdn\u00fd za volbu l\u00eddr\u016f replik. Zookeeper pos\u00edl\u00e1 kontroleru ozn\u00e1men\u00ed o \u010dlenstv\u00ed v clusteru a zm\u011bn\u00e1ch t\u00e9mat, a kontroler mus\u00ed jednat podle t\u011bchto zm\u011bn.<\/p>\n<p>Nap\u0159\u00edklad vezm\u011bte nov\u00e9 t\u00e9ma s deseti segmenty a koeficientem replikace 3. Kontroler mus\u00ed vybrat l\u00eddra ka\u017ed\u00e9ho segmentu s c\u00edlem optim\u00e1ln\u011b rozlo\u017eit l\u00eddry mezi brokery. <\/p>\n<p>Pro ka\u017ed\u00fd segment kontroler:<\/p>\n<ul>\n<li>aktualizuje informace v Zookeeper o ISR a l\u00eddrovi;\n<\/li>\n<li>pos\u00edl\u00e1 p\u0159\u00edkaz LeaderAndISRCommand ka\u017ed\u00e9mu brokerovi, kter\u00fd umis\u0165uje repliku tohoto segmentu, informuj\u00edc\u00ed brokery o ISR a l\u00eddrovi.<\/li>\n<\/ul>\n<p>\nKdy\u017e dojde k p\u00e1du brokera s l\u00eddrem, Zookeeper pos\u00edl\u00e1 ozn\u00e1men\u00ed kontroleru, a ten vyb\u00edr\u00e1 nov\u00e9ho l\u00eddra. Op\u011bt, kontroler nejprve aktualizuje Zookeeper a pot\u00e9 pos\u00edl\u00e1 p\u0159\u00edkaz ka\u017ed\u00e9mu brokerovi, upozor\u0148uj\u00edc\u00ed je na zm\u011bnu veden\u00ed.<\/p>\n<p>Ka\u017ed\u00fd l\u00eddr nese odpov\u011bdnost za sadu ISR. Nastaven\u00ed <i>replica.lag.time.max.ms<\/i> ur\u010duje, kdo do n\u00ed vstoup\u00ed. P\u0159i zm\u011bn\u011b ISR l\u00eddr p\u0159ed\u00e1v\u00e1 Zookeeper nov\u00e9 informace.<\/p>\n<p>Zookeeper je v\u017edy informov\u00e1n o jak\u00fdchkoli zm\u011bn\u00e1ch, aby v p\u0159\u00edpad\u011b selh\u00e1n\u00ed veden\u00ed hladce p\u0159e\u0161lo k nov\u00e9mu l\u00eddrovi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/3adb1d204b28e3ed85bef3530fa2b738.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 21. Konsensus Kafka<\/i><\/p>\n<h1>Protokol replikace<\/h1>\n<p>\nPochopen\u00ed detail\u016f replikace pom\u00e1h\u00e1 l\u00e9pe ch\u00e1pat potenci\u00e1ln\u00ed sc\u00e9n\u00e1\u0159e ztr\u00e1ty dat.<\/p>\n<h3>\u017d\u00e1dosti o z\u00edsk\u00e1n\u00ed, Log End Offset (LEO) a Highwater Mark (HW)<\/h3>\n<p>\nProzkoumali jsme, \u017ee followe\u0159i ob\u010das pos\u00edlaj\u00ed v\u016fdci \u017e\u00e1dosti na na\u010dten\u00ed (fetch). V\u00fdchoz\u00ed interval je 500 ms. To se li\u0161\u00ed od RabbitMQ, proto\u017ee v RabbitMQ replikace nen\u00ed iniciov\u00e1na zrcadlem fronty, ale v\u016fdcem. V\u016fdce pos\u00edl\u00e1 zm\u011bny na zrcadla.<\/p>\n<p>V\u016fdce a v\u0161ichni followe\u0159i uchov\u00e1vaj\u00ed offset konce logu (Log End Offset, LEO) a zna\u010dku Highwater (HW). Zna\u010dka LEO uchov\u00e1v\u00e1 offset posledn\u00ed zpr\u00e1vy v lok\u00e1ln\u00ed replikaci, zat\u00edmco HW ukl\u00e1d\u00e1 offset posledn\u00edho potvrzen\u00ed. Pamatujte, \u017ee pro stav \u201epotvrzeno\u201c mus\u00ed b\u00fdt zpr\u00e1va ulo\u017eena ve v\u0161ech replik\u00e1ch ISR. To znamen\u00e1, \u017ee LEO obvykle m\u00edrn\u011b p\u0159edb\u00edh\u00e1 HW.<\/p>\n<p>Kdy\u017e v\u016fdce obdr\u017e\u00ed zpr\u00e1vu, ulo\u017e\u00ed ji lok\u00e1ln\u011b. Followe\u0159i prov\u00e1d\u011bj\u00ed \u017e\u00e1dost na na\u010dten\u00ed, p\u0159ed\u00e1vaj\u00edce sv\u016fj LEO. Pak v\u016fdce pos\u00edl\u00e1 bal\u00ed\u010dek zpr\u00e1v po\u010d\u00ednaje t\u00edmto LEO a p\u0159ed\u00e1v\u00e1 aktu\u00e1ln\u00ed HW. Kdy\u017e v\u016fdce dostane informace, \u017ee v\u0161echny repliky ulo\u017eily zpr\u00e1vu se zadan\u00fdm offsetem, posune zna\u010dku HW. Pouze v\u016fdce m\u016f\u017ee posunout HW, a tak se v\u0161ichni followe\u0159i dozv\u011bd\u00ed aktu\u00e1ln\u00ed hodnotu v odpov\u011bd\u00edch na sv\u00e9 \u017e\u00e1dosti. To znamen\u00e1, \u017ee followe\u0159i mohou zaost\u00e1vat za v\u016fdcem, jak ve zpr\u00e1v\u00e1ch, tak co se t\u00fd\u010de znalosti HW. Spot\u0159ebitel\u00e9 dost\u00e1vaj\u00ed zpr\u00e1vy pouze do aktu\u00e1ln\u00edho HW.<\/p>\n<p>V\u0161imn\u011bte si, \u017ee \u201eulo\u017een\u00fd\u201c (persisted) znamen\u00e1, \u017ee je zapsan\u00fd v pam\u011bti, nikoli na disk. Pro v\u00fdkon, Kafka prov\u00e1d\u00ed synchronizaci na disk s ur\u010dit\u00fdm intervalem. RabbitMQ m\u00e1 tak\u00e9 takov\u00fd interval, ale po\u0161le potvrzen\u00ed vydavateli a\u017e pot\u00e9, co v\u016fdce a v\u0161echna zrcadla zap\u00ed\u0161\u00ed zpr\u00e1vu na disk. V\u00fdvoj\u00e1\u0159i Kafky se rozhodli, z d\u016fvodu v\u00fdkonu, pos\u00edlat ack, jakmile je zpr\u00e1va ulo\u017eena v pam\u011bti. Kafka se spol\u00e9h\u00e1 na to, \u017ee redundantnost kompenzuje riziko kr\u00e1tkodob\u00e9ho uchov\u00e1v\u00e1n\u00ed potvrzen\u00fdch zpr\u00e1v jen v pam\u011bti.<\/p>\n<h1>Selh\u00e1n\u00ed v\u016fdce<\/h1>\n<p>\nKdy\u017e v\u016fdce sel\u017ee, Zookeeper upozorn\u00ed kontrolera, kter\u00fd vybere novou repliku v\u016fdce. Nov\u00fd v\u016fdce nastav\u00ed novou zna\u010dku HW podle sv\u00e9ho LEO. Pot\u00e9 obdr\u017e\u00ed follo\u0159i informace o nov\u00e9m v\u016fdci. V z\u00e1vislosti na verzi Kafky si follower zvol\u00ed jeden ze dvou sc\u00e9n\u00e1\u0159\u016f:<\/p>\n<ol>\n<li>Zkr\u00e1t\u00ed lok\u00e1ln\u00ed log na zn\u00e1m\u00fd HW a po\u0161le nov\u00e9mu v\u016fdci \u017e\u00e1dost o zpr\u00e1vy po t\u00e9to zna\u010dce.\n<\/li>\n<li>Po\u0161le dotaz v\u016fdci, aby zjistil HW v okam\u017eiku jeho zvolen\u00ed v\u016fdcem, a pot\u00e9 zkr\u00e1t\u00ed log na toto posunut\u00ed. Pot\u00e9 za\u010dne prov\u00e1d\u011bt periodick\u00e9 dotazy na vzorkov\u00e1n\u00ed, po\u010d\u00ednaje t\u00edmto posunut\u00edm.<\/li>\n<\/ol>\n<p>\nN\u00e1sledovn\u00edk m\u016f\u017ee pot\u0159ebovat zkr\u00e1tit log z n\u00e1sleduj\u00edc\u00edch d\u016fvod\u016f:<\/p>\n<ul>\n<li>Kdy\u017e dojde k selh\u00e1n\u00ed v\u016fdce, prvn\u00ed n\u00e1sledovn\u00edk z mno\u017einy ISR, registrovan\u00fd v Zookeeper, vyhr\u00e1v\u00e1 volby a st\u00e1v\u00e1 se v\u016fdcem. V\u0161ichni n\u00e1sledovn\u00edci v ISR, a\u010dkoli jsou pova\u017eov\u00e1ni za \"synchronizovan\u00e9\", nemuseli od b\u00fdval\u00e9ho v\u016fdce obdr\u017eet kopie v\u0161ech zpr\u00e1v. Je velmi pravd\u011bpodobn\u00e9, \u017ee zvolen\u00fd n\u00e1sledovn\u00edk nem\u00e1 nejaktu\u00e1ln\u011bj\u0161\u00ed kopii. Kafka zaru\u010duje, \u017ee mezi replikami nen\u00ed nesoulad. Aby se tedy p\u0159ede\u0161lo nesouladu, ka\u017ed\u00fd n\u00e1sledovn\u00edk mus\u00ed zkr\u00e1tit sv\u016fj log na hodnotu HW nov\u00e9ho v\u016fdce v okam\u017eiku jeho zvolen\u00ed. To je dal\u0161\u00ed d\u016fvod, pro\u010d je nastaven\u00ed <i>acks=all<\/i> tak d\u016fle\u017eit\u00e9 pro konzistenci.\n<\/li>\n<li>Zpr\u00e1vy jsou pravideln\u011b zapisov\u00e1ny na disk. Pokud v\u0161echny uzly clusteru sel\u017eou sou\u010dasn\u011b, na disc\u00edch z\u016fstanou repliky s r\u016fzn\u00fdm posunut\u00edm. Je zcela mo\u017en\u00e9, \u017ee kdy\u017e se brokery znovu p\u0159ipoj\u00ed k s\u00edti, nov\u00fd v\u016fdce, kter\u00fd bude zvolen, bude pozadu za sv\u00fdmi n\u00e1sledovn\u00edky, proto\u017ee byl ulo\u017een na disk d\u0159\u00edve ne\u017e ostatn\u00ed.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Znovu p\u0159ipojen\u00ed k clusteru<\/h3>\n<p>\nP\u0159i znovu p\u0159ipojen\u00ed k clusteru repliky postupuj\u00ed stejn\u011b jako p\u0159i selh\u00e1n\u00ed v\u016fdce: kontroluj\u00ed replikaci v\u016fdce a zkracuj\u00ed sv\u016fj log na jeho HW (v okam\u017eiku zvolen\u00ed). Na rozd\u00edl od toho RabbitMQ pova\u017euje znovu p\u0159ipojen\u00e9 uzly za zcela nov\u00e9. V obou p\u0159\u00edpadech broker zahazuje jak\u00fdkoli existuj\u00edc\u00ed stav. Pokud je pou\u017eita automatick\u00e1 synchronizace, mus\u00ed master replikovat ve\u0161ker\u00fd aktu\u00e1ln\u00ed obsah do nov\u00e9ho zrcadla zp\u016fsobem \"a\u0165 si cel\u00fd sv\u011bt po\u010dk\u00e1\". B\u011bhem t\u00e9to operace master nep\u0159ij\u00edm\u00e1 \u017e\u00e1dn\u00e9 operace \u010dten\u00ed nebo z\u00e1pisu. Tento p\u0159\u00edstup vytv\u00e1\u0159\u00ed probl\u00e9my ve velk\u00fdch front\u00e1ch.<\/p>\n<p>Kafka je distribuovan\u00fd log a obecn\u011b uchov\u00e1v\u00e1 v\u00edce zpr\u00e1v ne\u017e fronta RabbitMQ, kde se data z fronty odstra\u0148uj\u00ed po p\u0159e\u010dten\u00ed. Aktivn\u00ed fronty by m\u011bly z\u016fstat relativn\u011b mal\u00e9. Ale Kafka je log s vlastn\u00ed politikou uchov\u00e1v\u00e1n\u00ed, kter\u00e1 m\u016f\u017ee stanovit dobu v dnech \u010di t\u00fddnech. P\u0159\u00edstup s blokov\u00e1n\u00edm fronty a plnou synchronizac\u00ed je zcela nep\u0159ijateln\u00fd pro distribuovan\u00fd log. M\u00edsto toho n\u00e1sledovn\u00edci Kafka jednodu\u0161e o\u0159ez\u00e1vaj\u00ed sv\u016fj log na HW v\u016fdce (v moment\u011b jeho zvolen\u00ed), pokud jejich kopie p\u0159edstihuje v\u016fdce. V pravd\u011bpodobn\u011bj\u0161\u00edm p\u0159\u00edpad\u011b, kdy je n\u00e1sledovn\u00edk pozadu, jednodu\u0161e za\u010d\u00edn\u00e1 po\u017eadovat vybr\u00e1n\u00ed od sv\u00e9ho aktu\u00e1ln\u00edho LEO.<\/p>\n<p>Nov\u00ed nebo znovu p\u0159ipojen\u00ed n\u00e1sledovn\u00edci za\u010d\u00ednaj\u00ed mimo ISR a ne\u00fa\u010dastn\u00ed se commit\u016f. Jen pracuj\u00ed vedle skupiny a p\u0159ij\u00edmaj\u00ed zpr\u00e1vy co nejrychleji, dokud nedo\u017eenou v\u016fdce a nevstoup\u00ed do ISR. Neexistuje zde \u017e\u00e1dn\u00e9 blokov\u00e1n\u00ed a nen\u00ed t\u0159eba vyhazovat v\u0161echny sv\u00e9 data.<\/p>\n<h1>Naru\u0161en\u00ed soudr\u017enosti<\/h1>\n<p>\nKafka m\u00e1 v\u00edce komponent\u016f ne\u017e RabbitMQ, a proto zde existuje slo\u017eit\u011bj\u0161\u00ed soubor chov\u00e1n\u00ed, kdy\u017e v klastru doch\u00e1z\u00ed k naru\u0161en\u00ed soudr\u017enosti. Ale Kafka byla p\u016fvodn\u011b navr\u017eena pro klastery, tak\u017ee \u0159e\u0161en\u00ed jsou velmi dob\u0159e promy\u0161len\u00e1.<\/p>\n<p>N\u00ed\u017ee jsou uvedeny n\u011bkter\u00e9 sc\u00e9n\u00e1\u0159e naru\u0161en\u00ed soudr\u017enosti:<\/p>\n<ul>\n<li>Sc\u00e9n\u00e1\u0159 1. N\u00e1sledovn\u00edk nevid\u00ed v\u016fdce, ale st\u00e1le vid\u00ed Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 2. V\u016fdce nevid\u00ed \u017e\u00e1dn\u00e9ho n\u00e1sledovn\u00edka, ale st\u00e1le vid\u00ed Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 3. N\u00e1sledovn\u00edk vid\u00ed v\u016fdce, ale nevid\u00ed Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 4. V\u016fdce vid\u00ed n\u00e1sledovn\u00edky, ale nevid\u00ed Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 5. N\u00e1sledovn\u00edk je zcela odpojen jak od ostatn\u00edch uzl\u016f Kafka, tak od Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 6. V\u016fdce je zcela odpojen jak od ostatn\u00edch uzl\u016f Kafka, tak od Zookeeper.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 7. \u0158\u00edd\u00edc\u00ed uzel Kafka nevid\u00ed jin\u00fd uzel Kafka.\n<\/li>\n<li>Sc\u00e9n\u00e1\u0159 8. \u0158\u00edd\u00edc\u00ed uzel Kafka nevid\u00ed Zookeeper.<\/li>\n<\/ul>\n<p>\nPro ka\u017ed\u00fd sc\u00e9n\u00e1\u0159 je ur\u010deno sv\u00e9 chov\u00e1n\u00ed.<\/p>\n<h3>Sc\u00e9n\u00e1\u0159 1. N\u00e1sledovn\u00edk nevid\u00ed v\u016fdce, ale st\u00e1le vid\u00ed Zookeeper<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/5f51ae679933b2b5a69e21831465d121.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr\u00e1zek 22. Sc\u00e9n\u00e1\u0159 1. ISR ze t\u0159\u00ed replik<\/i><\/p>\n<p>Naru\u0161en\u00ed soudr\u017enosti odpojuje broker 3 od broker\u016f 1 a 2, ale ne od Zookeeper. Broker 3 ji\u017e nem\u016f\u017ee odes\u00edlat po\u017eadavky na vybr\u00e1n\u00ed. Po uplynut\u00ed doby <i>replica.lag.time.max.ms<\/i> Odejdou z ISR a ne\u00fa\u010dastn\u00ed se commit\u016f. Jakmile je spojen\u00ed obnoveno, znovu zah\u00e1j\u00ed po\u017eadavky na na\u010d\u00edt\u00e1n\u00ed a p\u0159ipoj\u00ed se k ISR, jakmile dohon\u00ed vedouc\u00edho. Zookeeper bude nad\u00e1le p\u0159ij\u00edmat pings a pova\u017eovat, \u017ee broker je \u017eiv\u00fd a zdrav\u00fd.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/976b7ff080ee6a6d76a165f614f40e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 23. Sc\u00e9n\u00e1\u0159 1. Broker je odebr\u00e1n z ISR, pokud nebyl po ur\u010ditou dobu po\u017eadov\u00e1n na na\u010d\u00edt\u00e1n\u00ed v r\u00e1mci replica.lag.time.max.ms.<\/i><\/p>\n<p>Neexistuje \u017e\u00e1dn\u00e9 logick\u00e9 rozd\u011blen\u00ed (split-brain) nebo pozastaven\u00ed uzlu, jako v RabbitMQ. M\u00edsto toho doch\u00e1z\u00ed ke sn\u00ed\u017een\u00ed redundancy. <\/p>\n<h3>Sc\u00e9n\u00e1\u0159 2. Vedouc\u00ed nevid\u00ed \u017e\u00e1dn\u00e9ho n\u00e1sledovn\u00edka, ale st\u00e1le vid\u00ed Zookeepera.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/ff6aaa053d73e8b7c97111979bcf97aa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 24. Sc\u00e9n\u00e1\u0159 2. Vedouc\u00ed a dva n\u00e1sledovn\u00edci<\/i><\/p>\n<p>P\u0159eru\u0161en\u00ed s\u00ed\u0165ov\u00e9ho spojen\u00ed odd\u011bluje vedouc\u00edho od n\u00e1sledovn\u00edk\u016f, ale broker st\u00e1le vid\u00ed Zookeepera. Stejn\u011b jako v prvn\u00edm sc\u00e9n\u00e1\u0159i se ISR zmen\u0161uje, ale tentokr\u00e1t pouze do vedouc\u00edho, proto\u017ee v\u0161ichni n\u00e1sledovn\u00edci p\u0159est\u00e1vaj\u00ed pos\u00edlat po\u017eadavky na na\u010d\u00edt\u00e1n\u00ed. Znovu, neexistuje \u017e\u00e1dn\u00e9 logick\u00e9 rozd\u011blen\u00ed. M\u00edsto toho doch\u00e1z\u00ed ke ztr\u00e1t\u011b redundancy pro nov\u00e9 zpr\u00e1vy, dokud se spojen\u00ed neobnov\u00ed. Zookeeper nep\u0159est\u00e1v\u00e1 p\u0159ij\u00edmat pings a pova\u017euje, \u017ee broker je \u017eiv\u00fd a zdrav\u00fd.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/3c69e8327da241407f76719fc022c37a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 25. Sc\u00e9n\u00e1\u0159 2. ISR se zmen\u0161il pouze na vedouc\u00edho.<\/i><\/p>\n<h3>Sc\u00e9n\u00e1\u0159 3. N\u00e1sledovn\u00edk vid\u00ed vedouc\u00edho, ale nevid\u00ed Zookeepera.<\/h3>\n<p>\nN\u00e1sledovn\u00edk se odd\u011bluje od Zookeepera, ale ne od brokera s vedouc\u00edm. V d\u016fsledku toho n\u00e1sledovn\u00edk pokra\u010duje v prov\u00e1d\u011bn\u00ed po\u017eadavk\u016f na na\u010d\u00edt\u00e1n\u00ed a z\u016fst\u00e1v\u00e1 \u010dlenem ISR. Zookeeper ji\u017e nep\u0159ij\u00edm\u00e1 pings a registruje p\u00e1d brokera, ale proto\u017ee to je pouze n\u00e1sledovn\u00edk, po obnoven\u00ed nejsou \u017e\u00e1dn\u00e9 n\u00e1sledky.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/1183bcfe45a3225ae3ef1a0651f61350.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 26. Sc\u00e9n\u00e1\u0159 3. N\u00e1sledovn\u00edk st\u00e1le pos\u00edl\u00e1 vedouc\u00edmu po\u017eadavky na na\u010d\u00edt\u00e1n\u00ed.<\/i><\/p>\n<h3>Sc\u00e9n\u00e1\u0159 4. Vedouc\u00ed vid\u00ed n\u00e1sledovn\u00edky, ale nevid\u00ed Zookeepera.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/b3bf27fcb0eb806b27ad00f098e50a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 27. Sc\u00e9n\u00e1\u0159 4. Vedouc\u00ed a dva n\u00e1sledovn\u00edci.<\/i><\/p>\n<p>Vedouc\u00ed je odd\u011blen od Zookeepera, ale ne od broker\u016f s n\u00e1sledovn\u00edky. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/82d9f2e5868566678befc414d1885bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 28. Sc\u00e9n\u00e1\u0159 4. Vedouc\u00ed izolov\u00e1n od Zookeepera.<\/i><\/p>\n<p>Po ur\u010dit\u00e9 dob\u011b Zookeeper zaregistruje p\u00e1d brokera a informuje o tom kontroln\u00ed prvek. Ten vybere nov\u00e9ho vedouc\u00edho mezi n\u00e1sledovn\u00edky. P\u0159esto p\u016fvodn\u00ed vedouc\u00ed st\u00e1le pova\u017euje, \u017ee je vedouc\u00edm, a neust\u00e1le p\u0159ij\u00edm\u00e1 z\u00e1pisy s <i>acks=1<\/i>. N\u00e1sledovn\u00edci mu ji\u017e nepos\u00edlaj\u00ed po\u017eadavky na na\u010d\u00edt\u00e1n\u00ed, a tak je pova\u017euje za mrtv\u00e9 a pokus\u00ed se zmen\u0161it ISR na sebe. Ale proto\u017ee nen\u00ed p\u0159ipojen k Zookeeperovi, nem\u016f\u017ee to ud\u011blat, a v t\u00e9to chv\u00edli se vzd\u00e1v\u00e1 dal\u0161\u00edho p\u0159ij\u00edm\u00e1n\u00ed z\u00e1pis\u016f. <\/p>\n<p>Zpr\u00e1vy <i>acks=all<\/i> nedostanou potvrzen\u00ed, proto\u017ee ISR nejprve zahrnuje v\u0161echny repliky, a ne\u017e k nim zpr\u00e1vy doraz\u00ed. Kdy\u017e se p\u016fvodn\u00ed l\u00edder pokus\u00ed je odstranit z ISR, nebude to moci ud\u011blat a ve skute\u010dnosti p\u0159estane p\u0159ij\u00edmat jak\u00e9koli zpr\u00e1vy.<\/p>\n<p>Z\u00e1kazn\u00edci brzy zpozoruj\u00ed zm\u011bnu v\u016fdce a za\u010dnou pos\u00edlat z\u00e1pisy na nov\u00fd server. Jakmile se s\u00ed\u0165 obnov\u00ed, p\u016fvodn\u00ed l\u00edder uvid\u00ed, \u017ee u\u017e nen\u00ed v\u016fdcem, a zkr\u00e1t\u00ed sv\u016fj log na hodnotu HW, kterou m\u011bl nov\u00fd l\u00edder v okam\u017eiku z\u00e1vady, aby se vyhnul nesouladu log\u016f. Pak za\u010dne pos\u00edlat dotazy na vyhled\u00e1n\u00ed nov\u00e9mu l\u00edderovi. V\u0161echny z\u00e1pisy p\u016fvodn\u00edho l\u00eddra, kter\u00e9 nebyly replikov\u00e1ny nov\u00e9mu l\u00edderovi, se ztrat\u00ed. To znamen\u00e1, \u017ee budou ztraceny zpr\u00e1vy, kter\u00e9 p\u016fvodn\u00ed l\u00edder nepotvrdil v t\u011bch n\u011bkolika sekund\u00e1ch, kdy fungovali dva l\u00edd\u0159i.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/d88d6f33c13dccb814c0f206ec72512b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 29. Sc\u00e9n\u00e1\u0159 4. L\u00eddr na brokeru 1 se st\u00e1v\u00e1 followerem po obnoven\u00ed s\u00edt\u011b<\/i><\/p>\n<h3>Sc\u00e9n\u00e1\u0159 5. Follower je zcela odpojen jak od ostatn\u00edch uzl\u016f Kafka, tak od Zookeeperu<\/h3>\n<p>\nFollower je zcela izolov\u00e1n jak od ostatn\u00edch uzl\u016f Kafka, tak od Zookeeperu. Jednodu\u0161e se odstran\u00ed z ISR, dokud se s\u00ed\u0165 neobnov\u00ed, a pak do\u017eene ostatn\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/b092607f777014fd945f18734dd7f4e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 30. Sc\u00e9n\u00e1\u0159 5. Izolovan\u00fd follower se odstra\u0148uje z ISR<\/i><\/p>\n<h3>Sc\u00e9n\u00e1\u0159 6. L\u00eddr je zcela odpojen jak od ostatn\u00edch uzl\u016f Kafka, tak od Zookeeperu<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/bb808d534dbf65748eb0b481f86b4926.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 31. Sc\u00e9n\u00e1\u0159 6. L\u00eddr a dva followe\u0159i<\/i><\/p>\n<p>L\u00eddr je zcela izolov\u00e1n od sv\u00fdch follower\u016f, kontrol\u00e9ru a Zookeeperu. Po kr\u00e1tkou dobu bude st\u00e1le p\u0159ij\u00edmat z\u00e1pisy z <i>acks=1<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/6fda78bcd26ef6b916579d447e9fb1f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 32. Sc\u00e9n\u00e1\u0159 6. Izolace l\u00eddra od ostatn\u00edch uzl\u016f Kafka a Zookeeperu<\/i><\/p>\n<p>Nep\u0159ijme-li \u017e\u00e1dn\u00e9 dotazy po uplynut\u00ed <i>replica.lag.time.max.ms<\/i>, pokus\u00ed se zkr\u00e1tit ISR na sebe, ale nebude to moci ud\u011blat, proto\u017ee nen\u00ed spojen\u00ed se Zookeeperem, a pak p\u0159estane p\u0159ij\u00edmat z\u00e1pisy. <\/p>\n<p>Mezit\u00edm Zookeeper ozna\u010d\u00ed izolovan\u00e9ho brokera jako mrtv\u00e9ho a kontrol\u00e9r vybere nov\u00e9ho l\u00eddra.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/73d611a411fc64d835af2c714e9eba0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 33. Sc\u00e9n\u00e1\u0159 6. Dva l\u00edd\u0159i<\/i><\/p>\n<p>P\u016fvodn\u00ed l\u00edder m\u016f\u017ee p\u0159ij\u00edmat z\u00e1pisy po dobu n\u011bkolika sekund, ale pot\u00e9 p\u0159estane p\u0159ij\u00edmat jak\u00e9koli zpr\u00e1vy. Z\u00e1kazn\u00edci se aktualizuj\u00ed ka\u017ed\u00fdch 60 sekund s posledn\u00edmi metadata. Budou informov\u00e1ni o zm\u011bn\u011b l\u00eddra a za\u010dnou pos\u00edlat z\u00e1pisy nov\u00e9mu l\u00edderovi.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/ae99380c8a84fac15f440b699b9c552b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 34. Sc\u00e9n\u00e1\u0159 6. Producenti p\u0159ep\u00ednaj\u00ed na nov\u00e9ho l\u00eddra<\/i><\/p>\n<p>V\u0161echny potvrzen\u00e9 z\u00e1znamy proveden\u00e9 p\u016fvodn\u00edm l\u00eddrem od doby ztr\u00e1ty konektivity budou ztraceny. Jakmile se s\u00ed\u0165 obnov\u00ed, p\u016fvodn\u00ed l\u00eddr prost\u0159ednictv\u00edm Zookeeper zjist\u00ed, \u017ee u\u017e nen\u00ed l\u00eddrem. Pak zkr\u00e1t\u00ed sv\u016fj log na HW nov\u00e9ho l\u00eddra v okam\u017eiku jeho zvolen\u00ed a za\u010dne odes\u00edlat po\u017eadavky jako follower.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: odolnost proti chyb\u00e1m a vysok\u00e1 dostupnost\" src=\"\/wp-content\/uploads\/2019\/11\/10f0983a829b03ca9bbc62e12cbf8a5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Obr. 35. Sc\u00e9n\u00e1\u0159 6. P\u016fvodn\u00ed l\u00eddr se st\u00e1v\u00e1 followrem po obnoven\u00ed konektivity s\u00edt\u011b<\/i><\/p>\n<p>V t\u00e9to situaci m\u016f\u017ee b\u011bhem kr\u00e1tk\u00e9ho obdob\u00ed doj\u00edt k logick\u00e9mu rozd\u011blen\u00ed, ale pouze pokud <i>acks=1<\/i> a <i>min.insync.replicas<\/i> tak\u00e9 1. Logick\u00e9 rozd\u011blen\u00ed se automaticky ukon\u010duje bu\u010f po obnoven\u00ed s\u00edt\u011b, kdy p\u016fvodn\u00ed l\u00eddr pochop\u00ed, \u017ee u\u017e nen\u00ed l\u00eddrem, nebo kdy v\u0161ichni klienti pochop\u00ed, \u017ee l\u00eddr se zm\u011bnil a za\u010dnou zapisovat nov\u00e9mu l\u00eddrovi \u2014 v z\u00e1vislosti na tom, co nastane d\u0159\u00edv. V ka\u017ed\u00e9m p\u0159\u00edpad\u011b dojde ke ztr\u00e1t\u011b n\u011bkter\u00fdch zpr\u00e1v, ale pouze s <i>acks=1<\/i>.<\/p>\n<p>Existuje dal\u0161\u00ed varianta tohoto sc\u00e9n\u00e1\u0159e, kdy t\u011bsn\u011b p\u0159ed rozd\u011blen\u00edm s\u00edt\u011b follow\u0159i zaostali a l\u00eddr z\u00fa\u017eil ISR na jednu osobu. Pot\u00e9 se izoluje kv\u016fli ztr\u00e1t\u011b konektivity. Je zvolen nov\u00fd l\u00eddr, ale p\u016fvodn\u00ed l\u00eddr pokra\u010duje v p\u0159ij\u00edm\u00e1n\u00ed z\u00e1znam\u016f, i kdy\u017e <i>acks=all<\/i>, proto\u017ee v ISR krom\u011b n\u011bj nikdo jin\u00fd nen\u00ed. Tyto z\u00e1znamy budou ztraceny po obnoven\u00ed s\u00edt\u011b. Jedin\u00fd zp\u016fsob, jak se tomuto sc\u00e9n\u00e1\u0159i vyhnout, je <i>min.insync.replicas = 2<\/i>.<\/p>\n<h3>Sc\u00e9n\u00e1\u0159 7. Uzlov\u00fd kontrol\u00e9r Kafka nevid\u00ed dal\u0161\u00ed uzel Kafka<\/h3>\n<p>\nObecn\u011b plat\u00ed, \u017ee po ztr\u00e1t\u011b spojen\u00ed s uzlem Kafka kontrol\u00e9r nebude schopen p\u0159edat \u017e\u00e1dn\u00e9 informace o zm\u011bn\u011b l\u00eddra. V nejhor\u0161\u00edm p\u0159\u00edpad\u011b to povede k kr\u00e1tkodob\u00e9mu logick\u00e9mu rozd\u011blen\u00ed, jako ve sc\u00e9n\u00e1\u0159i 6. V\u011bt\u0161inou broker prost\u011b nebude kandid\u00e1tem na l\u00eddr v p\u0159\u00edpad\u011b selh\u00e1n\u00ed posledn\u00edho.<\/p>\n<h3>Sc\u00e9n\u00e1\u0159 8. Kontrol\u00e9r Kafka nevid\u00ed Zookeeper<\/h3>\n<p>\nOd odpojen\u00e9ho kontrol\u00e9ru Zookeeper nedostane ping a vybere nov\u00e9ho uzlu Kafka jako kontrol\u00e9ra. P\u016fvodn\u00ed kontrol\u00e9r m\u016f\u017ee nad\u00e1le p\u0159edstavovat sebe jako takov\u00e9ho, ale nedost\u00e1v\u00e1 \u017e\u00e1dn\u00e9 ozn\u00e1men\u00ed od Zookeeper, tak\u017ee nebude m\u00edt \u017e\u00e1dn\u00e9 \u00fakoly k pln\u011bn\u00ed. Jakmile se s\u00ed\u0165 obnov\u00ed, pochop\u00ed, \u017ee u\u017e nen\u00ed kontrol\u00e9rem, ale stal se b\u011b\u017en\u00fdm uzlem Kafka.<\/p>\n<h3>Z\u00e1v\u011bry ze sc\u00e9n\u00e1\u0159\u016f<\/h3>\n<p>\nVid\u00edme, \u017ee ztr\u00e1ta konektivity follower\u016f nevede k ztr\u00e1t\u011b zpr\u00e1v, ale pouze do\u010dasn\u011b zmen\u0161uje redundanci, dokud se s\u00ed\u0165 neobnov\u00ed. To samoz\u0159ejm\u011b m\u016f\u017ee v\u00e9st k ztr\u00e1t\u011b dat, pokud jsou ztraceny jeden nebo v\u00edce uzl\u016f.<\/p>\n<p>Pokud se v\u016fdce odpojil od Zookeeperu kv\u016fli ztr\u00e1t\u011b konektivity, m\u016f\u017ee to v\u00e9st ke ztr\u00e1t\u011b zpr\u00e1v s <i>acks=1<\/i>. Nedostatek spojen\u00ed se Zookeeperem zp\u016fsobuje kr\u00e1tkodob\u00e9 logick\u00e9 rozd\u011blen\u00ed se dv\u011bma v\u016fdci. Tento probl\u00e9m \u0159e\u0161\u00ed parametr <i>acks=all<\/i>.<\/p>\n<p>Parameter <i>min.insync.replicas<\/i> s dv\u011bma nebo v\u00edce replikami poskytuje dal\u0161\u00ed z\u00e1ruky, \u017ee takov\u00e9 kr\u00e1tkodob\u00e9 sc\u00e9n\u00e1\u0159e nevedou ke ztr\u00e1t\u011b zpr\u00e1v, jako v sc\u00e9n\u00e1\u0159i 6.<\/p>\n<h1>Shrnut\u00ed ztr\u00e1ty zpr\u00e1v<\/h1>\n<p>\nVyjmenujme v\u0161echny zp\u016fsoby, jak lze ztratit data v Kafce:<\/p>\n<ul>\n<li>Jak\u00e9koli selh\u00e1n\u00ed v\u016fdce, pokud byly zpr\u00e1vy potvrzeny pomoc\u00ed <i>acks=1<\/i>\n<\/li>\n<li>Jak\u00fdkoli ne\u010dist\u00fd (unclean) p\u0159echod v\u016fdcovstv\u00ed, tedy na followery mimo ISR, i s <i>acks=all<\/i>\n<\/li>\n<li>Izolace v\u016fdce od Zookeeperu, pokud byly zpr\u00e1vy potvrzeny pomoc\u00ed <i>acks=1<\/i>\n<\/li>\n<li>\u00dapln\u00e1 izolace v\u016fdce, kter\u00fd ji\u017e z\u00fa\u017eil skupinu ISR na sebe. V\u0161echny zpr\u00e1vy budou ztraceny, dokonce i <i>acks=all<\/i>. To plat\u00ed pouze v p\u0159\u00edpad\u011b, \u017ee <i>min.insync.replicas=1<\/i>.\n<\/li>\n<li>Sou\u010dasn\u00e9 selh\u00e1n\u00ed v\u0161ech uzl\u016f partition. Proto\u017ee zpr\u00e1vy jsou potvrzov\u00e1ny z pam\u011bti, n\u011bkter\u00e9 mo\u017en\u00e1 je\u0161t\u011b nebyly zaps\u00e1ny na disk. Po restartov\u00e1n\u00ed server\u016f m\u016f\u017ee chyb\u011bt n\u011bkolik zpr\u00e1v.<\/li>\n<\/ul>\n<p>\nNe\u010dist\u00fdm p\u0159echod\u016fm v\u016fdcovstv\u00ed se lze vyhnout bu\u010f jejich zak\u00e1z\u00e1n\u00edm, nebo zaji\u0161t\u011bn\u00edm redundance alespo\u0148 dvou. Nejsiln\u011bj\u0161\u00ed konfigurac\u00ed je kombinace <i>acks=all<\/i> a <i>min.insync.replicas<\/i> v\u00edce ne\u017e 1.<\/p>\n<h1>P\u0159\u00edm\u00e9 srovn\u00e1n\u00ed spolehlivosti RabbitMQ a Kafky<\/h1>\n<p>\nPro zaji\u0161t\u011bn\u00ed spolehlivosti a vysok\u00e9 dostupnosti ob\u011b platformy implementuj\u00ed syst\u00e9m prim\u00e1rn\u00ed a sekund\u00e1rn\u00ed replikace. Nicm\u00e9n\u011b RabbitMQ m\u00e1 achilovskou patu. P\u0159i znovuspojen\u00ed po selh\u00e1n\u00ed uzly zahazuj\u00ed sv\u00e1 data a synchronizace je blokov\u00e1na. Tento dvojit\u00fd \u00fader zpochyb\u0148uje trvanlivost velk\u00fdch front v RabbitMQ. Budete se muset sm\u00ed\u0159it bu\u010f se sn\u00ed\u017een\u00edm redundance, nebo s dlouh\u00fdmi blokacemi. Sn\u00ed\u017een\u00ed redundance zvy\u0161uje riziko hromadn\u00e9 ztr\u00e1ty dat. Pokud jsou v\u0161ak fronty mal\u00e9, aby se zajistila redundance s kr\u00e1tk\u00fdmi obdob\u00edmi nedostupnosti (n\u011bkolik sekund), lze se s t\u00edm vypo\u0159\u00e1dat pomoc\u00ed opakovan\u00fdch pokus\u016f o p\u0159ipojen\u00ed.<\/p>\n<p>V Kafce takov\u00fd probl\u00e9m nen\u00ed. Odm\u00edt\u00e1 data pouze z pohledu nesouladu l\u00eddra a followera. V\u0161echna spole\u010dn\u00e1 data jsou uchov\u00e1na. Krom\u011b toho replikace nem\u011bn\u00ed chod syst\u00e9mu. L\u00eddr pokra\u010duje v p\u0159\u00edjmu z\u00e1znam\u016f, zat\u00edmco se nov\u00fd follower do\u017eene, tak\u017ee pro DevOps je p\u0159ipojen\u00ed nebo op\u011btovn\u00e9 p\u0159ipojen\u00ed k clusteru trivi\u00e1ln\u00ed z\u00e1le\u017eitost\u00ed. Samoz\u0159ejm\u011b i nad\u00e1le z\u016fst\u00e1vaj\u00ed probl\u00e9my, jako je \u0161\u00ed\u0159ka p\u00e1sma s\u00edt\u011b p\u0159i replikaci. Pokud se z\u00e1rove\u0148 p\u0159id\u00e1 n\u011bkolik follower\u016f, m\u016f\u017eete se setkat s limitem \u0161\u00ed\u0159ky p\u00e1sma.<\/p>\n<p>RabbitMQ p\u0159evy\u0161uje Kafku v spolehlivosti p\u0159i sou\u010dasn\u00e9m selh\u00e1n\u00ed n\u011bkolika server\u016f v clusteru. Jak jsme ji\u017e zm\u00ednili, RabbitMQ zas\u00edl\u00e1 publisherovi potvrzen\u00ed a\u017e po zaps\u00e1n\u00ed zpr\u00e1vy na disk u hlavn\u00edho uzlu a v\u0161ech zrcadlech. To v\u0161ak p\u0159id\u00e1v\u00e1 dal\u0161\u00ed zpo\u017ed\u011bn\u00ed z dvou d\u016fvod\u016f:<\/p>\n<ul>\n<li>fsync ka\u017ed\u00fdch n\u011bkolik set milisekund\n<\/li>\n<li>Selh\u00e1n\u00ed zrcadla lze zaznamenat a\u017e po vypr\u0161en\u00ed doby \u017eivotnosti paket\u016f, kter\u00e9 kontroluj\u00ed dostupnost ka\u017ed\u00e9ho uzlu (net tick). Pokud zrcadlo zpomaluje nebo sel\u017ee, p\u0159id\u00e1v\u00e1 to zpo\u017ed\u011bn\u00ed.<\/li>\n<\/ul>\n<p>\nKafka spol\u00e9h\u00e1 na to, \u017ee pokud je zpr\u00e1va ulo\u017eena na n\u011bkolika uzlech, lze potvrzovat zpr\u00e1vy, jakmile se dostanou do pam\u011bti. T\u00edm se objevuje riziko ztr\u00e1ty zpr\u00e1v jak\u00e9hokoli typu (dokonce <i>acks=all<\/i>, <i>min.insync.replicy=2<\/i>) v p\u0159\u00edpad\u011b sou\u010dasn\u00e9ho selh\u00e1n\u00ed.<\/p>\n<p>Celkov\u011b Kafka demonstruje vy\u0161\u0161\u00ed v\u00fdkonnost a je p\u016fvodn\u011b navr\u017eena pro clustery. Po\u010det follower\u016f lze zv\u00fd\u0161it a\u017e na 11, pokud je to pot\u0159eba pro spolehlivost. Pom\u011br replikace 5 a minim\u00e1ln\u00ed po\u010det replik v synchronizovan\u00e9m stavu <i>min.insync.replicas=3<\/i> u\u010din\u00ed ztr\u00e1tu zpr\u00e1vy velmi vz\u00e1cnou ud\u00e1lost\u00ed. Pokud va\u0161e infrastruktura dok\u00e1\u017ee zajistit takov\u00fd pom\u011br replikace a \u00farove\u0148 redundance, m\u016f\u017eete si vybrat tuto mo\u017enost.<\/p>\n<p>Klastrov\u00e1n\u00ed RabbitMQ je dobr\u00e9 pro mal\u00e9 fronty. Ale i mal\u00e9 fronty mohou rychle r\u016fst p\u0159i vysok\u00e9m zat\u00ed\u017een\u00ed. Jakmile se fronty stanou velk\u00fdmi, budete muset u\u010dinit tvrd\u00fd v\u00fdb\u011br mezi dostupnost\u00ed a spolehlivost\u00ed. Klastrov\u00e1n\u00ed RabbitMQ je nejl\u00e9pe pou\u017eiteln\u00e9 pro netypick\u00e9 situace, kde v\u00fdhody flexibility RabbitMQ p\u0159evy\u0161uj\u00ed jak\u00e9koli nev\u00fdhody jeho klastrov\u00e1n\u00ed.<\/p>\n<p>Jedn\u00edm z protil\u00e1tek v\u016f\u010di zranitelnosti RabbitMQ v souvislosti s velk\u00fdmi frontami je rozd\u011blit je na mnoho men\u0161\u00edch. Pokud nepo\u017eadujete \u00fapln\u00e9 se\u0159azen\u00ed cel\u00e9 fronty, ale jen odpov\u00eddaj\u00edc\u00edch zpr\u00e1v (nap\u0159\u00edklad zpr\u00e1v konkr\u00e9tn\u00edho klienta), nebo dokonce nic ne\u0159ad\u00edte, je tento p\u0159\u00edstup p\u0159ijateln\u00fd: pod\u00edvejte se na m\u016fj projekt <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/7\/22\/creating-consumer-groups-in-rabbitmq-with-rebalanser-part-1\">Rebalanser<\/a><\/noindex> k rozd\u011blen\u00ed fronty (projekt zat\u00edm ve st\u00e1diu v\u00fdvoje). <\/p>\n<p>Nakonec nezapome\u0148te na \u0159adu chyb v mechanismech clusteringu a replikace jak u RabbitMQ, tak u Kafka. S \u010dasem se syst\u00e9my st\u00e1valy zralej\u0161\u00edmi a stabiln\u011bj\u0161\u00edmi, ale \u017e\u00e1dn\u00e1 zpr\u00e1va nikdy nebude na 100% chr\u00e1n\u011bna p\u0159ed ztr\u00e1tou! Krom\u011b toho se v datov\u00fdch centrech mohou vyskytnout velk\u00e9 hav\u00e1rie!<\/p>\n<p>Pokud jsem n\u011bco p\u0159ehl\u00e9dl, ud\u011blal chybu nebo nesouhlas\u00edte s jak\u00fdmkoliv z tvrzen\u00ed, nev\u00e1hejte napsat koment\u00e1\u0159 nebo se mnou kontaktovat.<\/p>\n<p>\u010casto se m\u011b ptaj\u00ed: \u201eCo si vybrat, Kafka nebo RabbitMQ?\u201c, \u201eKter\u00e1 platforma je lep\u0161\u00ed?\u201c. Pravda je takov\u00e1, \u017ee to opravdu z\u00e1vis\u00ed na va\u0161\u00ed situaci, aktu\u00e1ln\u00ed zku\u0161enosti atd. Neodv\u00e1\u017e\u00edm se vyjad\u0159ovat sv\u016fj n\u00e1zor, proto\u017ee by bylo p\u0159\u00edli\u0161 zjednodu\u0161uj\u00edc\u00ed doporu\u010dit n\u011bjakou jednu platformu pro v\u0161echny p\u0159\u00edpady pou\u017eit\u00ed a mo\u017en\u00e9 omezen\u00ed. Napsal jsem tuto s\u00e9rii \u010dl\u00e1nk\u016f, abyste si mohli utvo\u0159it vlastn\u00ed n\u00e1zor.<\/p>\n<p>Chci \u0159\u00edct, \u017ee ob\u011b syst\u00e9my jsou l\u00eddry v t\u00e9to oblasti. Mo\u017en\u00e1 jsem trochu zaujat\u00fd, proto\u017ee na z\u00e1klad\u011b sv\u00fdch zku\u0161enost\u00ed s projekty v\u00edce oce\u0148uji takov\u00e9 v\u011bci, jako je zaru\u010den\u00e9 po\u0159ad\u00ed zpr\u00e1v a spolehlivost. <\/p>\n<p>Vid\u00edm jin\u00e9 technologie, kter\u00fdm chyb\u00ed tato spolehlivost a zaru\u010den\u00e9 po\u0159ad\u00ed, pak se d\u00edv\u00e1m na RabbitMQ a Kafka \u2014 a ch\u00e1pu neuv\u011b\u0159itelnou hodnotu obou t\u011bchto syst\u00e9m\u016f.<br \/>\n<br \/>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/474984\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0438\u0437\u0430\u0446\u0438\u044e RabbitMQ \u0434\u043b\u044f \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438. \u0422\u0435\u043f\u0435\u0440\u044c \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u043f\u043e\u043a\u043e\u043f\u0430\u0435\u043c\u0441\u044f \u0432 Apache Kafka. \u0417\u0434\u0435\u0441\u044c \u0435\u0434\u0438\u043d\u0438\u0446\u0435\u0439 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0434\u0435\u043b (partition). \u0423 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0442\u043e\u043f\u0438\u043a\u0430 \u043e\u0434\u0438\u043d \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432. \u0412 \u043a\u0430\u0436\u0434\u043e\u043c \u0440\u0430\u0437\u0434\u0435\u043b\u0435 \u0435\u0441\u0442\u044c \u043b\u0438\u0434\u0435\u0440 \u0441 \u0444\u043e\u043b\u043b\u043e\u0432\u0435\u0440\u0430\u043c\u0438 \u0438\u043b\u0438 \u0431\u0435\u0437 \u043d\u0438\u0445. \u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u0442\u043e\u043f\u0438\u043a\u0430 \u0443\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u043e\u0432 \u0438 \u043a\u043e\u044d\u0444\u0444\u0438\u0446\u0438\u0435\u043d\u0442 \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u041e\u0431\u044b\u0447\u043d\u043e\u0435 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 3, \u044d\u0442\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52541","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"cs_CZ\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-10T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:17+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47RabbitMQ vs Kafka: odolnost a vysok\u00e1 dostupnost | ProHoster","description":"V","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c | ProHoster","og:description":"\u0412","og:url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-10T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:17+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52541","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:57:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:24","updated":"2026-01-24 03:57:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/52541","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=52541"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/52541\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=52541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=52541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=52541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}