kafka名词说明
分布式 高吞吐量 消息系统
producer：生产者
consumer：消费者
broker：机器，节点
controller：kafka服务器的主节点 负责管理元数据（zk存储一份）
follower：kafka服务器的从节点 （同步元数据）
topic：主题。类似于关系型数据库中的表
partition：一个主题可以有多个分区
replica：副本，为了保证数据安全，每个partition可以设置多个副本（leader replica和slave replica）
message：消息 存放在partition里
offset：偏移量 消费者的消费进度
NIO：同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理
reactor
跳表索引 空间换时间 加快消息所在文件查找
producer端高性能：批处理、内存池、封装同一服务器请求
批处理是消息达到16K或者默认0ms发送一批次 batch.size linger.ms
consumer
同一消费者组内部是P2P模式，一个消息只能被同一个消费者组的一个消费者消费
不同组是发布订阅模式
0.10后偏移量存储方式由zk改为kafka自身的topic 名字为__consumer_offsets-0到49默认50分区
zk不适合高并发
如何通过offset查找Message
例如，读取offset=368776的Message，需要通过如下两个步骤。
第一步：查找Segment File.
00000000000000000000.index表示最开始的文件，其实偏移量（offset）为0；第二个文件00000000000000368769.index的其实偏移量为368770（368769+1），依次类推。以其实偏移量命名并排序这些文件，只要根据offset**二分查找**文件列表，就可以快速定位到具体文件。
当offset=368776时，定位到00000000000000368769.index|log。
第二步：通过Segment File 查找Message。
通过第一步定位到Segment File,当offset=368776时，依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址，然后再通过00000000000000368769.log顺序查找，知道offset=368776为止。
Segment Index File采取稀疏索引存储方式，可以减少索引文件大小，通过Linux mmap接口可以直接进行内存操作。稀疏索引为数据文件的每个对应Message设置一个元数据指针，它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。
kafka元数据刷新时间默认5min
生产者发送数据流程
消息封装成ProducerRecord
序列化
消息计算分区(带key为hash，不带为轮询；与broker通信获取元数据信息)
将消息放到RecordAccumulator（缓存默认32M）
启动一个Sender线程，去缓存中取消息，封装成批次（默认16K）
该线程将批次数据发送到broker
RecordAccmulator 原理
ISR：副本同步队列
AR：所有副本
isr由leader负责维护，follower从leader同步数据有一定的延迟，如果某个follower超过该阈值没有完成同步，leader就会把该follower从isr中剔除，放到osr中，
osr+isr = ar
kafka中的broker 是干什么的
broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。
producer如何优化速度：
增加线程
提高 batch.size
增加更多 producer 实例
增加 partition 数
设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。
消费者分区分配策略
range
range策略是基于每个主题的 对于每个主题，我们以数字顺序排列可用分区，以字典顺序排列消费者。然后，将分区数量除以消费者总数，以确定分配给每个消费者的分区数量。如果没有平均划分（PS：除不尽），那么最初的几个消费者将有一个额外的分区。
轮询
轮询分配策略是基于所有可用的消费者和所有可用的分区的
与前面的range策略最大的不同就是它不再局限于某个主题
如果所有的消费者实例的订阅都是相同的，那么这样最好了，可用统一分配，均衡分配
丢数据场景：
ack=0 没有消息确认，
ack=1 leader收到消息即发送ack，此时如果isr中的follower还没同步leader，leader就出问题，这部分数据就回丢失
ack=-1 等待所有follower同步完数据后，再发送ack，延时高，数据安全性最高，也会出现丢失数据的情况：如果isr中只有leader一台机器时，相当于ack=1的时候
另一个是使用高级消费者的时候消费者读完数据就提交offset，但数据还没处理完就挂掉了，此时重新启动后上一部分数据就不能再消费（使用低级消费者）
数据重复场景：
cks = -1 的情况下，数据发送到 leader 后 ，部分 ISR 的副本同步，leader 此时挂掉。比如 follower1 和 follower2 都有可能变成新的 leader, producer 端会得到返回异常，producer 端会重新发送数据，数据可能会重复
另外, 在高阶消费者中，offset 采用自动提交的方式, 自动提交时，假设 1s 提交一次 offset 的更新，设当前 offset = 10，当消费者消费了 0.5s 的数据，offset 移动了 15，由于提交间隔为 1s，因此这一 offset 的更新并不会被提交，这时候我们写的消费者挂掉，重启后，消费者会去 ZooKeeper 上获取读取位置，获取到的 offset 仍为10，它就会重复消费. 解决办法使用低级消费者
Kafka中是怎么体现消息顺序性的？
kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.
KAFKA速度快的原因：
直接使用linux的cache高效缓存数据
顺序写磁盘 减少寻址
使用零拷贝 传统的数据发送需要发送四次上下切换，采用sendfile系统调用后，数据直接在内核态转换，系统上下文切换变成2次
数据传输的事物定义有哪三种？
数据传输的事务定义通常有以下三种级别：
（1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
（2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
（3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而
且仅仅被传输一次，这是大家所期望的
Kafka 判断一个节点是否还活着有那两个条件？
（1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连
接
（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
producer 是否直接将数据发送到 broker 的 leader(主节点)？
producer 直接将数据发送到 broker 的 leader(主节点)，不需要在多个节点进行分发，为了
帮助 producer 做到这点，所有的 Kafka 节点都可以及时的告知:哪些节点是活动的，目标
topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了
Kafa consumer 是否可以消费指定分区消息？
Kafa consumer 消费消息时，向 broker 发出"fetch"请求去消费特定分区的消息，consumer
指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有
了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的
Kafka 消息是采用 Pull 模式，还是 Push 模式？
producer 将消息推送到 broker，consumer 从 broker 拉取消息
Kafka 存储在硬盘上的消息格式是什么？
消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32
校验码。
消息长度: 4 bytes (value: 1+4+n)
版本号: 1 byte
CRC 校验码: 4 bytes
具体的消息: n bytes
Kafka 与传统消息系统之间有三个关键区别
(1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据
提升容错能力和高可用性
(3).Kafka 支持实时的流式处理
Kafka 高效文件存储设计特点：
(1).Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定
期清除或删除已经消费完文件，减少磁盘占用。
(2).通过索引信息可以快速定位 message 和确定 response 的最大大小。
(3).通过 index 元数据全部映射到 memory，可以避免 segment file 的 IO 磁盘操作。
(4).通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小
Kafka 新建的分区会在哪个目录下创建
在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，
这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘
上用于提高读写性能。
当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。
如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个
目录下创建文件夹用于存放数据。
但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？
答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic
名+分区 ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就
是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁
盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。
partition 的数据如何保存到硬盘
topic 中的多个 partition 以文件夹的形式保存到 broker，每个分区序号从 0 递增，
且消息有序
Partition 文件下有多个 segment（xxx.index，xxx.log）
segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为 1g
如果大小大于 1g 时，会滚动一个新的 segment 并且以上一个 segment 最后一条消息的偏移
量命名
消费者负载均衡策略
一个消费者组中的一个分片对应一个消费者成员，他能保证每个消费者成员都能访问，如
果组中成员太多会有空闲的成员
kafaka 生产数据时数据的分组策略
生产者决定数据产生到集群的哪个 partition 中
每一条消息都是以（key，value）格式
Key 是由生产者发送数据传入
所以生产者（key）决定了数据产生到集群的哪个 partition