Графический процесс отправки и хранения сообщений RocketMQ

RocketMQ

Базовые концепты

Общая структура

  • Продюсер: Продюсер
  • Потребитель: потребитель
  • Брокер: отвечает за хранение, доставку и запросы сообщений.
  • NameServer: Реестр маршрутизации. Функции включают в себя: управление брокером, управление маршрутной информацией.

Поток данных между модулями

Производство - модель потребления

процесс отправки сообщения

  • Когда Broker запустится, зарегистрируйте информацию в NameServer
  • Когда клиент вызывает производителя для отправки сообщения, он сначала получает информацию о маршрутизации темы от NameServer. Код заголовка сообщения: GET_ROUTEINFO_BY_TOPIC.
  • Информация о маршрутизации, возвращаемая NameServer, включая список очередей и брокеров, содержащихся в теме.
  • Согласно стратегии запроса, сторона Producer выбирает одну из очередей для последующего хранения сообщений
  • Каждое сообщение генерирует уникальный идентификатор, который добавляется к свойствам сообщения. Ключ атрибута — UNIQ_KEY.
  • Сообщение для специальной обработки, например: сообщение будет сжато более чем на 4M.
  • Производитель отправляет брокеру запрос rpc, чтобы сохранить сообщение для брокера. Код заголовка сообщения SEND_MESSAGE или SEND_MESSAGE_V2 (в конфигурационном файле устанавливается специальный флаг)

процесс хранения сообщений

  • После того, как посредник получает сообщение, он сохраняет информацию об исходном сообщении в MappedFile, соответствующем файлу CommitLog, а затем асинхронно обновляет ее на диск.
  • Поток ReputMessageServie асинхронно сохраняет сообщения в MappedFile в CommitLog в ConsumerQueue и IndexFile.
  • ConsumerQueue и IndexFile — это просто индексная информация исходного файла.

структура тела сообщения

  • Длина тела сообщения CommitLog различна, каждый файл CommitLog по умолчанию равен 1G.
  • Длина тела сообщения в ConsumerQueue фиксированная, 20 байт.

процесс отображения памяти

  • Отображенный в память файл MappedFile создается AllocateMappedFileService.
  • Создание MappedFile — типичная модель производитель-потребитель.
  • Когда MappedFileQueue вызывает getLastMappedFile для получения MappedFile, поместите запрос в очередь
  • Поток AllocateMappedFileService продолжает отслеживать очередь и создает объект MappedFile, когда в очереди есть запрос.
  • Наконец, объект MappedFile разогревается, и на нижнем уровне вызываются методы force и mlock.

Процесс чистки

  • Сообщения, отправляемые производителем брокеру, сохраняются в MappedFile, а затем синхронизируются на диск через механизм очистки диска.
  • Чистка делится на синхронную чистку и асинхронную чистку.
  • Асинхронные фоновые потоки очистки выполняются через определенные промежутки времени.
  • Синхронная дисковая щетка также является моделью производитель-потребитель. После сохранения брокера сообщений в MappedFile создайте запрос GroupCommitRequest в списке и заблокируйте ожидание. Фоновая нить берется из списка запросов и обновляется на диске, успех кисти в нерабочее время уведомляет ожидающую нить.