Очереди сообщений довольно известный шаблон при проектировании системы, в которой необходимо асинхронное общение между компонентами с гарантированной доставкой сообщений даже в случае недоступности обработчика сообщений.
Основные преимущества использования очередей сообщений:
– Очереди сообщений помогут избежать неэффективного использования ресурсов;
– Позволяют горизонтально масштабировать приложения; распределяют процессы обработки информации;позволяют балансировать нагрузку;
– Дают возможность выдерживать пиковые нагрузки;
– Отказоустойчивость, хранит сообщения пока не истечет таймаут, или пока сообщение не будет обработано потребителем, таким образом даже если потребитель не доступен, сообщение не потеряется, важно для систем, чувствительных к данным.
– Порядок доставки, очередь работает по системе FIFO — первый вошел, первый вышел.
1. Определение функциональных требований к очереди
Для каждой задачи определяются собственные требования к системе очередей. Далее будут рассмотрены основные требования предъявляемые к очередям
1) Пропускная способность;
2) Задержка сообщений.
3) Масштабируемость.
4) Поддержка протокола AMQP [1].
5) Упорядоченность доставки сообщений — очередь должна гарантировать, что если сообщение попало в очередь раньше другого, то и обработано потребителем оно так же будет раньше.
6) Отказоустойчивость — очередь не должна терять данные при выходе из строя одного из серверов. Так же ни одно из сообщений не должно быть обработано дважды, если этого не требуется.
7) Возможность хранения данных за определенный период и их выгрузка
2. Обзор систем обмена сообщениями.
2.1. RabbitMQ
RabbitMQ — популярный брокер сообщений, и у него есть много мощных функций. Документация на веб-сайте RabbitMQ отличная и имеется много книг. RabbitMQ написан на Erlang, не широко используемом языке программирования, но хорошо приспособленном для таких задач. Конфигурация RabbitMQ устанавливается в файле rabbitmq.config и содержит множество настраиваемых параметров. В терминах клиентского API RabbitMQ поддерживает длинный список языков и некоторые стандартные протоколы, например, STOMP, AMQP доступны с помощью плагина. Очереди и темы могут создаваться либо через веб-интерфейс, либо через клиентский API напрямую. Если у вас несколько узлов, их можно кластеризовать, а затем, очереди и темы, можно реплицировать на другие серверы.
2.1.1. Компоненты RabbitMQ
В статье [3] говорится о следующий компонентах RabbitMQ:
- producer — клиент, который создает сообщения
- consumer — клиент, который получает сообщения
- queue — неограниченная по размеру очередь, которая хранит сообщения
- exchange — компонент, который позволяет переправлять отправляемые в него сообщения на различные очереди.
RabbitMQ — простой в использовании, поддерживает огромное количество платформ для разработки. Он хорошо масштабируется при добавлении большего числа серверов.
RabbitMQ обладает следующими свойствами:
– Сообщения, опубликованные в очереди (через обменные пункты)
– Несколько потребителей могут подключиться к очереди
– Брокер сообщений распространяет сообщения среди всех доступных потребителей
– Сообщение может быть переадресовано, если потребитель не сработает
– Заказ на доставку гарантирован для очередей с одним потребителем (это невозможно, если очередь имеет несколько потребителей)
В [4] говорится о поддержке в RabbitMQ следующих протоколов:
– Поддержка протоколов HTTP, XMPP и STOMP
– Клиентских библиотек AMQP для Java и.NET Framework (поддержка других языков программирования реализована в ПО других производителей)
– Различных плагинов (таких как плагины для мониторинга и управления через HTTP или веб-интерфейс или плагин «Shovel» для передачи сообщений между брокерами)
В [5] [6] приводятся замера производительности RabbitMQ. Как результат — RabbitMQ позволяет обрабатывать порядка 20000 сообщений в секунду на одну машину.
2.2. Apache Kafka
Apache Kafka — один из важных компонентов этой экосистемы. Разработанная корпорацией LikedIn и названная в честь знаменитого писателя, служба обмена сообщениями Kafka обладает такими ценными качествами, как скорость работы, масштабируемость, способность секционировать и множество раз фиксировать одни и те же данные в памяти [8]. Перечислим основные отличия Kafka от традиционных систем обмена сообщениями:
– Служба Kafka изначально создавалась и позиционируется как распределенная программа — следовательно, она приспособлена к масштабированию.
– Система обладает отличной производительностью — как в случае публикации сообщений, так и в случае подписки на них.
– Kafka сохраняет сообщения на диске и, таким образом, может использоваться для пакетной передачи данных (например, для ETL-процессов (Extract, Transform, Load — «извлечение, трансформирование, загрузка»).
2.2.1. Архитектура Kafka
В [9] рассказывается про архитектуру Apache Kafka и рассматриваются основные компоненты ее архитектуры:
– Поток сообщений (message) определенного типа в терминах службы называется темой (topic). Сообщение — это полезный для некоего процесса комплект данных, тогда как тема — это категория, в соответствии с которой публикуется то или иное сообщение.
– Производитель (producer) — это любой процесс, публикующий сообщения в соответствующей теме.
– Опубликованные сообщения затем отправляются на хранение на кластер серверов, именуемых брокерами (brokers) или кластером Kafka.
– Потребитель (consumer) может подписаться на одну или несколько тем и использовать сообщения, забирая данные от брокеров.
Рис. 1. Архитектура Apache Kafka
Поскольку Kafka по своей природе является распределенной системой, кластер состоит из нескольких брокеров. Для удобства тема разбивается на секции, и каждый брокер отвечает за хранение одной или нескольких секций. Это дает возможность множеству производителей и потребителей публиковать и использовать сообщения для своих целей одновременно.
2.2.2. Преимущества Kafka
Объем потребляемых данных определяется не брокером, а потребителем. Брокер не обладает никакой информацией насчет того, принял ли потребитель сообщение или нет. [10] Однако для Kafka это не проблема, а преимущество: сообщение удаляется автоматически, если оно задерживается у брокера дольше определенного времени. При этом потребитель может в любой момент сделать «повторный заказ» на то или иное сообщение.
Во-вторых, всем известна основная проблема распределенных систем: она заключается в невозможности определить в любой момент времени, какой сервер активен, а какой нет. Из этой проблемы вытекают более конкретные и пугающие — безопасность данных, отказы системы и прочие «слабые места» распределенных систем. В рамках Apache Hadoop решением подобных вопросов занимается служба координации ZooKeeper, которая обладает необходимыми «плюшками» вроде скорости работы, отказоустойчивости и — естественно — распределенной архитектуры. Так вот, поскольку Kafka, как и любая распределенная система, будет неизбежно сталкиваться с присущими этому классу проблемами, очень важно иметь под рукой интегрированный инструмент, который снизит риски и позаботится о вопросах безопасности и восстановления после отказов. В этом свете большим преимуществом Kafka является полная интеграция службы с ZooKeeper — симбиоз во всей красе.
2.2.3. Производительность Apache Kafka.
В [9] приведен замер пропускной способости apache kafka. В зависимости от размера batch apache kafka имеет разную пропускную способность. При размере batch = 10, Kafka имеет пропускную способность порядка 35 000 сообщений в секунду, а при batch=100 достигается пропускная способность в 89000 в секудну на одну машину.
Kafka — инновационная система для обработки больших объемов данных. Ее архитектура позволяет потребителям самим регулировать скорость, с которой они будут получать данные. При этом, если возникнет отказ системы или исключительная ситуация, потребитель всегда имеет возможность получить сообщение повторно. Интеграция с ZooKeeper позволяет системе работать не только быстро и слаженно, но безопасно, что особенно важно в случае больших данных — ведь большие данные сопряжены с большими рисками.
Таким образом, Kafka очень хорошо подходит для требований, большой производительности, низкого использования ресурсов.
3. Результаты
На рисунке 2 представлена производительность серверов очередей apache kafka и rabbitMQ.
Рис. 2. Пропускная способность apache kafka/rabbitMQ
В таблице 1 представлена общая характеристика по критериям описанным в главе 1.
Таблица 1
|
характеристика |
Apache Kafka |
RabbitMq |
|
Пропускная способность тыс.с./с |
89 |
20 |
|
Масштабируемость |
Горизонтальная |
Горизонтальная |
|
Поддерживаемые протоколы |
Собственный протокол |
STOMP, AMQP |
|
Упорядоченность данных |
Присутствует |
Присутствует |
|
Отказоустойчивость |
Несколько кластеров |
Несколько кластеров |
|
Поддержка хранения сообщений |
Имеется |
Нет |
Заключение
В данной работе были рассмотрены 2 основных средства для обмена сообщениями.
Применять apache kafka следует если поток данных генерирует 100k событий в секунду, которые вам нужно доставить в партиционированном порядке со смесью потоковых и пакетных потребителей, если есть необходимость в перечитывании сообщений.
Применять RabbitMQ следует если поток сообщений 20000+ в секунду, которые необходимо перенаправлять сложными способами до потребителей, если вы хотите гарантировать доставку по одному сообщению, вы не заботитесь о заказанной доставке.
Литература:
- AMQP, https://ru.wikipedia.org/wiki/AMQP [Дата обращения 2017–04–15].
- http://spring-projects.ru/understanding/amqp/ [Дата обращения 2017–04–15].
- What are the differences between Apache Kafka and RabbitMQ, Stuart Charlton, https://www.quora.com/What-are-the-differences-between-Apache-Kafka-and-RabbitMQ [Дата обращения 2017–04–15].
- https://ru.wikipedia.org/wiki/RabbitMQ [Дата обращения 2017–04–15].
- Kafka or RabbitMQ: depends on your messages nature, Yuri Subach, https://yurisubach.com/2016/05/19/kafka-or-rabbitmq/ [Дата обращения 2017–04–15].
- Apache Kafka v/s RabbitMQ — Message Queue Comparison, http://www.cloudhack.in/2016/02/29/apache-kafka-vs-rabbitmq/ [Дата обращения 2017–04–15].
- Messaging with RabbitMQ — A Review, Christian Bick, http://bitsuppliers.com/messaging-with-rabbitmq/ [Дата обращения 2017–04–15].
- ДОБРО ПОЖАЛОВАТЬ В МИР APACHE KAFKA ЧАСТЬ 2, http://blog.vahan.pro/welcome-to-the-world-of-apache-kafka-part2/ [Дата обращения 2017–04–15].
- Инструментарий специалиста по большим данным: Apache Kafka, Лариса Шуринга, http://datareview.info/article/instrumentariy-spetsialista-po-bolshim-dannyim-apache-kafka/ [Дата обращения 2017–04–15].
- Monitoring Kafka performance metrics, Evan Mouzakitis, https://www.datadoghq.com/blog/monitoring-kafka-performance-metrics/ [Дата обращения 2017–04–15].
- https://www.rabbitmq.com/devtools.html [Дата обращения 2017–04–15].
- Apache Kafka. https://kafka.apache.org/. [Дата обращения 2017–04–15].
- Modern Open Source Messaging: Apache Kafka, RabbitMQ and NATS in Action, RICHARD SEROTER, https://seroter.wordpress.com/2016/05/16/modern-open-source-messaging-apache-kafka-rabbitmq-and-nats-in-action/ [Дата обращения 2017–04–15].
- Exploring Message Brokers: RabbitMQ, Kafka, ActiveMQ, and Kestrel, Peter Zaitsev,https://dzone.com/articles/exploring-message-brokers [Дата обращения 2017–04–15].
- Очередь сообщений (Message Queue), Роман Кононов, https://habrahabr.ru/post/165981/ [Дата обращения 2017–04–15].
