ActiveMQ 与 Kafka 的比较 | redhat


将 ActiveMQ 与 Kafka 进行比较类似于将关系数据库与 NoSQL 进行比较。

ActiveMQ 不像 Kafka 那样适合云。但这并不意味着 ActiveMQ 不再有任何用例。仍然有大量业务用例需要保证信息的交付。

推送消息与拉取事件
Apache ActiveMQ Artemis 公开了开放接口和开放协议。客户端应用程序可以通过 JMS、AMQP 或 MQTT 与服务器交换信息。因此,这些客户端应用程序可以用多种语言编写,例如Java.NETJavaScriptPython

另一方面,Apache Kafka 使用自己的协议。只有使用 Kafka API 的客户端才能与之交互。

服务质量
将数据视为事件而不是消息导致了定义某些责任的不同方式。Kafka 会从外部系统查询数据并存储起来供以后消费。它不对如何解释数据或确定其重要性承担任何责任。这个责任将留给消费者。

另一方面,ActiveMQ 将被外部系统请求为其传输数据,并将隐含地接受以适当的服务质量处理消息的某些责任。  

如果我们考虑恰好一次交付服务质量,我们可以很容易地理解这种差异。这两种技术都可以实现。但一方面由服务器保证,另一方面由消费者强制执行。尽管有一些实验组件旨在将事务的概念引入 Kafka,但我们已经从 CAP 定理中知道它必须留下分区或高可用性。

更进一步,Kafka 甚至不会确保数据的安全存储。数据将被发送到缓存,缓存最终会将其刷新到磁盘。或者,ActiveMQ 执行同步写入以确保已确认的数据永远不会丢失。

聚类
使用 ActiveMQ,消费者不必准确地连接到生成消息的位置。消息的正确路由是服务器承担的另一项责任。这与让邮递员确保将邮件送达正确地址的原理相同。
因此,如果集群功能确实可以增加入站吞吐量,它通常会伴随着出站延迟的减少,因为数据需要经过跃点才能到达集群上的正确消费者。

对于 Kafka,服务器不负责确保将事件发送到正确的目的地。相反,它将帮助愿意消费事件的客户端应用程序连接到事件所在的节点(图 4),从而保证最大吞吐量和最小延迟。在这里,这更接近于充当邮局。