Kafka

kafka是个日志处理缓冲组件，主要在大数据信息处理中使用。和传统的消息队列相比简化了队列结构和功能，以文件流形式处理存储（持久化）消息（主要是日志）。

日志信息通常数据量巨大，处理组件一般会处理不过来，所以有了缓冲层kafka。kafka支持巨大的日志吞吐量。为了防止数据丢失，其消息被消费后不会直接丢弃，要多存储一段时间，等超过设置的时间阈值才会丢弃。这是mq和redis所不具备的。

主要特点如下:

巨型存储量: 支持TB甚至PB级别数据。

Kafka作为新一代的消息系统，mq是比较成熟消息系统，而redis也可以发布订阅，那么这三者有何异同？

RabbitMQ

是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

KAFKA

本人所在的公司使用kafa作为ETL数据通道，通过kafka配套的connect和schemaRegisty来方便快速实现异构数据源的相互转换和存储，通过connect插件生产和消费数据，通过schemaRegisty转换异构数据（可以在几乎所有你知道的数据源之间相互转换），并且数据可以重复被消费（可以通过配置指定数据存储时长）。kafka的开发团队围绕着kafka开发了一整套自成体系的生态圈（confluent platform）。

优点：

1. 可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
2. 高性能。Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
3. 容错性。Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。

缺点：

Redis

看到问题的第一个反应是，MQ和Redis有啥可比性，再看了看题目【作为消息队列使用时】，仔细想了想Redis何尝不能作为消息队列使用呢，就算是用数据库实现也完全没有问题。

Redis其实可以当做一个轻量级的队列使用。Redis在数据量大的时候入队较慢，Redis出队则无论数据量大小性能都不错。

只不过消息队列中的很多功能都需要额外实现，平时我们还是把它用作内存数据库吧。

分别来说一下：

kafka目前主要作为大数据的流式处理的队列组件，作为大数据的组件，必然是可以处理海量的数据，并且必须具备高可用的特性，是一种分布式的消息队列，保存的数据既有内存中，也有硬盘中，硬盘中的数据默认保留7天。

redis作为目前大热的内存nosql，是一种分布式的内存k-v型数据库，也可以作为消息队列使用，是使用了redis的列表类型，并非专门的消息队列，相比于kafka而言，无法处理海量的数据，但是读取速度由于是内存读取，速度相对较快。

mq作为传统的消息队列，主要应用于传统项目，相对于前二者而言不具备分布式高可用特性。

可按需求来使用。

补充一下使用场景：

Redis 消息队列：高并发，轻量级，低延迟，吞吐量不大，对持久化要求不高的场景

Kafka消息队列：高吞吐量，实时流式处理，持久化，高可用在至100k+/sec，多一次语义

Mq:轻量级消息，高可用在20k+/sec，快速响应，更好的事务控制，更复杂的路由支持，和更多开发语言的兼容支持。

RabbitMQ

是使用 Erlang 编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人（Broker）构架，这意味着消息在发送给客户端时先在中排队。对路由（Routing），负载均衡（Load balance）或者数据持久化都有很好的支持。

Redis

是一个 Key-Value 的 NoSQL 数据库，开发维护很活跃，虽然它是一个 Key-Value 数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于 RabbitMQ 和 Redis 的入队和出队操作，各执行 100万次，每 10 万次记录一次执行时间。测试数据分为 128Bytes、512Bytes、1K 和 10K 四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于 RabbitMQ，而如果数据大小超过了 10K，Redis 则慢的无法忍受；出队时，无论数据大小，Redis 都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。