{"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\/fr\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ contre Kafka : r\u00e9silience et haute disponibilit\u00e9 dans les clusters","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"RabbitMQ
\n
\nLa r\u00e9silience et la haute disponibilit\u00e9 sont des sujets importants, c'est pourquoi nous consacrerons des articles distincts \u00e0 RabbitMQ et \u00e0 Kafka. Cet article est consacr\u00e9 \u00e0 RabbitMQ, tandis que le suivant portera sur Kafka, en le comparant \u00e0 RabbitMQ. L'article est long, alors installez-vous confortablement.<\/p>\n

Examinons les strat\u00e9gies de r\u00e9silience, de coh\u00e9rence et de haute disponibilit\u00e9 (HA), ainsi que les compromis \u00e0 accepter dans chaque strat\u00e9gie. RabbitMQ peut fonctionner sur un cluster de n\u0153uds, le classant ainsi comme un syst\u00e8me distribu\u00e9. Lorsqu'il s'agit de syst\u00e8mes distribu\u00e9s, nous parlons souvent de coh\u00e9rence et de disponibilit\u00e9. <\/p>\n

Ces concepts d\u00e9crivent comment le syst\u00e8me se comporte en cas de d\u00e9faillance. Une d\u00e9faillance de la connexion r\u00e9seau, un plantage du serveur, une d\u00e9faillance du disque dur, une indisponibilit\u00e9 temporaire du serveur due \u00e0 une collecte de d\u00e9chets, une perte de paquets ou un ralentissement de la connexion. Tout cela peut entra\u00eener une perte de donn\u00e9es ou des conflits. Il s'av\u00e8re qu'il est presque impossible de construire un syst\u00e8me qui soit \u00e0 la fois compl\u00e8tement coh\u00e9rent (sans perte de donn\u00e9es, sans divergences de donn\u00e9es) et disponible (acceptant des op\u00e9rations de lecture et d'\u00e9criture) pour toutes les d\u00e9faillances.
\n<\/a><\/noindex>
\nNous verrons que la coh\u00e9rence et la disponibilit\u00e9 se situent \u00e0 des extr\u00e9mit\u00e9s oppos\u00e9es du spectre, et vous devez choisir dans quelle direction optimiser. La bonne nouvelle est qu'avec RabbitMQ, ce choix est possible. Vous disposez de \u00ab manettes de nerd \u00bb pour ajuster l'\u00e9quilibre en faveur d'une plus grande coh\u00e9rence ou d'une plus grande disponibilit\u00e9.<\/p>\n

Nous mettrons particuli\u00e8rement l'accent sur les configurations qui entra\u00eenent une perte de donn\u00e9es en raison des accus\u00e9s de r\u00e9ception. Il existe une cha\u00eene de responsabilit\u00e9 entre les \u00e9diteurs, les courtiers et les consommateurs. Une fois qu'un message a \u00e9t\u00e9 remis au courtier, c'est son travail de ne pas perdre ce message. Lorsque le courtier accuse r\u00e9ception de la r\u00e9ception d'un message \u00e0 l'\u00e9diteur, nous ne nous attendons pas \u00e0 ce qu'il soit perdu. Mais nous verrons que cela peut vraiment se produire en fonction de la configuration de votre courtier et de votre \u00e9diteur.<\/p>\n

Primitifs de r\u00e9silience d'un seul n\u0153ud<\/h1>\n

<\/p>\n

Queues de r\u00e9silience \/ routage<\/h3>\n

\nDans RabbitMQ, il existe deux types de files d'attente : les files d'attente durables (durable) et non durables (non-durable). Toutes les files d'attente sont sauvegard\u00e9es dans la base de donn\u00e9es Mnesia. Les files d'attente durables sont r\u00e9annonc\u00e9es lors du d\u00e9marrage du n\u0153ud et, par cons\u00e9quent, survivent \u00e0 un red\u00e9marrage, \u00e0 une panne syst\u00e8me ou \u00e0 un \u00e9chec du serveur (tant que les donn\u00e9es sont conserv\u00e9es). Cela signifie que tant que vous d\u00e9clarez le routage (exchange) et la file d'attente comme durables, l'infrastructure des files d'attente \/ routage passera en mode op\u00e9rationnel.<\/p>\n

Les files d'attente non durables et le routage sont supprim\u00e9s lors du red\u00e9marrage du n\u0153ud.<\/p>\n

Messages durables<\/h3>\n

\nLe fait qu'une file d'attente soit durable ne signifie pas que tous ses messages survivront au red\u00e9marrage du n\u0153ud. Seuls les messages d\u00e9finis par le publiant comme durables<\/i> (persistent) seront restaur\u00e9s. Les messages durables cr\u00e9ent effectivement une charge suppl\u00e9mentaire pour le courtier, mais si la perte d'un message est inacceptable, il n'y a pas d'autre option.<\/p>\n

\"RabbitMQ
\nFig. 1. Matrice de durabilit\u00e9<\/i><\/p>\n

Clustering avec r\u00e9plication de files d'attente<\/h1>\n

\nPour survivre \u00e0 la perte d'un courtier, nous avons besoin de redondance. Nous pouvons regrouper plusieurs n\u0153uds RabbitMQ en un cluster, puis ajouter une redondance suppl\u00e9mentaire en r\u00e9pliquant les files d'attente entre plusieurs n\u0153uds. Ainsi, si un n\u0153ud tombe, nous ne perdons pas de donn\u00e9es et restons accessibles. <\/p>\n

R\u00e9plication de file d'attente:<\/p>\n