то же
- Принципы, лежащие в их основе, во многом схожи, и 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 узлов. В случае сбоя необходимо избрать только лидера раздела, что очень эффективно.
использованная литература
- Первый взгляд на MQ [Разница между хранилищами Kafka и RocketMQ, которую нужно увидеть в интервью]
- Основная конструкция высокопроизводительной памяти Rocketmq
- [Dry Car] Анализ характеристик транзакций Kafka
- Kafka Design Analysis (8) - Принцип семантики и механизма транзакций ровно один раз
- Промежуточное ПО для сообщений — сравнение возможностей RocketMQ и Kafka
- Небольшое сравнение Kafka и RocketMQ
- Проблемы, которые необходимо решить в промежуточном программном обеспечении сообщений RocketMQ