kafka是流文件处理平台中可以说是成功的，毕竟现在涉及的领域之大已经不得不让我们多少了解一点。kafka也算是我工作以来接触最多的一项技术了，截止目前也就刚能达到勉强能用的程度。
kafka官方给出的定义是：
kafka是一个分布式的流处理平台。有高吞吐、高容错、支持发布-订阅的特点。
kafka是个分布式的系统，所以这就决定了这个系统是强依赖zookeeper的，需要一个第三方的管理员来调用kafka的主机资源，消费者分配等。
我认为kafka是一个简单的消息处理平台，通俗一点讲就是，往一个池子里注水，排水的过程。大致分为三部分，简单画一下：
这三部分都是可以由多个组成的，多profucer、多Brokers、多Consumers。
Brokers是一般是一个>1的集群
由zookeeper进行管理调度，这里最主要的是leader的选举，follower的复制。consumer的话也由zookeeper进行协调对应topic的对应partition的，下面详细说一下：
生产者（Producer）
这是数据的生产者，通过这部分操作把数据发送的kafka的主机上，就是向池子里注水，当然，注水口可以是1，可以为多；
Broker：相当于水池
它在这等着生产者不断的注水，消费者不断的排水，这样很容易就产生一个矛盾说是进的多，拍的少的话，池子很快就满了，这个是有考虑的，比如消息的存放时间、消息的压缩存储、消息分区的规划等，之后详细介绍。
消费者（Consumer）
消息的消费者，是从水池排水、抽水的角色，这歌跟实际的抽水还是不太一样的，Broker里面存放的是消息，消息的消费是可以重复的、可以多个消费者同时、分时，重复消费的，当然这是在消息生存的周期内来说的，一般主机上消息的存放时间是7天。
既然庞大的数据都扔到这样一个池子里面，怎么会实现高吞吐的性能呢？
这里就要说到kafka中Topic这个概念。生产、消费都已topic为关键词，比如我在生产数据的时候，我要指定这个关键词，我这一批数据都扔到这个关键词上当成一类处理，还有就是先后生产的数据是在磁盘上顺序存储的，这时候有朋友就应该能想到：磁盘的顺序读写速度可是不输给内存的，所以才使kafka高吞吐的性能成为可能。
Topic这个类下面还有个Partition的概念，partition是topic下面的分区，在生产的时候可以轮询写入到这个topic的多个partition里，这样也为数据的查询提高了更快的速度，有实验已经验证过，topic的多partition的吞吐率（TPS）是要高于单partiton的。
好了，今天就写这么多吧，也算是带大家在学习kafka的基础上入个门。
下面附上官网这张图吧，可能有助于大家理解，其实主要是因为它比我画的那个好看。哈哈！
