Архитектура RocketMQ

RocketMQ

Архитектура RocketMQ

image

Обзор

Apache RocketMQ是一个分布式消息和流处理平台,具有低延迟,高性能和高可靠性,亿万级容量和灵活的可扩展性。它由四部分组成:名称服务器,代理服务器,生产者和消费者。它们中的每一个都可以水平扩展,而不会出现单点故障。 Как показано на фиг.

кластер серверов имен

Серверы имен обеспечивают легкое обнаружение и маршрутизацию служб. Каждый сервер имен записывает полную маршрутную информацию, предоставляет соответствующие услуги чтения и записи и поддерживает быстрое расширение хранилища.

прокси-кластер

Брокер занимается хранилищем сообщений и обрабатывает хранилище сообщений, предоставляя упрощенный механизм темы (TOPIC) и очереди (QUEUE). Они поддерживают модели push и pull, включают в себя механизмы отказоустойчивости (2 реплики или 3 реплики), могут выдерживать сильные пики и иметь очередь из сотен миллиардов сообщений в последовательности. Кроме того, агент обеспечивает устойчивость к сбоям, обширную метрическую статистику и механизмы оповещения, которых нет в традиционных системах обмена сообщениями.

кластер производителей

Производители поддерживают распределенное развертывание. Распределенные производители отправляют сообщения в кластеры брокеров с помощью нескольких режимов балансировки нагрузки. Процесс отправки поддерживает быстрый сбой и низкую задержку.

потребительский кластер

Кластер потребителя также поддерживает распределенное развертывание в режиме push и pull. Он также поддерживает использование кластера и широковещательную рассылку сообщений. Он предоставляет механизм подписки на сообщения в реальном времени, который удовлетворяет потребности большинства потребителей, а веб-сайт RocketMQ предоставляет очень простое краткое руководство для заинтересованных пользователей.

служба имен

Сервер имен — это полноценный сервис с двумя основными функциями:

  • Управление прокси-сервером: сервер имен получает регистрации от кластера прокси-серверов и предоставляет механизм пульса для проверки работоспособности прокси-сервера.
  • Управление маршрутизацией: каждый сервер имен будет хранить всю информацию о маршрутизации прокси-кластера и информацию об очереди для клиентских запросов.

Как мы знаем, клиенты RocketMQ (производители/потребители) будут запрашивать у NameServer информацию о маршрутизации очереди, но как клиент находит адрес NameServer?

Существует четыре способа предоставить клиенту список адресов серверов имен:

  • Программно: доб :producer.setNamesrvAddr("ip:port").
  • Конфигурация Java: доб:rocket.namesrv.addr.
  • Переменные среды: доб:NAMESRV_ADDR.
  • Конечная точка HTTP.

Для более подробного ознакомления с тем, как клиент находит адрес NameServer, см.здесь

Прокси-сервис

Прокси-сервер отвечает за хранение и доставку сообщений, запрос сообщений, гарантию высокой доступности и т. д.

Как показано на рисунке ниже, прокси-сервер имеет следующие важные подмодули:

image

  • Модуль удаленного взаимодействия: точка входа прокси-сервера, которая обрабатывает запросы от клиентов.
  • Модуль управления клиентами: управляйте клиентами (производителями/потребителями) и поддерживайте подписки на темы для потребителей.
  • Модуль службы хранилища: предоставляет простой API для хранения или запроса сообщений на физических дисках.
  • Сервисный модуль высокой доступности: обеспечивает синхронизацию данных между главным агентом и подчиненным агентом.
  • Служба индексирования: в соответствии с определенным ключом создайте индекс сообщений и предоставьте быстрый запрос сообщений.

Развертывание

В этом разделе описывается готовое к развертыванию решение. Вообще говоря, мы развертываем отказоустойчивый кластер RocketMQ без единой точки отказа.

Предпосылки

Прежде чем приступить к этому разделу, убедитесь, что вы прочитали раздел «Быстрый старт» и знакомы с основными концепциями и компонентами RocketMQ.

Готовое к производству развертывание

  • сервер имен

Чтобы гарантировать правильную работу кластера в случае выхода из строя одного экземпляра, рекомендуется использовать два или более экземпляра сервера имен. Пока работает один экземпляр сервера имен, весь кластер остается в работе.

Серверы имен следуют шаблону проектирования без совместного использования, прокси-серверы отправляют данные пульса всем серверам имен, а производители и потребители могут запрашивать метаданные с любого доступного сервера имен при отправке/потреблении сообщений.

  • играет роль

Агенты можно разделить на две категории в зависимости от их ролей: главные агенты и подчиненные агенты. Главный агент предоставляет доступ RW (чтение и запись), в то время как подчиненный агент получает доступ только для чтения.

Чтобы развернуть высокодоступный кластер RockeMQ без единой точки отказа, необходимо развернуть ряд наборов брокеров. Набор брокеров включает в себя главного брокера и несколько подчиненных брокеров, где для идентификатора главного брокера установлено значение 0, а для идентификатора брокера подчиненного брокера установлено значение, отличное от 0. Брокеры в наборе брокеров имеют одно и то же имя брокера (brokerName). В крайних случаях необходимо настроить как минимум два прокси в наборе прокси. Каждая тема находится у двух или более брокеров.

настроить

При развертывании кластера RocketMQ рекомендуется следующая конфигурация:

Broker configuration

Property Name Default value Details
listenPort 10911 listen port for client
namesrvAddr null name server address
brokerIP1 InetAddress for network interface Should be configured if having multiple addresses
brokerName null broker name
brokerClusterName DefaultCluster this broker belongs to which cluster
brokerId 0 broker id, 0 means master, positive integers mean slave
storePathCommitLog $HOME/store/commitlog/ file path for commit log
storePathConsumerQueue $HOME/store/consumequeue/ file path for consume queue
mapedFileSizeCommitLog 1024 * 1024 * 1024(1G) mapped file size for commit log
deleteWhen 04 When to delete the commitlog which is out of the reserve time
fileReserverdTime 72 The number of hours to keep a commitlog before deleting it
brokerRole ASYNC_MASTER SYNC_MASTER/ASYNC_MASTER/SLVAE
flushDiskType ASYNC_FLUSH {SYNC_FLUSH/ASYNC_FLUSH}. Broker of SYNC_FLUSH mode flushes each message onto disk before acknowledging producer. Broker of ASYNC_FLUSH mode, on the other hand, takes advantage of group-committing, achieving better performance.

Инструмент управления командной строкой

RocketMQ предоставляет инструмент управления CLI (интерфейс командной строки) для запросов, управления и диагностики различных проблем.

Как получить

Инструменты управления предоставляются вместе с RocketMQ, вы либо загружаете предварительно собранную двоичную версию, либо создаете ее самостоятельно из исходного кода, чтобы она у вас была.

Если вам нужен исходный код, модуль инструментов RocketMQ включает его исходный код.

как использовать

Инструменты управления очень просты в использовании и приведены здесь для демонстрационных целей, предполагая среду Linux. В каталоге /bin каталога установки mq используйте команду bash: mqadmin, вы можете увидеть следующее меню справки:

The most commonly used mqadmin commands are:
   updateTopic          Update or create topic
   deleteTopic          Delete topic from broker and NameServer
   updateSubGroup       Update or create subscription group
   deleteSubGroup       Delete subscription group from broker
   updateBrokerConfig   Update broker's config
   updateTopicPerm      Update topic perm
   topicRoute           Examine topic route info
   topicStatus          Examine topic Status info
   topicClusterList     get cluster info for topic
   brokerStatus         Fetch broker runtime status data
   queryMsgById         Query Message by Id
   queryMsgByKey        Query Message by Key
   queryMsgByUniqueKey  Query Message by Unique key
   queryMsgByOffset     Query Message by offset
   queryMsgByUniqueKey  Query Message by Unique key
   printMsg             Print Message Detail
   sendMsgStatus        Send msg to broker
   brokerConsumeStats   Fetch broker consume stats data
   producerConnection   Query producer's socket connection and client version
   consumerConnection   Query consumer's socket connection, client version and subscription
   consumerProgress     Query consumers's progress, speed
   consumerStatus       Query consumer's internal data structure
   cloneGroupOffset     Clone offset from other group
   clusterList          List all of clusters
   topicList            Fetch all topic list from name server
   updateKvConfig       Create or update KV config
   deleteKvConfig       Delete KV config
   wipeWritePerm        Wipe write perm of broker in all name server
   resetOffsetByTime    Reset consumer offset by timestamp(without client restart)
   updateOrderConf      Create or update or delete order conf
   cleanExpiredCQ       Clean expired ConsumeQueue on broker.
   cleanUnusedTopic     Clean unused topic on broker
   startMonitoring      Start Monitoring
   statsAll             Topic and Consumer tps stats
   syncDocs             Synchronize wiki and issue to github.com
   allocateMQ           Allocate MQ
   checkMsgSendRT       Check message send response time
   clusterRT            List All clusters Message Send RT

Режим репликации master-slave

Чтобы гарантировать, что любые успешно опубликованные сообщения не будут потеряны, RocketMQ предоставляет режим репликации посредством двух репликаций: синхронной и асинхронной для большей устойчивости и высокой доступности.

Репликация Master-Slave: Sync/Async Broker

Как и многие системы репликации, агент синхронизации не подтверждает, пока журнал фиксации не будет реплицирован на ведомое устройство. Вместо этого асинхронные брокеры возвращаются сразу же после обработки сообщения на ведущем устройстве.

Как настроить

Дистрибутив RocketMQ в папке conf поставляется с тремя готовыми конфигурациями для справки.

2m-2s-sync
2m-2s-async
2m-noslave

Примечание. Во всех конфигурациях используется асинхронный режим обновления.

развертывать

Возьмем в качестве примера развертывание 2M-2S-SYNC. Сначала запустите два сервера имен, как показано в разделе «Быстрый старт». Допустим, их IP-адреса 192.168.0.2 и 192.168.0.3.

Запустите прокси (при условии, что бинарник RocketMQ находится в /home/rocketmq/dist)

>cd /home/rocketmq/dist/bin
>bash mqbroker -c ../conf/2m-2s-sync/broker-a.properties -n 192.168.0.2:9876,192.168.0.3:9876
>bash mqbroker -c ../conf/2m-2s-sync/broker-a-s.properties -n 192.168.0.2:9876,192.168.0.3:9876
>bash mqbroker -c ../conf/2m-2s-sync/broker-b.properties -n 192.168.0.2:9876,192.168.0.3:9876
>bash mqbroker -c ../conf/2m-2s-sync/broker-b-s.properties -n 192.168.0.2:9876,192.168.0.3:9876
How to verify
Execute the following command to verify according to the CLI section:
> bash mqadmin clusterlist

Основная идея

image

После понимания некоторых основных моделей и концепций MQ мы можем углубиться в некоторые вопросы проектирования системы обмена сообщениями:

  • Проблемы параллелизма потребителей
  • Проблемы потребителей
  • Проблема балансировки потребительской нагрузки
  • маршрутизация сообщений
  • мультиплексирование соединения
  • Канарские развертывания

режиссер

Производитель отправляет сообщения, сгенерированные системой бизнес-приложений, на сервер брокера, RocketMQ предоставляет несколько режимов отправки: синхронный, асинхронный и одностороннюю передачу.

производственная группа

Производители той же роли сгруппированы вместе. Если экземпляр продюсера опускается при обработке транзакции, брокер может связаться с различным экземпляром производителя той же группы производителей для совершения или откатывания транзакции.

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

потребитель

Потребитель получает отмену с прокси-сервера и вводит сообщение в приложение. С точки зрения пользовательского приложения предусмотрено два типа потребителей:

подтолкнуть потребителя

С другой стороны, punsh-consumer инкапсулирует извлечение сообщения, потребление прогресса и поддержание другой работы внутри, оставляя интерфейс обратного вызова для реализации конечным пользователем, который будет выполняться при поступлении сообщения.

тянуть потребителя

Потребитель PULL активно вытаскивает сообщения с прокси-сервера, и после того, как выталкивается партия сообщений, приложение пользователя запускает процесс потребления.

группа потребителей

Подобно вышеупомянутым группам производителей, потребители с одинаковыми ролями группируются вместе и называются группами потребителей.

Группы потребителей — это хорошая концепция, которая упрощает достижение целей балансировки нагрузки и отказоустойчивости, когда речь идет о потреблении сообщений.

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

тема

Тема — это категория, в которой производители доставляют сообщения, а потребители извлекают сообщения. Отношения между производителем и потребителем темы очень свободные. В частности, тема может иметь 0, 1 или более производителей, которые отправляют ей сообщения; и наоборот, производители могут отправлять сообщения для разных тем. С точки зрения потребителя, на тему может подписаться 0, 1 или более групп потребителей. Точно так же группа пользователей может подписаться на одну или несколько тем, пока экземпляры группы потребителей остаются подписанными.

Информация

Сообщение – это информация, которая должна быть доставлена. Сообщение должно иметь тему, которую можно интерпретировать как адрес, на который должно быть отправлено письмо. Сообщения также могут иметь необязательные теги и дополнительные пары ключ-значение. Например, вы можете настроить бизнес-ключи для сообщений и искать сообщения на прокси-сервере для диагностики проблем во время разработки.

очередь сообщений

Темы делятся на одну или несколько подтем: «очереди сообщений».

Этикетка

Другими словами, подтемы тегов предоставляют пользователям дополнительную гибкость. Для тегов сообщения с разными целями из одного и того же бизнес-модуля могут иметь одинаковую тему и разные теги. Теги помогут сохранить код чистым и согласованным, а теги также помогут с системой запросов, предоставляемой RocketMQ.

играет роль

Брокер является основной частью системы RocketMQ, он получает сообщения от производителей, сохраняет их и готовится обрабатывать запросы на включение от потребителей. Он также хранит метаданные, связанные с сообщениями, включая группы потребителей, смещения хода выполнения и информацию о теме/очереди.

сервер имен

Серверы имен используются в качестве поставщиков маршрутной информации. Клиент-производитель/потребитель просматривает тему, чтобы найти соответствующий список брокеров.

модель сообщения

  • кластер
  • транслировать

Заказ сообщения

При использовании DefaultMQPushConsumer вы можете принимать сообщения по порядку или одновременно.

  • Заказал

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

Примечание. Если указано последовательное потребление, максимальный параллелизм потребления сообщений — это количество очередей сообщений, на которые подписана группа потребителей.

  • одновременный

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

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