Эта статья сначала приводит к тому, какие проблемы обычно должен решать промежуточное программное обеспечение сообщений, с какими трудностями столкнутся при их решении, можно ли решить Apache RocketMQ как высокопроизводительное распределённое промежуточное программное обеспечение с открытым исходным кодом от Alibaba и как эти проблемы определены в спецификации. В этой статье будет представлена архитектура RocketMQ, чтобы дать читателям быстрое понимание RocketMQ.
1. Какие проблемы должен решать промежуточное ПО сообщений? Publish/Subscribe — самая базовая функция промежуточного программного обеспечения сообщений, а также относительна к традиционной коммуникации RPC. Я не буду вдаваться в подробности.
Приоритет, описанный в спецификации приоритета сообщения, относится к очереди сообщений, каждое сообщение имеет свой приоритет, обычно описываемый целыми числами; сообщение с высоким приоритетом доставляется первым, если сообщение полностью находится в очереди памяти, его можно отсортировать по приоритету до доставки, чтобы высокий приоритет был доставлен первым.
Поскольку все сообщения в RocketMQ сохраняются, если они отсортированы по приоритету, накладные расходы будут очень большими, поэтому RocketMQ не поддерживает приоритет сообщений специально, но может реализовать аналогичные функции в обходном пути, то есть настроить очередь с высоким приоритетом и очередь с обычным приоритетом и отправлять разные приоритеты в разные очереди.
Для приоритетных вопросов их можно разделить на две категории:
- Пока приоритет достигнут, он не является приоритетом в строгом смысле и обычно делится на высокие, средние, низкие или несколько дополнительных уровней. Каждый приоритет может быть представлен отдельной темой, а при отправке сообщения указывать разные темы, которые представляют приоритет, что может решить большинство приоритетных задач, но снижает точность бизнес-приоритетов.
- Строгий приоритет, приоритет выражается целым числом, например 0 ~ 65535; такой приоритет обычно не подходит для решения с разными темами. Если вы хотите, чтобы MQ решил эту проблему, это сильно повлияет на производительность MQ. Вот момент, чтобы убедиться, что бизнесу действительно нужна строгая приоритизация, и если приоритеты сжаты в немного, насколько это повлияет на бизнес?
Порядок сообщения относится к типу сообщения, который может быть использован в порядке отправки. Например, заказ генерирует 3 сообщения: создание заказа, оплата заказа и завершение заказа. При употреблении полезно употреблять в таком порядке. Но при этом заказы могут использоваться параллельно.
RocketMQ может строго следить за упорядочённостью сообщений.
Фильтр сообщенийБрокер Фильтрация сообщений
В Broker фильтрация по требованиям потребителя имеет преимущество в снижении передачи ненужных сообщений потребителю.
Недостаток в том, что это увеличивает нагрузку на брокера и относительно сложна в реализации.
1. Taobao Notify поддерживает различные методы фильтрации, включая прямую фильтрацию по типу сообщения и гибкую фильтрацию синтаксических выражений, что может удовлетворить почти самые сложные потребности фильтрации.
2. Taobao RocketMQ поддерживает фильтрацию по простому тегу сообщения, а также заголовку сообщения и телу сообщения.
3. Гибкая фильтрация синтаксических выражений также поддерживается в спецификации уведомлений CORBA.
Фильтрация сообщений со стороны потребителя
Эта фильтрация может быть полностью настроена приложением, но минус в том, что много бесполезных сообщений отправляется потребителю.
Существует несколько распространённых методов сохранения, используемых при сохранении сообщений:
- Сохраняйте в базе данных, например, Mysql.
- Сохраняйте в KV хранилище, такие как levelDB, Berkeley DB и другие системы хранения KV.
- Сохранение в виде файловых записей, таких как Kafka, RocketMQ
- Создайте сохраняющийся образ данных памяти, например, beanstalkd, VisiNotify
- (1), (2) и (3) все три метода сохраняния способны расширять буфер очереди памяти, и (4) являются просто образом памяти, который может восстанавливать данные из предыдущей памяти после завершения и перезапуска брокера.
Спецификации уведомлений JMS и CORBA явно не указывают, как сохраняться, но производительность части сохранения напрямую определяет производительность всего промежуточного программного обеспечения сообщений.
RocketMQ полностью использует кэш памяти файловой системы Linux для повышения производительности.
Существует несколько ситуаций, в которых надёжность сообщения влияет на надёжность сообщения:
- Брокер закрывает сделки в обычном режиме
- Крах брокера
- Сбой ОС
- Машина теряет питание, но источник питания можно восстановить немедленно.
- Машина не включается (возможно, она повреждена ключевыми устройствами, такими как процессор, материнская плата, память и т.д.)
- Повреждение дискового устройства.
(1), (2), (3) и (4) — это ситуации, при которых аппаратные ресурсы можно восстановить мгновенно, и RocketMQ может гарантировать, что сообщения не будут потеряны или немного данных (в зависимости от того, является ли метод прошивки синхронным или асинхронным).
(5) (6) Это единственная точка отказа, которую невозможно восстановить; после её возникновения все сообщения на этой единственной точке теряются. В обоих случаях RocketMQ гарантирует, что 99% сообщений не теряются при асинхронной репликации, но всё равно очень мало сообщений, которые могут быть потеряны. Технология синхронной двойной записи полностью позволяет избежать одиночных точек, что неизбежно влияет на производительность, делая её подходящей для ситуаций с чрезвычайно высокими требованиями к надёжности сообщений, например, для приложений, связанных с Money.
RocketMQ поддерживает синхронную двойную запись, начиная с версии 3.0.
Сообщения с низкой задержкой могут достичь потребителя сразу после того, как сообщение доходит до брокера, без накопления сообщений.
RocketMQ использует метод long polling pull, чтобы сообщение было в очень реальном времени, а оно в реальном времени не ниже push.
Хотя бы один раз означает, что каждое сообщение должно быть доставлено один раз.
RocketMQ Consumer сначала отправляет сообщение в локальную зону, а затем возвращает ACK на сервер после завершения потребления.
Ровно один раз- Этап отправки сообщений не позволяет отправлять дублирующиеся сообщения.
- На этапе Consume Message дублирующиеся сообщения не разрешаются использовать.
Только при выполнении двух вышеуказанных условий сообщение можно считать «Ровно один раз», и для достижения этих двух пунктов неизбежно возникнут огромные накладные расходы в распределённой системной среде. Поэтому для достижения высокой производительности RocketMQ не гарантирует эту функцию и требует дедупликации в бизнесе, что означает, что потребительские сообщения должны быть идемпотентными. Хотя RocketMQ не может строго гарантировать отсутствие дублирования, в обычных условиях редко происходит повторяющаяся отправка и потребление, только сетевые аномалии, потребительский старт и остановка, а также другие аномальные ситуации, такие как дублирование сообщений.
Основная причина этой проблемы — наличие неопределённости в сетевых вызовах, то есть третье состояние — отсутствие успеха и неудачи, поэтому возникает проблема повторения сообщений.
Что делать, если Broker's Buffer заполнен? Буфер брокера обычно относится к размеру буфера памяти в очереди в брокере, который обычно ограничен по размеру, что если буфер заполнен?
Вот как это реализовано в спецификации уведомлений CORBA:
- RejectNewEvents отклоняет новое сообщение и возвращает код ошибки RejectNewEvents производителю.
- Отбрасывайте существующие сообщения в соответствии с определённой политикой
- AnyOrder — любое событие может быть отброшено при переполнении. Это настройка по умолчанию для этого свойства.
- FifoOrder — Первое полученное событие будет первым отброшенным.
- LifoOrder — последнее полученное событие будет первым отброшенным.
- PriorityOrder — События следует отбрасывать в порядке приоритета, чтобы события с меньшим приоритетом были отброшены раньше событий с более высоким приоритетом.
- DeadlineOrder — события должны сначала отклоняться в порядке самого короткого срока действия.
В RocketMQ нет концепции буфера памяти, а очереди RocketMQ являются постоянными дисками, и данные регулярно очищаются.
Для решения этой проблемы RocketMQ имеет очень существенное отличие от других MQ: буфер памяти RocketMQ абстрагируется в бесконечную очередь, независимо от количества данных, его можно установить, эта бесконечность основана, брокер регулярно удаляет просроченные данные, например, брокер сохраняет сообщения только 3 дня, а длина этого буфера бесконечна, данные трёхдневной давности удаляются из конца очереди.
Ретроспективное потребление — это сообщение, которое потребитель успешно воспринял, и это сообщение необходимо повторно потреблять из-за спроса бизнеса. Например, из-за отказа потребительской системы данные за час назад необходимо повторно потреблять после восстановления, после чего брокер должен предоставить механизм для возврата прогресса потребления в зависимости от временного измерения.
RocketMQ поддерживает ретроспективное потребление по времени, с временной точностью до миллисекунд, которое можно откатить вперёд или назад.
Основная функция промежуточного программного обеспечения для стекирования сообщений — асинхронное разделение, а ещё одна важная функция — блокировка пика потока данных на фронтенде и обеспечение стабильности бэкенд-системы, что требует, чтобы промежуточное программное обеспечение имело определённую способность стека сообщений, и куча сообщений интегрирует следующие две ситуации:
- Сообщения накапливаются в буферах памяти, и как только они превышают буфер памяти, сообщения могут быть сброшены согласно определённой политике сброса, как описано в спецификации уведомлений CORBA. Он подходит для сервисов, способных терпеть отброс сообщений; в данном случае накопленная ёмкость сообщений в основном зависит от размера буфера памяти, и снижение производительности не будет слишком большим после стека сообщения, поскольку объём данных в памяти ограниченно влияет на возможность доступа к внешнему миру.
- Сообщения накапливаются в постоянных системах хранения, таких как база данных, KV, форма записи файлов. Когда сообщения нельзя попасть в кэш памяти, неизбежно возникает доступ к диску, который генерирует большое количество чтения ввода-вывода, а пропускная способность чтения напрямую определяет возможность доступа к сообщениям после их накопления.
Существует четыре основных пункта для оценки способности накопления сообщений:
- Сколько сообщений можно накопить, сколько байт? То есть огромная ёмкость сообщения.
- После того как сообщение накопилось, влияет ли его пропускная способность из-за накопления?
- Повлияет ли нормальное потребление потребителей после того, как сообщение накопится?
- После того как сообщения накопились, какова пропускная способность при доступе к сообщениям, накопленным на диске?
Распределённые транзакции Несколько известных распределённых спецификаций транзакций, таких как XA, JTA и др. Среди них спецификация XA широко поддерживается крупными производителями баз данных, такими как Oracle, MySQL и другими. Среди них лидер по внедрению TM от XA, такой как Oracle Tuxedo, широко используется в финансах, телекоммуникациях и других сферах.
Распределённые транзакции включают двухэтапные задачи фиксации, и с точки зрения хранения данных необходимо поддерживать KV-хранение, поскольку второй этап отката коммита требует изменения состояния сообщения, что включает действие поиска сообщения по ключу. RocketMQ обходит проблему поиска сообщения по ключу на второй ступени, используя первую ступень для отправки подготовленного сообщения, получение смещения сообщения, а вторую ступень для доступа к нему через смещение и модификацию состояния; смещение — это адрес данных.
Метод реализации транзакций в RocketMQ осуществляется не через KV-хранилище, а через метод смещения, у которого есть серьёзный недостаток: изменение данных через смещение приводит к слишком большому числу грязных страниц в системе, что требует особого внимания.
Запланированные сообщения Запланированные сообщения означают, что сообщения не могут быть использованы потребителями сразу после отправки брокеру и могут использоваться только в определённый момент времени или после ожидания определённого времени.
Если вы хотите поддерживать произвольную точность по времени, на уровне брокера нужно заниматься сортировкой сообщений, а если требуется постоянство, то сортировка сообщений неизбежно повлечёт за собой огромные нагрузки на производительность.
RocketMQ поддерживает временные сообщения, но не поддерживает произвольную точность времени и поддерживает определённые уровни, такие как таймингинг 5с, 10с, 1м и т.д.
Повторная попытка сообщения После того как пользователь не сможет поглотить сообщение, создайте механизм повторной попытки, чтобы сообщение воспользовалось снова. Ошибки потребительских сообщений обычно рассматриваются в следующих ситуациях:
- Из-за причин самого сообщения, например, сбоя десериализации, сами данные сообщения не могут быть обработаны (например, пополнение телефонного счета, номер мобильного телефона текущего сообщения уведомлен, нельзя пополнить) и т.д. Эта ошибка обычно требует пропуска этого сообщения и использования других, и это неудачное сообщение оказывается на 99% неудачным, даже если потребление повторяется сразу, поэтому лучше всего использовать механизм повторной попытки с ограничением времени, то есть повторную попытку через 10 секунд.
- Поскольку зависимые сервисы приложений недоступны, например, подключение к базе данных недоступно, недоступна внешняя системная сеть и т.д. При возникновении этой ошибки, даже если текущее неудачное сообщение пропущено, будут использованы и другие сообщения. В этом случае рекомендуется применить режим «сон 30» и «потреблять» следующее сообщение, что снижает давление на брокера при повторной попытке.
Обзор RocketMQ. Давайте узнаем, решает ли RocketMQ проблемы, с которыми сталкивается упомянутое выше промежуточное ПО.
Что такое RocketMQ?
Приведённая выше рисунок является типичной моделью промежуточного программного обеспечения для отправки и получения сообщений, RocketMQ также разработан таким образом, короче говоря, RocketMQ обладает следующими характеристиками:
- Это промежуточное программное обеспечение с моделью сообщений в очереди с высокой производительностью, высокой надёжностью, высоким уровнем реального времени и распределёнными характеристиками.
- Производитель, Потребитель и Очередь могут быть распределены.
- Producer последовательно отправляет сообщения в некоторые очереди, коллекция очередей называется Topic, потребитель. Если распространённое потребление, один потребительский экземпляр поглощает все очереди, соответствующие этой теме, а если кластерное потребление, несколько потребительских экземпляров равномерно потребляют коллекцию очередей, соответствующую этой теме.
- Гарантирован строгий порядок сообщений
- Обеспечивает режимы богатого отбора сообщений
- Эффективное горизонтальное масштабирование абонентов
- Механизм подписки на сообщения в реальном времени
- Сотни миллионов сообщений по накоплению
- Меньшая зависимость
Структура физического развертывания RocketMQ
Как показано на рисунке выше, структура развертывания RocketMQ обладает следующими характеристиками:
- Сервер имён — это практически бессостоянный узел, который может быть развернут в кластерах без какой-либо синхронизации информации между узлами.
- Развертывание Broker относительно сложно: Broker делится на Master и Slave, Master может соответствовать нескольким Slave, но Slave может соответствовать только одному Мастеру; соответствие между Мастером и Слейвом определяется указанием одного и того же BrokerName, разного BrokerId, BrokerId равен 0 для Мастера, а не-0 означает Слейв. Магистерские программы также могут использоваться в нескольких вариантах. Каждый брокер устанавливает длинное соединение со всеми узлами кластера сервера имён и регулярно регистрирует информацию о теме для всех серверов имён.
- Производитель устанавливает длинное соединение с одним из узлов кластера сервера имён (случайным образом), периодически получает информацию о маршрутизации темы от сервера имён, устанавливает длинное соединение с мастером, предоставляющим сервис темы, и регулярно отправляет сердечные удары мастеру. Producer полностью бессостоятелен и может быть развернут в кластерах.
- Потребитель устанавливает длинное соединение с одним из узлов кластера сервера имён (случайным образом), регулярно получает информацию о маршрутизации темы от сервера имён, устанавливает длинное соединение с мастером и подчинённым, предоставляющими сервис темы, и регулярно отправляет сердечные сигналы Мастеру и Слейву. Потребители могут подписываться на сообщения как от Мастера, так и от Слейва, а правила подписки определяются конфигурацией Брокера.
Логическая структура развертывания RocketMQ
Как показано на рисунке выше, логическая структура развертывания RocketMQ имеет две характеристики: производитель и потребитель.
Используемая для представления приложения для обмена сообщениями, группа Producer содержит несколько экземпляров Producer, которые могут быть несколькими машинами, несколькими процессами одной машины или несколькими объектами Producer процесса. Группа продюсеров может отправлять несколько сообщений по теме, и группа производителей функционирует следующим образом:
- Определить тип Продюсера
- Вы можете запросить, что в этом приложении для обмена сообщениями есть несколько экземпляров Producer через инструмент O&M
- При отправке распределённого сообщения о транзакции, если производитель неожиданно выходит из строя, брокер активно перезвонит на любую машину из группы производителей для подтверждения статуса транзакции.
Используемая для представления потребительского приложения для обмена сообщениями, потребительская группа содержит несколько потребительских экземпляров, которые могут быть несколькими машинами, несколькими процессами или несколькими потребительскими объектами процесса. Несколько потребителей в потребительской группе потребляют сообщения равномерно распределённо, и если они настроены на вещание, каждый экземпляр в этой группе потребляет полный объём данных.
Структура хранения данных RocketMQ
Как показано на рисунке выше, RocketMQ использует метод хранения, который отделяет данные от индексов. Эффективно снизить потери файловых ресурсов, ресурсов ввода-вывода и памяти. Даже с такими масштабными данными, как Alibaba, сценарии с высокой параллелизмом эффективно снижают сквозную задержку и обеспечивают сильные горизонтальные возможности масштабирования.
|
Опубликовано 28.07.2017 20:26:52
|
|
|
|
Опубликовано 29.07.2017 8:09:37