Узнайте о сходствах и различиях между RocketMQ и Kafka за три минуты

очередь сообщений

то же

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

разница

форма хранения

  • Kafka использует разделы, и каждый раздел каждой темы соответствует файлу. Последовательная запись, регулярная очистка диска. Однако, если у одного брокера слишком много разделов, последовательная запись вырождается в случайную запись, слишком много грязных страниц в кэше страниц, инициируются частые прерывания ошибки страницы, и производительность значительно падает.
  • RocketMQ использует CommitLog+ConsumeQueue.Все темы одного брокера записываются последовательно в CommitLog, а Page Cache нужно хранить только самые последние страницы. При этом каждая очередь в каждой теме имеет в качестве индекса соответствующий файл ConsumeQueue. ConsumeQueue занимает очень мало места в кэше страниц, и влияние сброса невелико.

надежность хранения

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

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

И Kafka, и RocketMQ поддерживают только порядок разделов с одной темой. Хотя RocketMQ официально утверждает, что поддерживает строгий порядок, метод заключается в использовании одного раздела.

Отложенное сообщение

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

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

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

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

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

сообщение не удалось повторить

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

DLQ (очередь недоставленных сообщений)

  • RocketMQ записывает все сообщения о неудачном потреблении через DLQ.
  • У Кафки нет DLQ. Сторонние инструменты, такие как Spring, реализуются путем записи сообщений об ошибках в специальную тему.

ретроспективное потребление

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

дела

  • RocketMQ поддерживает сообщения о транзакциях и использует двухэтапную фиксацию + регулярную проверку брокера. Однако он может гарантировать согласованность только между производителем и посредником, а посредник и потребитель могут повторить попытку только в одном направлении. То есть конечная согласованность гарантируется.
  • Kafka начинает поддерживать сообщения о транзакциях с версии 0.11, в дополнение к поддержке окончательной согласованности реализована семантика сообщения ТОЧНО ОДИН РАЗ (один раздел).

обнаружение службы

  • Сам RocketMQ реализует namesrv.
  • Кафка использует ZooKeeper.

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

  • Граничность дизайна высокой доступности RocketMQ контролируется только брокером. Его гарантия высокой доступности решается репликацией Master-Plave Master-Plave.
  • Контроль высокой доступности Кафки на размере частиц раздела. Лидер каждой темы разбиения и разбиения реплики могут загружать баланс на всем брокере.
  • По сравнению со схемой репликации master-slave RocketMQ, эта конструкция Kafka имеет следующие преимущества:
    • В Kafka нет необходимости устанавливать подчиненных брокеров, и все брокеры могут отправлять и получать сообщения. Балансировка нагрузки также лучше.
    • Выбор раздела Kafka выполняется автоматически, и RocketMQ должен сам указать отношение ведущий-подчиненный.
    • Количество реплик раздела Kafka указано как N, что может допустить сбой N-1 узлов. В случае сбоя необходимо избрать только лидера раздела, что очень эффективно.

использованная литература