На картинке вы видите 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 проталкивает сообщение до тех пор, пока оно не будет доставлено. После успешной доставки сообщение удаляется из очереди.
Этот подход можно сравнить с почтовым отделением и почтальоном, когда посылки (сообщения) приходят от отправителей на почту, оттуда рассылаются по почтовым отделениям, а потом почтальон разносит их по адресам и убеждается, что посылка дошла до получателя.
Спасибо Максиму Зубову за помощь в придумывании метафоры с читальным залом 🙂
Ссылки
- 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
- https://habr.com/ru/post/354486/
- https://habr.com/ru/company/itsumma/blog/416629/
- https://habr.com/ru/company/piter/blog/352978/
30,309 просмотров всего, 10 просмотров сегодня
В случае с реббитом написано, что не потребители запрашивают сообщения у реббита, а сам реббит проталкивает потребителям. А, собственно, в чем тогда надобность этого реббита и почему я не могу сделать то же самое напрямую, тупо вызвав метод потребителя из метода отправителя и передав туда нужную инфу? Т.е. есть 2 разных сервиса, один должен передавать инфу другому. Я могу просто добавить веб апи во второй сервис и вызвать этот апи из первого, для чего тут вообще нужен реббит? Я бы еще понял, что этот посредник может быть нужен в случаях, когда , напр., сервер с потребителем упал и ты не… Read more »
Если вдруг второй сервис захочет сделать N запросов в секунду, а первый не в силах обработь такое количество данных мы получим проблему. В случае с очередью данные будут идти отмерянными «порциями» и система будет получать поступательную нагрузку
Что значит «админ тупо выключит сервер». Вы вобще представляете себе как работают распределенные системы, типа Openstack
С чего бы админу выключать кластер с кроликом то? Это же тебе не как выключить свет в опенсорсе в конце рабочего дня… К тому же твоя веб апишка второго сервиса которую должен дергать первый сервис полностью синхронная шо как бэ связывает первый и второй сервис полностью на момент передачи сообщения, в то же время кролик предлагает тебе полностью ассинхронгое взаимодействие сервисов.
спасибо, понравился стиль изложения 🙂
Спасибо за столь лестный отзыв 🙂