Apache kafka 与 ActiveMQ 有什么区别答案

【问题标题】：What is the difference between Apache kafka vs ActiveMQApache kafka 与 ActiveMQ 有什么区别
【发布时间】：2017-12-01 05:38:08
【问题描述】：

我正在研究 Apache Kafka。我想知道哪个更好：Kafka 或 ActiveMQ。这两种技术的主要区别是什么？我想在 Spring MVC 中实现 Kafka。

【问题讨论】：

ActiveMQ or RabbitMQ or ZeroMQ or的可能重复

标签： apache-kafka activemq

【解决方案1】：

Kafka 和 ActiveMQ 可能有一些重叠，但它们最初是为不同的目的而设计的。所以比较它们就像比较苹果和橙子一样。

卡夫卡

Kafka 是一个分布式流媒体平台，具有非常好的水平扩展能力。它允许应用程序处理和重新处理磁盘上的流数据。由于它的高吞吐量，它通常用于实时数据流。

ActiveMQ

ActiveMQ 是一个通用的消息代理，它支持多种消息传递协议，例如 AMQP、STOMP、MQTT。它支持更复杂的消息路由模式以及Enterprise Integration Patterns。一般来说，它主要用于应用程序/服务之间的集成，尤其是在Service Oriented Architecture中。

【讨论】：

首先想到的是比较苹果公司。用橘子

【解决方案2】：

Kafka 架构不同于 ActiveMQ。

在 Kafka 中，生产者将消息发布到主题，主题是特定类型的消息流。消费者将通过拉取数据订阅一个或多个 broker 的主题。

主要区别：

ActiveMQ 代理必须维护每条消息的传递状态，从而导致吞吐量降低。与 ActiveMQ 不同，Kafka 生产者不会等待来自代理的确认，并且会以代理可以处理的最快速度发送消息。 整体吞吐量如果代理可以像生产者一样快地处理消息，将会很高。
Kafka 有一个更高效的存储格式。平均而言，Kafka 中每条消息的开销为 9 字节，而 ActiveMQ 中为 144 字节。
ActiveMQ 是基于 push 的消息系统，Kafka 是基于 pull 的消息系统。在 AcitveMQ 中，Producer 向 Broker 发送消息，Broker 向所有消费者推送消息。生产者有责任确保消息已被传递。在 Kafka 中，Consumer 会在自己的时间从 broker 拉取消息。消费它应该消费的消息是消费者的责任。
AMQ 中的慢消费者可能会导致非持久主题出现问题，因为它们可以强制代理将旧消息保留在 RAM 中，一旦内存填满，就会迫使代理减慢生产者的速度，从而导致快速消费者的速度变慢。 Kakfa 中缓慢的消费者不会影响其他消费者。
在 Kafka 中 - 消费者可以回退到旧的偏移量并重新使用数据。当您修复某些问题并决定在问题解决后重新播放旧消息时，它很有用。
队列和主题的性能会随着 ActiveMQ 中消费者的增加而降低。但是 Kafka 没有增加更多消费者的缺点。
由于分区的复制，Kafka 具有高度可扩展性。它可以确保消息在分区中按顺序传递。
ActiveMQ 是传统的消息传递系统，而 Kakfa 则适用于具有海量数据和有效流处理的分布式处理系统

由于上述效率，Kafka 的吞吐量超过了 ActiveMQ 和 RabbitMQ 等普通消息传递系统。

更多详情可以阅读notes.stephenholiday.com

编辑：特别是对于那些认为生产者不等待经纪人确认确认的人可以阅读ActiveMQ documentation页面

ProducerWindowSize 是生产者在等待来自代理的确认消息之前将传输给代理的最大数据字节数，它已接受先前发送的消息。

【讨论】：

2. ActiveMQ 并没有多使用 70% 的磁盘空间——这显然是错误的。
3.这是不正确的——ActiveMQ 消费者拉取消息
3.仍然不正确。 ActiveMQ是一个broker，生产者和消费者是分开的，和Kafka一样。在这方面，两者没有区别。
2.称其为“更有效”是一种误导。 ActiveMQ 以元数据（标头和属性）的标准格式存储消息。 Kafka 将其推送到应用程序进行定义。这是一个利益与权衡的交易。
是的，我是说描述他们的测试场景的 Kafka 文档包含不一致和不准确的地方。我认为世界上最好的 kafka 架构师所说的他们认为每个 Kafka 代理的 55Mb/s 到 75MB/s 的限制支持了我的观点。我认为我们，技术人员，应该能够进行建设性的对话，并超越“kafka scale 更好”——我觉得这过于简单化，最终对业务不利。

【解决方案3】：

我每周都会听到这个问题......虽然 ActiveMQ（如一般的 IBM MQ 或 JMS）用于传统消息传递，Apache Kafka 被用作流平台（消息传递 + 分布式存储 + 数据处理）。两者都是为不同的用例而构建的。

您可以将 Kafka 用于“传统消息传递”，但不能将 MQ 用于特定于 Kafka 的场景。

文章“Apache Kafka 与企业服务总线 (ESB) - 朋友、敌人还是敌人？ (https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)”讨论了为什么 Kafka 不具有竞争力，但却是集成和消息传递解决方案的补充（包括 ActiveMQ）以及如何集成两者。

【讨论】：

【解决方案4】：

我认为在讨论使用哪些代理（以及何时出现 Kafka）时应该注意的一件事是，经常引用的 Kafka benchmark 显示了任何现代分布式计算机的上限。今天的代理都具有以 MB/s 为单位的大致相同的总容量。与其他代理相比，Kafka 在处理小消息（10-1024 字节）方面表现非常出色，但仍限制在 ~75 Mb/s 左右（每个代理）。

在谈论“聚类”时，经常会有苹果与橘子的比较。 ActiveMQ 和其他企业代理集群消息的发布和消费者订阅的跟踪。 Kafka 对发布进行集群化，并要求消费者跟踪订阅。看似微不足道，但差别很大。

所有代理都有相同的背压问题——Kafka 可以做一个“懒惰的持久性”，生产者不需要等待代理同步到磁盘。这对很多用例都有好处，但可能不是 ppatierno 在幻灯片中提到的我关心每一条消息的场景。

Kafka 非常适合水平扩展，例如小消息的大数据处理。 ActiveMQ 更适合经常被称为企业消息传递的用例类（这只是一个术语，并不意味着 Kafka 不适合企业）--事务处理数据（尽管 Kafka 正在添加这个）.. kiosk .. 零售店.. 存储和转发.. dmz 遍历.. 数据中心到数据中心发布.. 等等

【讨论】：

你能说一下为什么 Kafka 不是你想要的 I-care-about-every-single-message 场景吗？消息队列，您可以在其中跟踪您的进度，并且发送者保留它发送的消息的积压，以便接收者可以回滚并连接并再次请求旧消息是非常可靠的，不是吗？它获得了更好的吞吐量。像这样：cedanet.com.au/ceda/persistent-message-queue.php
Kafka Producer API 中“send()”的默认行为是异步的。消息在内存中缓冲时进程失败将导致消息丢失。脑裂和分区领导故障转移也可能导致消息丢失。没有灵丹妙药......它的好处和权衡。 FWIW——生产者端扇出 + 类似 JMS 的持久性让我投票选出最佳分布式计算选项，以免丢失消息。
解决吞吐量问题——多线程生产。单线程阻塞并不总是“坏的”。它是可靠的，并提供消息排序的最佳可用维护。再次，它的好处和权衡。接收器回滚和重新处理非常可靠。令人头疼的是（恕我直言）由于缺乏如何最有效地做到这一点的现成样本，因此刚接触消息传递的程序员经常遇到它。幂等/重放也有其缺点和可靠性问题。
问：CEDA 与存储转发有何不同？看起来就像本地代理的本地生产者线程......然后本地代理转发到将其写入磁盘的远程代理。
75Mbps 根本不代表 Kafka 规模。这大约是我在生产中看到的 1%。