ActiveMQ、RabbitMQ是用的比较多得消息队列，但是随着时间的推移，大数据的应运而生，这两种消息队列使用的也是越来越少了，Kafka渐渐进入开发人员的视线，再加上Kafka天生的集群运行、大数据量的处理能力，以及数据的持久化能力等，主导地位也是必然的事情。
1. Kafka的前世今生
Kafka最初是LinkedIn的一个内部基础设施系统。最初开发的起因是，LinkedIn虽然有了数据库和其他系统可以用来存储数据，但是缺乏一个可以帮助处理持续数据流的组件。所以在设计理念上，开发者不想只是开发一个能够存储数据的系统，如关系数据库、Nosql数据库、搜索引擎等等，更希望把数据看成一个持续变化和不断增长的流，并基于这样的想法构建出一个数据系统，一个数据架构。
Kafka可以看成一个流平台，这个平台上可以发布和订阅数据流，并把他们保存起来，进行处理。Kafka有点像消息系统，允许发布和订阅消息流，但是它和传统的消息系统有很大的差异，首先，Kafka是个现代分布式系统，以集群的方式运行，可以自由伸缩。其次，Kafka可以按照要求存储数据，保存多久都可以，第三，流式处理将数据处理的层次提示到了新高度，消息系统只会传递数据，Kafka的流式处理能力可以让我们用很少的代码就能动态地处理派生流和数据集。所以Kafka不仅仅是个消息中间件。
2. KafKa基本概念
2.1 消息和批次
消息，Kafka里的数据单元，也就是我们一般消息中间件里的消息的概念。消息由字节数组组成。消息还可以包含键，用以对消息选取分区。
为了提高效率，消息被分批写入Kafka。批次就是一组消息，这些消息属于同一个主题和分区。如果只传递单个消息，会导致大量的网络开销，把消息分成批次传输可以减少这开销。但是，这个需要权衡，批次里包含的消息越多，单位时间内处理的消息就越多，单个消息的传输时间就越长。如果进行压缩，可以提升数据的传输和存储能力，但需要更多的计算处理。
2.2 主题和分区
Kafka里的消息用主题进行分类，主题下有可以被分为若干个分区。分区本质上是个提交日志，有新消息，这个消息就会以追加的方式写入分区，然后用先入先出的顺序读取。
但是因为主题会有多个分区，所以在整个主题的范围内，是无法保证消息的顺序的，单个分区则可以保证。Kafka通过分区来实现数据冗余和伸缩性，因为分区可以分布在不同的服务器上，那就是说一个主题可以跨越多个服务器。前面我们说Kafka可以看成一个流平台，很多时候，我们会把一个主题的数据看成一个流，不管有多少个分区。
3. 生产者和消费者、偏移量、消费者群组
生产者：生产者默认情况下把消息均衡分布到主题的所有分区上，如果需要指定分区，则需要使用消息里的消息键和分区器。
偏移量：消费者订阅主题，一个或者多个，并且按照消息的生成顺序读取。消费者通过检查所谓的偏移量来区分消息是否读取过。偏移量是一种元数据，一个不断递增的整数值，创建消息的时候，Kafka会把他加入消息。在一个分区里，每个消息的偏移量是唯一的。每个分区最后读取的消息偏移量会保存到Zookeeper或者Kafka上，这样分区的消费者关闭或者重启，读取状态都不会丢失。
消费者群组：多个消费者可以构成一个消费者群组。怎么构成？共同读取一个主题的消费者们，就形成了一个群组。群组可以保证每个分区只被一个消费者使用。消费者和分区之间的这种映射关系叫做消费者对分区的所有权关系，很明显，一个分区只有一个消费者，而一个消费者可以有多个分区。
3.1 Broker和集群
一个独立的Kafka服务器叫Broker。Broker的主要工作是接收生产者的消息，设置偏移量，提交消息到磁盘保存；为消费者提供服务，响应请求，返回消息。在合适的硬件上，单个Broker可以处理上千个分区和每秒百万级的消息量。
多个Broker可以组成一个集群。每个集群中Broker会选举出一个集群控制器。控制器会进行管理，包括将分区分配给Broker和监控Broker。
集群里，一个分区从属于一个Broker，这个Broker被称为首领。但是分区可以被分配给多个Broker，这个时候会发生分区复制。
4. 日志
日志：Kafka是会把数据进行持久化，但是如何持久化？就是通过日志，消息请求到Kafka服务后会分配到对应的分区进行持久化，每个Broker都有至少一个日志路径，每个分区都是有对应的日志文件进行持久化。用于在日志进行恢复使用。
其实换句话说，可以把这个日志理解成消息的数据库。
5. 基本结构了解
图中内容不多做解释，基本都在上面的概念中，结合概念理解，效果会更好。
6. 为什么选择Kafka
为什么越来越多的公司选择Kafka？看下面的表格：
| ActiveMQ | RabbitMQ | RocketMQ | Kafka | |
|---|---|---|---|---|
| 性能（单台） | 6000+ | 万级(12000+) | 十万级 | 百万级 |
| 消息持久化 | 支持 | 支持 | 支持 | 支持 |
| 多语言支持 | 支持 | 支持 | 很少 | 支持 |
| 社区活跃度 | 高 | 高 | 中 | 高 |
| 支持协议 | 多（JMS,AMQP….. ） | 多（AMQP,STOMP,MQTT….. ） | 少 | 少 |
| 综合评价 | 优点： 成熟，已经在很多公司得到应用。较多的文档。各种协议支持较好，有多个语言的成熟客户端。缺点：性能较弱。缺乏大规模吞吐的场景的应用，有江河日下之感。 | 优点：性能较好，管理界面较丰富，在互联网公司也有较大规模的应用，有多个语言的成熟客户端。缺点：内部机制很难了解，也意味很难定制和掌控。集群不支持动态扩展。 | 优点：模型简单，接口易用。在阿里有大规模应用。分布式系统，性能很好，版本更新很快。 缺点：文档少，支持的语言较少,尚未主流。 | 优点：天生分布式，性能最好，所以常见用于大数据领域。 缺点：运维难度大，偶尔有数据混乱的情况，对ZooKeeeper强依赖。多副本机制下对带宽有一定的要求。 |
