一般的来说，一个Kafka集群包含一个或多个的Producer，一个或多个的Broker，一个或多个的Consumer Group，和一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，管理集群在运行过程中负责均衡、故障转移和恢复什么的。Producer使用Push（推送）的方式将消息发布到Broker，Consumer使用Pull（拉取）的方式从Broker获取消息，两者都是主动操作的。
1.3.1 Topic和Partition
Kafka最初设计初衷就是高吞吐率、速度快。所以在对Topic和Partition的设计中，把Topic分成一个或者多个分区，每个Partition在物理磁盘上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。当我们创建一个Topic是，同时可以指定分区数据，数目越多，吞吐量越大，但是消耗的资源也越多，当我们向Kafka发送消息时，会均衡的将消息分散存储在不同的分区中。在存储的过程中，每条消息都是被顺序写到磁盘上的。（顺序写磁盘的时候比随机写内存的想效率还高，这也是Kafka快的一个原因之一）。
下面是Kafka的写入原理图，可以看出下列消息都是顺序的，消费者消费的时候也是按着顺序来消费的。
对于传统的MQ而言，一般经过消费后的消息都会被删除，而Kafka却不会被删除，始终保留着所有的消息，只记录一个消费者消费消息的offset（偏移量）作为标记，可以允许消费者可以自己设置这个offset，从而可以重复消费一些消息。但不删除肯定不行，日积月累，消息势必会越来越多，占用空间也越来越大。Kafka提供了两种策略来删除消息：一是基于时间，二是基于Partition文件的大小，可以通过配置来决定用那种方式。不过现在磁盘那么廉价，空间也很大，隔个一年半载删除一次也不为过。
1.3.2 Producer
生产者发送消息时，会根据Partition的策略来决定存到那个Partition中，一般的默认的策略是Kafka提供的均衡分布的策略，即实现了我们所要的负载均衡。一般的，当我们的消息对顺序没有要求的话那就多设置几个分区，这样就能很好地负载均衡增加吞吐量了。分区的个数可以手动配置，也可以在创建Topic的时候就事先指定。发送消息的时候，需要指定消息的key值，Producer会根据这个key值和Partition的数量来决定这个消息发到哪个分区，可能里边就是一个hash算法。
1.3.3 Consumer Group 和 Consumer
我们知道传统的消息队列有两种传播消息的方式，一种是单播，类似队列的方式，一个消息只被消费一次，消费过了，其他消费者就不能消费了；另一种是多播，类似发布-订阅的模式，一个消息可以被多个消费者同时消费。Kafka通过消费者组的方式来实现这两种方式，在一个Consumer Group中，每一个Topic中的消息只能被这个组中的一个Consumer消费，所以对于设置了多分区的Topic来说，分区的个数和消费者的个数应该是一样的，一个消费者消费一个分区，这样每个消费者就成了单播形式，类似队列的消费形式。所以说，一个消费者组里边的消费者不能多于Topic的分区数，一旦多于，多出来的消费者就不能消费到消息。另外，不同的消费者组可以同时消费一个消息，这样就实现了多播，类似发布-订阅的模式。我们可以设置每个组中一个消费者的方式来实现发布-订阅的模式。当我们有多个程序都要对消息进行处理时，我们就可以把他们设置到不同的消费者组中，来实现不同的功能。
好了，以上我们已经对Kafka有了一个初步的认识，接下来就可以来使用了。
二、Kafka的安装与使用
使用Kafka需要先安装jdk，1.7以上的版本，配置好环境变量，这一步就不啰嗦了！！
2.1 下载Kafka