好，我们先来张图，
本来想画张图，一直没有去做，先用这张图。很经典
ps：这张图其实就是今天的主角。废话不多说，直接说重点。
为什么要贴这样一张图，这张图太牛逼了，
，这里体现的，它亦乎天然的节点扩展能力，决定它无与伦比高效的读写能力，让你觉得原来软件设计是如此的美妙的一件事啊，好了，下面就说说，这伟大的设计。ps：装逼了。。
首先这里有3个broke，可以理解为开了3个kafka服务，不管它是在一台服务器上还是3台服务器上都可以，其实就是kafka集群，开的越多，我现在可以告诉你，读写能力就会越强，那到底是怎么回事呢？
下面就要讲到今天主角-分区，主角也将决定kafka读写能力的主角。就是如图的各partitions，这个东西很重要，kafka的核心设计。如下图来自官网
现在咱们就以发布订阅模式来剖析它，这个模式大家应该都比较熟悉，简单而言就是生产者发布消息，消费者订阅消息进行消费，还不懂的，请自行补习了哈。
好了，partitions其实就是存数据的地方了，就是发布的消息，消费的消息，都会来自于此。再仔细看图，一个topic0中，在每个broke中分别有partition0.partition1.partition2，（最后那个应该是partition2，这里我觉得有点不对，所以说要自己画这张图）
等等，这些多partions，发布的消息，具体要落到那个partitions中呢，还是落到所有的partitions中呢，“所有这个”是之后讲的主从备份主从选举高可用的功能了。所以kafka也有主从机制的哦。如果具体只落到某一个partitions中，那规则是什么呢？其实发布者（客户端）发布消息都会带有一个key，这个key，hash再于所有partitions数取模之后，就会得到具体某个分区partitions的索引，比如得到0就是partition0，1就是partition1，这种算法在很多场景都有运用，而且非常高效。
好了，现在知道数据是根据key来定位到某个partition上的，那比如说有100个设备，往kafka发数据，device1.device2…device100。像这里总共有3个borke，有三个partitions，partition0、partition1、partition2，然后可能就是这样分布，device1.device3等30个的数据会落到partition0，device2.device5等34个的数据会落在partition1，device3，device4等36个的数据会落在partition2，分区数不变的情况，这些device，就会固定发到某个分区上了，这样每个机器的发送的数据，不也很均匀的落在3个partition中了吗，这样是不是就有3个设备可以同时往kafka发送消息的并发能力了？如果多台集群不就有多个并发发送的能力了吗，而且对于每个partitions机会其实也均等，这也是为什么通常运用到日志系统和互联网中，对内容一致性要求不那么高对吞吐量要求很高的场景了，因为理论上来说的话，有多少个分区就具体多强的并发能力了，如上图也能感受出来了把。
接下来再讲讲分区的内部的结构，先也来张图，官网的
虽然生产可以并发往partition输送数据，消费者当然也可以，但是消息者可以共用一个partition嘛。当然可以，依靠的就是每个消费者自己维护的offset，比如说如上图，消费者A现在正在消费offset=9这条数据，让该消费者就知道我下次消费的就是offset=10这条数据了。所以不官你生产者怎么生产数据，消费只要知道自己消费的位置就行了，虽然offset是partition的，但是我们自己知道自己消费到哪了，各消费者也就不会产生冲突了。
接着，我们再来看第一张图，讲主从备份。
主从备份，是kafka是保证数据的高可用而设计，在系统的设计中，CAP原理，只能满足其中的两项，这里保证了高可用，所有它就是AP，也验证了前面的说的适合一致性弱，吞吐量大的场景的运用。既然是主从备份，那一般都有选举机制了。其实确实是这样的，采用就是zookeeper的选举机制，所以kafka是要结合zookpeepr来用的，一开始有一个broke中的一个主题中一个分区为主，用来读写，其他broke中的同一个主题的另外一些分区为备份，并不会参与读写，主要是备份(固网有句这样的话： All reads and writes go to the leader of the partition. Typically, there are many more partitions than brokers and the leaders are evenly distributed among brokers. The logs on the followers are identical to the leader’s log—all have the same offsets and messages in the same order (though, of course, at any given time the leader may have a few as-yet unreplicated messages at the end of its log).意思是所有的读写都是发生在主节点上，通常由比broke更多的主节点分区交错分布在不同broke上，从节点保持和主节点一样的offset和消息，但是往往在发生主从复制的时候，主上面还有一些消息还没有同步，所以说它是有可能数据丢失的），如第一图中的绿色箭头那样，现在三个broke就有一个主，两个备份分别再不同的broke上，用来宕机时的主从切换，当主的节点挂掉之后，zookpeeper就会从备中的选举其中一个作为主，继续承担读写的功能，从而实现高可用，主从的功能在发布一个topic的时候，是可以设置的。 bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test
如官网创建一个topic，需要指定–replication-factor，实际上就是指定主从的数量，默认一个，就是一个主，
如果多个就是一个主，其他都是从，当然这种从实际上放在其他的节点上面，才是有意义，所以一般也就需要相当台的
服务主机作为支撑了。
还有一个重要的知识点就是producer发布生产数据时的级别，ack就是回复，有三个级别。
ack=0，级别最低，发送完就不管了，所以级别是最低，效率也是最高的，但是容易丢失数据。
ack = 1 该级别需要等到broken上主分区的确认，所有效率次之，如果，如果主节点挂了，消费者就消费不到数据了。
ack=-1 这种级别最高，但是效率也最差，就是要等待所有从的确认，所有面对高吞吐量的场景不适合，显然一个个确认非常耗时。
最后，还有一个非常的重要的消费端模式，需要介绍下，就是同一个消费组，消费一个topic，一个消费者只能消费一个分区，多余消费者根本就不参与消费，多余的分区也是不能被消费到的，也验证前面说的。
至此已经把kafka基本的结构图说清楚了。实际项目中用它的时候，了解到这个层次也就差不多，但是以上的一些概念和特点，也是做kafka的时候，我认为必须了解的，要不你很可能就是拿来用，并不不了解它的原理，适合做什么事，怎样可能达到优化你项目的目的。