一.Kafka概述
1.定义
Kafka最新定义：Kafka是一个开源的分布式事件流平台（Event Streaming Flatform），被数千家公司用于高性能==数据管道==、==流分析==、==数据集成==和==关键任务应用==。
2.消息队列
1）消息队列的应用场景
传统的消息队列的主要应用场景包括：缓存/消峰、解耦和异步通信。
2）消息队列的两种模式
3.Kafka基础架构
1）Producer
消息生产者，就是向Kafka broker发消息的客户端。
2）Consumer
消息消费者，向Kafka broker取消息的客户端。
3）Consumer Group（CG）
消费者组，由多个consumer组成。==消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费==；消费者组之间互不影响。所有的消费者都属于某个消费者组，即==消费者组是逻辑上的一个订阅者==。
4）Broker
==一台Kafka服务器就是一个broker==。一个集群由多个broker组成。==一个broker可以容纳多个topic==。
5）Topic
可以理解为一个队列，生产者和消费者面向的都是一个topic。
6）Partition
为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，==一个topic可以分为多个partition，每个partition是一个有序的队列==。
7）Replica
副本。==一个topic的每个分区都有若干个副本，一个Leader和若干个Follower==。
8）Leader
每个分区多个副本的“主”，==生产者发送数据的对象，以及消费者消费数据的对象都是Leader==。
9）Follower
每个分区多个副本中的“从”，==实时从Leader中同步数据，保持和Leader数据的同步==。Leader发生故障时，某个Follower会成为新的Leader。
二.Kafka生产者
1.生产者消息发送流程
1）发送原理
在消息发送的过程中，涉及到了两个线程——==main线程==和==Sender线程==。
在main线程中创建了一个双端队列RecordAccumulator。main线程将消息发送给RecordAccumulator；
Sender线程不断从RecordAccumulator中拉取消息发送到Kafka Broker。
2.异步发送API
1）带回调函数的异步发送
回调函数会在producer收到ack时调用，为异步调用，该方法有两个参数，分别是==元数据信息（RecordMetadata）==和==异常信息（Exception）==，如果Exception为null，说明消息发送成功，如果Exception不为null，说明消息发送失败。
==注意：消息发送失败会自动重试，不需要我们在回调函数中手动重试。==
3.同步发送API
4.生产者分区
1）分区好处
- 默认的分区器 DefaultPartitioner
5.生产经验
1）生产者如何提高吞吐量
- 批次写入
- 数据压缩
- 增大缓冲区
2）数据可靠性
3）数据去重
==注：开启参数enable.idempotence 默认为true，false关闭。==
4）数据有序
5）数据乱序
三.Kafka Broker
1.Kafka Broker工作流程
1）Zookeeper存储的Kafka信息
- /kafka/brokers/ids 记录有哪些服务器。
- /kafka/brokers/topics/xxx/partition/0/state 记录谁是Leader，有哪些服务器可用。
- /kafka/controller 辅助选举Leader。
- offset存储在kafka主题中。
2）Kafka Broker总体工作流程
2.Kafka副本
1）副本基本信息
（1）Kafka副本作用：提高数据可靠性。
（2）Kafka默认副本1个，生产环境一般配置为2个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
（3）Kafka中副本分为：Leader和Follower。Kafka生产者只会把数据发往Leader，然后Follower找Leader进行同步数据。
（4）Kafka分区中的所有副本统称为AR（Assigned Repllicas）。
==AR = ISR + OSR==
==ISR==，表示和Leader保持同步的Follower集合。如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s。Leader发生故障之后，就会从ISR中选举新的Leader。
==OSR==，表示Follower与Leader副本同步时，延迟过多的副本。
2）Leader和Follower故障处理细节
3.文件存储
1）文件存储机制
Topic数据的存储机制
index文件和log文件详解
2）文件清理策略
Kafka中默认的日志保存时间为7天，可以通过调整如下参数修改保存时间。
log.retention.hours，最低优先级小时，默认7天。
log.retention.minutes，分钟。
log.retention.ms，最高优先级毫秒。
log.retention.check.interval.ms，负责设置检查周期，默认5分钟。
那么日志一旦超过了设置的时间，怎么处理呢？
Kafka中提供的日志清理策略有==delete==和==compact==两种。
delete日志删除：将过期数据删除
- [x] ==log.cleanup.policy = delete 所有数据启用删除策略==
（1）基于时间：默认打开。以segment中所有记录中的最大时间戳作为该文件时间戳。
（2）基于大小：默认关闭。超过设置的所有日志总大小，删除最早的segment。
log.retention.bytes，默认等于-1，表示无穷大。
思考：如果一个segment中有一部分数据过期，一部分没有过期，怎么处理？
- [x] ==compact日志压缩==
4.高效读写数据
- [x] Kafka本身是分布式集群，可以采用分区技术，并行度高
- [x] 读数据采用稀疏索引，可以快速定位要消费的数据
- [x] 顺序写磁盘
- [x] 页缓存 + 零拷贝技术
四.Kafka消费者
1.Kafka消费方式
2.Kafka消费者工作流程
1）消费者总体工作流程
2）消费者组原理
3.消费者API
注意：在消费者API代码中必须配置消费者组id。命令行启动消费者不填写消费者组id会被自动填写随机的消费者组id。
4.分区的分配以及再平衡
说明：Kafka默认的分区分配策略就是Range + CooperativeSticky，所以不需要修改策略。
1）Range以及再平衡
注意：分区数可以增加，但是不能减少。
2）RoundRobin以及再平衡
3）Sticky以及再平衡
粘性分区定义：可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。
粘性分区是Kafka从0.11.x版本开始引入这种分配策略，首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。
5.offset位移
1）offset的默认维护位置
__consumer_offsets主题里面采用key和value的方式存储数据。
key是group.id+topic+分区号；
value就是当前offset的值。
每隔一段时间，kafka内部会对这个topic进行compact，也就是每个group.id+topic+分区号就保留最新数据。
2）自动提交offset
3）手动提交offset
4）指定Offset消费
auto.offset.reset = earliest | latest | none 默认是latest。
当Kafka中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办？
（1）earliest：自动将偏移量重置为最早的偏移量，—from-beginning。
（2）latest（默认值）：自动将偏移量重置为最新偏移量。
（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常。
（4）任意指定offset位移开始消费
5）漏消费和重复消费
重复消费：已经消费了数据，但是offset没提交。
漏消费：先提交offset后消费，有可能会造成数据的漏消费。
6.消费者事务
7.数据积压（消费者如何提高吞吐量）
