предисловие
Я разобрал некоторые блок-схемы/схемы, связанные с RocketMQ, сделал заметки и давайте учиться вместе.
Что такое RocketMQ
- Это промежуточное программное обеспечение сообщений модели очереди с высокой производительностью, высокой надежностью, высокими характеристиками реального времени и распределенными характеристиками.
- Производитель, Потребитель и Очередь могут быть распределены.
- Источник отправляет сообщения в несколько очередей по очереди. Коллекция очередей называется Тема. Если Потребитель осуществляет широковещательное потребление, потребитель Экземпляр потребляет все очереди, соответствующие этой теме. Если используется кластерное потребление, несколько экземпляров Consumer будут в среднем использовать набор очередей, соответствующий этой теме.
- Возможность гарантировать строгий порядок сообщений
- Обеспечивает расширенный режим извлечения сообщений
- Эффективная горизонтальная масштабируемость абонента
- Механизм подписки на сообщения в реальном времени
- Возможность накопления сообщений на уровне миллиардов
- менее зависимый
Диаграмма основных компонентов RocketMQ
RocketMQ — это промежуточное программное обеспечение для сообщений с открытым исходным кодом, которое в основном состоит из NameServer, Producer, Broker и Consumer.
NameServer
NameServer в основном отвечает за управление темами и информацией о маршрутизации, и его функции аналогичны zookeeper Dubbo.
Producer
Производитель сообщений отвечает за генерацию сообщений.Как правило, бизнес-система отвечает за генерацию сообщений.
Broker
Роль ретранслятора сообщений отвечает за хранение и пересылку сообщений.
Consumer
Потребитель сообщений отвечает за потребление сообщений, как правило, фоновая система отвечает за асинхронное потребление.
Схема физического развертывания RokcetMQ
NameServer
NameServer — это почти не сохраняющий состояние узел, который можно развернуть в кластерах без какой-либо синхронизации информации между узлами.
Broker
Брокеры делятся на Master и Slave. Один Master может соответствовать нескольким Slave, но один Slave может соответствовать только одному Master. Соответствующая связь между Master и Slave определяется путем указания одного и того же BrokerName и разных BrokerId. BrokerId равен 0 для Master , а не 0 Указывает на ведомое устройство. Мастер также может развернуть несколько. Каждый брокер устанавливает долгосрочные соединения со всеми узлами в кластере серверов имен и регулярно регистрирует информацию о теме на всех серверах имен.
Producer
Источник устанавливает постоянное соединение с одним из узлов (выбранных случайным образом) в кластере серверов имен, периодически получает информацию о маршрутизации темы от сервера имен, устанавливает постоянное соединение с мастером, предоставляющим службу темы, и регулярно отправляет пульс на мастер. Producer полностью не имеет состояния и может быть развернут в кластерах.
Consumer
Потребитель устанавливает постоянное соединение с одним из узлов (выбранным случайным образом) в кластере серверов имен, периодически получает информацию о маршрутизации темы от сервера имен, устанавливает постоянные соединения с главным и подчиненным, которые предоставляют службы темы, и регулярно отправляет тактовые импульсы на сервер имен. Мастер и Раб. Потребители могут подписываться на сообщения либо от ведущего, либо от ведомого.Правила подписки определяются конфигурацией брокера.
Логическая структура развертывания RocketMQ
Producer Group
Группа производителей, используемая для представления приложения для отправки сообщений, содержит несколько экземпляров производителей, которые могут быть несколькими компьютерами или Несколько процессов машины или несколько объектов Producer процесса. Группа продюсеров может отправлять несколько тем Сообщение, группа продюсеров работает следующим образом:
- Идентифицирует класс производителя
- Вы можете использовать инструмент эксплуатации и обслуживания, чтобы запросить наличие нескольких экземпляров Producer в этом приложении для отправки сообщений.
- При отправке сообщения о распределенной транзакции, если производитель неожиданно выйдет из строя посередине, брокер будет активно перезванивать любому Машина для подтверждения статуса транзакции.
Consumer Group
Группа потребителей, используемая для представления приложения сообщений потребителя, содержит несколько экземпляров получателя, которые могут быть несколькими машинами или Таким образом, несколько процессов или несколько объектов Consumer для процесса. Несколько потребителей в группе потребителей распределены равномерно Если он установлен в широковещательный режим, то каждый экземпляр в этой группе потребителей потребляет весь объем данных.
Механизм регистрации и удаления маршрута NameServer
- Брокер отправляет на сервер имен каждые 30 секунд пакет пульса, и этот пакет пульса содержит информацию о маршрутизации темы.
- NarneServer обновляет информацию в brokerLiveTable после получения пакета пульса брокера, особенно записывая время пульса lastUpdateTime.
- NarneServer сканирует каждые 10 с brokerLiveTable, определяя время получения таблицы, было последним сердцебиением пакетов, сравнивает текущее время и время последнего превышения 120 с, что брокер недоступен для удаления всей информации, связанной с таблицей маршрутизации брокера
- Производитель сообщения вытягивает маршрутную информацию темы, то есть производитель сообщения не сразу воспринимает добавление и удаление сервера-брокера.
Диаграмма модели домена сообщений RocketMQ
Topic
- Тема представляет собой тип сообщений первого уровня.Например, сообщения в системе электронной коммерции можно разделить на: сообщения о транзакциях, сообщения о логистике и т.д. Сообщение должно иметь тему.
- Самая детальная единица подписки, группа может подписаться на сообщения из нескольких тем.
Tag
Тег представляет тип сообщения второго уровня, например, сообщения о транзакциях можно разделить на: сообщения о создании транзакции, сообщения о завершении транзакции и т.д. RocketMQ обеспечивает 2-уровневую классификацию сообщений, удобную и гибкую в управлении.
Group
Группа, группа может подписаться на несколько тем.
Message Queue
Физическая единица управления сообщением. В теме может быть несколько очередей.Введение очередей позволяет распределять и группировать хранение сообщений, а также имеет возможность горизонтального масштабирования.
В RocketMQ все очереди сообщений являются персистентными структурами данных с бесконечной длиной, так называемая бесконечная длина означает, что каждая единица хранения в очереди имеет фиксированную длину, и доступ к единице хранения осуществляется с помощью Offset, а смещение имеет тип java long ., 64 бита, теоретически он не переполнится через 100 лет, поэтому он считается бесконечным по длине.
Также можно считать, что Message Queue — это массив бесконечной длины, а Offset — индекс.
Схема последовательного сообщения
Порядок потребления сообщений должен совпадать с порядком отправки сообщений.В RocketMQ главное - локальный порядок, то есть для того, чтобы тип сообщения удовлетворял порядку, Producer должен быть отправлен в единственном -threaded порядке и отправляются в ту же очередь, чтобы потребитель мог следить за тем, как производитель потребляет сообщения в том порядке, в котором они отправляются.
Схема дизайна хранилища сообщений RocketMQ
CommitLog
Файл хранения сообщений, сообщения всех тем сообщений хранятся в файле CommitLog. Логический вид файлового хранилища Commitlog показан на рисунке
ConsumeQueue
Очередь потребления сообщений.После того как сообщение достигает файла CommitLog, оно будет асинхронно перенаправлено в очередь потребления сообщений для обработки потребителями сообщений. Формат хранения ConsumeQueue следующий:
- Один файл ConsumeQueue по умолчанию содержит 300 000 записей, а длина одного файла составляет 30w × 20 байт.Один файл ConsumeQueue можно рассматривать как массив записей ConsumeQueue, нижний индекс которого является логическим прогресс сохраняется. Смещение является логическим смещением.
- ConsumeQueue — это индексный файл файла Commitlog.Механизм его построения заключается в том, что когда сообщение поступает в файл Commitlog, специальным потоком генерируется задача пересылки сообщения, тем самым создается файл очереди потребления сообщений и упомянутый ниже индексный файл.
IndexFile
Индексный файл сообщения, в котором в основном хранится соответствие между ключом сообщения и смещением.
Очередь потребления сообщений представляет собой индексный файл, специально созданный RocketMQ для подписки на сообщения, что повышает скорость получения сообщений на основе тем и очередей сообщений. Кроме того, RocketMQ вводит механизм индексации Hash для индексирования сообщений. точки: хэш-слот и хеш-конфликтующие структуры связанных списков. Макет индексного файла RocketMQ показан на рисунке.
lndexFile содержит всего lndexHeader, слот Hash, запись Hash
Служба статуса транзакции
Сохраняет состояние транзакции каждого сообщения.
Служба сообщений по времени
Каждый уровень задержки соответствует очереди потребления сообщений, в которой хранится ход извлечения сообщений из очереди задержки.
Уровень модели хранения файлов RMQ
Уровень бизнес-процессора RocketMQ
Запись бизнес-логики для брокера для чтения и записи сообщений. Этот уровень в основном включает операции обработки, связанные с бизнес-логикой (согласно синтаксическому анализу RequestCode в RemotingCommand, чтобы различать определенные типы бизнес-операций, а затем выполнять различные процессы бизнес-обработки), например, предварительно -этапы проверки и проверки, создание объекта MessageExtBrokerInner, декодирование десериализации, создание возвращаемого объекта Response и т. д.
Слой компонента хранилища данных RocketMQ
- Этот уровень в основном представляет собой класс ядра хранилища RocketMQ — DefaultMessageStore, который является записью доступа к файлам данных сообщений RocketMQ.Файлы данных журнала, хранящиеся в сообщениях CommitLog, читаются и записываются с помощью методов «putMessage ()» и «getMessage ()» этого class.Operation (конкретные операции доступа для чтения и записи по-прежнему зависят от методов, предоставляемых объектной моделью CommitLog на следующем уровне);
- Кроме того, при инициализации компонента будет запущено множество потоков фоновых служб, связанных с хранилищем, включая AllocateMappedFileService (поток службы предварительного выделения MappedFile), ReputMessageService (поток службы сообщений воспроизведения хранилища), HAService (высокая доступность синхронизации главного и подчиненного брокера). служебный поток), StoreStatsService (служебный поток статистики хранилища сообщений), IndexService (поток службы индексных файлов) и т. д.
Слой логических объектов хранилища RocketMQ
- Этот уровень в основном включает в себя три класса моделей IndexFile, ConsumerQueue и CommitLog, которые напрямую связаны с хранилищем файлов данных RocketMQ.
- IndexFile предоставляет службы доступа к файлам данных индекса, ConsumerQueue предоставляет службы доступа к логическим очередям сообщений, а CommitLog предоставляет службы доступа к файлам данных журнала, хранящимся в сообщениях.
- Эти три класса моделей также составляют общую структуру уровня хранения RocketMQ.
Слой отображения инкапсулированной файловой памяти
- RocketMQ в основном использует MappedByteBuffer и FileChannel в JDK NIO для чтения и записи файлов данных.
- Среди них метод файла MappedByteBuffer с отображенным в память файлом диска используется для завершения чтения и записи больших файлов, и этот класс инкапсулирован в класс MappedFile в RocketMQ.
- Здесь каждый тип отдельного файла обеспечивается службами операций чтения и записи классом MappedFile (среди них класс MappedFile предоставляет службы, связанные с файлами, такие как последовательная запись/произвольное чтение, очистка данных памяти, очистка памяти и т. д.).
Слой дискового хранилища
В основном относится к диску, используемому для развертывания сервера RocketMQ. Здесь необходимо учитывать влияние различных типов дисков (таких как SSD или обычные жесткие диски) и параметров производительности диска (таких как IOPS, пропускная способность и задержка доступа) на операции последовательной записи/произвольного чтения.
Сброс сообщений в RocketMQ
В RocketMQ сброс сообщений можно в основном разделить на два типа: синхронный сброс и асинхронный сброс.
синхронная щетка
- К тому времени, когда будет возвращен статус успешной записи, сообщение будет записано на диск.
- Конкретный процесс заключается в том, что после того, как сообщение записано в PAGECACHE памяти, он немедленно информирует поток очистки о необходимости очистки диска, а затем ожидает завершения очистки.После выполнения потока очистки он пробуждает ожидание. поток и возвращает статус, что сообщение было успешно написано.
- Обычно используется только в финансовых сценариях.
Асинхронная щетка
Когда возвращается статус успешной записи, сообщение может быть записано только в PAGECACHE памяти.Операция записи возвращается быстро и пропускная способность велика;когда количество сообщений в памяти накапливается до определенного уровня, операция записи в диск срабатывает равномерно для быстрой записи.Схема потока сообщений в системе
1. Производитель отправляет сообщение, и сообщение попадает в кучу java из сокета.
2. Производитель отправляет сообщение, и сообщение передается из кучи java в PAGACACHE, физическую память.
3. Источник отправляет сообщение, которое сбрасывается асинхронным потоком, и сообщение сбрасывается из PAGECACHE на диск.
4. Потребитель тянет сообщение (обычное потребление), и сообщение напрямую передается из PAGECACHE (данные в физической памяти) в сокет, достигая потребителя, Не проходит через кучу java. Этот тип сценария потребления является наиболее распространенным: онлайн-физическая память 96G, согласно сообщениям 1K, может кэшировать 100 миллионов сообщений в физической памяти. интерес.
5. Потребитель извлекает сообщение (аномальное потребление), и сообщение напрямую передается из PAGECACHE (данные в виртуальной памяти) в сокет.
6. Потребитель тянет сообщение (аномальное потребление).Поскольку сокет обращается к виртуальной памяти, происходит прерывание ошибки страницы.В это время будет сгенерирован дисковый ввод-вывод, и диск будет удален с диска. Загрузить сообщение с диска в PAGECACHE, а затем отправить его прямо из сокета.
7. То же самое.
8. То же, что и 6.
Ссылка и спасибо
- Начало работы с RocketMQ за десять минут
- Серия распределенных сообщений: объясните введение и эволюцию RocketMQ, дизайн архитектуры, ключевые функции и сценарии приложений.
- Хранилище сообщений RocketMQ
- «Введение в принципы RocketMQ»
Личный публичный аккаунт
Приглашаем всех обратить внимание, учиться и обсуждать вместе.