Kafka与RabbitMQ
一、什么是kafka，什么是rabbit
Kafka是由Scala语言开发的一种分布式流处理框架，主要用于处理活跃的流式数据，以及大数据量的数据处理。它采用发布-订阅模型，支持消息的批量处理，数据的存储和获取是本地磁盘顺序批量操作，这使得消息处理的效率较高，吞吐量较大。
RabbitMQ则是由Erlang语言开发，主要用于实时的、对可靠性要求较高的消息传递。它采用AMQP（高级消息队列协议）进行消息的传递，并且有一个broker（消息代理）作为中心，可以确认消息的传递。RabbitMQ支持消息的可靠的传递，支持事务，但并不支持批量操作，基于存储的可靠性的要求存储可以采用内存或硬盘，但吞吐量相对较小。
二、rabbit和kafka的特性
（1）Kafka的特性：
- 大规模数据处理：Kafka的吞吐量巨大，其数据存储和获取是本地磁盘的批量处理，可以达到百万/s。
- 持久性消息存储：Kafka是一个持久性消息存储，在数据写入后即使出现系统崩溃，也能够保证数据的完整性。
- 可靠性的支持：Kafka的broker支持主备模式，为数据的安全性提供了保障。
（2）RabbitMQ的特性：
- 消息确认机制：RabbitMQ具有生产者confirm机制以及消费者的消息应答机制ack，可以保证消息的可靠传递。
- 消息顺序性：在RabbitMQ中，在一个队列里的消息是严格顺序的，按照先进先出。
- 持久化支持：RabbitMQ支持持久化，可以把消息写入到磁盘中，保证数据在内存不足时也不会丢失。
- 高可用性：RabbitMQ使用了MirrorQueue的机制，可以将重要队列“复制”到集群中的其他broker上，保证这些队列的消息不会丢失。
（3）二者的相同点在于都是为了解决消息的传递问题，但在很多方面也有显著的不同：
- 架构模型：RabbitMQ遵循AMQP协议，由Exchange、Binding、queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费。而Kafka遵从一般的MQ结构，以producer、broker、consumer为中心。
- 消息确认机制：Kafka并不具有应答机制，而RabbitMQ具有生产者confirm机制以及消费者的消息应答机制ack。
- 消息的顺序：在RabbitMQ中，在一个队列里面，rabbitmq的消息是严格顺序的，按照先进先出。然而在Kafka中，虽然每个partition中的消息是有序的，但是因为Kafka将数据分布在不同的partition中，所以总体是无序的。
- 吞吐量：在不使用ACK机制的情况下，RabbitMQ的QPS可以达到6W+，而在双方使用ACK机制的情况下，QPS降到了1W+。与此相反的是，Kafka具有巨大的吞吐量，数据的存储以及获取是本地磁盘的批量处理，可以达到百万/s。
- 可靠性： RabbitMQ使用了MirrorQueue的机制，也可以做到多个机器进行热备。而Kafka的主备模式提供了另外一种可靠性保障。
总的来说，RabbitMQ和Kafka在特性和应用场景上各有优势和劣势。在选择使用时需要考虑到自身需求以及两者的特性和限制。
三、两者使用场景，如何才能方便应用
我们首先要明白kafka不是消息中间件的一种实现，他是分布式流系统，他的定位就是来处理日志及大数据方面，吞吐量无疑是很高的。而rabbit他的push模式就导致了他得延时是较低的，但是场景上只支持主从，所以在本身的设计上就是比较小的，cpu消耗自然就更低。
从消息顺序来讲：
Kafka可以保证在单个分区中的消息顺序是有序的，即按照消息的写入顺序进行消费。但是，当使用多个分区时，就不能保证消息的顺序了，因为每个分区都是独立的，消息的写入顺序和消费顺序都是分区内部的顺序，与其他分区无关，如果需要保证消息的顺序，可以将所有的消息写入到单个分区中，或者使用单个消费者或消费者组来消费消息。
而对于RabbitMQ，如果是单个消费者，那么它先进先出的机制，可以保证消息的有序性，但是如果有多个消费者从同一个队列中读取消息，那么就难以保证消息的顺序。例如，一个消费者在处理消息后可能由于失败等原因将消息放回队列，这样另一个消费者就可以继续处理它，从而可能导致消息的顺序错乱。这种情况下，可以通过限制消费者并发数=1的方式来保证消息的有序性。
（1）Kafka的使用场景和例子：
- 大规模数据流处理：Kafka可以处理大规模的数据流，并且具有高吞吐量和持久性特性，可以承受大量的数据。例如，一个大型的网络应用需要收集来自数百台服务器的日志数据，并将这些数据传递给分布式数据处理系统（如 Apache Spark）进行实时数据分析和仪表板展示。 Kafka可以作为数据枢纽，服务器将日志消息发布到Kafka Topic中，而 Spark 则通过消费者从 Kafka 中订阅和处理这些消息。
- 实时数据流处理：Kafka可以支持实时的数据流处理，并且具有低延迟的特性。例如，电商平台需要实时处理订单和库存消息，当有新订单生成时，需要通知库存管理系统进行库存调整。 Kafka可以用于传递这些实时的订单和库存消息，并支持低延迟的处理。
（2）RabbitMQ的使用场景和例子：
- 消息路由：RabbitMQ可以通过消息路由的方式将消息发送到不同的消费者或者消费者组中。例如，一个电子商务平台需要处理订单和库存管理，当有新订单生成时，需要通知库存管理系统进行库存调整。 RabbitMQ可以将订单消息路由到库存管理系统，并通知其进行库存调整。
- 消息持久化：RabbitMQ可以保证消息的持久化存储，以便在系统故障时能够恢复消息。例如，在电子商务平台中，如果订单处理系统出现故障，RabbitMQ可以保证订单消息不被丢失，并在系统恢复后继续处理。
总体来说，Kafka更适合大规模的数据流处理和实时数据处理场景，而RabbitMQ更适合消息路由和持久化存储场景，要选择适合自己项目的架构。
四、总结
Kafka和RabbitMQ都是用于消息传递的工具，它们具有不同的特性和应用场景。Kafka适合处理大规模的实时数据流，并具有高吞吐量和持久性特性，而RabbitMQ更适合消息路由和持久化存储，并具有消息确认机制和严格的消息顺序。在选择使用时，需要考虑到自身需求以及两者的特性和限制。
PS：可以结合使用：虽然Kafka和RabbitMQ具有不同的特性和应用场景，但它们可以结合使用，以获得更好的效果。例如，可以使用Kafka来处理大规模的实时数据流，并使用RabbitMQ来处理消息路由和持久化存储
本文简述一些特性以及区别，但是我们要应用于生产上的项目和结构还是要去看官方文档，文档里都有详细的方案，从而助我们更好的分辨需要用什么工具。本文如果有什么错误点欢迎大家指正。
