Общая документация:Каталог статей
Github : github.com/black-ant

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

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

Введение

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

RabbitMQ :
Kafka
RocketMQ
TubeMQ
ZeroMQ
ActiveMQ

2. Структурный обзор

2.1 Предварительные знания: JMS

JMS является основой многих сред MQ.JMS определяет набор интерфейсов и семантики, которые позволяют Java-приложениям взаимодействовать с другими реализациями обмена сообщениями.Он определяет как спецификацию, так и структуру реализации.

Основы JMS:

JMS имеет следующие важные роли и цели:

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

Состав участников JMS:

Поставщик JMS: система обмена сообщениями, реализующая спецификацию JMS.
Клиенты JMS: Java-приложения, которые отправляют и получают сообщения.
Messages: объекты, используемые для передачи сообщений между клиентами JMS.
Администрируемые объекты: предварительно настроенные объекты JMS, созданные администраторами для использования клиентов JMS.

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

В JMS определены 2 способа передачи сообщений.

Точка-точка (цель очереди):

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

Публикация/подписка (тема назначения):

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

Состав сообщения JMS:

Сообщение состоит из трех частей: заголовка, свойств и тела.

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

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

Тело (также необязательное) содержит фактические данные для обмена. JMS 规范定义了 JMS 提供者必须支持的六种类型的消息:

Сообщение: представляет сообщение без тела сообщения.
StreamMessage : сообщение, тело которого содержит поток примитивного типа Java. Пишется и читается последовательно
MapMessage : тело сообщения содержит набор пар имя/значение. Порядок записей не определен
TextMessage : тело сообщения содержит строку Java.
ObjectMessage : тело сообщения содержит сериализованный объект Java.
BytesMessage : сообщение, тело которого содержит поток неинтерпретированных байтов.

2.2 RabbitMQ

RabbitMq реализован на основе AMQP (Advanced Message Queuing Protocol), который имеет следующие характеристики:

Поддерживает множество протоколов обмена сообщениями, таких как AMQP, MQTT, STOMP, поэтому также известен как гибридный брокер.
Поддерживаются несколько методов обмена сообщениями типа «публикация-подписка», «точка-точка» и «запрос-ответ».
Использует модель «умный брокер/глупый потребитель» и последовательно доставляет сообщения потребителям.
Поддержка Java, Ruby, . NET, PHP и многих других языков, а также предоставляет подключаемые модули, которые можно добавлять для расширения вариантов использования и сценариев интеграции.
Предусмотрены синхронный и асинхронный режимы связи.

Основные понятия RabbitMQ:

виртуальный хост: виртуальный хост содержит набор обменов сообщениями, очередей и привязок
Сообщение: сообщение является анонимным и состоит из заголовка сообщения и тела сообщения.
Binding: обмен должен быть привязан к очереди
Канал: независимый двунаправленный канал потока данных в мультиплексном соединении.
Exchange: Exchange используется для пересылки сообщений, но не для хранения.

ExchangeType

fanout:Направит все сообщения, отправленные на Exchange, во все привязанные к нему очереди.
direct :Правило маршрутизации Exchange прямого типа также очень простое, оно направит сообщение в те Очереди, чей ключ привязки точно соответствует ключу маршрутизации.
topic :Направлять сообщения в очередь, ключ привязки которой соответствует ключу маршрутизации, и можно использовать подстановочные знаки: например: «*» соответствует любому тексту в определенном месте, «.» делит ключ маршрутизации на несколько частей, «#» соответствует всем правилам. , так далее.
headers :По атрибуту заголовка в содержимом сообщения

Возможности RabbitMQ:

1. Надежность
RabbitMQ использует некоторые механизмы для обеспечения надежности, такие как постоянство, подтверждение передачи и подтверждение публикации.

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

3. Кластеризация
Несколько серверов RabbitMQ могут образовывать кластер для формирования логического брокера.

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

5. Мультипротокол
RabbitMQ поддерживает различные протоколы очередей сообщений, такие как STOMP, MQTT и другие.

6. Много клиентов
RabbitMQ поддерживает практически все распространенные языки, такие как Java, .NET, Ruby и т. д.

7. Интерфейс управления
RabbitMQ предоставляет простой в использовании пользовательский интерфейс, который позволяет пользователям отслеживать и управлять многими аспектами брокера сообщений.

8. Отслеживание
Если сообщение является ненормальным, RabbitMQ предоставляет механизм отслеживания сообщения, потребитель может узнать, что произошло.

9. Система плагинов
RabbitMQ предоставляет множество плагинов, которые можно расширять разными способами, или вы можете написать свои собственные плагины.

Процесс RabbitMQ:

2.3 Kafka

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

Kafka предоставляет своим пользователям три основные функции

Публикация и подписка на поток записей
Эффективно хранить потоки записей в том порядке, в котором они были созданы
Обработка потоков записей в режиме реального времени

Члены Кафки:

Producer :В соответствии с методом раздела сообщение публикуется в разделе указанной темы.
**кластер kafka **Получив сообщение от производителя, он сохраняет его на жесткий диск
Consumer :Извлекайте сообщения из кластера kafka и контролируйте смещение для получения сообщений.
Тема:Различные классификации источников сообщений, обрабатываемых kafka
partition :Тема физически сгруппирована. Тема может быть разделена на несколько разделов. Каждый раздел представляет собой упорядоченную очередь. Каждому сообщению раздела будет присвоен упорядоченный идентификатор (смещение).
replicas :Набор реплик раздела
leader :Роли в репликах, производители и потребители взаимодействуют только с Лидером
follower :Роль в репликах, которая реплицирует данные от лидера, а ведомый является кандидатом в лидеры
Сообщение:Сообщение, основная единица общения, каждый производитель может опубликовать несколько сообщений в теме.
Consumer group :Сообщение может потребляться потребителем в нескольких группах

Кафка процесс:

Подпроцесс паба:

Производители периодически отправляют сообщения в темы.
Брокеры Kafka хранят все сообщения в разделах, настроенных для этой конкретной темы. Это гарантирует, что сообщения распределяются поровну между разделами. Если производитель отправляет два сообщения и есть два раздела, Kafka сохранит одно сообщение в первом разделе, а второе сообщение — во втором разделе.
Потребители подписываются на определенные темы.
Как только потребитель подпишется на тему, Kafka предоставит потребителю текущее смещение темы, а также сохранит смещение в ансамбле Zookeeper.
Потребители будут периодически запрашивать у Kafka (например, 100 мс) новые сообщения.
Как только Kafka получает сообщения от производителей, она пересылает эти сообщения потребителям.
Потребитель получит сообщение и обработает его.
Как только сообщение будет обработано, потребитель отправит подтверждение брокеру Kafka.
Как только Kafka получает подтверждение, он изменяет смещение на новое значение и обновляет его в Zookeeper. Поскольку смещение поддерживается в Zookeeper, потребитель может правильно прочитать следующую почту, даже во время брутфорса сервера.
Описанный выше процесс будет повторяться до тех пор, пока потребитель не остановит запрос.
Потребители могут вернуться/перейти к нужному смещению темы в любое время и прочитать все последующие сообщения.

Процесс подписки:

Производители отправляют сообщения в тему через регулярные промежутки времени.
Kafka хранит все сообщения в разделах, настроенных для этой конкретной темы, аналогично предыдущей схеме.
Один потребитель подписывается на определенную тему, допустим, Тема-01 — это Группа-1 с идентификатором группы.
Kafka взаимодействует с потребителями так же, как сообщения публикации-подписки, пока новый потребитель не подпишется на ту же тему с тем же идентификатором группы Topic-01.
Как только появляется новый потребитель, Kafka переключает свою работу в общий режим и обменивается данными между двумя потребителями. Этот общий доступ будет продолжаться до тех пор, пока количество пользователей не достигнет количества разделов, настроенных для этой конкретной темы.
Как только количество потребителей превысит количество разделов, новые потребители не будут получать никаких дальнейших сообщений, пока существующие потребители не откажутся от подписки на любой из них. Это происходит потому, что каждому потребителю в Kafka будет назначен хотя бы один раздел, и как только все разделы будут назначены существующим потребителям, новым потребителям придется ждать.

Общая архитектура Кафки:

Кафка против RabbitMQ

2.4 RocketMQ

Apache RocketMQ — это унифицированный механизм обмена сообщениями, облегченная платформа обработки данных.

Члены RocketMQ:

Режиссер:Ответственный за создание сообщений производитель отправляет сообщения, сгенерированные системой бизнес-приложений, на сервер сообщений.
Потребитель:Ответственный за потребление сообщений, потребитель выдвигает информацию с сервера сообщения и подает его в приложение пользователя.
Сервер сообщений (брокер):Это центр хранения сообщений, и его основная функция — получать и хранить сообщения от Продюсера, а Потребитель получает сообщения отсюда.
Сервер имен (NameServer):Он используется для сохранения метаинформации, такой как тема, связанная с брокером, и предоставления ее производителю, чтобы предоставить потребителям возможность найти информацию о брокере.

Процесс RocketMQ

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

2,Брокерский старт
Брокер поддерживает длительные соединения со всеми Namesrv и регулярно отправляет пакеты пульса. Пакет пульса содержит текущую информацию о брокере (IP + порт и т. д.) и хранит всю информацию о теме. После успешной регистрации между Topic и Broker в кластере Namesrv устанавливается отношение сопоставления.

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

4.Производитель отправляет сообщение
При запуске сначала установите длинное соединение с одним из кластеров Namesrv, и получите от Namesrv, на каких Брокерах существует текущий отправленный Топик, а затем установите длинное соединение с соответствующим Брокером и отправляйте сообщения непосредственно Брокеру.

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

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

По сравнению с другими очередями сообщений (PS: получено от официального представителя RocketMQ)

2.5 ActiveMQ

Apache ActiveMQ — самый популярный многопротокольный сервер обмена сообщениями на основе Java с открытым исходным кодом. Он поддерживает стандартные отраслевые протоколы,

Apache ActiveMQ работает быстро, поддерживает множество многоязычных клиентов и протоколов, имеет простые в использовании шаблоны корпоративной интеграции и множество дополнительных функций, полностью поддерживая JMS 1.1 и J2EE 1.4. Apache ActiveMQ выпущен под лицензией Apache 2.0.

Брокер Apache ActiveMQЯвляется реализацией службы обмена сообщениями Java (Java Messaging Service, JMS). JMS — это спецификация Java, которая позволяет приложениям отправлять данные друг другу и друг другу простым и стандартным способом.

ActiveMQ — этоJMS-провайдер. JMS 提供者形成了一个软件框架，用于促进在应用程序中使用 JMS 概念。 ActiveMQ 的一个节点允许客户端连接到它并使用这些消息传递概念，这个节点称为“ ActiveMQ Broker”

Возможности ActiveMQ:

1 支持多种跨语言协议 :  Java, C, C++, C#, Ruby, Perl, Python, PHP
2 支持企业集成方案  , 可集成在  在 JMS 客户机和 Message Broker 中
3 支持许多 例如 信息组, 虚拟目的地, 及 综合目的地
4 完全支持 JMS 1.1和 J2EE 1.4，支持瞬态、持久、事务和 XA 消息传递
5 支持 Spring
6 支持常见的 J2EE 服务器
7 支持热插拔
8 支持高性能日志
9 支持高性能集群
10 提供Web API
11 允许 web 浏览器成为消息传递结构的一部分

Режим ActiveMQ:

ActiveMQ реализован на основе JMS, поэтому он поддерживает функции, предоставляемые JMS:

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

Pub/Sub (публикация/подписка, публикация/подписка)Домен сообщений использует тему в качестве пункта назначения, издатели отправляют сообщения в тему, а подписчики регистрируются для получения сообщений из темы. Любое сообщение, отправленное в тему, будет автоматически доставлено всем подписчикам. Способы получения (синхронный и асинхронный) такие же, как и в домене P2P.

Как работает ActiveMQ

Как только сообщения поступают в систему, они располагаются в двух режимах: очередь и тема. Очередь — это канал FIFO (первым пришел — первым обслужен) сообщений, генерируемых и потребляемых брокерами и клиентами. Производители создают сообщения и помещают их в эти очереди. Затем пользовательское приложение опрашивает и собирает эти сообщения, по одному за раз. Темы — это каналы вещания сообщений на основе подписки. Когда производственное приложение отправляет сообщение, несколько получателей, «подписанных» на тему, получат широковещательную рассылку сообщения. Это генерирующее приложение иногда называют издателем в контексте тематических сообщений.

Процесс ActiveMQ:

Это включает соответствующую логику подтверждения потребления:

(1) клиент получает сообщение;
(2) клиент обрабатывает сообщение;
(3) сообщение подтверждается;

Всего существует четыре механизма подтверждения:

Session.AUTO_ACKNOWLEDGE :Когда клиент (потребитель) успешно возвращается из метода получения или из метода MessageListener.onMessage, сеанс автоматически подтверждает сообщение, а затем автоматически удаляет сообщение.

Session.CLIENT_ACKNOWLEDGE :Клиент подтверждает сообщение, явно вызывая метод подтверждения сообщения. То есть на принимающей стороне вызывается метод message.acknowledge();, иначе сообщение не будет удалено.

Session. DUPS_OK_ACKNOWLEDGE :Подтверждать не нужно, это своего рода "ленивое" подтверждение сообщения. Сообщение может быть отправлено повторно. Когда сообщение повторно передается во второй раз, для JMSRedelivered в заголовке сообщения будет установлено значение true, чтобы указать, что текущее сообщение было передано один раз, и клиенту необходимо повторно передать сообщение Дублирование управления обработкой сообщений.

Session.SESSION_TRANSACTED :Транзакция совершена и подтверждена.

Сравнение MQ ActiveMQ и кролика MQ

На основе версии ------------ > :

ActiveMQ — это брокер сообщений с открытым исходным кодом, основанный на клиенте службы сообщений Java.
RabbitMQ реализован на основе протокола Advanced Message Queuing.

Как это работает ------------ > :
RabbitMQ работает централизованно, что делает его уникальным подходом. RabbitMQ очень портативен и удобен для пользователя. Потому что большие операции, такие как балансировка нагрузки или постоянные очереди сообщений, выполняются только с ограниченным количеством строк кода. Но этот подход менее масштабируемый и более медленный, потому что его задержка добавляется от центрального узла и размера конверта сообщения. ActiveMQ проще реализовать, и он предоставляет расширенные функции, такие как кластеризация, кэширование, ведение журнала и хранение сообщений.

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

Реализация ------------ > :ActiveMQ состоит из клиента службы сообщений Java, способного поддерживать несколько клиентов или серверов. Реализован RabbitMQ для разработки высокоуровневого протокола очередей сообщений. Он был расширен для поддержки различных протоколов, таких как MQTT и STOMP.

Другие преимущества ---------- >:
RabbitQПоддерживает несколько протоколов обмена сообщениями, предоставляя подтверждения и очереди сообщений. Его можно включить на различных языках, таких как Python, . и Ява. Он также позволяет разработчикам использовать такие приложения, как Chef, Docker и Puppet. Он обеспечивает высокую пропускную способность и высокую доступность за счет создания возможных кластеров. Благодаря поддержке подключаемой аутентификации и авторизации он легко работает как с общедоступными, так и с частными облаками. HTTP-API — это инструмент командной строки с пользовательским интерфейсом, облегчающий администрирование и мониторинг RabbitMQ.

ActiveMQОн имеет много преимуществ, может применяться в соответствии с потребностями и имеет высокую эффективность. Он поддерживает С, С++, . NET и Python, а также может встраивать многоплатформенные приложения с помощью расширенного протокола очереди сообщений. Он обеспечивает гибкий обмен сообщениями между веб-приложениями через потоковый протокол обмена текстовыми сообщениями STOMP. Он также запрограммирован для управления устройствами IoT.

2.6 ZeroMQ

Этот MQ потрясающий, обратите внимание, есть большая разница:

Основы ZeroMQ

ZeroMQ (также известный как ømq, 0MQ или ZMQ) — это высокопроизводительныйБиблиотека асинхронного обмена сообщениями (не фреймворк), предназначенный для распределенных или параллельных приложений. Он предоставляет очередь сообщений, но в отличие от ПО промежуточного слоя, ориентированного на сообщения, система ZeroMQ может работать без выделенного брокера сообщений.

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

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

Интересно то, что Zero MQ предоставляет разные реализации для разных языков, напримерJava может найти JZMQ в Git

Логическая архитектура ZeroMQ

Сокеты: при использовании сокетов взаимодействие пользователя с этими сокетами похоже на сокеты TCP, разница между ними заключается в том, что каждый сокет может обрабатывать несколько одноранговых соединений.
Рабочий поток: В рабочих потоках находятся различные объекты.Каждый объект удерживается родительским объектом (право собственности представлено простой полной линией на диаграмме). Многие объекты хранятся непосредственно в сокетах, однако есть случаи, когда сущности контролируются объектами, принадлежащими сокетам.
Прослушиватель: объект прослушивателя TCP прослушивает входящие TCP-соединения и генерирует объект механизма/сеанса для каждого нового соединения.
Session: это объект сеанса для связи с сокетом ZeroMQ.
Engine : Объект двигателя взаимодействует с сетью.
Pipe: когда сеанс обменивается сообщениями с сокетом. Существует два направления доставки сообщений. Объект Pipe обрабатывает каждое направление доставки сообщений. По сути, каждый канал представляет собой незаблокированную очередь для быстрого обмена сообщениями между потоками.

ZeroMQ взрывает сам себя

TCP：ZeroMQ基于消息，使用消息模式而不是字节流。
XMPP：ZeroMQ更简单、快速、更底层。Jabber可建在ØMQ之上。
AMQP：完成相同的工作，ZeroMQ要快100倍，而且不需要代理（规范更简洁——比AMQP的规范文档少278页）
IPC：ZeroMQ可以跨主机通信
CORBA：ZeroMQ不会将复杂到恐怖的消息格式强加于你。
RPC：ZeroMQ完全是异步的，你可以随时增加/删除参与者。
RFC 1149：ZeroMQ比它快多了！
29west LBM：ZeroMQ是自由软件！
IBM Low-latency：ZeroMQ是自由软件！
Tibco：ZeroMQ仍然是自由软件！

Шаблон сообщения ZeroMQ

опубликовать подписаться

Pull or Push

Ответ на асинхронный запрос
ZeroMQ Request.jpg

Разница между ZeroMQ и RabbitMQ

ZeroMQ против Кафки

2.7 TubeMQ

TubeMQ производится Tencent и в настоящее время передана в дар Apache.TubeMQ представляет собой промежуточное ПО для распределенных сообщений триллионного уровня, ориентированное на передачу и хранение больших объемов данных и обладающее уникальными преимуществами в производительности, надежности и стоимости.Официальные данные должны поддерживать 10 триллионов + доступ к данным.

Архитектура членства TubeMQ

Portal:Портальная часть отвечает за внешнее взаимодействие и операции по эксплуатации и обслуживанию, включая API и Web.API подключается к системам управления вне кластера.Web – это страница, инкапсулирующая функции ежедневной эксплуатации и обслуживания на основе API;

Владелец:Контрольная часть отвечает за управление кластером.Эта часть состоит из одного или нескольких Мастер-нод.Мастер-HA завершается через контроль активности и переключение между Мастер-нодами в режиме реального времени (это когда нужно заполнить все Мастер-ноды соответствующего кластера при использовании TubeMQ Lib Причина обращения), главный Мастер отвечает за управление состоянием всего кластера, планирование ресурсов, проверку разрешений, запрос метаданных и т. д.;

Маклер:Часть Store отвечает за фактическое хранение данных.Эта часть состоит из независимых узлов Broker.Каждый узел Broker управляет коллекцией тем в этом узле, включая добавление, удаление, изменение и проверку темы, хранение сообщений в теме , потребление, старение, расширение партиций, офсетная запись потребления данных и т. д., внешние возможности кластера, включая количество топиков, пропускную способность, емкость и т. д., дополняются горизонтальным расширением узла Брокер;

Клиент:Клиентская часть отвечает за производство и потребление данных. Мы предоставляем эту часть в виде Lib. Сторона потребителя — это та, которую все используют больше всего. По сравнению с прошлым, сторона потребителя теперь поддерживает два режима извлечения данных: Push и Pull , а поведение потребления данных поддерживает порядок и потребление фильтров. Для режима потребления Pull бизнес может сбросить точное смещение через клиент, чтобы поддержать однократное потребление бизнеса.В то же время потребитель недавно запустил клиент BidConsumer для переключения между кластерами без перезапуска;

Работник зоопарка:Отвечает за часть zk хранения смещения.Эта часть функции была ослаблена до только постоянного хранения смещения.Учитывая следующую функцию копирования нескольких узлов, этот модуль временно зарезервирован.

Возможности TubeMQ

чистый язык реализации Java
Внедрить главный координационный узел: по сравнению с Kafka, использующей Zookeeper для полного управления метаданными и обеспечения гарантии высокой доступности, система TubeMQ использует самоуправляемый механизм арбитража метаданных.Главный узел использует встроенную базу данных BDB для завершения хранения и обновления метаданных в кластере. как функция HA, она отвечает за контроль работы и управление конфигурацией кластера TubeMQ, а также предоставляет внешние интерфейсы и т. д. Через главный узел настройки конфигурации брокера, изменения и запросы в кластере TubeMQ обеспечивают полное автоматическое закрытие -управление циклом, снижающее сложность обслуживания системы.
Балансировка нагрузки потребителей на стороне сервера: TubeMQ использует схему балансировки нагрузки на стороне службы вместо работы на стороне клиента, что улучшает возможности управления и контроля системы и упрощает реализацию клиента, упрощая обновление алгоритма балансировки.
Системные операции блокировки на уровне строки: Используйте блокировки уровня строки для одновременной операции со промежуточными состояниями в брокере, и пишите, чтобы избежать проблем дублирования
Регулировка управления компенсацией: Offset управляется каждым брокером самостоятельно, а ZK используется только для постоянного хранения данных (изначально считалось, что он полностью убирает зависимости ZK, и будет временно зарезервирован с учетом последующего расширения функционала)
Улучшение механизма чтения сообщений: TubeMQ принимает режим случайного чтения сообщений, и в то же время, чтобы уменьшить задержку сообщения, добавляется чтение и запись кеша памяти.Для машин с устройствами SSD добавлена обработка переноса задержки сообщения на потребление SSD решить проблему снижения пропускной способности при серьезной задержке потребления. Небольшая емкость SSD-диска и ограниченное количество обновлений диска позволяют удовлетворить потребности бизнеса в быстром производстве и потреблении.
контроль потребительского поведения: Поддерживает динамическое управление поведением потребителей при доступе к системе в режиме реального времени с помощью политик, включая текущее ограничение, приостановку потребления и динамическую настройку частоты получения данных для определенных служб при высокой нагрузке на систему;
Управление уровнем обслуживания и контроль: Для эксплуатации и обслуживания системы, эксплуатационных характеристик, различных потребностей состояния загрузки машины, эксплуатации и обслуживания системы для поддержки динамического управления различными потребителями с помощью политики поведения потребителей, например, существуют ли права потребителей, классификация потребителей для обеспечения задержки , ограничение контроля потребления и получение данных контроля частоты
Контроль безопасности системы: В соответствии с различными потребностями бизнеса в обслуживании данных и соображениями безопасности эксплуатации и обслуживания системы, система TubeMQ добавляет конвейер шифрования транспортного уровня TLS, аутентификацию и авторизацию производственных и потребительских служб, а также управление токенами доступа для распределенного контроля доступа для удовлетворения бизнес-потребности и требования к эксплуатации и обслуживанию системы с точки зрения безопасности системы
Улучшенное использование ресурсов: По сравнению с Kafka, TubeMQ использует режим мультиплексирования соединений, чтобы уменьшить потребление ресурсов соединения; благодаря структуре логических разделов количество файловых дескрипторов, занимаемых системой, уменьшается, а режим фильтрации на стороне сервера используется для уменьшения использования ресурсов пропускной способности сети; Используйте, чтобы уменьшить сильные зависимости Zookeeper и ограничения узких мест
Улучшения клиента: Исходя из удобства бизнес-использования, мы упростили клиентскую логику, чтобы сделать ее наименьшим набором функций.Используем статистический алгоритм качества приема на основе ответных сообщений для автоматического удаления плохих узлов Брокера.Попытка соединения избежать блокировки отправки при отправка больших объемов данных

Сравнение TUBEMQ

TODO

2.8 DDMQ

DDMQ — это продукт очереди сообщений, созданный архитектурным отделом Didi Chuxing на основе Apache RocketMQ.

Структура DDMQ

Поскольку он разработан в Китае, документов еще много.Структура похожа на RocketMQ.Вы можете напрямую читать документы @www.oschina.net/p/ddmq

2.9 IBM MQ

Функция:

Вы можете использовать IBM® MQ, чтобы приложения могли обмениваться данными в разное время и во многих различных вычислительных средах.

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

Функции

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

PS: IBM MQ только упоминается в проекте на данном этапе, но на самом деле понимание его не очень глубокое, так что оставим здесь дырочку, можно посмотреть деталиОфициальный сайт IBM, они идеальны

3. Резюме

Каждая структура будет иметь свои собственные компромиссы.Например, ZeroMQ быстр, но теряет определенную степень целостности и требует подходящего выбора.

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

благодарный

@ Талант /user/322782…

@ www.ibm.com/

@ ракета в настоящее время.apache.org/docs/model Iva…

@ www.oschina.net/p/ddmq