Введение | Очередь сообщений является важным промежуточным программным обеспечением в распределенных системах и играет важную роль в системных архитектурах, таких как высокая производительность, высокая доступность и низкая связанность. В этой статье были проведены некоторые исследования компонентов очереди сообщений Kafka, Pulsar, RocketMQ, RabbitMQ и NSQ, а также собрана соответствующая информация, служащая справочной информацией по выбору промежуточного программного обеспечения MQ для бизнеса.

1. Обзор

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

• Разделение разделяет восходящий и нисходящий поток процесса. Восходящий поток фокусируется на создании сообщений, а нисходящий — на обработке сообщений.
• Широковещательная передача: сообщение, созданное восходящим потоком, легко обрабатывается несколькими нисходящими службами.
• буфер,Как справиться с внезапным увеличением трафика,в свою очередь сообщения могут действовать как буфер,Защитите нижестоящие службы, чтобы они могли обрабатывать сообщения на основе фактических возможностей потребления.
• В асинхронном режиме восходящий поток может вернуться сразу после отправки сообщения, а нисходящий поток может обработать сообщение асинхронно.
• Избыточность, сохранение исторических сообщений, повторные попытки или возврат для предотвращения потерь в случае сбоя обработки или возникновения исключения.

В последние годы стали уделять внимание очередь с более высокой степенью Сообщение Выбор промежуточного программного обеспечения,Такие как Kafka, Pulsar, RocketMQ и т. д.,Сначала сделайте что-нибудь с точки зрения макросаконтраст：

в заключение:

• В таких сценариях, как обработка журналов и обработка больших данных, Kafka по-прежнему является лучшим выбором, учитывая его высокую пропускную способность и низкую задержку.
• Для данных бизнес-транзакций существуют такие сценарии, как задержка сообщений, использование режима очереди, удаленное аварийное восстановление, темы с несколькими сообщениями и т. д. Вы можете выбрать TDMQ/Pulsar.
• В других сценариях использования, адаптированных для бизнеса, поскольку стек серверных технологий представляет собой Golang, вы можете рассмотреть возможность использования NSQ для индивидуальной разработки или исследований и обучения.
• Производительность промежуточного программного обеспечения для обмена сообщениями во многом зависит от параметров сервера и клиента, сценариев использования и т. д. Прежде чем система будет подключена к сети, ее необходимо подвергнуть стресс-тестированию и настроить в соответствии с реальными сценариями применения.

2. Введение в архитектуру

(1) Кафка

(Источник: https://zhuanlan.zhihu.com/p/38269875)

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

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

• Регистрация брокера позволяет своевременно обнаруживать сбои брокера.
• Регистрация темы поддерживает узлы-брокеры, где расположены копии каждого раздела темы, а также соответствующие роли лидера/последователя.
• Регистрация потребителей сохраняет смещение группы потребителей и соответствующие отношения между потребителями и разделами для достижения балансировки нагрузки.

(2) Пульсар

(Источник: https://cloud.tencent.com/developer/article/1845616)

Pulsar состоит из трех важных компонентов: Broker, BookKeeper и ZooKeeper. Broker — это служба без сохранения состояния, и клиенту необходимо подключиться к Broker для доставки сообщений. BookKeeper и ZooKeeper — это сервисы с отслеживанием состояния. Узел BookKeeper называется Bookie, который отвечает за хранение сообщений и курсоров. ZooKeeper хранит метаданные Broker и Bookie. Pulsar использует эту архитектуру для разделения хранилища и вычислений. Брокер отвечает за вычисления, а Bookie — за хранилище с отслеживанием состояния.

Многоуровневая архитектура Pulsar влияет на способ хранения данных. Pulsar делит раздел темы на сегменты (сегменты), а затем сохраняет эти фрагменты на узлах хранения Apache BookKeeper для повышения производительности, масштабируемости и доступности. Распределенный журнал Pulsar ориентирован на сегменты, реализован с расширенным хранилищем журналов (через Apache BookKeeper) и имеет встроенную поддержку многоуровневого хранения, поэтому сегменты могут быть равномерно распределены по узлам хранения. Поскольку данные, относящиеся к какой-либо конкретной теме, не привязаны к конкретному узлу хранения, узлы хранения можно легко заменить или масштабировать. Кроме того, самый маленький или самый медленный узел в кластере не будет ограничивать хранилище или пропускную способность.

(3) Рокет МК

(Источник: https://rocketmq.apache.org/docs/rmq-arc/)

RocketMQ — это промежуточное программное обеспечение для обмена сообщениями с открытым исходным кодом от Alibaba.,Это платформа распределенного обмена сообщениями и потоковой передачи данных с открытым исходным кодом.。Всего четыре части：NameServer,Broker,Producer,Consumer。

NameServer в основном используется для управления брокерами и информацией о маршрутизации. Сервер брокера зарегистрируется на NameServer при запуске, и между ними поддерживается механизм мониторинга пульса, чтобы гарантировать, что NameServer знает статус выживания брокера. Более того, каждый NameServer хранит всю информацию о кластере брокера и информацию о запросах клиента производителя/потребителя.

Брокер отвечает за управление хранением и распространением сообщений, синхронизацию данных «главный-подчиненный», индексацию сообщений, а также предоставление запросов сообщений и другие возможности.

(4) КроликMQ

(Источник: https://www.cxymm.net/article/Super_RD/70238869)

RabbitMQ реализован на основе протокола AMQP и в основном состоит из Exchange и Queue, которые затем связываются через RoutingKey. Сообщения доставляются в Exchange, а затем принимаются через Queue.

(5) НСВ

(Источник: https://zhuanlan.zhihu.com/p/37081073)

NSQ в основном состоит из двух частей: nsqlookup и nsqd:

• Nsqlookup — это демон-процесс, отвечающий за управление информацией о топологии и предоставление услуг обнаружения. Клиент получает узел nsqd, где находится указанная тема, путем запроса nsqlookupd. nsqd регистрирует и передает информацию о своей теме и канале в nsqlookup.
• Процесс-демон nsqd, запущенный на сервере, отвечает за получение, постановку в очередь и доставку сообщений клиенту.

2. Ключевые моменты для выбора

Начнем с подведения итогов, а затем проанализируем каждую функцию промежуточного программного обеспечения очереди сообщений одну за другой.

(1) Функция

• двухтактная модель потребления

Клиенты-потребители получают сообщения так же, как Kafka и RocketMQ извлекают сообщения посредством длительного опроса. Pull, RabbitMQ, Pulsar и NSQ используют Push.

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

• очередь задержки

Отложенная доставка сообщений. Когда сообщение создается и доставляется в очередь сообщений, в некоторых бизнес-сценариях не требуется, чтобы потребители получали сообщение немедленно, а ждут определенный период времени, прежде чем потребитель сможет получить сообщение для использования. Очереди задержки обычно делятся на два типа: задержка на основе сообщений и задержка на основе очереди. Задержка на основе сообщений подразумевает установку разного времени задержки для каждого сообщения. Когда новые сообщения попадают в очередь, они сортируются по времени задержки. Конечно, это окажет большее влияние на производительность. Другой вид задержки на основе очереди относится к настройке очередей с разными уровнями задержки. Время задержки каждого сообщения в очереди одинаково, что позволяет избежать потери производительности, вызванной сортировкой на основе времени задержки. сообщение об истечении времени ожидания может быть доставлено.

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

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

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

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

RabbitMQ необходимо установить плагин Rabbitmq_delayed_message_exchange.

NSQ сохраняет задержанные сообщения через приоритетную очередь в памяти, поддерживая точность второго уровня и задержку до 2 часов.

• очередь недоставленных писем

По некоторым причинам сообщение не может быть доставлено правильно. Чтобы гарантировать, что сообщение не будет отклонено без причины, оно обычно помещается в очередь со специальной ролью. Эту очередь обычно называют очередью недоставленных писем. Соответствующим этому является также понятие «очереди отката». Представьте себе, что если во время потребления потребителя возникает исключение, то потребление не будет подтверждено (Ack), и после отката сообщения сообщение всегда будет недоступно. сообщение будет помещено в начало очереди, а затем будет непрерывно обрабатываться и откатываться, в результате чего очередь попадет в бесконечный цикл. Чтобы решить эту проблему, вы можете настроить очередь отката для каждой очереди. И она, и очередь недоставленных сообщений обеспечивают механизм обработки исключений. В реальных ситуациях роль очереди отката могут играть очередь недоставленных писем и очередь повторов.

Kafka не имеет очереди недоставленных писем и записывает смещение текущего потребления через Offset.

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

RocketMQ использует DLQ для записи всех сообщений об ошибках потребления.

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

В NSQ нет очереди недоставленных писем.

• приоритетная очередь

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

Kafka, RocketMQ, Pulsar и NSQ не поддерживают очереди с приоритетом, а приоритет сообщения может быть достигнут с помощью разных очередей.

RabbitMQ поддерживает приоритетные сообщения.

• Отслеживание сообщений

Обычно сообщения обрабатываются после завершения использования, и сообщение больше не может быть использовано. Обратное отслеживание сообщений — это полная противоположность. Это означает, что после того, как сообщение будет использовано, ранее использованное сообщение все еще может быть использовано. Для сообщений распространенной проблемой является «потеря сообщения». Как правило, трудно отследить, действительно ли оно потеряно из-за дефектов в промежуточном программном обеспечении сообщений или из-за неправильного использования пользователем. Если само промежуточное программное обеспечение сообщений имеет функцию обратного отслеживания сообщений, вы можете это сделать. может воспроизвести «потерянные» сообщения путем обратного отслеживания потребления и выяснить источник проблемы. Роль обратного отслеживания сообщений выходит далеко за рамки этого, например, восстановление индекса и реконструкция локального кэша. Некоторые решения для компенсации бизнеса также могут быть реализованы с помощью обратного отслеживания.

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

Pulsar поддерживает возврат сообщений по времени.

RocketMQ поддерживает возврат по времени, а принцип реализации соответствует Kafka.

RabbitMQ не поддерживает обратный поиск, сообщения будут помечены для удаления после пометки для подтверждения.

Общие сообщения NSQ не отслеживаются, но вы можете использовать инструмент nsq_to_file для записи сообщений в файл и последующего воспроизведения сообщений из файла.

• Сохранение сообщений

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

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

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

Сообщения Pulsar хранятся в кластере хранения BookKeeper и также представляют собой файлы на диске.

NSQ записывает сообщения в файлы с помощью инструмента nsq_to_file.

• Механизм подтверждения сообщения

Очереди сообщений необходимо управлять ходом потребления и подтверждать, успешно ли потребитель обработал сообщение. Компонент очереди сообщений, использующий метод push, часто подтверждает одно сообщение. Для неподтвержденных сообщений он выполняет отложенную повторную доставку или попадает в очередь недоставленных сообщений.

Кафка подтверждает сообщение через Offset.

RocketMQ, как и Kafka, также отправляет Offset. Разница в том, что потребители могут помечать сообщения, которые не удалось использовать, как ошибки потребления. Брокер повторит попытку доставки. Если накопится несколько ошибок потребления, они будут доставлены в очередь недоставленных сообщений.

RabbitMQ похож на NSQ. Потребитель подтверждает одно сообщение, в противном случае оно будет помещено обратно в очередь для ожидания следующей доставки.

Pulsar использует специализированное управление курсорами. Кумулятивное подтверждение имеет тот же эффект, что и однократное или выборочное подтверждение Kafka;

• Срок жизни сообщения

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

Kafka удаляет сообщения в соответствии с установленным сроком хранения. Возможно, сообщение не было использовано и было удалено по истечении срока действия. TTL не поддерживается.

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

RocketMQ имеет относительно мало информации о TTL сообщения, но интерфейс, похоже, поддерживает его.

RabbitMQ имеет два метода: один из них — установить его в свойствах очереди при объявлении очереди. Сообщения во всей очереди имеют одинаковый период действия. Вы также можете установить атрибуты сообщения при отправке сообщения и установить разные сроки жизни для каждого сообщения.

Похоже, NSQ еще не поддерживается, и в открытом состоянии возникла проблема с запросом функции.

• Мультитенантная изоляция

Мультитенантность означает возможность обслуживать нескольких арендаторов с помощью одного экземпляра программного обеспечения. Арендатор — это группа пользователей, имеющих одинаковое «вид» системы. В системах, не поддерживающих мультитенантность, часто необходимо создавать несколько экземпляров очереди сообщений для разных пользователей или разных кластеров для достижения физической изоляции, что приведет к высоким затратам на эксплуатацию и обслуживание. Мультитенантные возможности Pulsar как системы обмена сообщениями корпоративного уровня предназначены для удовлетворения следующих потребностей:

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

Pulsar удовлетворяет вышеуказанные потребности следующими способами:

• Получите необходимую вам безопасность с помощью аутентификации, авторизации и ACL (списков контроля доступа) для каждого арендатора.
• Обеспечьте соблюдение квот хранилища для каждого клиента.

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

• последовательность сообщений

Последовательность сообщений означает обеспечение порядка сообщений. Порядок потребления сообщений соответствует порядку создания.

Kafka гарантирует, что сообщения внутри раздела упорядочены.

Pulsar поддерживает два режима потребления: режим потоковой передачи с эксклюзивной подпиской гарантирует только порядок сообщений, а модель очереди с общей подпиской не гарантирует порядок.

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

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

NSQ использует собственный случай/выбор golang для реализации распределения сообщений. Он не обеспечивает гарантий упорядочения, не может сопоставлять характерные сообщения с потребителями и не может обеспечить упорядочивание сообщений.

• Запрос сообщения

В реальной разработке часто необходимо проверять содержимое сообщений в MQ, например, запрашивая конкретные сообщения MQ через определенный MessageKey/ID. Или вы можете отслеживать ссылки на сообщения, чтобы знать, откуда они приходят и куда отправляются, чтобы вы могли быстро устранять неполадки и обнаруживать проблемы.

Уровень хранения Kafka реализован в виде распределенного журнала фиксации, и каждая операция записи последовательно добавляется в конец журнала. Чтение также является последовательным чтением. Функция поиска не поддерживается.

Pulsar может запрашивать содержимое сообщения, параметры сообщения и траекторию конкретного сообщения через идентификатор сообщения.

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

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

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

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

Kafka имеет два режима потребления, которые в конечном итоге гарантируют, что раздел будет использовать только один потребитель:

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

Pulsar имеет следующие четыре режима потребления. Эксклюзивный режим и режим аварийного восстановления аналогичны Kafka. Это потоковые модели. Каждый раздел имеет только один потребительский режим, который может обеспечить упорядоченность сообщений. Режим совместного использования и режим совместного использования ключей представляют собой модели очереди. Несколько потребителей могут увеличить скорость потребления, но не могут гарантировать упорядоченность.

• Эксклюзивный эксклюзивный режим (режим по умолчанию): Подписка может быть связана только с одним Потребителем. Только этот Потребитель может получать все сообщения из Темы. В случае сбоя Потребителя потребление прекратится.
• Режим аварийного восстановления (отработка отказа): при наличии нескольких потребителей они будут отсортированы в словарном порядке, а первый потребитель инициализируется как единственный потребитель, принимающий сообщения. Когда первый потребитель отключится, все сообщения (неподтвержденные и впоследствии входящие) будут переданы следующему потребителю в очереди.
• Общий режим (Shared): сообщения распределяются между разными потребителями посредством механизма циклического опроса (который также можно настроить), и каждое сообщение будет распространяться только одному потребителю. Когда потребитель отключается, все неподтвержденные сообщения, отправленные ему, будут перепланированы и переданы другим выжившим потребителям.
• Режим совместного использования КЛЮЧА (Key_Shared): при наличии нескольких потребителей сообщения будут распределяться в соответствии с ключом. Сообщения с одним и тем же ключом будут распространяться только одному и тому же потребителю.

RocketMQ имеет два режима потребления: широковещательный режим BROADCASTING и режим кластеризации CLUSTERING.

Широковещательное потребление означает: сообщение потребляется несколькими потребителями. Даже если эти потребители принадлежат к одной и той же ConsumerGroup, сообщение будет использовано один раз каждым потребителем в ConsumerGroup. Концепция ConsumerGroup в широковещательном потреблении может считаться бессмысленной с точки зрения широковещательного потребления. разделение сообщений.

Режим потребления кластера: экземпляры потребителей в ConsumerGroup равномерно распределяют потребляемые сообщения. Например, тема имеет 9 сообщений, а одна из ConsumerGroup имеет 3 экземпляра (возможно, 3 процесса или 3 машины), тогда каждый экземпляр потребляет только часть из них, и потребляемые сообщения не могут быть использованы другими экземплярами.

Потребление RabbitMQ и NSQ аналогично режиму совместного использования Pulsar. В форме очереди увеличение количества потребителей в группе потребителей может увеличить скорость потребления.

• надежность сообщения

Потеря сообщений — распространенная проблема, с которой приходится сталкиваться при использовании промежуточного программного обеспечения для сообщений. Помимо этого, надежность сообщений также является ключевым фактором при измерении качества промежуточного программного обеспечения для сообщений. Особенно важна надежность сообщений в сфере финансовых платежей. Например, в случае сбоя службы будут ли потеряны некоторые сообщения, которые были успешно созданы производителем, во время переключения высокой доступности? Синхронная очистка — эффективный способ повышения надежности компонента, и промежуточное программное обеспечение сообщений не является исключением. И Kafka, и RabbitMQ могут поддерживать синхронную очистку, но в большинстве сценариев надежность компонента не должна определяться синхронной очисткой. используя для его обеспечения чрезвычайно ресурсоемкие операции, для его обеспечения используется механизм многократного копирования.

Kafka может установить уровень надежности, настроив параметр request.required.acks, который указывает, сколько копий сообщения должно подтвердить успешный прием, прежде чем оно будет успешно отправлено задачей.

• request.required.acks=-1 (Полное синхронное подтверждение, надежная гарантия надежности)
• request.required.acks=1 (лидер подтверждает получение, по умолчанию)
• request.required.acks=0 (без подтверждения, но высокая пропускная способность)

В Pulsar есть концепция, похожая на Kafka, которая называется Ack Quorum Size (Qa) — это количество букмекеров, которые должны быть подтверждены ответом после отправки каждого запроса на запись. Чем больше значение, тем больше времени требуется для подтверждения этого. запись успешна. Его значение. Верхний предел – количество копий Qw. Для обеспечения единообразия Qa должно быть: (Qw+1)/2 или более, то есть для обеспечения безопасности данных нижний предел Qa равен (Qw+1)/2.

RocketMQ похож на Kafka.

RabbitMQ — это архитектура «главный-подчиненный», которая реализует множественные копии и строгую семантику согласованности посредством зеркальных кольцевых очередей. Несколько копий могут гарантировать, что после аварийного выхода из строя главного узла подчиненный узел может быть повышен до уровня нового главного узла и продолжать предоставлять услуги для обеспечения доступности.

NSQ будет хранить сообщения в локальных файлах с помощью компонента go-diskqueue и контролировать размер очереди в памяти с помощью параметра mem-queue-size. Если mem-queue-size=0, каждое сообщение будет храниться на диске и там. не нужно беспокоиться о перезапуске узла, приводящем к потере сообщений. Однако, поскольку они хранятся на локальном диске, если узел отключится от сети, сообщения, накопленные на диске узла, будут потеряны.

(2) Производительность

Компания Кафки Confluent опубликовала статью «Сравнительный анализ Apache Kafka, Apache Pulsar и RabbitMQ: какой из них самый быстрый?» в августе 2020 года и предложила платформу MQ Benchmark с открытым исходным кодом. сквозная задержка Kafka, Pulsar и RabbitMQ. Наконец, был сделан вывод, что Кафка имеет относительно лучшую производительность.

Но затем StreamNative указал на некоторые проблемы с эталонным тестом Confluence в декабре 2020 года и повторно выполнил результаты после настройки параметров Pulsar. Отчет о тестировании показал, что Pulsar может достичь той же пропускной способности, что и Kafka, а в некоторых случаях в этом сценарии. латентность Пульсара значительно ниже, чем у Кафки.

Более того, при тестировании производительности существует множество влияний на настройки параметров клиента и сервера, конфигурацию производительности машины и т. д., например, уровень надежности сообщения, алгоритм сжатия и т. д. Трудно добиться честного теста с «полным» контролем переменных. . И это также упоминается в Readme на Github с открытым исходным кодом OpenMessaging Benchmark.

Однако есть несколько моментов, вызывающих беспокойство:

• Задержка RabbitMQ находится на уровне микросекунд, а задержка других компонентов находится на уровне миллисекунд. Она должна быть относительно низкой среди компонентов MQ.
• Когда отдельный экземпляр Kafka имеет большое количество тем/разделов, его производительность будет значительно снижена.

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

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

И Pulsar, и Kafka широко используются на различных предприятиях, и каждый из них имеет свои преимущества. Оба могут обрабатывать большой трафик практически с одинаковым количеством оборудования. Некоторые пользователи ошибочно полагают, что Pulsar использует множество компонентов и поэтому требует много серверов для достижения производительности, сравнимой с Kafka. Эта идея применима к некоторым конкретным конфигурациям оборудования, но в большинстве случаев, когда конфигурации ресурсов одинаковы, Pulsar имеет более очевидные преимущества и может достичь большей производительности при тех же ресурсах. Например, компания Splunk недавно поделилась причинами, по которым они выбрали Pulsar вместо Kafka, отметив, что «благодаря многоуровневой архитектуре Pulsar помог им сократить затраты на 30–50 %, задержку на 80–98 % и эксплуатационные расходы на 33 %. -50%». Команда Splunk обнаружила, что Pulsar может лучше использовать дисковый ввод-вывод, снизить загрузку ЦП и лучше управлять памятью.

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

(3) Эксплуатация и техническое обслуживание

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

• Высокая доступность

Kafka решает проблему высокой доступности путем разделения нескольких копий.

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

RocketMQ и RabbitMQ представляют собой архитектуры «главный-подчиненный». Когда главный узел умирает, исходный подчиненный узел продолжает предоставлять услуги. Резервный компьютер предоставляет услуги потребления, гарантирующие, что сообщения не будут потеряны, но не предоставляет услуги записи.

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

• Межрегиональное аварийное восстановление

Pulsar изначально поддерживает межрегиональное аварийное восстановление. На этом рисунке всякий раз, когда производители P1, P2 и P3 отправляют сообщения в темы T1 в кластере A, кластере B и кластере C соответственно, эти сообщения быстро реплицируются. разные кластеры. Как только сообщение будет реплицировано, потребители C1 и C2 будут использовать сообщение из своих соответствующих кластеров.

Благодаря поддержке этой межрегиональной схемы аварийного восстановления, во-первых, мы можем легко распределять услуги по нескольким компьютерным залам, во-вторых, мы можем реагировать на сбои на уровне компьютерного зала, то есть, когда один компьютерный зал недоступен, услуги можно перенести; Принять другие компьютерные залы, чтобы продолжать предоставлять услуги внешнему миру.

В одном предложении межрегиональная репликация Pulsar фактически означает создание источника в локальном кластере, использование удаленного кластера в качестве адреса отправки источника, отправку туда сообщений из локального кластера и поддержку Cusor локально для обеспечения надежности сообщений. и идемпотентность.

• Расширение кластера

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

Поскольку разделы тем кластера Kafka физически хранятся на узле Broker, вновь добавленные узлы кластера не имеют сегментов разделов хранения, поэтому они не могут предоставлять услуги немедленно. Поэтому некоторые разделы тем необходимо выделить вновь добавленным узлам. , который будет включать в себя процесс балансировки данных разделов, копирование данных определенных разделов на новые узлы. Этот процесс связан с объемом данных, накопленных в данный момент в разделе, и производительностью брокера. Может случиться так, что нагрузка на исходный брокер слишком велика, а накопленные данные слишком велики, что приведет к увеличению времени балансировки данных.

Бесконечный распределенный журнал Pulsar ориентирован на сегменты, реализован с расширенным хранилищем журналов (через Apache BookKeeper) и имеет встроенную поддержку многоуровневого хранения, поэтому сегменты могут быть равномерно распределены по узлам хранения. Поскольку данные, относящиеся к какой-либо конкретной теме, не привязаны к конкретному узлу хранения, узлы хранения можно легко заменить или масштабировать в большую или меньшую сторону. Кроме того, самый маленький или самый медленный узел в кластере не будет ограничивать хранилище или пропускную способность.

Новые узлы RocketMQ добавляются непосредственно в кластер, создают новые темы в новом брокере и распределяют очереди или распределяют очереди на основе существующих тем. Разница с Kafka в том, что разделы Kafka находятся на разных физических машинах, а Rocketmq является логическим разделом и использует очередь, поэтому дисбаланса данных нет.

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

• стоимость использования

Kafka/Pulsar/RocketMQ/RabbitMQ — это стандартные продукты, запущенные в Tencent Cloud. Вы можете напрямую приобретать и создавать экземпляры, что может значительно снизить затраты на развертывание и эксплуатацию. NSQ еще не подключен к сети, и его необходимо развернуть самостоятельно.

CKafka продается в виде экземпляров на Tencent Cloud. Профессиональная версия имеет минимальную конфигурацию 1494 юаней в месяц, твердотельный накопитель 500 ГБ, 40 МБ/с. Тарификация TDMQ Pulsar зависит от количества вызовов/размера сообщения/хранилища в аналогичном хранилище. без обслуживания. Оплата зависит от размера и т. д., а количество звонков составляет 2,00 юаня/миллион раз. В случае небольшого использования, например, в некоторых небольших и быстрых онлайн-бизнесах, стоимость TDMQ Pulsar будет намного ниже, чем CKafka.

RocketMQ и RabbitMQ — недавно выпущенные продукты. Они все еще находятся на стадии публичного бета-тестирования и пока не имеют цен.

3. Резюме

Kafka и Pulsar являются основными промежуточными программами для очереди сообщений Tencent Cloud. Оба обладают высокой производительностью, высокой надежностью и поддерживают множество сценариев. Kafka был запущен раньше и имеет относительно зрелые решения для различных сценариев, таких как ведение журналов и обработка больших данных. Будучи новичком, Pulsar поддерживает больше функций, чем CKafka, и имеет межрегиональное аварийное восстановление, мультитенантность и другие функции, что решает многие недостатки дизайна Kafka, а также проблемы с затратами на эксплуатацию и обслуживание, а также повышает общую стабильность. Многие крупные отечественные и зарубежные компании также имеют множество практических примеров использования Pulsar. Поэтому для некоторых традиционных сценариев ведения журналов, обработки больших данных и других сценариев, требующих высокой пропускной способности и низкой надежности сообщений, вы можете выбрать Kafka. Существует множество отличных документов, объясняющих, как настраивать параметры для повышения производительности. В некоторых сценариях, которые требуют большей надежности сообщений и аварийного восстановления или имеют высокую степень секционирования, очереди с задержкой и т. д., вы можете выбрать Pulsar.

Наш стек серверных технологий основан на Golang. В приведенном выше сравнении мы также выбрали NSQ, очередь сообщений, разработанную на основе Golang. Если у вас есть какие-то индивидуальные потребности или вам нужна дополнительная разработка, вы можете выбрать NSQ. Вы также можете прочитать исходный код NSQ, чтобы узнать, как реализовать превосходное высокопроизводительное промежуточное программное обеспечение очереди сообщений, такое как компонент diskqueue, дисковую очередь сообщений, которую можно повторно использовать в некоторых сценариях.

Ссылки:

1.Kafka vs. Pulsar vs. RabbitMQ: Performance, Architecture, and Features Compared

2. Анализ выбора промежуточного программного обеспечения сообщений: посмотрите на общую ситуацию из сравнения Kafka и RabbitMQ.

3.TTL RabbitMQ (период действия сообщения) и DLX (обмен/очередь недоставленных писем) 4. Анализ задержки доставки сообщений Apache Pulsar 5. Глубокое понимание задержанных сообщений RocketMQ. 6. Поймите сходства и различия между RocketMQ и Kafka за три минуты.

7. Решение приоритетной очереди GeTui на основе Apache Pulsar 8. Анализ выбора промежуточного программного обеспечения сообщений: посмотрите на общую ситуацию из сравнения Kafka и RabbitMQ. 9.Приоритет сообщений в RocketMQ

10.очередь сообщений--NSQ&Kafka

11. Разберитесь в сходствах и различиях между RocketMQ и Kafka за три минуты. 12. Попрощайтесь с традиционной архитектурой обмена финансовыми сообщениями: практика Apache Pulsar в Ping An Securities

13. [Накопление знаний] Накопление сообщений MQ и истечение срока действия TTL.

14.Официальная документация-арендатор Pulsar 15. Многопользовательская система обмена сообщениями Apache Pulsar.

Об авторе

Ли Минкуань

Инженер-разработчик серверной части Tencent Education

Инженер-разработчик серверной части Tencent Education, окончил Университет Сунь Ятсена. В настоящее время отвечает за внутренние исследования и разработку продуктов Tencent, связанных с образованием.

Рекомендуем к прочтению

Онлайн-учебник! Как C++ может быстро реализовать оптимизацию компиляции в облачных приложениях?

CGO позволяет Go и C объединиться и разрушить «барьеры» между обеими сторонами!

Рекомендация по фронтенду! Сколько шагов нужно, чтобы начать работу с Webpack?

Переход с C++ на Rust: две основные темы, на которые стоит обратить внимание!