redis：
主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用。
RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上。
kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。
2)在吞吐量，
rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。
kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。
3)在可用性方面，
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka的broker支持主备模式。
4)在集群负载均衡方面，
rabbitMQ的负载均衡需要单独的loadbalancer进行支持。
kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。
//______________________________________________________________
功能上，两者都是实现了AMQP协议。那么在使用上的最大区别是什么呢？如何根据自己的需求进行选型？
kafka是严格顺序保证的消息队列。即使在分布式环境下，也保证在同一分区内消息的顺序性。既然是顺序的，那么在同一个Topic下面，如果前面的消息没有消费完毕(收到回应)，则不能读取下一条消息。那么在消费端，就变成了一个单线程操作，无法并发。虽然kafka可以通过分区实现并发，不过这个需要用多台kafka实现。
还有个办法是在消费kafka消息的时候，消费完立即交给线程池处理，这样可以极大提高并发性。不过这样带来的问题是，如果线程没有处理完机器挂了，就会出现消息丢失的情况，需要在设计上考虑到。
Rabbitmq不承诺消息的顺序性，因此可以并发多线程处理。在队列中不必排队。如果你对顺序处理没有要求，可以用Rabbitmq实现较大的并发。
关于消息顺序问题
1.生产者生产消息，broker相当于一个内存队列，是可以保证顺序的
2.只有在多消费者或者多线程的消费的时候，才会出现顺序问题。
3.而对于解决顺序问题，又有相应的策略，
kafka是使用partition来指定某个消费者消费，
Rabbitmq是使用不同的队列绑定到消费者
原文：https://www.cnblogs.com/bobdeng/p/8431829.html