基础概念
Topic
一个topic相当于一个数据库中的表，同一类数据“存储”在一个topic中。topic只是一个逻辑概念，具体数据存储在partition中。
Partition
分区具体在服务器上面表现起初就是一个目录。
一个Topic有多个分区，这些分区会存储到不同的服务器上面，或者说，其实就是在不同的主机上建了不同的目录。
分区的主要信息就存在了.log文件里面。
分区概念的引入也是Kafka性能高的主要原因之一。多个分区多个线程，多个线程并行处理肯定回避单线程好得多。
Partition相当于分布式存储单元。
这个设计是保证了海量数据处理的基础。加锁没有分区100T的文件只能单独存放在一个服务器上面，那就直接沾满了整个服务器了。
注意：
- 分区会有单点故障问题，所以我们会为每个分区设置副本数。
- 分区的编号是从0开始的。
Broker
Broker就是一个Kafka实例，用于接收和转发消息。
Producer
往消息系统里面发送数据的就是生产者。
Consumer
从Kafka里读取数据的称之为消费者。
Consumer Group
设置了同一个group id的consumer，为同一个group。
在同一个Consumer Group内，一条消息只能被一个Consumer消费。
如果想让一个消息让多个消费者消费的话，那就为每个消费者设置不同的group id。
Message
Kafka里面的我们处理的数据叫做消息。
ISR and AR
简单来说，分区中的所有副本统称为AR(Assigned Replicas)。所有与leader副本版本一定程度同步的副本（包括leader副本在内）组成ISR(In Sync Replicas)。ISR集合是AR集合的一个子集。
消息会先发送到leader副本，然后follower副本才能从leader中拉取消息进行同步。同步期间，follow副本相对于leader副本而言会有一定程度的滞后。
与leader副本同步滞后过多的副本（不包括leader副本）将组成OSR（Out-of-Sync Replied）由此可见，AR=ISR+OSR。正常情况下，所有的follower副本都应该与leader副本保持一定程度的同步，即AR=ISR，OSR集合为空。
ISR的伸缩性
leader副本负责维护和跟踪ISR集合中所有follower副本的滞后状态，当follower副本落后太多或失效时，leader副本会把它从ISR集合中剔除。如果OSR集合中所有follower副本"追上"了leader副本，那么leader副本会把它从OSR集合中移至ISR集合。
默认情况下，当leader副本发生故障时，只有在ISR集合中的follower副本才有资格被选举为新的leader，而在OSR集合中的副本则没有任何机会。
集群
假设创建一个名称为topicA的Topic，分区个数为3，集群中Kafka的实例为3（即Broker个数），那么将会产生3个分区，每个Broker下面会有一个文件夹
kafka-topics.bat --create --zookeeper 127.0.0.1:2181 --replication-factor 1 --partitions 3 --topic TopicA
如下图所示：
可以看到，在三台服务器上，都创建了一个文件夹，文件夹的名字以Topic-开头，index结尾，index从0开始。
可以看到这种上面这种情况存在一个问题，会出现单点故障。如果某一台服务器出现了问题，那么将无法提供服务。
所以就引出了副本的概念。
Replica 副本
Kafka中的Partition为了保证数据安全，所以每个Partiton可以设置多个副本。
kafka-topics.bat --create --zookeeper 127.0.0.1:2181 --replication-factor 2 --partitions 3 --topic topicA
脚本中 --replication-factor 设置的是副本个数。这里我们设置每个分区的副本个数为2。
查看一下topicA的描述信息
kafka-topics.bat --describe --topic topicA --zookeeper 127.0.0.1:2181
| Topic:topicA | PartitionCount:3 | ReplicationFactor:2 |
|---|---|---|
| Topic:topicA | Partition:0，Leader:0 | Replicas:0,1 |
| Topic:topicA | Partition:1，Leader:1 | Replicas:1,2 |
| Topic:topicA | Partition:2，Leader:2 | Replicas:2,0 |
由上面的表格可以看到，三个分区，每个分区有一个Leader以及一个副本。
上图可以看到：数据是由master同步到follower，保证主从数据一致。当主挂了的时候，从节点可以立即接手，充当master节点，从而保证服务的高可用。
Consumer Group
上面说到同一个Consumer Group中，同一条消息只有一个Consumer消费数据。一个分区的数据只能被一个Consumer消费，而一个Consumer可以消费多个Partition。所以在同一个Group内，最好的情况是Consumer个数等于Partition个数，这样能够最有效的利用资源。如果Consumer个数多于Partition个数，那么会有消费者没办法消费数据。
上图中ConsumerC处于不消费状态，只有在其他的消费者崩溃或者宕掉的情况下，才有可能接收数据。
生产者只往master节点发送数据。
Kafka性能好在什么地方？
一、顺序写
操作系统每次从磁盘读写数据的时候，需要先寻址，也就是先要找到数据在磁盘上的物理位置，然后再进行数据读写，如果是机械硬盘，寻址就需要较长的时间。
Kakfa的设计中，数据其实是存储在磁盘上面，一般来说，会把数据存储在内存上面性能才会好。
但是Kafka用的是顺序写，追加数据是追加到末尾，磁盘顺序写的性能极高，在磁盘个数一定，转数达到一定的情况下，基本和内存速度一致。
随机写的话是在文件的某个位置修改数据，性能会较低。
二、零拷贝
先来看看非零拷贝的情况：
可以看到数据的拷贝从内存拷贝到Kafka服务进程那块，又拷贝到Socket缓存那块，整个过程耗费的时间比较高。
Kafka利用了Linux的sendFile技术（NIO），省去了进程切换和一次数据拷贝，让性能变得更好。
三、日志分段存储
Kafka规定了一个分区内的.log文件最大为1G，做这个限制的目的是为了方便把.log加载到内存去操作：
00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex
00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex
00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex
这个9936472之类的数字，就是代表了这个日志段文件里包含的起始Offset，也就说明这个分区灼烧都写入了近1000万条数据了。
Kafka Broker有一个参数，log.segment.bytes，限定了每个日志段文件的大小，最大就是1G。
一个日志段文件满了，就自动开一个新的日志段文件来写入，避免单个文件过大，影响文件的读写性能，这个过程叫做log rolling，正在被写入的那个日志段文件，叫做active log segment。
如果对HDFS有了解的就会发现NameNode的edits log 也会做出限制，所以这些框架都会考虑这些问题。
四、Kafka的网络设计
Kafka 的网络设计和 Kafka 的调优有关，这也是为什么它能支持高并发的原因：
首先客户端发送请求全部会先发送给一个 Acceptor，Broker 里面会存在 3 个线程（默认是 3 个）。
这 3 个线程都是叫做 Processor，Acceptor 不会对客户端的请求做任何的处理，直接封装成一个个 socketChannel 发送给这些 Processor 形成一个队列。
发送的方式是轮询，就是先给第一个 Processor 发送，然后再给第二个，第三个，然后又回到第一个。
消费者线程去消费这些 socketChannel 时，会获取一个个 Request 请求，这些 Request 请求中就会伴随着数据。
线程池里面默认有 8 个线程，这些线程是用来处理 Request 的，解析请求，如果 Request 是写请求，就写到磁盘里。读的话返回结果。
Processor 会从 Response 中读取响应数据，然后再返回给客户端。这就是 Kafka 的网络三层架构。
所以如果我们需要对 Kafka 进行增强调优，增加 Processor 并增加线程池里面的处理线程，就可以达到效果。
Request 和 Response 那一块部分其实就是起到了一个缓存的效果，是考虑到 Processor 们生成请求太快，线程数不够不能及时处理的问题。
所以这就是一个加强版的 Reactor 网络线程模型。
