Kafka还是RabbitMQ？
现在的系统已经离不开消息队列，我们可以用他做异步，做解耦，做流处理，做可靠传输。市面上的消息队列也有很多，比如阿里云的oss，RocketMQ，ZeroMQ，RabbitMQ，Kafka等，甚至Java中的List也可以称为一个简单的消息队列，种类如此繁多，我们该如何选择呢？现在主流的消息队列可以分为两类，一类以kafka为代表，一类以RabbitMQ为代表，二者有很多相似的地方，也都有各自的优势。
那我们平时构建系统的时候，该选择哪种消息队列呢？这里我们将RbbitMQ与kafka做一下对比（因为他们都是spring默认集成的消息队列），以便于我们做出最优的选择。
RabbitMQ：关于rabbit的详细介绍这里不说，感兴趣的可以看我之前的文章，一句话rabbit作为传统意义上的消息队列，基于AMQP协议开发，倾向于做按各种规则的消息转发。
Kafka：关于kafka的详细介绍会在以后的文章里写，因为刚开始用，想深入了解后再写出来。kafka更倾向于一个流式管道的概念，消息从一处流向另一处，吞吐量比rabbit更高。
接下来通过俩张图来理解他俩的设计与区别。
首先来看rabbit，他通过broker来进行统一调配消息去向，生产者通过指定的规则将消息发送到broker，broker再按照规则发送给消费者进行消费，消费者方可以选择消费方式为pull或者是broker主动push，支持的消费模式也有多种，点对点，广播，正则匹配等。
Kafka主要为高吞吐量的订阅发布系统而设计，主要追求速度与持久化。kafka中的消息由键、值、时间戳组成，kafka不记录每个消息被谁使用，只通过偏移量记录哪些消息是未读的，kafka中可以指定消费组来实现订阅发布的功能。
了解了二者大体的区别以后，我们再来看具体的适用场景。
Kafka：
1.从A系统到B系统的消息没有复杂的传递规则，并且具有较高的吞吐量要求。
2.需要访问消息的历史记录的场景，因为kafak是持久化消息的，所以可以通过偏移量访问到那些已经被消费的消息（前提是磁盘空间足够，kafka没有将日志文件删除）
3.流处理的场景。处理源源不断的流式消息，比较典型的是日志的例子，将系统中源源不断生成的日志发送到kafka中。
rabbit：
1.需要对消息进行更加细粒度的控制，包括一些可靠性方面的特性，比如死信队列。
2.需要多种消费模式（点对点，广播，订阅发布等）
3.消息需要通过复杂的路由到消费者。
最后是关于性能方面，众所周知，kafka的吞吐量优于rabbit，大约是100k/sec，而rabbit大约是20k/sec，但是这个不应该成为我们选择的主要原因，因为性能方面的瓶颈都是可以通过集群方案来解决的。
最后要说的是，没有最好的队列，只有最合适的队列。
参考：Understanding When to use RabbitMQ or Apache Kafka
rabbitmq和kafka的区别
RabbitMQ和Kafka的主要区别如下：1、消息协议：RabbitMQ使用AMQP（高级消息队列协议），而Kafka使用其自定义的协议。AMQP是一种标准协议，可以提供更强的互操作性，但Kafka的自定义协议可能具有更高的性能。2、消息格式：RabbitMQ支持多种消息格式，如JSON、XML等，而Kafka只支持二进制格式。这使得RabbitMQ在处理复杂消息时更为灵活。3、息持久性：RabbitMQ支持消息的持久化，可以将消息存储在磁盘上，以确保消息不会在服务器崩溃时丢失。而Kafka也支持消息的持久化，但它的设计目标是为了实现高吞吐量，因此可能会牺牲一些持久化性能。4、消息确认机制：RabbitMQ支持消息的确认机制，可以确保消息已经被消费者接收。而Kafka使用基于消费者的组的确认机制，只有在消费者组中的所有消费者都成功消费消息时，才会确认消息已经消费。5、可扩展性：Kafka比RabbitMQ更具有可扩展性，可以更容易地添加更多的节点以扩展消息处理能力。消息队列系统的功能：1、消息发送：应用程序可以将消息发送到消息队列中，以便另一个应用程序在需要时读取它。2、消息接收：应用程序可以从消息队列中接收消息，以便进行处理。3、消息存储：消息队列系统可以将消息存储在队列中，以便在需要时进行读取或处理。4、消息传递：消息队列系统可以确保消息在发送和接收之间可靠地传递，并处理任何传输错误或丢失。5、消息处理：应用程序可以读取消息并处理它，以便进行后续操作。
