Въведение в ActiveMQ срещу Kafka

Apache ActiveMQ е мулти-протокол с отворен код, сървър за съобщения, базиран на Java. Той реализира JMS (Java Message Service) API и е в състояние да поддържа различни протоколи за съобщения, включително AMQP, STOMP и MQTT. Обикновено се използва за изпращане на съобщения между приложения / услуги. В тази тема ще научим за ActiveMQ срещу Kafka.

От друга страна, Apache Kafka е софтуер за обработка на потоци с отворен код, разработен от LinkedIn (и по-късно дарен на Apache) за ефективно управление на техните нарастващи данни и преминаване към обработка в реално време от пакетна обработка. Той е написан на Scala и Java и се основава на модела за публикуване и абониране на съобщения.

Сравнение между главата на ActiveMQ срещу Kafka (Инфографика)

По-долу са горните разлики между ActiveMQ срещу Kafka

Ключови разлики между ActiveMQ срещу Kafka

ActiveMQ и Kafka са проектирани за различни цели. Следват основните разлики:

Kafka е разпределена поточна платформа, която предлага висока хоризонтална мащабируемост. Също така, той осигурява висока производителност и затова се използва за обработка на данни в реално време. ActiveMQ е решение за съобщения с общо предназначение, което поддържа различни протоколи за съобщения. Kafka е доста по-бърз от ActiveMQ. Той може да обработва милиони съобщения в секунда.

ActiveMQ поддържа както опашки за съобщения, така и публикува / абонирайте системи за съобщения. Kafka, от друга страна, се основава на публикуване / абониране, но има определени предимства на опашките за съобщения.

ActiveMQ гарантира, че ще бъде доставено съобщение, но при Kafka има вероятност (колкото и малка да е тя), че съобщението може да не бъде доставено.

Загубата на съобщения в Kafka може да се случи при следния сценарий:

  • Това може да се случи, докато паралелно консумирате съобщения. Помислете за ситуация, при която 2 съобщения идват до потребителите: X и Y. Двете съобщения се обработват паралелно. Докато обработваше съобщенията, Y беше успешен и извърши компенсирането. Въпреки това, докато обработваше съобщението, X допусна грешка. Имайки предвид, че съобщението B има по-голямо компенсиране, Kafka ще запази последното компенсиране и съобщението A никога не се връща към потребителя.

Доста по-лесно е да се реализира точно веднъж доставка на съобщения в ActiveMQ, отколкото е в Kafka. Доставката на дублиращи съобщения в Kafka може да се случи при следния сценарий:

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

В Kafka съобщението е основно двойка ключ-стойност. Полезният товар на съобщението е стойността. Ключът, от друга страна, обикновено се използва за целите на дяла и трябва да съдържа специфичен за бизнеса ключ, за да се поставят свързани съобщения в един и същ дял.

В ActiveMQ съобщението се състои от метаданни (заглавки и свойства) и тяло (което е полезният товар).

ActiveMQ срещу Kafka сравнителна таблица

Нека да обсъдим топ 10 разликата между ActiveMQ срещу Kafka

ActiveMQКафка
Това е традиционна система за съобщения, която се занимава с малко количество данни. Той има следните случаи на употреба:

  • Транзакционни съобщения
  • Високопроизводително разпределение на пазарни данни
  • Клъстер и модел за асинхронно съобщение с общо предназначение
  • Уеб поточно предаване на данни
  • API за почивка към съобщения с помощта на HTTP
Това е разпределена система, предназначена за обработка на огромно количество данни. Той има следните случаи на употреба:

  • Съобщения
  • Проследяване на активността на уебсайта
  • Метрика
  • Обобщаване на вход
  • Обработка на потоци
  • Sourcing за събития
  • Дневник за ангажиране
Има поддръжка за транзакции. Двете нива на поддръжка на транзакции са:

  • JMS транзакции
  • XA транзакции

Той използва TransactionStore за обработка на транзакции. TransactionStore ще кешира всички съобщения и ACKS, докато се извърши извършване или отмяна.

Първоначално Kafka не поддържаше транзакции, но след излизането си от 0.11, до известна степен поддържа транзакциите.
Той поддържа състоянието на доставка на всяко съобщение, което води до по-ниска пропускателна способност.Производителите на Kafka не чакат потвърждения от брокерите. Така че, брокерите могат да пишат съобщения с много висока скорост, което води до по-висока пропускателна способност
В ActiveMQ отговорност на производителите е да гарантират, че съобщенията са доставени.В Kafka е отговорност на потребителите да консумират всички съобщения, които трябва да консумират.
Не може да гарантира, че съобщенията се получават в същия ред, в който са изпратени.Той може да гарантира, че съобщенията се получават в реда, в който са изпратени на ниво дял.
Има нещо, наречено селектор на съобщения за API на JMS, което позволява на потребителя да посочи съобщенията, от които се интересува. И така, работата по филтрирането на съобщенията е до JMS, а не към приложенията.Kafka няма концепция за филтри при брокерите, която да гарантира, че съобщенията, които потребителите получават, отговарят на определен критерий. Филтрирането трябва да се извърши от потребителите или от приложенията.
Това е платформа за съобщения с push тип, където доставчиците избутват съобщенията до потребителите.Това е платформа за съобщения от типа „pull“, където потребителите изтеглят съобщенията от брокерите.
Не е възможно да се мащабират хоризонтално. Не съществува и концепция за репликация.Той е силно мащабируем. Поради реплики на дялове, той предлага и по-висока наличност.
Изпълнението на опашката и темата се влошава, тъй като броят на потребителите се увеличава.

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

заключение

Видяхме, че Kafka и ActiveMQ имат различни случаи на употреба. Една компания ще поиска Kafka, ако трябва да обработва огромно количество данни в реално време и може да понесе загуба на съобщения до известна степен. Като има предвид, че ActiveMQ би бил правилният избор, ако се грижи за еднократната доставка и съобщенията са ценни (например при финансови транзакции).

Препоръчителен член

Това е ръководство за ActiveMQ срещу Kafka. Тук обсъждаме основните разлики на ActiveMQ срещу Kafka с инфографика и таблица за сравнение. Може да разгледате и следните статии, за да научите повече -

  1. Кафка срещу Спарк
  2. Pig vs Spark
  3. Hadoop срещу Apache Spark
  4. Apache Storm срещу Kafka: 9 най-добри разлики, които трябва да знаете

Категория:

Разработване на софтуер