MQ - KAFKA 基础篇

##1、KAFKA的核心组件/API
Producer API，它允许应用程序向一个或多个 topics 上发送消息记录

Consumer API，允许应用程序订阅一个或多个 topics 并处理为其生成的记录流

Streams API，它允许应用程序作为流处理器，从一个或多个主题中消费输入流并为其生成输出流，有效的将输入流转换为输出流。

Connector API，它允许构建和运行将 Kafka 主题连接到现有应用程序或数据系统的可用生产者和消费者。例如，关系数据库的连接器可能会捕获对表的所有更改
如下是KAFKA API图

##2、KAFKA的一些概念
我们从几个图来了解KAFKA的相关概念

2.1、broker/物理概念：一个kafka服务器实例就是一个broker，多个kafka instance构成kafka cluster。broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。
2.2、topic/逻辑概念：在 kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 topic。在 kafka 中，可以无数个topic。
2.3、partion/物理概念：默认一个topic有一个分区（partition），自己可设置多个分区（分区分散存储在服务器不同节点上），partition在磁盘上就体现为一个目录。一个分区就是一个 提交日志。消息以追加的形式写入分区，先后以顺序的方式读取。
2.4、segment/物理概念：一个partition当中存在多个segment文件段，每个 segment 文件的大小相等且每个segment分为两部分，.log文件和.index文件，其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置
2.5、producer/物理概念：生产消息并通过zookeeper集群得知broker地址将消息push到broker中
2.6、consumer/物理概念：生产消息并通过zookeeper集群得知broker地址将消息从broker中pull到
2.7、zookeeper cluster/物理概念：相当于注册中心，含有broker信息，producer信息，consumer信息
2.8、consumer group/逻辑概念：由多个consumer组成共同消费broker/topic中的消息，消费者在消费消息时需要提供一个group id。注意的是同组消费者是处于竞争关系，即消息只能被同组中的某个消费者消费
2.9、controller/逻辑概念：控制器，在 Kafka 集群中会有一个或多个 broker，其中有一个 broker 会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。
2.10、ConsumerCoordinator与GroupCoordinator：新版本消费者为了降低对zk的依赖，避免羊群效应和脑裂问题，服务端引入了组协调器，消费者客户端引入了消费者协调器负责与服务端的组协调器进行交互。最重要的职责就是负责执行消费者再均衡的操作，包括分区分配的工作也是在再均衡期间完成的。

##3、对于上面kafka概念补充说明
3.1、topic补充说明：
3.1.1：首先它是一个逻辑上的东西，它有多个或一个分区组成，并且当有多个分区且多个broker实例时，一个topic的消息以分区的形式可以存在在不同的broker上。如下图partition0+partition1+partition2=topic，且partition0、partition1、partition2可以自由地分布在不同broker中

3.1.2：topic的Partition数量在创建topic时配置。
3.1.3：Partition数量决定了每个Consumer group中并发消费者的最大数量。如下图有两个broker，且topic被分成P0，P1，P2，P3四个分区，一个组中最大的并发消费数量为group B中的四个。

3.1.4：Partition中写入的offset
kafka当中的partition的offset任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset是一个long类型数字，它唯一标识了一条消息，消费者通过（offset，partition，topic）跟踪记录。结合3.3看就能理解

3.2、Partition副本补充说明：
3.2.1：一个broker下不存在某个partition的副本，副本只能存在在其他broker中，如下图：

3.2.2：副本分为leader副本和follower副本。
leader副本,代表分区本身,生产者的push和消费者pull的时候都只能通过leader推送和获取.凡事都可能例外，在最新版本中存在配置可消费非leader副本（与跨中心镜像容灾相关，日常使用不到）。
follower副本,leader的跟班,负责同步leader的消息,是leader的备份,防止broker故障时丢失消息.对用户来说,不用关心,kafka内部维护,并在leader崩溃时自动选举新的leader。
isr副本集合：跟随leader最快的副本,在leader故障时,可配置优先从isr中选举leader或仅从isr中选举leader. isr是为了提高kafka的吞吐量,当kafka收到消息时,不用等待所有副本回复确认,这是可用性和一致性的权衡.isr在高版本的kafka中有配置的最大等待同步时间确定,低版本中还要再加一个最大延迟的条数.总之是个动态维护的副本子集。

3.3、Segment补充说明
一个partition当中由多个segment文件组成，每个segment文件，包含两部分，一个是.log文件，另外一个是.index文件，其中.log文件包含了我们发送的数据存储，.index文件，记录的是我们.log文件的数据索引值，以便于我们加快数据的查询速度。下图是.index文件和.log文件对应关系：
3.3.1：.index文件3,497代表：数据文件中的第三个message,它的偏移地址为497；.log文件Message 368772表示：在全局partiton中是第368772个message
3.3.2：.index文件采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间

3.4、生产者、消费者、消费者组关系补充说明：
3.4.1：一个consumer group对kafka集群来讲，是逻辑上的一个consumer，各消费一部分数据
3.4.2：一个topic的 partion数 >= 一个consumer group的consumer数,一般建议保持相等,当分区数大于消费者数时,默认分配方式采用range,既partion数/consumer,余数分给前面的几个consumer。consumer group的设置,可灵活实现发布订阅方式(groupId相同)和点对点方式(groupId不同)
3.4.2:生产者是线程安全的，生产者实例数和线程数无关，达到期望的生产速率即可。消费者是线程不安全的，一个线程对应一个消费者实例。生产者消费者均是针对leader而言，其他非leader副本对客户端是不可见的

3.5：controller补充说明：
3.5.1：当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
3.5.2：当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
3.5.3：当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配。
3.5.4：Kafka中的控制器选举工作依赖于ZooKeeper，成功竞选为控制器的broker会在ZooKeeper中创建/controller这个临时（EPHEMERAL）节点。另外配合/controller_epoch节点来确保控制器的唯一性，通过zk的特性保证同一时刻仅有一个控制器且zk记录了最新的控制器纪元，排除旧的控制器的消息干扰，大部分分布式选举组件都有这个功能。