Сравнение преимуществ Alibaba RocketMQ

Почему стоит выбрать ПО промежуточного слоя для обмена сообщениями RocketMQ?

Существует множество основных MQ, таких как ActiveMQ, RabbitMQ, RocketMQ, Kafka, ZeroMQ и т. д.

Alibaba также использовала ActiveMQ раньше. С развитием бизнеса модуль ввода-вывода ActiveMQ столкнулся с узким местом. Позже Alibaba прошла ряд оптимизаций, но все еще не могла решить ее очень хорошо. После этого Alibaba сосредоточилась на основном промежуточном программном обеспечении для сообщений. kafka, но kafka не соответствует их требованиям, особенно малой задержке и высокой надежности.

Поэтому RocketMQ стоит на плечах гигантов (kafka), и оптимизирует его, чтобы он больше подходил под характеристики интернет-компаний. Он разработан на чистой Java и обладает характеристиками высокой пропускной способности, высокой доступности и подходит для крупномасштабных распределенных системных приложений. RocketMQ в настоящее время широко используется в Alibaba Group для транзакций, перезарядки, потоковых вычислений, отправки сообщений, потоковой передачи журналов, распространения бинглога и других сценариев.

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

Сравнение RocketMQ и kafka (18 отличий) [перевод]

Внутренняя система транзакций Taobao использует промежуточное программное обеспечение Notify message, независимо разработанное Taobao, и использует Mysql в качестве носителя для хранения сообщений, который может быть полностью расширен горизонтально.Чтобы еще больше снизить затраты, мы считаем, что часть хранения может быть дополнительно оптимизирована. В начале 2011 года Linkin открыл исходный код Kafka, который является превосходным промежуточным программным обеспечением для сообщений Kafka. система сообщений в основном находится в передаче журнала, для использования в транзакциях Taobao, есть еще много функций, которые не удовлетворяются в таких сценариях, как заказ и перезарядка, по этой причине мы переписали RocketMQ на языке Java, стремясь к надежному сообщению передача без журналов (сценарии журналов также в порядке).В настоящее время RocketMQ широко используется в заказах в Alibaba Group.Транзакции, перезарядка, потоковые вычисления, отправка сообщений, обработка потока журналов, распределение binglog и другие сценарии.

достоверность данных

• RocketMQ поддерживает асинхронную очистку в реальном времени, синхронную очистку, синхронную репликацию и асинхронную репликацию.

• Kafka использует асинхронную очистку, асинхронную репликацию/синхронную репликацию.

Резюме: синхронная очистка RocketMQ более надежна, чем Kafka на одной машине, и не приведет к потере данных из-за сбоев операционной системы. Теоретическая производительность синхронной репликации Kafka ниже, чем у синхронной репликации RocketMQ. Причина в том, что данные Kafka организованы в разделы, а это означает, что на экземпляре Kafka будут сотни разделов данных. Экземпляр RocketMQ RocketMQ может полностью использовать механизм фиксации группы ввода-вывода для передачи данных в пакетах и ​​настройку синхронной репликации по сравнению с асинхронной репликацией, потеря производительности составляет от 20% до 30%.Кафка лично не тестировал его, но я думаю, что он будет теоретически быть ниже, чем RocketMQ.

Сравнение производительности

• Одномашинная запись Kafka в TPS составляет около миллиона в секунду, а размер сообщения составляет 10 байт.

• Одна машина RocketMQ записывает около 70 000 сообщений в секунду в один экземпляр TPS и развертывает 3 брокера на одной машине, которые могут обрабатывать до 120 000 сообщений в секунду, а размер сообщения составляет 10 байт.

Резюме: TPS Kafka работает до миллиона на одной машине, главным образом потому, что сторона Producer объединяет несколько небольших сообщений и отправляет их брокеру пакетами. Почему RocketMQ этого не сделал?

1. Производители обычно используют язык Java, кэшируют слишком много сообщений, GC — очень серьезная проблема.

2. Производитель вызывает интерфейс отправки сообщений, но сообщение не отправляется Брокеру и возвращает успех бизнесу.В это время Производитель не работает, что приведет к потере сообщений и бизнес-ошибкам.

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

4. Функция кэширования может быть полностью выполнена бизнесом верхнего уровня.

Количество очередей, поддерживаемых одной машиной

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

• Одна машина RocketMQ поддерживает до 50 000 очередей, и нагрузка существенно не изменится.

Каковы преимущества наличия большего количества очередей?

1. Одна машина может создавать больше тем, поскольку каждая тема состоит из набора очередей.

2. Размер кластера потребителей пропорционален количеству очередей, чем больше очередей, тем больше может быть кластер потребителей.

доставка сообщений в реальном времени

• Kafka использует метод короткого опроса, а производительность в реальном времени зависит от интервала опроса.Версии после 0.8 поддерживают длинный опрос.

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

Ошибка потребления повторная попытка

• Ошибка потребления Kafka не поддерживает повторную попытку.

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

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

Если есть слишком много силы, вызов будет успешным позже.Например, Alipay дебетует банк также аналогичное требование.

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

Строгий порядок сообщений

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

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

Распределение двоичного журнала MySQL требует строгого порядка сообщений.

сообщение по времени

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

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

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

• Время задержки на уровне миллисекунд, указанное Alibaba Cloud MQ.

Распределенный обмен транзакционными сообщениями

• Kafka не поддерживает сообщения о распределенных транзакциях.

• Alibaba Cloud MQ поддерживает сообщения о распределенных транзакциях, а будущая версия RocketMQ с открытым исходным кодом также планирует поддерживать сообщения о распределенных транзакциях.

запрос сообщения

• Kafka не поддерживает запросы сообщений

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

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

откат сообщения

• Kafka теоретически может отслеживать сообщения в соответствии со смещением

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

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

Параллелизм потребления

• Параллелизм потребления Kafka зависит от количества разделов, настроенных темой.Если количество разделов равно 10, то для параллельного потребления может использоваться максимум 10 машин (каждая машина может запускать только один поток), или одна машина потребляет (10 потоков потребляют параллельно). То есть параллелизм потребления согласуется с количеством разделов.

• Параллелизм потребления RocketMQ делится на два случая

• Параллелизм метода последовательного потребления точно такой же, как у Кафки.

• Степень параллелизма в неупорядоченном режиме зависит от количества потоков Потребителя, например, если в топике настроено 10 очередей, потребляют 10 машин и на каждой машине 100 потоков, то параллелизм равен 1000.

трек сообщения

• Kafka не поддерживает следы сообщений

• Alibaba Cloud MQ поддерживает отслеживание сообщений

Дружественность к языку разработки

• Кафка написана на scala.

• RocketMQ написан на языке Java.

Фильтрация сообщений на стороне брокера

• Kafka не поддерживает фильтрацию сообщений на стороне брокера.

• RocketMQ поддерживает два метода фильтрации сообщений на стороне брокера.

• Фильтровать по переменным сообщения, что эквивалентно концепции подтем

• Загружая на сервер кусок кода Java, вы можете фильтровать сообщение в любой форме и даже фильтровать и разделять тело сообщения.

возможность стекирования сообщений

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

Активность сообщества с открытым исходным кодом

• Обновления сообщества Kafka идут медленно

• Сообщество RocketMQ на GitHub насчитывает 250 человек, пользователи компании зарегистрировали контактную информацию, а группа QQ насчитывает более 1000 участников. MQ ###Коммерческая поддержка

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

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

зрелость

• Кафка относительно зрел в области ведения журналов.

• RocketMQ используется большим количеством приложений в Alibaba Group, генерируя большое количество сообщений каждый день, и успешно поддерживает множество тестов массовых сообщений Tmall Double 11. Это мощный инструмент для пиков и спадов данных.

Сравнение промежуточного программного обеспечения сообщений Kafka, RabbitMQ, RocketMQ — производительность отправки сообщений [перевод]

введение

В распределенных системах мы широко используем промежуточное программное обеспечение сообщений для обмена данными между системами, чтобы облегчить асинхронную развязку. Существует много промежуточного программного обеспечения для сообщений с открытым исходным кодом.Некоторое время назад наш собственный продукт, RocketMQ (ядро MetaQ), также был легко открыт и привлек всеобщее внимание.

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

Имея в виду этот вопрос, наша группа тестирования промежуточного программного обеспечения сравнила производительность трех распространенных продуктов обмена сообщениями (Kafka, RabbitMQ, RocketMQ).

Kafka — это распределенная система обмена сообщениями LinkedIn с открытым исходным кодом, которая в настоящее время является частью рейтингового проекта Apache. Главной особенностью Kafka является то, что он обрабатывает потребление сообщений на основе режима Pull и преследует высокую пропускную способность.Первоначальная цель — использовать для сбора и передачи журналов. Версия 0.8 начинает поддерживать репликацию, но не поддерживает транзакции, нет строгих требований к дублированию сообщений, потерям и ошибкам, и она подходит для сервисов сбора данных интернет-сервисов, генерирующих большие объемы данных.

RabbitMQ — это система очереди сообщений с открытым исходным кодом, разработанная с использованием языка Erlang и реализованная на основе протокола AMQP. Основными функциями AMQP являются ориентированность на сообщения, организация очередей, маршрутизация (включая двухточечную связь и публикацию/подписку), надежность и безопасность. Протокол AMQP чаще используется в корпоративных системах.В сценариях, требующих высокой согласованности данных, стабильности и надежности, требования к производительности и пропускной способности отходят на второй план.

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

Цели тестирования

Сравните производительность Kafka, RabbitMQ и RocketMQ при отправке небольших сообщений (124 байта). В этом стресс-тесте мы ориентируемся только на показатели производительности сервера, поэтому стандарты стресс-теста таковы:

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

сценарии тестирования

В сценарии синхронной отправки отчетливо различается производительность промежуточного программного обеспечения с тремя сообщениями:

Пропускная способность Kafka достигает 17,3 Вт/с, что достойно того, чтобы быть лидером в области промежуточного программного обеспечения с высокой пропускной способностью. Это в основном зависит от его режима очереди, чтобы гарантировать, что процесс записи на диск является линейным вводом-выводом. В этот момент дисковый ввод-вывод брокера достиг узкого места.

RocketMQ также показал хорошие результаты с пропускной способностью 11,6 Вт/с и коэффициентом использования диска IO %, близким к 100%. После того, как сообщение RocketMQ записано в память, оно возвращается в ack, а на операцию сброса диска выделяется отдельный поток, все сообщения записываются в файлы последовательно.

Пропускная способность RabbitMQ составляет 5,95 Вт/с, а потребление ресурсов ЦП высокое. Он поддерживает протокол AMQP, который очень тяжеловесен, поэтому для обеспечения надежности сообщения приходится идти на компромисс в отношении пропускной способности. Мы также провели тест производительности RabbitMQ в сценарии сохраняемости сообщений, и пропускная способность составила около 2,6 Вт/с.

Заключение теста

С точки зрения производительности сервера для обработки синхронной передачи Kafka>RocketMQ>RabbitMQ.

приложение:

тестовая среда

Сервер развернут на одной машине, и конфигурация машины следующая:

Версия приложения:

тестовый скрипт

Kafka vs RocketMQ — Влияние количества тем на производительность одной машины [перевод]

введение

В прошлом выпуске мы сравнили производительность трех типов продуктов для обмена сообщениями (Kafka, RabbitMQ, RocketMQ) при простой отправке небольших сообщений, и они привлекли к себе большое внимание программистов.Задача веб-сайта заключается только в отправке сообщений. В этом выпуске мы смоделируем реальный сценарий:

1. Отправка сообщений и подписка должны сосуществовать

2. Необходимо поддерживать нескольких подписчиков для подписки на интересующие их сообщения. Ввиду высоких показателей и внимания Kafka и RocketMQ в предыдущем выпуске, в этом выпуске мы остановимся только на этих двух продуктах, и сравним какой именно лучше в приведенных выше сценариях. Прежде чем официально начать тест, мы должны сначала разъяснить всем два понятия:

Что такое тема

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

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

Что такое раздел

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

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

Цели тестирования

Сравнивая влияние количества тем на производительность Kafka и RocketMQ, когда отправитель и получатель сосуществуют, количество разделов равно 8. В данном стресс-тесте мы ориентируемся только на показатели производительности сервера, поэтому критерии выхода из стресс-теста такие:

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

сценарии тестирования

Количество разделов по умолчанию для каждой темы равно 8, и каждая тема соответствует одному подписчику, и количество тем постепенно увеличивается. Получите следующие данные:

продукт	Количество тем	Параллелизм на стороне отправителя	Временное время передатчика (мс)	Отправитель TPS	Потребительская ТПС
RocketMQ	64	800	8	9w	8.6w
128	800	9	7.8w	7.7w
256	800	10	7.5w	7.5w
Kafka	64	800	5	13.6w	13.6w
128	256	23	8500	8500
256	256	133	2215	2352

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

В соответствии с изменением количества тем сравнительная кривая возможностей обработки сообщений двух рисуется следующим образом:

Из рисунка видно, что:

1. Когда количество тем в Kafka увеличилось с 64 до 256, пропускная способность упала на 98,37%.

2. Когда количество тем в RocketMQ увеличилось с 64 до 256, пропускная способность упала всего на 16%.

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

Заключение теста

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

приложение:

тестовая среда

Сервер развернут на одной машине, и конфигурация машины следующая:

CPU	24 ядра
ОЗУ	94G
жесткий диск	Seagate Constellation ES (SATA 6Gb/s) 2,000,398,934,016 bytes [2.00 TB] 7202 rpm
сетевая карта	1000Mb/s

Версия приложения:

ПО промежуточного слоя сообщений	Версия
Kafka	0.8.2
RocketMQ	3.4.6

тестовый скрипт

конец давления	Java-клиент для Jmeter
размер сообщения	128 байт
параллелизм	Оптимальный параллелизм, который может достичь максимального TPS сервера
Количество тематических разделов	8
Стратегия кисти	Асинхронное размещение

Продолжение следует

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

Этот тест на данный момент подошел к концу. Многотемные сценарии, участвовавшие в тесте, фактически заняли всего 20 минут для стресс-теста. Для продукта промежуточного программного обеспечения сообщений время выполнения слишком мало, чтобы судить об их стабильности. В следующем выпуске мы продолжим исследовать стабильность внешних сервисов Kafka и RocketMQ в сценариях с несколькими разделами. Пожалуйста, с нетерпением ждите следующего конкурса!

Kafka vs RocketMQ — влияние нескольких тем на стабильность производительности [перевод]

введение

В последнем выпуске мы сравниваем RocketMQ и KAFKA в многопоритетном сценарии, анализ сравнения отправки и получении сообщений, производительность RocketMQ стабильна, а TPS Kafka может поддерживать 130 000 в 64 темах, и он упадет до 8500, когда он достигнет 128 тем, что делает невозможным завершить тест. Мы не можем не спрашивать:

Почему я не вижу тенденции резкого падения производительности Кафки?

В сегодняшнем тесте давайте проверим эту проблему, а затем проверим стабильность внешних служб двух систем. В этом тесте будет введено понятие "тест на стабильность" Что такое тест на стабильность? Давайте сначала посмотрим на определение:

Тест на стабильность: проверьте способность системы к долговременной стабильной работе. Во время работы системы оказывайте давление на систему и наблюдайте за различными показателями производительности системы и показателями загрузки сервера.

Это кажется немного абстрактным, давайте рассмотрим пример.

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

Рис. 1. Сравнение стабильности скорости потного BMW и паровоза

Горизонтальная ось на приведенном выше рисунке представляет время теста, а вертикальная ось представляет скорость поезда и лошади.Можно видеть, что ускорение и максимальная скорость лошади лучше, чем у поезда. Однако из-за физической силы через 15 минут лошади уже трудно поддерживать максимальную скорость, и она может только передохнуть, а затем разогнаться до исчерпания своих физических сил; при этом поезд достигает максимальной скорости на протяжении всего пути. процесс, он в основном останется неизменным. Так что вывод очевиден, устойчивость поезда по скорости лучше, чем у потного БМВ.

Подумайте об этом: что бы вы получили, если бы время теста составляло всего 15 минут? Потный BMW превосходит поезд по ускорению, максимальной скорости и даже по пройденному за единицу времени расстоянию. Поэтому, если вы хотите провести оценку при транспортировке на дальние расстояния, то правильным методом испытаний является увеличение времени испытаний для наблюдения за стабильностью испытуемого объекта.

Хорошо, вернемся к вопросу, оставленному нашим последним тестом - в падении нет тренда. Причина, вероятно, в том, что в первые дни существования 32Topic и 64Topic у Kafka уже был нисходящий тренд, но у нас не хватило времени на стресс-тест, поэтому он был засчитан как пройденный тест.

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

Цели тестирования

В случае одновременного завершения отправки и получения сообщений RocketMQ и Kafka работают примерно по 1 ч. Наблюдайте за колебаниями показателей производительности Kafka и RocketMQ (TPS и время отклика) при разном количестве тем.

сценарии тестирования

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

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

Рисунок 2. Сравнение кривых эффективности по 32 темам

Через 18 минут кривая TPS синего Kafka начала беспорядочно колебаться, в то время как RocketMQ была стабильной. Давайте посмотрим на ситуацию с 64 темами, как показано на следующем рисунке:

Рисунок 3. Сравнение кривых эффективности по 64 темам

Рисунок 4. Сравнение времени отклика 64 тематических клиентов

TPS Kafka оставался стабильным в течение первых 20 минут и опередил RocketMQ с большим отрывом. Через 20 минут снова стали появляться нерегулярные колебания, и эти колебания напрямую приводили к изменению времени отклика (рисунок 4).В определенный момент время отклика клиента Kafka достигало 25 миллисекунд, тогда как весь процесс RocketMQ составлял 5 миллисекунд. В этом сравнении трех сценариев Kafka выигрывает один, то есть сценарий с темами 8. Как показано на рисунке 5, из-за ограничения количества тем и количества разделов Kafka подходит только для малого бизнеса. системы.

Рис. 5. Сравнение кривых эффективности по 8 темам

Заключение теста

1. Увеличение количества тем никак не влияет на RocketMQ, а давно работающий сервис очень стабилен.

2. Количество тем в Kafka рекомендуется не превышать 8. Более 8 тем приведут к резким колебаниям времени отклика Kafka, что приведет к чрезмерно длительному времени отклика для некоторых клиентов, что повлияет на доставку клиентов в режиме реального времени и бизнес-пропускную способность клиентов.

приложение

тестовая среда

Сервер развернут на одной машине, и конфигурация машины следующая:

CPU	24 ядра
ОЗУ	94G
жесткий диск	Seagate Constellation ES (SATA 6Gb/s) 2.00 TB 7202 rpm
сетевая карта	1000Mb/s

Версия приложения:

ПО промежуточного слоя сообщений	Версия
Kafka	0.8.2
RocketMQ	3.4.8

Тестовый сценарий:

конец давления	Java-клиент для Jmeter
размер сообщения	128 байт
параллелизм	Оптимальный параллелизм, который может достичь максимального TPS сервера
Количество тематических разделов	8
Стратегия кисти	Асинхронное размещение

Продолжение следует

После теста в этом выпуске RocketMQ также побеждает Kafka по стабильности.Если это только небольшой бизнес, Kafka может удовлетворить потребности, но если есть более высокие требования к сложности и стабильности бизнеса, RocketMQ является лучший выбор. .

Этот тест на данный момент подошел к концу, но битва между Kafka и RocketMQ не прекратилась.Сравнения сцен еще впереди, так что следите за обновлениями конкурса!

Kafka vs RocketMQ — Надежность автономной системы [Перевод]

введение

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

• для чего “可靠性”?

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

• для чего “软件可靠性”?

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

• для чего “消息中间件的可靠性”?

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

Так какой из них лучше по надежности между Kafka и RocketMQ (далее RMQ)? Соревнуйтесь с нами в этом выпуске теста!

Цели тестирования

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

сценарии тестирования

В следующем сценарии для отправки сообщений в тему используется несколько отправителей, метод отправки — синхронная отправка, количество разделов — 8, и запущен только один подписчик.

Сцена 1. 模拟进程退出

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

Примечание. В приведенном выше тестовом сценарии интервал асинхронного обновления Kafka составляет 1 секунду, а для синхронной отправки следует установить request.required.acks=1, иначе сообщения будут потеряны.

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

Сценарий 2.模拟机器掉电

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

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

Повторно выполните приведенный выше тест и получите следующие данные:

Во-первых, при настройке синхронной прошивки ни один из них не терял сообщения. Из-за того, что мы используем обычные ПК, пропускная способность обоих не высока. В это время самый высокий TPS у Kafka составляет всего 500 в секунду, а RMQ может достигать 4000 в секунду, что уже в 8 раз больше, чем у Kafka.

Почему пропускная способность Kafka такая низкая? Поскольку сама Kafka не реализует никакого механизма синхронной очистки, то есть в этом сценарии Kafka обречена на потерю сообщений. Но чтобы каждое сообщение возвращалось после его размещения, мы можем добиться этого, изменив частоту асинхронной очистки. Установите параметр log.flush.interval.messages=1, то есть очищайте диск один раз для каждого сообщения. Таким образом, Kafka не будет терять сообщения, но частое чтение и запись на диск напрямую приведет к снижению производительности.

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

Заключение теста

1. В сценарии, когда процесс Broker убит, и Kafka, и RocketMQ могут обеспечить пропускную способность без потери сообщений, а надежность относительно высока.

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

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

приложение:

тестовая среда

Сервер развернут на одной машине, и конфигурация машины следующая:

Версия приложения:

тестовый скрипт

Разница между синхронной очисткой и асинхронной очисткой

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

Продолжение следует

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

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