{"id":52525,"date":"2019-11-10T00:00:00","date_gmt":"2019-11-09T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah"},"modified":"2020-02-18T14:00:16","modified_gmt":"2020-02-18T11:00:16","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ vs Kafka: fejltolerance og h\u00f8j tilg\u00e6ngelighed i klynger","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"RabbitMQ
\n
\nFejltolerance og h\u00f8j tilg\u00e6ngelighed er store emner, s\u00e5 vi vil dedikere separate artikler til RabbitMQ og Kafka. Denne artikel handler om RabbitMQ, mens den n\u00e6ste vil v\u00e6re om Kafka i sammenligning med RabbitMQ. Artiklen er lang, s\u00e5 g\u00f8r dig komfortabel.<\/p>\n

Lad os se p\u00e5 strategier for fejltolerance, konsistens og h\u00f8j tilg\u00e6ngelighed (HA), samt de kompromiser, der er n\u00f8dvendige i hver strategi. RabbitMQ kan k\u00f8re p\u00e5 et cluster af noder \u2014 og klassificeres s\u00e5 som et distribueret system. N\u00e5r vi taler om distribuerede systemer, handler det ofte om konsistens og tilg\u00e6ngelighed. <\/p>\n

Disse begreber beskriver, hvordan systemet opf\u00f8rer sig ved fejl. Fejl i netv\u00e6rksforbindelsen, serverfejl, harddiskfejl, midlertidig utilg\u00e6ngelighed af serveren p\u00e5 grund af affaldssamling, pakke tab eller langsom netv\u00e6rksforbindelse. Alt dette kan f\u00f8re til datatab eller konflikter. Det viser sig, at det n\u00e6rmest er umuligt at have et system, der er b\u00e5de fuldst\u00e6ndig konsistent (uden datatab, uden datainkonsekvenser) og tilg\u00e6ngeligt (det vil tage l\u00e6se- og skriveoperationer) under alle fejlsituationer.
\n<\/a><\/noindex>
\nVi vil se, at konsistens og tilg\u00e6ngelighed befinder sig p\u00e5 forskellige ender af spektret, og du skal v\u00e6lge, hvilken retning du vil optimere imod. Den gode nyhed er, at med RabbitMQ er s\u00e5dan et valg muligt. Du har nogle \"n\u00f8rdede\" kontrolknapper, s\u00e5 du kan justere balancen mod mere konsistens eller mere tilg\u00e6ngelighed.<\/p>\n

Vi vil s\u00e6tte fokus p\u00e5, hvilke konfigurationer der f\u00f8rer til datatab p\u00e5 grund af bekr\u00e6ftede opskrivninger. Der er et ansvarssamarbejde mellem udgivere, brokere og forbrugere. N\u00e5r en besked overdrages til brokeren, er det dens opgave at ikke miste beskeden. N\u00e5r brokeren bekr\u00e6fter over for udgiveren, at den har modtaget beskeden, forventer vi ikke, at den g\u00e5r tabt. Men vi vil se, at det faktisk kan ske, afh\u00e6ngigt af konfigurationen af din broker og udgiver.<\/p>\n

Primitiver for et enkelt nodes robusthed<\/h1>\n

<\/p>\n

Robuste k\u00f8er\/routing<\/h3>\n

\nI RabbitMQ findes der to typer af k\u00f8er: langvarige\/vedholdende (durable) og ikke vedholdende (non-durable). Alle k\u00f8er gemmes i Mnesia-databasen. Vedholdende k\u00f8er erkl\u00e6res igen ved opstart af noden og overlever dermed genstart, systemfejl eller servernedbrud (s\u00e5 l\u00e6nge dataene bevares). Dette betyder, at s\u00e5 l\u00e6nge du erkl\u00e6rer routing (exchange) og k\u00f8en som vedholdende, vil k\u00f8- og routinginfrastrukturen komme tilbage i drift.<\/p>\n

Ikke-vedholdende k\u00f8er og routing fjernes ved genstart af noden.<\/p>\n

Vedholdende beskeder<\/h3>\n

\nAt en k\u00f8 er holdbar, betyder ikke, at alle dens beskeder overlever genstart af noden. Kun de beskeder, der er markeret af udgiveren som vedholdende<\/i> (persistent), vil blive genoprettet. Vedholdende beskeder skaber faktisk ekstra belastning p\u00e5 brokeren, men hvis tab af beskeder ikke er acceptabelt, er der ingen anden udvej.<\/p>\n

\"RabbitMQ
\nFig. 1. Vedholdenhedsmatrix<\/i><\/p>\n

Klyngedannelse med k\u00f8spejling<\/h1>\n

\nFor at overleve tab af brokeren har vi brug for redundans. Vi kan samle flere RabbitMQ-noder i en klynge og derefter tilf\u00f8je yderligere redundans ved at replikere k\u00f8erne mellem flere noder. P\u00e5 denne m\u00e5de, hvis en node fejler, taber vi ikke data og forbliver tilg\u00e6ngelige. <\/p>\n

K\u00f8spejling:<\/p>\n