{"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\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/6557ce69c2b3070622feca8b3c228b09.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">den f\u00f6reg\u00e5ende artikeln.<\/a><\/noindex> Vi har granskat RabbitMQ-kluster f\u00f6r att s\u00e4kerst\u00e4lla drifts\u00e4kerhet och h\u00f6g tillg\u00e4nglighet. Nu dyker vi djupare ner i Apache Kafka.<\/p>\n<p>H\u00e4r \u00e4r en replikeringsenhet en partition. Varje \u00e4mne har en eller flera partitioner. I varje partition finns en ledare med eller utan f\u00f6ljare. Vid skapandet av ett \u00e4mne anges antalet partitioner och replikationsfaktorn. Ett vanligt v\u00e4rde \u00e4r 3, vilket inneb\u00e4r tre repliker: en ledare och tv\u00e5 f\u00f6ljare.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/36deb6d506223c2ee2ec147d5c215789.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 1. Fyra partitioner \u00e4r f\u00f6rdelade mellan tre broker.<\/i><\/p>\n<p>Alla l\u00e4s- och skrivf\u00f6rfr\u00e5gningar g\u00e5r till ledaren. F\u00f6ljare skickar periodiskt f\u00f6rfr\u00e5gningar till ledaren f\u00f6r att f\u00e5 de senaste meddelandena. Konsumenter kontaktar aldrig f\u00f6ljarna; de finns bara f\u00f6r redundans och drifts\u00e4kerhet.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/715c51d75cb45863cfad4b37e81b9a9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Partitionens fel<\/h1>\n<p>\nN\u00e4r en broker g\u00e5r ner, slutar ofta ledarna f\u00f6r flera partitioner att fungera. En av f\u00f6ljarna fr\u00e5n en annan nod blir ledare f\u00f6r dem. I sj\u00e4lva verket \u00e4r det inte alltid s\u00e5, eftersom synkroniseringsfaktorn avg\u00f6r: finns det synkroniserade f\u00f6ljare, och om inte, \u00e4r det till\u00e5tet att g\u00e5 \u00f6ver till en osynkroniserad replika. Men l\u00e5t oss inte komplicera det just nu.<\/p>\n<p>Broker 3 g\u00e5r offline \u2013 och f\u00f6r partition 2 v\u00e4ljs en ny ledare p\u00e5 broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/b8cfce64cf6b848b0659de023f9d9b63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 2. Broker 3 d\u00f6r, och dess f\u00f6ljare p\u00e5 broker 2 v\u00e4ljs till ny ledare f\u00f6r partition 2.<\/i><\/p>\n<p>D\u00e4refter g\u00e5r broker 1 ner och partition 1 f\u00f6rlorar ocks\u00e5 sin ledare, vars roll g\u00e5r till broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/9f5409c723da7ff059b93f9b23e7d5f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 3. Endast en broker \u00e5terst\u00e5r. Alla ledare finns p\u00e5 en broker med noll redundans.<\/i><\/p>\n<p>N\u00e4r broker 1 \u00e5terkommer till n\u00e4tverket l\u00e4gger den till fyra f\u00f6ljare, vilket ger viss redundans till varje partition. Men alla ledare f\u00f6rblir fortfarande p\u00e5 broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/f9c8e42f51258b7fd7f6f35dc7b8cc3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 4. Ledarna f\u00f6rblir p\u00e5 broker 2.<\/i><\/p>\n<p>N\u00e4r broker 3 startas tillbaka kommer vi tillbaka till tre repliker p\u00e5 partitionen. Men alla ledare f\u00f6rblir fortfarande p\u00e5 broker 2.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/9c8c02be4161f8468b5dbc1e3f6ecb3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 5. Obalanserad placering av ledarna efter \u00e5terst\u00e4llning av broker 1 och 3.<\/i><\/p>\n<p>Kafka har verktyg f\u00f6r en mer effektiv ombalansering av ledarna j\u00e4mf\u00f6rt med RabbitMQ. D\u00e4r beh\u00f6vde man anv\u00e4nda en tredjeparts-plugin eller skript som \u00e4ndrade policyn f\u00f6r migrering av huvudnoden genom att minska redundansen under migreringen. Dessutom var man tvungen att acceptera otillg\u00e4nglighet under synkronisering f\u00f6r stora k\u00f6er.<\/p>\n<p>Kafka har ett begrepp om \"prefererade repliker\" f\u00f6r ledaren. N\u00e4r \u00e4mnespartitioner skapas f\u00f6rs\u00f6ker Kafka j\u00e4mnt f\u00f6rdela ledarna \u00f6ver noderna och markerar dessa f\u00f6rsta ledare som prefererade. Med tiden kan ledarna p\u00e5 grund av serveromstart, fel och anslutningsproblem hamna p\u00e5 andra noder, som i det ovan beskrivna extrema fallet.<\/p>\n<p>F\u00f6r att \u00e5tg\u00e4rda detta erbjuder Kafka tv\u00e5 alternativ:<\/p>\n<ul>\n<li>Alternativ <i>auto.leader.rebalance.enable=true<\/i> detta g\u00f6r det m\u00f6jligt f\u00f6r kontrollernoden att automatiskt omf\u00f6rdela ledarna tillbaka till de prefererade replikerna och d\u00e4rigenom \u00e5terst\u00e4lla den j\u00e4mna f\u00f6rdelningen.\n<\/li>\n<li>Administrat\u00f6ren kan k\u00f6ra skriptet <i>kafka-preferred-replica-election.sh<\/i> f\u00f6r att omf\u00f6rdela manuellt.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/831930b06809637018fecb6d7d5a558d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 6. Repliker efter ombalansering<\/i><\/p>\n<p>Detta var en f\u00f6renklad version av felet, men verkligheten \u00e4r mer komplex, \u00e4ven om det inte \u00e4r n\u00e5got som \u00e4r alltf\u00f6r komplicerat. Allt handlar om synkroniserade repriser (In-Sync Replicas, ISR).<\/p>\n<h1>Synkroniserade repliker (ISR)<\/h1>\n<p>\nISR \u00e4r en upps\u00e4ttning av partitionsrepliker som anses vara \"synkroniserade\" (in-sync). H\u00e4r finns en ledare, och det beh\u00f6ver inte finnas n\u00e5gra f\u00f6ljare. En f\u00f6ljare anses vara synkroniserad om den har gjort exakta kopior av alla meddelanden fr\u00e5n ledaren innan tidsintervallet <i>replica.lag.time.max.ms<\/i>.<\/p>\n<p>En f\u00f6ljare tas bort fr\u00e5n ISR-upps\u00e4ttningen om den:<\/p>\n<ul>\n<li>inte har beg\u00e4rt en h\u00e4mtning under tidsintervallet <i>replica.lag.time.max.ms<\/i> (anses vara d\u00f6d)\n<\/li>\n<li>inte har kunnat uppdateras under tidsintervallet <i>replica.lag.time.max.ms<\/i> (anses vara l\u00e5ngsam)<\/li>\n<\/ul>\n<p>\nF\u00f6ljare g\u00f6r beg\u00e4rningar om h\u00e4mtning under tidsintervallet <i>replica.fetch.wait.max.ms<\/i>, vilket som standard \u00e4r 500 ms.<\/p>\n<p>F\u00f6r att tydligt f\u00f6rklara syftet med ISR m\u00e5ste vi titta p\u00e5 bekr\u00e4ftelser fr\u00e5n producenten (producer) och n\u00e5gra felsscenarier. Producenter kan v\u00e4lja n\u00e4r en broker skickar en bekr\u00e4ftelse:<\/p>\n<ul>\n<li>acks=0, bekr\u00e4ftelse skickas inte\n<\/li>\n<li>acks=1, bekr\u00e4ftelse skickas efter att ledaren har skrivit meddelandet i sin lokala logg\n<\/li>\n<li>acks=all, bekr\u00e4ftelse skickas efter att alla repliker i ISR har skrivit meddelandet i sina lokala loggar<\/li>\n<\/ul>\n<p>\nI Kafka-termer, om ISR har beh\u00e5llit meddelandet, sker en \"commit\". Acks=all \u00e4r det s\u00e4kraste alternativet, men \u00e4ven det medf\u00f6r extra f\u00f6rdr\u00f6jning. L\u00e5t oss \u00f6verv\u00e4ga tv\u00e5 exempel p\u00e5 fel och hur olika alternativ f\u00f6r 'acks' interagerar med konceptet ISR.<\/p>\n<h3>Acks=1 och ISR<\/h3>\n<p>\nI det h\u00e4r exemplet ser vi att om ledaren inte v\u00e4ntar p\u00e5 att varje meddelande ska bekr\u00e4ftas av alla f\u00f6ljare, d\u00e5 kan datarf\u00f6rlust uppst\u00e5 vid ett ledarskapsfel. \u00d6verg\u00e5ngen till en osynkroniserad f\u00f6ljare kan till\u00e5tas eller f\u00f6rhindras genom inst\u00e4llningen <i>unclean.leader.election.enable<\/i>.<\/p>\n<p>I det h\u00e4r exemplet har producenten inst\u00e4llt ack=1. Avsnittet \u00e4r f\u00f6rdelat \u00f6ver alla tre m\u00e4klare. M\u00e4klaren 3 ligger efter; han har synkroniserats med ledaren f\u00f6r \u00e5tta sekunder sedan och ligger nu efter med 7456 meddelanden. M\u00e4klaren 1 ligger bara en sekund efter. V\u00e5r producent skickar ett meddelande och f\u00e5r snabbt tillbaka en ack, utan \u00f6verhead fr\u00e5n l\u00e5ngsamma eller d\u00f6da f\u00f6ljare som ledaren inte v\u00e4ntar p\u00e5.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/f194e6309b732b772574392eff482a8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 7. ISR med tre repliker<\/i><\/p>\n<p>M\u00e4klaren 2 g\u00e5r ner, och producenten f\u00e5r ett anslutningsfel. Efter att ledarskapet g\u00e5tt \u00f6ver till m\u00e4klare 1 f\u00f6rlorar vi 123 meddelanden. F\u00f6ljaren p\u00e5 m\u00e4klare 1 var med i ISR, men blev inte helt synkroniserad med ledaren n\u00e4r denne f\u00f6ll.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/367f219daebafefe585059f67fdedf6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 8. Meddelanden g\u00e5r f\u00f6rlorade vid fel<\/i><\/p>\n<p>I konfigurationen <i>bootstrap.servers<\/i> har producenten listat flera m\u00e4klare, och han kan fr\u00e5ga en annan m\u00e4klare vem som blivit den nya ledaren f\u00f6r avsnittet. D\u00e4refter ansluter han till m\u00e4klare 1 och forts\u00e4tter att skicka meddelanden.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/ba45c51f4ce1f63f10b2fa0e1487b223.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. Meddelandeutskick \u00e5terupptas efter ett kort avbrott<\/i><\/p>\n<p>M\u00e4klaren 3 ligger \u00e4nnu mer efter. Han g\u00f6r f\u00f6rfr\u00e5gningar om h\u00e4mtningar, men kan inte synkroniseras. Detta kan bero p\u00e5 l\u00e5ngsamma n\u00e4tverksanslutningar mellan m\u00e4klare, lagringsproblem, etc. Han tas bort fr\u00e5n ISR. Nu best\u00e5r ISR av en enda replik \u2014 ledaren! Producenten forts\u00e4tter att skicka meddelanden och f\u00e5r bekr\u00e4ftelser.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/592c74632e3a8d80c2b4fc15bde5d401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 10. F\u00f6ljaren p\u00e5 m\u00e4klare 3 tas bort fr\u00e5n ISR<\/i><\/p>\n<p>M\u00e4klaren 1 faller, och ledarskapet g\u00e5r \u00f6ver till m\u00e4klare 3 med en f\u00f6rlust p\u00e5 15286 meddelanden! Producenten f\u00e5r ett meddelande om anslutningsfel. \u00d6verg\u00e5ngen till ledaren utanf\u00f6r ISR var m\u00f6jlig endast p\u00e5 grund av inst\u00e4llningen <i>unclean.leader.election.enable=true<\/i>. Om den \u00e4r inst\u00e4lld p\u00e5 <i>false<\/i>, skulle \u00f6verg\u00e5ngen inte ha intr\u00e4ffat, och alla l\u00e4s- och skrivf\u00f6rfr\u00e5gningar skulle ha avvisats. I s\u00e5 fall v\u00e4ntar vi p\u00e5 att m\u00e4klare 1 ska \u00e5terv\u00e4nda med sina of\u00f6r\u00e4ndrade data i repliken, som \u00e5terigen tar p\u00e5 sig ledarskapet.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/30f01ca715ccc194890ae061a3ef7396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. M\u00e4klaren 1 faller. Vid fel g\u00e5r ett stort antal meddelanden f\u00f6rlorade<\/i><\/p>\n<p>Tillverkaren kopplar upp sig mot den senaste brokeren och ser att denne nu \u00e4r ledare i sektionen. Han b\u00f6rjar skicka meddelanden till broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/986532d9b22b6514b6039c8460b1beb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. Efter en kort paus skickas meddelanden \u00e5ter till sektion 0.<\/i><\/p>\n<p>Vi har sett att f\u00f6rutom korta avbrott f\u00f6r att etablera nya anslutningar och leta efter en ny ledare, har tillverkaren kontinuerligt skickat meddelanden. Denna konfiguration s\u00e4kerst\u00e4ller tillg\u00e4nglighet genom konsistens (datas\u00e4kerhet). Kafka f\u00f6rlorade tusentals meddelanden, men fortsatte att ta emot nya poster.<\/p>\n<h3>Acks=all och ISR<\/h3>\n<p>\nL\u00e5t oss repetera detta scenario igen, men med <i>acks=all<\/i>. F\u00f6rdr\u00f6jningen hos broker 3 \u00e4r i genomsnitt fyra sekunder. Tillverkaren skickar ett meddelande med <i>acks=all<\/i>, och f\u00e5r nu inget snabbt svar. Ledaren v\u00e4ntar tills meddelandet har sparats av alla repliker i ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/95b1abdc92e699f7bc41ebab249a2e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. ISR med tre repliker. En arbetar l\u00e5ngsamt, vilket leder till skrivf\u00f6rdr\u00f6jning.<\/i><\/p>\n<p>Efter fyra sekunder av ytterligare f\u00f6rdr\u00f6jning skickar broker 2 ett ack. Alla repliker \u00e4r nu helt uppdaterade.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/64356dc8d2641a3e22947126dd047f39.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 14. Alla repliker sparar meddelanden och skickar ack.<\/i><\/p>\n<p>Broker 3 ligger nu \u00e4nnu mer efter och tas bort fr\u00e5n ISR. F\u00f6rdr\u00f6jningen minskar betydligt, eftersom det inte finns n\u00e5gra l\u00e5ngsamma repliker kvar i ISR. Broker 2 v\u00e4ntar nu endast p\u00e5 broker 1, som har en genomsnittlig f\u00f6rdr\u00f6jning p\u00e5 500 ms.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/5d3bd67dc53cb868fa40b358ed483a1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. Replik p\u00e5 broker 3 tas bort fr\u00e5n ISR.<\/i><\/p>\n<p>Sedan faller broker 2, och ledarskapet \u00f6verg\u00e5r till broker 1 utan f\u00f6rlust av meddelanden.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/e3f0417aa7714ea5eae8a8e8d61662bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 16. Broker 2 faller.<\/i><\/p>\n<p>Tillverkaren hittar en ny ledare och b\u00f6rjar skicka meddelanden till denne. F\u00f6rdr\u00f6jningen minskar ytterligare, eftersom ISR nu best\u00e5r av en enda replik! D\u00e4rf\u00f6r tillf\u00f6r alternativet <i>acks=all<\/i> ingen redundans.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/fec9aae9977757d5f61c2909ceae0536.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 17. Replik p\u00e5 broker 1 tar ledarskapet utan f\u00f6rlust av meddelanden.<\/i><\/p>\n<p>Sedan faller broker 1, och ledarskapet \u00f6verg\u00e5r till broker 3 med en f\u00f6rlust av 14238 meddelanden!<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/730b3951fb75ab3a782fc6d064615212.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 18. Broker 1 d\u00f6r och \u00f6verg\u00e5ngen av ledarskapet med inst\u00e4llningen unclean leder till omfattande dataf\u00f6rlust.<\/i><\/p>\n<p>Vi skulle kunna avst\u00e5 fr\u00e5n att st\u00e4lla in alternativet <i>unclean.leader.election.enable<\/i> till v\u00e4rdet <i>true<\/i>. Som standard \u00e4r det lika med <i>false<\/i>. Inst\u00e4llningen <i>acks=all<\/i> med <i>unclean.leader.election.enable=true<\/i> s\u00f6ker s\u00e4kerst\u00e4lla tillg\u00e4nglighet med viss extra datas\u00e4kerhet. Men, som du ser, kan vi fortfarande f\u00f6rlora meddelanden.<\/p>\n<p>Men vad om vi vill \u00f6ka datas\u00e4kerheten? Vi kan st\u00e4lla in <i>unclean.leader.election.enable = false<\/i>, men detta skyddar oss inte n\u00f6dv\u00e4ndigtvis fr\u00e5n dataproblem. Om ledaren faller h\u00e5rt och tar med sig datan, s\u00e5 \u00e4r meddelandena \u00e4nd\u00e5 f\u00f6rlorade, och tillg\u00e5ngen \u00e4r borta tills administrat\u00f6ren \u00e5terst\u00e4ller situationen.<\/p>\n<p>Det \u00e4r b\u00e4ttre att garantera redundans f\u00f6r alla meddelanden, annars b\u00f6r man avst\u00e5 fr\u00e5n att g\u00f6ra inspelningar. P\u00e5 s\u00e5 s\u00e4tt kan dataproblem, \u00e5tminstone ur broker-synvinkel, endast intr\u00e4ffa vid tv\u00e5 eller flera samtidiga fel.<\/p>\n<h3>Acks=all, min.insync.replicas och ISR<\/h3>\n<p>\nMed toppkonfigurationen <i>min.insync.replicas<\/i> \u00f6kar vi dataskyddsniv\u00e5n. L\u00e5t oss g\u00e5 igenom den sista delen av det tidigare scenariot en g\u00e5ng till, men den h\u00e4r g\u00e5ngen med <i>min.insync.replicas=2<\/i>.<\/p>\n<p>S\u00e5 broker 2 har en ledare replica, medan f\u00f6ljaren p\u00e5 broker 3 har tagits bort fr\u00e5n ISR.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/5831463293f1837d3232756894e97162.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 19. ISR av tv\u00e5 repliker<\/i><\/p>\n<p>Broker 2 faller, och ledarskapet g\u00e5r \u00f6ver till broker 1 utan att meddelanden f\u00f6rloras. Men nu best\u00e5r ISR endast av en replica. Detta uppfyller inte minimikravet f\u00f6r att f\u00e5 inspelningar, och d\u00e4rf\u00f6r svarar broker med ett fel vid inspelningsf\u00f6rs\u00f6ket. <i>NotEnoughReplicas<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/6b2ee477f4c33ec84f3068b792814e5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 20. Antalet ISR \u00e4r en mindre \u00e4n angivet i min.insync.replicas<\/i><\/p>\n<p>Denna konfiguration offrar tillg\u00e4nglighet f\u00f6r konsekvens. Innan vi bekr\u00e4ftar ett meddelande garanterar vi att det skrivs p\u00e5 minst tv\u00e5 repliker. Detta ger producenten mycket st\u00f6rre s\u00e4kerhet. H\u00e4r \u00e4r f\u00f6rlust av meddelanden endast m\u00f6jlig om tv\u00e5 repliker faller samtidigt under en kort period, innan meddelandet har replikerats till den ytterligare f\u00f6ljaren, vilket \u00e4r osannolikt. Men om du \u00e4r superparanoid kan du st\u00e4lla in replikationsf\u00f6rh\u00e5llandet till 5, och <i>min.insync.replicas<\/i> f\u00f6r 3. H\u00e4r m\u00e5ste tre brokers falla samtidigt f\u00f6r att f\u00f6rlora inspelningen! Naturligtvis f\u00e5r du betala f\u00f6r s\u00e5dan tillf\u00f6rlitlighet med extra latens.<\/p>\n<h1>N\u00e4r tillg\u00e4nglighet \u00e4r n\u00f6dv\u00e4ndig f\u00f6r dataskydd<\/h1>\n<p>\nSom i <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">i fallet med RabbitMQ<\/a><\/noindex>, ibland \u00e4r tillg\u00e4nglighet n\u00f6dv\u00e4ndig f\u00f6r dataskydd. Du m\u00e5ste t\u00e4nka p\u00e5 f\u00f6ljande:<\/p>\n<ul>\n<li>Kan publisher bara returnera ett fel, och \u00f6verordnad tj\u00e4nst eller anv\u00e4ndare f\u00f6rs\u00f6ka igen senare?\n<\/li>\n<li>Kan en publicerare spara meddelandet lokalt eller i databasen f\u00f6r att f\u00f6rs\u00f6ka igen senare?<\/li>\n<\/ul>\n<p>\nOm svaret \u00e4r nej, s\u00e5 \u00f6kar optimering av tillg\u00e4nglighet dataskyddet. Du kommer att f\u00f6rlora mindre data om du v\u00e4ljer tillg\u00e4nglighet ist\u00e4llet f\u00f6r att avst\u00e5 fr\u00e5n inspelning. S\u00e5 allt handlar om att hitta balansen, och beslutet beror p\u00e5 den specifika situationen.<\/p>\n<h1>Meningen med ISR<\/h1>\n<p>\nISR-settet m\u00f6jligg\u00f6r att v\u00e4lja en optimal balans mellan dataskydd och f\u00f6rdr\u00f6jning. Till exempel kan man s\u00e4kerst\u00e4lla tillg\u00e4nglighet vid en majoritet av replikas svikt, samtidigt som man minimerar p\u00e5verkan fr\u00e5n d\u00f6da eller l\u00e5ngsamma replikas n\u00e4r det g\u00e4ller f\u00f6rdr\u00f6jning.<\/p>\n<p>Vi v\u00e4ljer sj\u00e4lva v\u00e4rdet <i>replica.lag.time.max.ms<\/i> i enlighet med v\u00e5ra behov. I grund och botten betyder detta alternativ hur mycket f\u00f6rdr\u00f6jning vi \u00e4r villiga att acceptera n\u00e4r <i>acks=all<\/i>. Standardv\u00e4rdet \u00e4r tio sekunder. Om detta \u00e4r f\u00f6r l\u00e5ng tid f\u00f6r dig kan du minska det. D\u00e5 kommer f\u00f6r\u00e4ndringsfrekvensen i ISR att \u00f6ka, eftersom f\u00f6ljare oftare kommer att tas bort och l\u00e4ggas till.<\/p>\n<p>I RabbitMQ finns bara ett set av speglar som m\u00e5ste replikeras. L\u00e5ngsamma speglar tillf\u00f6r extra f\u00f6rdr\u00f6jning och svar fr\u00e5n d\u00f6da speglar kan dr\u00f6ja \u00e4nda tills pakettiden g\u00e5r ut som kontrollerar tillg\u00e4ngligheten f\u00f6r varje nod (net tick). ISR \u00e4r ett intressant s\u00e4tt att undvika dessa problem med \u00f6kad f\u00f6rdr\u00f6jning. Men vi riskerar att f\u00f6rlora redundans, eftersom ISR kan minska till endast ledaren. F\u00f6r att undvika denna risk, anv\u00e4nd inst\u00e4llningen <i>min.insync.replicas<\/i>.<\/p>\n<h1>Garanti f\u00f6r klientanslutning<\/h1>\n<p>\nI inst\u00e4llningarna <i>bootstrap.servers<\/i> f\u00f6r producent och konsument kan flera m\u00e4klare anges f\u00f6r klientanslutning. Id\u00e9n \u00e4r att n\u00e4r en nod kopplas bort finns det flera reservalternativ som klienten kan ansluta till. Dessa beh\u00f6ver inte n\u00f6dv\u00e4ndigtvis vara ledarna f\u00f6r partitionerna, utan bara en plattform f\u00f6r initial inladdning. Klienten kan fr\u00e5ga dem vilken nod partitionens ledare f\u00f6r l\u00e4sning\/skrivning ligger p\u00e5.<\/p>\n<p>I RabbitMQ kan klienter ansluta till vilken nod som helst, och den interna routingen skickar f\u00f6rfr\u00e5gan dit den ska. Detta inneb\u00e4r att du kan st\u00e4lla in en lastbalanserare framf\u00f6r RabbitMQ. Kafka kr\u00e4ver att klienter ansluter till den nod d\u00e4r ledaren f\u00f6r den relevanta partitionen finns. I en s\u00e5dan situation kan man inte installera en lastbalanserare. Listan <i>bootstrap.servers<\/i> \u00e4r kritisk f\u00f6r att klienter ska kunna n\u00e5 r\u00e4tt noder och lokalisera dem efter ett fel.<\/p>\n<h1>Kafka-konsensusarkitektur<\/h1>\n<p>\nVi har hittills inte diskuterat hur klustret k\u00e4nner av att en m\u00e4klare faller och hur en ny ledare v\u00e4ljs. F\u00f6r att f\u00f6rst\u00e5 hur Kafka fungerar med n\u00e4tverkspartitioner m\u00e5ste man f\u00f6rst f\u00f6rst\u00e5 konsensusarkitekturen.<\/p>\n<p>Varje Kafka-kluster distribueras tillsammans med ett Zookeeper-kluster \u2014 detta \u00e4r en tj\u00e4nst f\u00f6r distribuerad konsensus som g\u00f6r att systemet kan uppn\u00e5 konsensus om ett givet tillst\u00e5nd med prioritet p\u00e5 konsistens framf\u00f6r tillg\u00e4nglighet. Godk\u00e4nnande av l\u00e4s- och skrivoperationer kr\u00e4ver godk\u00e4nnande av merparten av Zookeepers noder.<\/p>\n<p>Zookeeper lagrar klustrets tillst\u00e5nd:<\/p>\n<ul>\n<li>Listor av \u00e4mnen, partitioner, konfiguration, nuvarande ledarrepplikat, f\u00f6redragna replikat.\n<\/li>\n<li>Medlemmar i klustret. Varje broker pingar Zookeeper-klustret. Om den inte f\u00e5r en ping under en angiven tidsperiod, registrerar Zookeeper brokern som otillg\u00e4nglig.\n<\/li>\n<li>Val av huvud- och reservnoder f\u00f6r kontrollern.<\/li>\n<\/ul>\n<p>\nKontrollerknuten \u00e4r en av Kafka-brokerna som \u00e4r ansvarig f\u00f6r att v\u00e4lja ledare f\u00f6r replikat. Zookeeper skickar meddelanden om medlemskap i klustret och \u00e4ndringar av \u00e4mnen till kontrollern, och kontrollern m\u00e5ste agera i enlighet med dessa f\u00f6r\u00e4ndringar.<\/p>\n<p>Till exempel, l\u00e5t oss ta ett nytt \u00e4mne med tio partitioner och en replikationskoefficient p\u00e5 3. Kontrollern m\u00e5ste v\u00e4lja ledare f\u00f6r varje partition och f\u00f6rs\u00f6ka optimalt f\u00f6rdela ledarna mellan brokerna. <\/p>\n<p>F\u00f6r varje partition g\u00f6r kontrollern:<\/p>\n<ul>\n<li>uppdaterar informationen i Zookeeper om ISR och ledaren;\n<\/li>\n<li>skickar LeaderAndISRCommand till varje broker som har en replik av denna partition, informerar brokerna om ISR och ledaren.<\/li>\n<\/ul>\n<p>\nN\u00e4r en broker med ledaren g\u00e5r ner, skickar Zookeeper ett meddelande till kontrollern, och denne v\u00e4ljer en ny ledare. Kontrollen uppdaterar f\u00f6rst Zookeeper och skickar sedan ett kommando till varje broker, vilket informerar dem om f\u00f6r\u00e4ndringen av ledarskapet.<\/p>\n<p>Varje ledare \u00e4r ansvarig f\u00f6r en upps\u00e4ttning ISR. Inst\u00e4llningen <i>replica.lag.time.max.ms<\/i> best\u00e4mmer vem som kommer att ing\u00e5 d\u00e4r. N\u00e4r ISR \u00e4ndras, vidarebefordrar ledaren ny information till Zookeeper.<\/p>\n<p>Zookeeper \u00e4r alltid informerad om eventuella f\u00f6r\u00e4ndringar s\u00e5 att ledarskapet smidigt kan \u00f6verg\u00e5 till en ny ledare vid ett fel.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/3adb1d204b28e3ed85bef3530fa2b738.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 21. Kafka-konsensus<\/i><\/p>\n<h1>Replikationsprotokoll<\/h1>\n<p>\nAtt f\u00f6rst\u00e5 detaljerna i replikationen hj\u00e4lper till att b\u00e4ttre f\u00f6rst\u00e5 de potentiella scenarierna f\u00f6r dataf\u00f6rlust.<\/p>\n<h3>F\u00f6rfr\u00e5gningar om uttag, Log End Offset (LEO) och Highwater Mark (HW)<\/h3>\n<p>\nVi har granskat hur f\u00f6ljare periodvis skickar f\u00f6rfr\u00e5gningar om datainsamling (fetch) till ledaren. Standardintervallet \u00e4r 500 ms. Detta skiljer sig fr\u00e5n RabbitMQ d\u00e4r replikering initieras av master och inte av k\u00f6spegeln. Mastern pushar f\u00f6r\u00e4ndringar till speglarna.<\/p>\n<p>Ledaren och alla f\u00f6ljare sparar loggslut-offset (Log End Offset, LEO) och h\u00f6gvattenm\u00e4rke (Highwater, HW). LEO-m\u00e4rket lagrar offset f\u00f6r det sista meddelandet i den lokala replikationen, medan HW lagrar offset f\u00f6r den senaste commit. Kom ih\u00e5g att ett meddelande m\u00e5ste vara sparat i alla replikor ISR f\u00f6r att statusen ska markeras som \"commit\". Det betyder att LEO vanligtvis ligger n\u00e5got f\u00f6re HW.<\/p>\n<p>N\u00e4r ledaren tar emot ett meddelande sparar han det lokalt. En f\u00f6ljare g\u00f6r en f\u00f6rfr\u00e5gning f\u00f6r att h\u00e4mta data genom att ange sin LEO. D\u00e4refter skickar ledaren ett meddelandepaket som b\u00f6rjar vid detta LEO samt skickar den aktuella HW. N\u00e4r ledaren f\u00e5r information om att alla replikor har sparat meddelandet med det angivna offsetet, flyttar han HW-m\u00e4rket. Endast ledaren kan flytta HW, och hela f\u00f6ljare f\u00e5r veta det aktuella v\u00e4rdet i svaren p\u00e5 sin f\u00f6rfr\u00e5gan. Detta inneb\u00e4r att f\u00f6ljare kan halka efter ledaren b\u00e5de i meddelanden och i sin k\u00e4nnedom om HW. Konsumenterna f\u00e5r endast meddelanden fram till den aktuella HW.<\/p>\n<p>Observera att \"sparad\" (persisted) inneb\u00e4r att den \u00e4r skriven i minnet, inte p\u00e5 disken. F\u00f6r prestandans skull utf\u00f6r Kafka disk-synkronisering med ett visst intervall. RabbitMQ har ocks\u00e5 ett s\u00e5dant intervall, men det skickar bekr\u00e4ftelse till publiceraren f\u00f6rst efter att mastern och alla speglar har skrivit meddelandet p\u00e5 disken. Kafka-utvecklarna har av prestandask\u00e4l beslutat att skicka ack s\u00e5 snart meddelandet \u00e4r skrivet i minnet. Kafka satsar p\u00e5 att redundans kompenserar f\u00f6r risken med kortsiktig lagring av bekr\u00e4ftade meddelanden endast i minnet.<\/p>\n<h1>Ledarskapsfel<\/h1>\n<p>\nN\u00e4r ledaren faller, meddelar Zookeeper kontrollern, som v\u00e4ljer en ny replik av ledaren. Den nya ledaren s\u00e4tter ett nytt HW-m\u00e4rke enligt sin LEO. Sedan f\u00e5r f\u00f6ljare information om den nya ledaren. Beroende p\u00e5 versionen av Kafka kommer f\u00f6ljaren att v\u00e4lja ett av tv\u00e5 scenarier:<\/p>\n<ol>\n<li>Trunkera den lokala loggen till det k\u00e4nda HW och skicka en f\u00f6rfr\u00e5gan till den nya ledaren f\u00f6r meddelanden efter detta m\u00e4rke.\n<\/li>\n<li>Skickar en f\u00f6rfr\u00e5gan till ledaren f\u00f6r att ta reda p\u00e5 HW vid tidpunkten f\u00f6r deras val som ledare, och sk\u00e4r sedan loggen till detta f\u00f6rskott. Den b\u00f6rjar sedan g\u00f6ra periodiska f\u00f6rfr\u00e5gningar om sampling, med b\u00f6rjan fr\u00e5n detta f\u00f6rskott.<\/li>\n<\/ol>\n<p>\nEn f\u00f6ljare kan beh\u00f6va sk\u00e4ra sin logg av f\u00f6ljande sk\u00e4l:<\/p>\n<ul>\n<li>N\u00e4r en ledarfel intr\u00e4ffar, vinner den f\u00f6rsta f\u00f6ljaren i ISR-setet, registrerad i Zookeeper, valet och blir ledare. Alla f\u00f6ljare i ISR, \u00e4ven om de anses vara 'synkroniserade', kanske inte har f\u00e5tt kopior av alla meddelanden fr\u00e5n den tidigare ledaren. Det \u00e4r fullt m\u00f6jligt att den valda f\u00f6ljarens kopia inte \u00e4r den mest aktuella. Kafka garanterar att det inte finns n\u00e5gra avvikelser mellan repliker. F\u00f6r att undvika avvikelser m\u00e5ste varje f\u00f6ljare sk\u00e4ra sin logg till v\u00e4rdet HW f\u00f6r den nya ledaren vid tidpunkten f\u00f6r deras val. Detta \u00e4r ytterligare ett sk\u00e4l till varf\u00f6r inst\u00e4llningen <i>acks=all<\/i> \u00e4r avg\u00f6rande f\u00f6r konsekvens.\n<\/li>\n<li>Meddelanden skrivs periodiskt till disk. Om alla noder i klustret misslyckas samtidigt, kommer kopiorna att sparas p\u00e5 diskar med olika f\u00f6rskott. Det \u00e4r fullt m\u00f6jligt att n\u00e4r m\u00e4klarna \u00e5terg\u00e5r till n\u00e4tverket, den nya ledaren som v\u00e4ljs, kan ligga efter sina f\u00f6ljare, eftersom den har sparats p\u00e5 disk tidigare \u00e4n de andra.<\/li>\n<\/ul>\n<p><\/p>\n<h3>\u00c5teranslutning till klustret<\/h3>\n<p>\nVid \u00e5teranslutning till klustret behandlas repliker p\u00e5 samma s\u00e4tt som vid ledarfel: de kontrollerar ledarens replik och sk\u00e4r sin logg till dess HW (vid tidpunkten f\u00f6r valet). F\u00f6r j\u00e4mf\u00f6relse bed\u00f6mer RabbitMQ \u00e5teranslutna noder som helt nya. I b\u00e5da fallen avvisar m\u00e4klaren allt befintligt tillst\u00e5nd. Om automatisk synkronisering anv\u00e4nds, m\u00e5ste m\u00e4staren replikera allt aktuellt inneh\u00e5ll till den nya spegeln p\u00e5 ett s\u00e4tt som 'l\u00e5t hela v\u00e4rlden v\u00e4nta'. Under denna operation accepterar m\u00e4staren inga l\u00e4s- eller skrivoperationer. Denna metod skapar problem i stora k\u00f6er.<\/p>\n<p>Kafka \u00e4r en distribuerad logg och i allm\u00e4nhet lagrar den fler meddelanden \u00e4n RabbitMQ-k\u00f6n, d\u00e4r data tas bort fr\u00e5n k\u00f6n efter att de har l\u00e4sts. Aktiva k\u00f6n b\u00f6r f\u00f6rbli relativt sm\u00e5. Men Kafka \u00e4r en logg med sin egen lagringspolicy, som kan st\u00e4lla in en tidsgr\u00e4ns p\u00e5 dagar eller veckor. Tillv\u00e4gag\u00e5ngss\u00e4ttet med k\u00f6blockering och fullst\u00e4ndig synkronisering \u00e4r helt oacceptabelt f\u00f6r en distribuerad logg. Ist\u00e4llet trunkerar Kafka-f\u00f6ljare helt enkelt sin logg till HW-ledaren (vid tidpunkten f\u00f6r dess val) om deras kopia ligger f\u00f6re ledaren. I det mer troliga fallet n\u00e4r f\u00f6ljaren ligger efter, b\u00f6rjar den helt enkelt att g\u00f6ra beg\u00e4rningar om h\u00e4mtning fr\u00e5n sin nuvarande LEO.<\/p>\n<p>Nya eller \u00e5terf\u00f6renade f\u00f6ljare b\u00f6rjar utanf\u00f6r ISR och deltar inte i \u00e5taganden. De arbetar bara bredvid gruppen, f\u00e5r meddelanden s\u00e5 snabbt de kan tills de ikapp leder och g\u00e5r med i ISR. Det h\u00e4r finns ingen blockering och inget behov av att kassera all sin data.<\/p>\n<h1>Brott mot sammanh\u00e5llning<\/h1>\n<p>\nKafka har fler komponenter \u00e4n RabbitMQ, s\u00e5 h\u00e4r finns en mer komplex upps\u00e4ttning beteenden n\u00e4r sammanl\u00e4nkningen i klustret st\u00f6rs. Men Kafka designades ursprungligen f\u00f6r kluster, s\u00e5 l\u00f6sningarna \u00e4r mycket v\u00e4l genomt\u00e4nkta.<\/p>\n<p>Nedan f\u00f6ljer n\u00e5gra scenarier f\u00f6r st\u00f6rd sammanl\u00e4nkning:<\/p>\n<ul>\n<li>Scenario 1. F\u00f6ljaren ser inte ledaren, men ser fortfarande Zookeeper.\n<\/li>\n<li>Scenario 2. Ledaren ser inga f\u00f6ljare, men ser fortfarande Zookeeper.\n<\/li>\n<li>Scenario 3. F\u00f6ljaren ser ledaren, men ser inte Zookeeper.\n<\/li>\n<li>Scenario 4. Ledaren ser f\u00f6ljare, men ser inte Zookeeper.\n<\/li>\n<li>Scenario 5. F\u00f6ljaren \u00e4r helt avskuren fr\u00e5n b\u00e5de andra Kafka-noder och Zookeeper.\n<\/li>\n<li>Scenario 6. Ledaren \u00e4r helt avskuren fr\u00e5n b\u00e5de andra Kafka-noder och Zookeeper.\n<\/li>\n<li>Scenario 7. Kafka-kontrollknuten ser inte n\u00e5gon annan Kafka-nod.\n<\/li>\n<li>Scenario 8. Kafka-kontrollern ser inte Zookeeper.<\/li>\n<\/ul>\n<p>\nVarje scenario har sitt eget beteende.<\/p>\n<h3>Scenario 1. F\u00f6ljaren ser inte ledaren, men ser fortfarande Zookeeper.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/5f51ae679933b2b5a69e21831465d121.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Scenario 1. ISR med tre repliker.<\/i><\/p>\n<p>Sammanl\u00e4nkningens st\u00f6rning avskiljer broker 3 fr\u00e5n broker 1 och 2, men inte fr\u00e5n Zookeeper. Broker 3 kan inte l\u00e4ngre g\u00f6ra beg\u00e4rningar om h\u00e4mtning. Efter tidsgr\u00e4nsen. <i>replica.lag.time.max.ms<\/i> han tas bort fr\u00e5n ISR och deltar inte i meddelandet transaktioner. S\u00e5 snart anslutningen \u00e5terst\u00e4lls, kommer han att \u00e5teruppta beg\u00e4rningar om h\u00e4mtning och ansluta sig till ISR n\u00e4r han hinner ikapp ledaren. Zookeeper kommer att forts\u00e4tta ta emot pingar och anse att broker \u00e4r levande och frisk.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/976b7ff080ee6a6d76a165f614f40e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 23. Scenarie 1. Broker tas bort fr\u00e5n ISR om ingen beg\u00e4ran om h\u00e4mtning tas emot inom intervallet replica.lag.time.max.ms.<\/i><\/p>\n<p>Det finns inget logiskt uppdelning (split-brain) eller paus av noden, som i RabbitMQ. Ist\u00e4llet minskas redundansen. <\/p>\n<h3>Scenarie 2. Ledaren ser inga f\u00f6ljare, men ser fortfarande Zookeeper.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/ff6aaa053d73e8b7c97111979bcf97aa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Scenarie 2. Ledaren och tv\u00e5 f\u00f6ljare.<\/i><\/p>\n<p>St\u00f6rning av n\u00e4tverksanslutningen separerar ledaren fr\u00e5n f\u00f6ljare, men broker ser fortfarande Zookeeper. Som i det f\u00f6rsta scenariet, komprimeras ISR, men denna g\u00e5ng bara till ledaren, eftersom alla f\u00f6ljare slutar skicka beg\u00e4rningar om h\u00e4mtning. \u00c5terigen, det finns inget logiskt uppdelning. Ist\u00e4llet sker en f\u00f6rlust av redundans f\u00f6r nya meddelanden tills anslutningen \u00e5terst\u00e4lls. Zookeeper forts\u00e4tter att ta emot pingar och anser att broker \u00e4r levande och frisk.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/3c69e8327da241407f76719fc022c37a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 25. Scenarie 2. ISR har komprimerats endast till ledaren.<\/i><\/p>\n<h3>Scenarie 3. F\u00f6ljare ser ledaren, men ser inte Zookeeper.<\/h3>\n<p>\nF\u00f6ljaren \u00e4r separerad fr\u00e5n Zookeeper men inte fr\u00e5n broker med ledaren. Som ett resultat forts\u00e4tter f\u00f6ljaren att g\u00f6ra h\u00e4mtningar och vara medlem i ISR. Zookeeper f\u00e5r inte l\u00e4ngre pingar och registrerar att brokern har kraschat, men eftersom det bara \u00e4r en f\u00f6ljare, finns det inga konsekvenser efter \u00e5terst\u00e4llningen.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/1183bcfe45a3225ae3ef1a0651f61350.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 26. Scenarie 3. F\u00f6ljaren forts\u00e4tter att skicka beg\u00e4rningar om h\u00e4mtning till ledaren.<\/i><\/p>\n<h3>Scenarie 4. Ledaren ser f\u00f6ljare, men ser inte Zookeeper.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/b3bf27fcb0eb806b27ad00f098e50a26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 27. Scenarie 4. Ledaren och tv\u00e5 f\u00f6ljare.<\/i><\/p>\n<p>Ledaren \u00e4r separerad fr\u00e5n Zookeeper men inte fr\u00e5n brokers med f\u00f6ljare. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/82d9f2e5868566678befc414d1885bfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 28. Scenarie 4. Ledaren \u00e4r isolerad fr\u00e5n Zookeeper.<\/i><\/p>\n<p>Efter ett tag kommer Zookeeper att registrera ett broker-kraschat och meddela kontrollern. Den kommer att v\u00e4lja en ny ledare bland f\u00f6ljare. Men den ursprungliga ledaren kommer att forts\u00e4tta tro att han \u00e4r ledaren och kommer att forts\u00e4tta ta emot poster med <i>acks=1<\/i>. F\u00f6ljare skickar inte l\u00e4ngre beg\u00e4rningar om h\u00e4mtning, s\u00e5 han kommer att betrakta dem som d\u00f6da och f\u00f6rs\u00f6ka komprimera ISR till sig sj\u00e4lv. Men eftersom han inte har n\u00e5gon anslutning till Zookeeper, kan han inte g\u00f6ra det, och vid denna tidpunkt kommer han att avst\u00e5 fr\u00e5n att ta emot fler poster. <\/p>\n<p>Meddelanden <i>acks=all<\/i> de f\u00e5r ingen bekr\u00e4ftelse eftersom ISR f\u00f6rst inkluderar alla repliker, och meddelandena hinner inte fram till dem. N\u00e4r den ursprungliga ledaren f\u00f6rs\u00f6ker ta bort dem fr\u00e5n ISR, kan hon inte g\u00f6ra det och slutar helt enkelt ta emot n\u00e5gra meddelanden.<\/p>\n<p>Kunderna m\u00e4rker snart bytet av ledare och b\u00f6rjar skicka poster till den nya servern. S\u00e5 snart n\u00e4tverket har \u00e5terst\u00e4llts, ser den ursprungliga ledaren att hon inte l\u00e4ngre \u00e4r ledare och avsk\u00e4r loggen till det HW-v\u00e4rde som den nya ledaren hade vid tidpunkten f\u00f6r avbrottet, f\u00f6r att undvika loggkonflikter. Sedan kommer hon att b\u00f6rja skicka beg\u00e4rningar om h\u00e4mtning till den nya ledaren. Alla poster fr\u00e5n den ursprungliga ledaren som inte replikerats till den nya ledaren g\u00e5r f\u00f6rlorade. Det vill s\u00e4ga, meddelanden som inte bekr\u00e4ftats av den ursprungliga ledaren under de d\u00e4r sekunderna, d\u00e5 tv\u00e5 ledare verkade fungera, kommer att g\u00e5 f\u00f6rlorade.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/d88d6f33c13dccb814c0f206ec72512b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 29. Scenario 4. Ledaren p\u00e5 broker 1 blir en f\u00f6ljare efter n\u00e4tverks\u00e5terst\u00e4llning.<\/i><\/p>\n<h3>Scenario 5. F\u00f6ljaren \u00e4r helt isolerad fr\u00e5n andra Kafka-noder och fr\u00e5n Zookeeper.<\/h3>\n<p>\nF\u00f6ljaren \u00e4r helt isolerad fr\u00e5n andra Kafka-noder och fr\u00e5n Zookeeper. Han tas helt enkelt bort fr\u00e5n ISR tills n\u00e4tverket \u00e5terst\u00e4lls, och sedan kommer han i kapp de andra.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/b092607f777014fd945f18734dd7f4e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 30. Scenario 5. Den isolerade f\u00f6ljaren avl\u00e4gsnas fr\u00e5n ISR.<\/i><\/p>\n<h3>Scenario 6. Ledaren \u00e4r helt isolerad fr\u00e5n andra Kafka-noder och fr\u00e5n Zookeeper.<\/h3>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/bb808d534dbf65748eb0b481f86b4926.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 31. Scenario 6. Ledaren och tv\u00e5 f\u00f6ljare.<\/i><\/p>\n<p>Ledaren \u00e4r helt isolerad fr\u00e5n sina f\u00f6ljare, controllern och Zookeeper. Under en kort period kommer han att forts\u00e4tta ta emot poster. <i>acks=1<\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/6fda78bcd26ef6b916579d447e9fb1f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 32. Scenario 6. Isolering av ledaren fr\u00e5n andra Kafka-noder och Zookeeper.<\/i><\/p>\n<p>Om han inte f\u00e5r n\u00e5gra f\u00f6rfr\u00e5gningar efter <i>replica.lag.time.max.ms<\/i>, kommer han att f\u00f6rs\u00f6ka komprimera ISR till sig sj\u00e4lv, men han kommer inte att kunna g\u00f6ra det eftersom det inte finns n\u00e5gon koppling till Zookeeper, varp\u00e5 han slutar att ta emot poster. <\/p>\n<p>Under tiden kommer Zookeeper att markera den isolerade brokern som d\u00f6d, och controllern kommer att v\u00e4lja en ny ledare.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/73d611a411fc64d835af2c714e9eba0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 33. Scenario 6. Tv\u00e5 ledare.<\/i><\/p>\n<p>Den ursprungliga ledaren kan ta emot poster under n\u00e5gra sekunder, men slutar sedan ta emot n\u00e5gra meddelanden. Kunderna uppdaterar var 60:e sekund med den senaste metadata. De kommer att informeras om ledarbytet och b\u00f6rja skicka poster till den nya ledaren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/ae99380c8a84fac15f440b699b9c552b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 34. Scenario 6. Producenter byter till den nya ledaren.<\/i><\/p>\n<p>Alla bekr\u00e4ftade poster som gjorts av den ursprungliga ledaren sedan f\u00f6rlusten av sammanl\u00e4nkning kommer att g\u00e5 f\u00f6rlorade. S\u00e5 snart n\u00e4tverket \u00e5terst\u00e4lls kommer den ursprungliga ledaren genom Zookeeper att uppt\u00e4cka att de inte l\u00e4ngre \u00e4r ledaren. D\u00e5 kommer de att trimma sin logg till HW f\u00f6r den nya ledaren vid tidpunkten f\u00f6r valet och b\u00f6rja skicka f\u00f6rfr\u00e5gningar som en f\u00f6ljare.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ mot Kafka: redundans och h\u00f6g tillg\u00e4nglighet\" src=\"\/wp-content\/uploads\/2019\/11\/10f0983a829b03ca9bbc62e12cbf8a5d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 35. Scenario 6. Den ursprungliga ledaren blir f\u00f6ljare efter att n\u00e4tverkskopplingen har \u00e5terst\u00e4llts<\/i><\/p>\n<p>I denna situation kan det under en kort period observeras en logisk uppdelning, men endast om <i>acks=1<\/i> och <i>min.insync.replicas<\/i> ocks\u00e5 1. Den logiska uppdelningen avslutas automatiskt antingen efter att n\u00e4tverket har \u00e5terst\u00e4llts, n\u00e4r den ursprungliga ledaren inser att de inte l\u00e4ngre \u00e4r ledaren, eller n\u00e4r alla klienter f\u00f6rst\u00e5r att ledaren har \u00e4ndrats och b\u00f6rjar skriva till den nya ledaren \u2013 beroende p\u00e5 vad som intr\u00e4ffar f\u00f6rst. I vilket fall som helst kommer vissa meddelanden att g\u00e5 f\u00f6rlorade, men endast med <i>acks=1<\/i>.<\/p>\n<p>Det finns ett annat alternativ till detta scenario, n\u00e4r precis f\u00f6re n\u00e4tverksuppdelningen f\u00f6ljare har halkat efter, och ledaren har krympt ISR till endast sig sj\u00e4lv. D\u00e5 isoleras de p\u00e5 grund av den f\u00f6rlorade kopplingen. En ny ledare v\u00e4ljs, men den ursprungliga ledaren forts\u00e4tter att ta emot poster, \u00e4ven <i>acks=all<\/i>, eftersom det inte finns n\u00e5gon annan \u00e4n dem i ISR. Dessa poster kommer att g\u00e5 f\u00f6rlorade efter att n\u00e4tverket har \u00e5terst\u00e4llts. Det enda s\u00e4ttet att undvika detta alternativ \u00e4r <i>min.insync.replicas = 2<\/i>.<\/p>\n<h3>Scenario 7. Kafka-controller ser inte en annan Kafka-nod<\/h3>\n<p>\nGenerellt, efter att ha f\u00f6rlorat kontakten med en Kafka-nod, kan kontrollern inte \u00f6verf\u00f6ra n\u00e5gon information om ledarbyte till den. I v\u00e4rsta fall leder detta till en kortsiktig logisk uppdelning, som i scenario 6. Oftast kommer broker helt enkelt inte att bli kandidat f\u00f6r ledarskap vid den senaste felaktigheten.<\/p>\n<h3>Scenario 8. Kafka-controller ser inte Zookeeper<\/h3>\n<p>\nFr\u00e5n den avbrutna kontrollen f\u00e5r Zookeeper ingen ping och v\u00e4ljer en ny Kafka-nod som controller. Den ursprungliga kontrollen kan forts\u00e4tta att framst\u00e4lla sig som s\u00e5dan, men den f\u00e5r inga meddelanden fr\u00e5n Zookeeper, s\u00e5 den har inga uppgifter att utf\u00f6ra. S\u00e5 snart n\u00e4tverket har \u00e5terst\u00e4llts, kommer den att f\u00f6rst\u00e5 att den inte l\u00e4ngre \u00e4r controller, utan har blivit en vanlig Kafka-nod.<\/p>\n<h3>Slutsatser fr\u00e5n scenarier<\/h3>\n<p>\nVi ser att f\u00f6rlust av anslutning av f\u00f6ljare inte leder till f\u00f6rlust av meddelanden, utan bara tillf\u00e4lligt minskar redundansen tills n\u00e4tverket \u00e5terst\u00e4lls. Detta kan naturligtvis leda till dataf\u00f6rlust om en eller flera noder g\u00e5r f\u00f6rlorade.<\/p>\n<p>Om ledaren avskiljs fr\u00e5n Zookeeper p\u00e5 grund av f\u00f6rlust av anslutning kan detta leda till f\u00f6rlust av meddelanden med <i>acks=1<\/i>. Avsaknad av kontakt med Zookeeper orsakar en kortvarig logisk avskiljning med tv\u00e5 ledare. Detta problem l\u00f6ses av parameter <i>acks=all<\/i>.<\/p>\n<p>Parameter <i>min.insync.replicas<\/i> . Att ha tv\u00e5 eller flera repliker ger ytterligare garantier f\u00f6r att s\u00e5dana kortsiktiga scenarier inte leder till meddelandef\u00f6rlust, som i scenario 6.<\/p>\n<h1>Sammanfattning av meddelandef\u00f6rlust<\/h1>\n<p>\nL\u00e5t oss lista alla s\u00e4tt p\u00e5 vilka data kan g\u00e5 f\u00f6rlorade i Kafka:<\/p>\n<ul>\n<li>N\u00e5got fel p\u00e5 ledaren, om meddelanden bekr\u00e4ftades med <i>acks=1<\/i>\n<\/li>\n<li>N\u00e5gon oren (unclean) \u00f6verg\u00e5ng av ledarskapet, det vill s\u00e4ga till en f\u00f6ljare utanf\u00f6r ISR, \u00e4ven med <i>acks=all<\/i>\n<\/li>\n<li>Isolering av ledaren fr\u00e5n Zookeeper, om meddelanden bekr\u00e4ftades med <i>acks=1<\/i>\n<\/li>\n<li>Fullst\u00e4ndig isolering av ledaren som redan har komprimerat ISR-gruppen till sig sj\u00e4lv. Alla meddelanden kommer att g\u00e5 f\u00f6rlorade, \u00e4ven <i>acks=all<\/i>. Detta \u00e4r sant endast om <i>min.insync.replicas=1<\/i>.\n<\/li>\n<li>Samtida fel p\u00e5 alla noder i partitionen. Eftersom meddelanden bekr\u00e4ftas fr\u00e5n minnet, kanske vissa \u00e4nnu inte har skrivits till disk. Efter omstart av servrar kan vissa meddelanden saknas.<\/li>\n<\/ul>\n<p>\nOrena \u00f6verg\u00e5ngar av ledarskapet kan f\u00f6rhindras antingen genom att f\u00f6rbjuda dem eller genom att s\u00e4kerst\u00e4lla att det finns redundans av minst tv\u00e5. Den mest robusta konfigurationen \u00e4r en kombination av <i>acks=all<\/i> och <i>min.insync.replicas<\/i> mer \u00e4n 1.<\/p>\n<h1>Direkt j\u00e4mf\u00f6relse av p\u00e5litlighet mellan RabbitMQ och Kafka<\/h1>\n<p>\nF\u00f6r att s\u00e4kerst\u00e4lla p\u00e5litlighet och h\u00f6g tillg\u00e4nglighet implementerar b\u00e5da plattformarna ett system f\u00f6r prim\u00e4r och sekund\u00e4r replikation. Men RabbitMQ har en akillesh\u00e4l. Vid \u00e5teranslutning efter ett fel sl\u00e4pper noderna sina data, och synkroniseringen blockeras. Denna dubbla attack ifr\u00e5gas\u00e4tter livsl\u00e4ngden f\u00f6r stora k\u00f6er i RabbitMQ. Du m\u00e5ste antingen acceptera minskad redundans eller l\u00e5nga blockeringar. Minskad redundans \u00f6kar risken f\u00f6r massdataf\u00f6rlust. Men om k\u00f6erna \u00e4r sm\u00e5 kan man hantera redundans med korta perioder av otillg\u00e4nglighet (n\u00e5gra sekunder) genom att f\u00f6rs\u00f6ka \u00e5teransluta.<\/p>\n<p>I Kafka finns det inget s\u00e5dant problem. Den kastar bort data endast vid avvikelsen mellan ledaren och f\u00f6ljaren. All gemensam data bevaras. Dessutom blockerar replikeringen inte systemet. Ledaren forts\u00e4tter att ta emot poster medan den nya f\u00f6ljaren tar igen, s\u00e5 f\u00f6r DevOps blir det en trivial uppgift att g\u00e5 med eller \u00e5teransluta till klustret. Sj\u00e4lvklart kvarst\u00e5r fortfarande problem, s\u00e5som n\u00e4tverksbandbredd vid replikering. Om flera f\u00f6ljare l\u00e4ggs till samtidigt kan man st\u00f6ta p\u00e5 bandbreddsgr\u00e4nsen.<\/p>\n<p>RabbitMQ \u00f6vertr\u00e4ffar Kafka n\u00e4r det g\u00e4ller tillf\u00f6rlitlighet vid samtidig fel i flera servrar i klustret. Som vi tidigare n\u00e4mnt, bekr\u00e4ftar RabbitMQ till publicisten f\u00f6rst efter att meddelandet skrivits till disk hos ledaren och alla spegelkopior. Men detta medf\u00f6r en extra f\u00f6rdr\u00f6jning av tv\u00e5 anledningar:<\/p>\n<ul>\n<li>fsync varenda n\u00e5gra hundra millisekunder\n<\/li>\n<li>F\u00f6ljderna av en spegel kan bara m\u00e4rkas efter en tids livscykel av paket som kontrollerar tillg\u00e4ngligheten f\u00f6r varje nod (net tick). Om spegeln stannar eller faller, medf\u00f6r detta f\u00f6rdr\u00f6jning.<\/li>\n<\/ul>\n<p>\nKafka satsar p\u00e5 att om meddelandet lagras p\u00e5 flera noder, kan meddelanden bekr\u00e4ftas s\u00e5 snart de har hamnat i minnet. Detta medf\u00f6r en risk f\u00f6r f\u00f6rlust av meddelanden av alla typer (\u00e4ven <i>acks=all<\/i>, <i>min.insync.repliker=2<\/i>) vid samtidig fel.<\/p>\n<p>\u00d6verlag visar Kafka h\u00f6gre prestanda och \u00e4r ursprungligen designad f\u00f6r kluster. Antalet f\u00f6ljare kan \u00f6kas till 11 om det beh\u00f6vs f\u00f6r tillf\u00f6rlitlighet. Replikationsf\u00f6rh\u00e5llandet 5 och det minimi antal repliker i synkroniserat tillst\u00e5nd <i>min.insync.replicas=3<\/i> g\u00f6r f\u00f6rlust av meddelanden till en mycket s\u00e4llsynt h\u00e4ndelse. Om din infrastruktur kan st\u00f6dja ett s\u00e5dant replikationsf\u00f6rh\u00e5llande och niv\u00e5 av redundans, kan du v\u00e4lja detta alternativ.<\/p>\n<p>Klassificering av RabbitMQ \u00e4r bra f\u00f6r sm\u00e5 k\u00f6er. Men \u00e4ven sm\u00e5 k\u00f6er kan snabbt v\u00e4xa vid h\u00f6g trafik. S\u00e5 snart k\u00f6erna blir stora m\u00e5ste man g\u00f6ra ett h\u00e5rt val mellan tillg\u00e4nglighet och tillf\u00f6rlitlighet. Klassificering av RabbitMQ passar b\u00e4st f\u00f6r mer ovanliga situationer d\u00e4r f\u00f6rdelarna med flexibiliteten i RabbitMQ \u00f6verv\u00e4ger nackdelarna med dess klassificering.<\/p>\n<p>Ett av motgifterna mot s\u00e5rbarheten i RabbitMQ g\u00e4llande stora k\u00f6er \u00e4r att dela upp dem i flera mindre. Om man inte kr\u00e4ver fullst\u00e4ndig ordning p\u00e5 hela k\u00f6n, utan bara f\u00f6r de relevanta meddelandena (t.ex. meddelanden fr\u00e5n en specifik kund), eller helt och h\u00e5llet struntar i ordningen, kan denna l\u00f6sning vara acceptabel: kolla in mitt projekt. <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/7\/22\/creating-consumer-groups-in-rabbitmq-with-rebalanser-part-1\">Omf\u00f6rdelare<\/a><\/noindex> f\u00f6r att dela upp k\u00f6n (projektet \u00e4r fortfarande i ett tidigt stadium). <\/p>\n<p>Slutligen, gl\u00f6m inte bort en rad buggar i kluster- och replikationsmekanismerna b\u00e5de hos RabbitMQ och Kafka. Med tiden har systemen blivit mer mogna och stabila, men inget meddelande kommer n\u00e5gonsin att vara 100 % skyddat mot f\u00f6rlust! Dessutom sker det storskaliga katastrofer i datacenter!<\/p>\n<p>Om jag har missat n\u00e5got, gjort ett misstag eller om ni inte h\u00e5ller med om n\u00e5gon av p\u00e5st\u00e5endena, tveka inte att skriva en kommentar eller kontakta mig.<\/p>\n<p>Jag f\u00e5r ofta fr\u00e5gan: \"Vad ska man v\u00e4lja, Kafka eller RabbitMQ?\", \"Vilken plattform \u00e4r b\u00e4ttre?\" Sanningen \u00e4r att det verkligen beror p\u00e5 din situation, nuvarande erfarenhet osv. Jag tvekar att uttrycka en \u00e5sikt, eftersom det skulle vara en alltf\u00f6r stor f\u00f6renkling att rekommendera en specifik plattform f\u00f6r alla anv\u00e4ndningsfall och m\u00f6jliga begr\u00e4nsningar. Jag har skrivit denna artikelserie s\u00e5 att du kan bilda dig en egen \u00e5sikt.<\/p>\n<p>Jag vill s\u00e4ga att b\u00e5da systemen \u00e4r ledande inom omr\u00e5det. Kanske \u00e4r jag lite partisk, f\u00f6r utifr\u00e5n mina projekt tenderar jag att v\u00e4rdera s\u00e5dana saker som garanterad ordning p\u00e5 meddelandena och p\u00e5litlighet h\u00f6gt. <\/p>\n<p>Jag ser andra teknologier som saknar denna p\u00e5litlighet och garanterad ordning, och sedan ser jag p\u00e5 RabbitMQ och Kafka \u2013 och inser det otroliga v\u00e4rdet av b\u00e5da dessa system.<br \/>\n<br \/>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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 mot Kafka: katastrof\u00e5terst\u00e4llning och h\u00f6g tillg\u00e4nglighet | ProHoster","description":"I","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/52541","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=52541"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/52541\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=52541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=52541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=52541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}