1. Техническая архитектура

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

1. NameServer：NameServerдаRocketMQОдин из основных компонентов,В основном используется для управления метаданными всей системы обмена сообщениями.,Например, адрес брокера, информация о маршрутизации темы и т. д. NameServer — это узел, практически не имеющий состояния.,Может быть развернут в кластерах,Нет необходимости в синхронизации информации между узлами. Когда брокер запускается,Зарегистрирует свою собственную информацию на NameServer,Включает информацию о маршрутизации для тем и очередей. Производитель и Потребитель установят длинные соединения с NameServer.,И регулярно извлекает информацию о маршрутизации тем с NameServer.
2. Broker：Brokerда Роль ретранслятора сообщений,Отвечает за хранение и пересылку сообщений. Брокер использует режим кластера «главный-подчиненный»,Внедрите хранилище с несколькими копиями и высокую доступность. Каждый узел Broker должен устанавливать долговременные соединения со всеми узлами NameServer.,Для регистрации информации о маршрутизации темы и отправки контрольных сигналов. В режиме «ведущий-подчиненный» брокера,Подчиненный узел будет активно получать сообщения от главного узла.
3. Producer：ProducerОтветственный за создание сообщений,Обычно ответственность за это несет бизнес-система. Производитель будет отправлять сообщения, сгенерированные в системе бизнес-приложений, на сервер Брокера. Производитель устанавливает длинное соединение с любым узлом NameServer.,И регулярно извлекает информацию о маршрутизации тем с NameServer. Использует ли производитель кластер,Зависит от бизнес-системы, в которой он находится.
4. Consumer：ConsumerОтвечает за потребление сообщений,Как правило, за асинхронное потребление отвечает серверная система. Потребитель устанавливает длинное соединение с любым узлом NameServer.,И регулярно извлекает информацию о маршрутизации тем с NameServer.

Архитектура RocketMQ поддерживает горизонтальное расширение, и можно легко добавлять новых производителей и потребителей сообщений, чтобы справиться с возросшей нагрузкой. В то же время RocketMQ также предоставляет богатую модель извлечения сообщений, эффективные возможности горизонтального расширения подписчиков, механизм подписки на сообщения в реальном времени и возможности накопления миллиардов сообщений. Кроме того, RocketMQ также поддерживает клиентские SDK на нескольких языках, таких как Java, C++, Python и т. д., что позволяет разработчикам взаимодействовать с RocketMQ, используя знакомые им языки программирования.

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

В общем, Архитектура RocketMQ в основном разделена на четыре части.,Как показано на рисунке выше:

1. Производитель: роль публикации сообщений, поддержка развертывания распределенного кластера.
2. Потребитель: роль потребления сообщений, поддержка развертывания распределенного кластера. Поддерживает два режима получения сообщений: push и pull.
3. NameServer: управляет прокси-сервером брокера.
4. BrokerServer: ядро ​​RocketMQ, отвечающее за получение и пересылку сообщений.

2. Архитектура развертывания

Особенности развертывания сети RocketMQ:

1. NameServer — это узел, практически не имеющий состояния, который можно развернуть в кластере без какой-либо синхронизации информации между узлами.
2. Развертывание брокера является относительно сложным. Брокер разделен на главного и подчиненного устройства. Один мастер может соответствовать нескольким подчиненным устройствам, но один подчиненный может соответствовать только одному главному устройству. Соответствующие отношения между главным и подчиненным устройствами определяются путем указания одного и того же имени брокера и разных идентификаторов брокера. BrokerId — 0, указывает на ведущего, значение, отличное от 0, указывает на ведомое. Мастер также может развернуть несколько. Каждый брокер устанавливает длинные соединения со всеми узлами кластера NameServer и регулярно регистрирует информацию о теме на всех серверах NameServer.
3. Производитель устанавливает длинное соединение с одним из узлов (случайно выбранных) в кластере NameServer, регулярно получает информацию о маршрутизации Topic от NameServer, устанавливает длинное соединение с Master, который предоставляет услуги Topic, и регулярно отправляет контрольные сигналы Master. Производитель полностью не сохраняет состояние и может быть развернут в кластерах.
4. Потребитель устанавливает длительное соединение с одним из узлов (случайно выбранных) в кластере NameServer, регулярно получает информацию о маршрутизации темы от NameServer, устанавливает длительное соединение с главным и подчиненным устройствами, которые предоставляют услуги темы, и регулярно отправляет контрольные сигналы главному устройству. и Раб. Потребители могут подписаться на сообщения от главного или подчиненного устройства.
5. В сочетании со схемой архитектуры развертывания рабочий процесс кластера можно описать следующим образом:

• Запустите NameServer, подождите, пока брокер, производитель и потребитель подключатся через порт прослушивания, который эквивалентен центру управления маршрутизацией.
• Брокер запускается, поддерживает длительные соединения со всеми серверами имен и регулярно отправляет пакеты Heartbeat. Пакет Heartbeat содержит текущую информацию о брокере (IP + порт и т. д.) и всю информацию о теме. После успешной регистрации между темой и брокером в кластере NameServer возникнет связь сопоставления.
• Прежде чем отправлять и получать сообщения, создайте тему. При создании темы вам необходимо указать, на каком брокере будет храниться тема. Вы также можете создать тему автоматически при отправке сообщения.
• Производитель отправляет сообщение. При запуске он сначала устанавливает длинное соединение с одним из кластеров NameServer и получает от NameServer, на каком брокере находится отправленная в данный момент тема, включая список всех очередей в теме, затем выбирает очередь и устанавливает его с брокером, где находится очередь. Затем длинное соединение отправляет сообщение брокеру.
• Потребитель аналогичен производителю. Он устанавливает длинное соединение с одним из серверов имен, определяет, на каких брокерах существует текущая тема подписки, а затем напрямую устанавливает канал соединения с брокером, чтобы начать получать сообщения.

Я участвую в последнем конкурсе эссе для специального учебного лагеря Tencent Technology Creation 2024. Приходите и разделите со мной приз!