NLPx

Tales of Data Science

Немного о брокерах сообщений — Kafka и RabbitMQ

 

На картинке вы видите Apache Kafka и RabbitMQ.

Решил кратко написать про разницу между двумя брокерами сообщений Apache Kafka и RabbitMQ. там вся суть — в двух предложениях-метафорах, но на всякий случай напишу чуть больше информации.

Введение

Брокер сообщений (он же диспетчер очереди) — это штука, которая принимает и отдает сообщения между отдельными модулями/приложениями внутри некоторой сложной системы, где модули/приложения должны общаться между собой — то есть пересылать данные друг другу.

 

Распределенная система — такая система, которая работает сразу на множестве машин, образующих цельный кластер.  Кластер это набор компьютеров/серверов, объединенных сетью и взаимодействующих между собой. Важнейшие плюсы такого подхода – высокодоступность и отказоустойчивость.

 

Вертикальная масштабируемость — это наращивание ресурсов, то есть увеличение количества ядер, оперативной памяти и т.д. на одном сервере.

Плюсы:

  • Достаточно просто и понятно.

Минусы:

  • Нельзя наращивать бесконечно.
  • При добавлении ресурсов (оперативка и т.д.) обычно приходится выключать сервера, что не круто.

 

Горизонтальная масштабируемость — это добавление новых серверов с более или менее любыми характеристиками в вычислительный кластер.

Плюсы:

  • Нет таких проблем, как у вертикальной масштабируемости

Минусы:

  • Не везде поддерживается горизонтальная масштабируемость
  • Очень не все системы работают в кластерах, а те, которые в них работают, обычно достаточно сложные в эксплуатации

 

Отказоустойчивая система  это такая система, где отсутствует единая точка отказа, их конфигурацию можно корректировать, подстраиваясь под случающиеся отказы. Единая точка отказа — штука, характерная для нераспределенных систем. Например, если один сервер у вас откажет, то вся система отключается.

Плюсы:

  • Они отказоустойчивые!

Минусы:

  • Для обеспечения отказоустойчивости обязательно приходится частично жертвовать производительностью, поскольку чем лучше ваша система переносит отказы, тем ниже ее производительность.

 

Apache Kafka

Apache Kafka — распределенный горизонтально масштабируемый отказоустойчивый программный брокер сообщений.

Приложения (генераторы) посылают сообщения (записи) на узел Kafka (брокер), и указанные сообщения обрабатываются другими приложениями, так называемыми потребителями. Указанные сообщения сохраняются, a потребители подписываются для получения новых сообщений. Kafka гарантирует, что все сообщения будут упорядочены именно в той последовательности, в которой поступили. Kafka не отслеживает, какие записи считываются потребителем и после этого удаляются, а просто хранит их в течение заданного периода времени. Потребители сами опрашивают Kafka, не появилось ли у него новых сообщений, и указывают, какие записи им нужно прочесть.

Этот подход похож на библиотеку с читальным залом, когда кто угодно приходит, берет книгу (сообщение), читает ее в читальном зале, затем отдает обратно. А книги, когда устаревают, просто выбрасываются из библиотеки.

 

RabbitMQ

RabbitMQ, как и Kafka, тоже распределенный горизонтально масштабируемый отказоустойчивый программный брокер сообщений.

Приложения (publishers) посылают сообщения на узел RabbitMQ (exchange), при этом RabbitMQ отсылает обратно приложениям подтверждение, что сообщение получено. Получатели (consumers) постоянно соединены с RabbitMQ по TCP и ждут, когда RabbitMQ протолкнет (push) им сообщения. Получатели подтверждают получение сообщения или сообщают о неудаче. Если доставка неудачна, то RabbitMQ проталкивает сообщение до тех пор, пока оно не будет доставлено. После успешной доставки сообщение удаляется из очереди.

Этот подход можно сравнить с почтовым отделением и почтальоном, когда посылки (сообщения) приходят от отправителей на почту, оттуда рассылаются по почтовым отделениям, а потом почтальон разносит их по адресам и убеждается, что посылка дошла до получателя.

 

Спасибо Максиму Зубову за помощь в придумывании метафоры с читальным залом 🙂

Ссылки

  1. http://xgu.ru/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D0%B5%D0%B9
  2. https://habr.com/ru/post/354486/
  3. https://habr.com/ru/company/itsumma/blog/416629/
  4. https://habr.com/ru/company/piter/blog/352978/

 

6,275 просмотров всего, 8 просмотров сегодня

Немного о брокерах сообщений — Kafka и RabbitMQ
5 4 votes

3
Leave a Reply

avatar
2 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
ГошаtorsellloАндрей Recent comment authors
newest oldest most voted
Гоша
Guest
Гоша

В случае с реббитом написано, что не потребители запрашивают сообщения у реббита, а сам реббит проталкивает потребителям. А, собственно, в чем тогда надобность этого реббита и почему я не могу сделать то же самое напрямую, тупо вызвав метод потребителя из метода отправителя и передав туда нужную инфу? Т.е. есть 2 разных сервиса, один должен передавать инфу другому. Я могу просто добавить веб апи во второй сервис и вызвать этот апи из первого, для чего тут вообще нужен реббит? Я бы еще понял, что этот посредник может быть нужен в случаях, когда , напр., сервер с потребителем упал и ты не… Read more »

Андрей
Guest
Андрей

спасибо, понравился стиль изложения 🙂